Strati e livelli di SOAP

Question

Strati e livelli di SOAP

#1 da (2 voti)

5

Sto progettando il back-end di un servizio web SOAP e ho una domanda su come sto pensando di farlo.

Ho intenzione di andare con un semplice design a strati che consiste in 3 livelli separati.

Layer 1 -> Layer 2 -> Layer 3

Livello 1: implementerà l'interfaccia scheletro SOAP, quindi questo sarà il punto di ingresso principale della mia applicazione. Questo livello estrarrà i dati dalla richiesta SOAP e li passerà al livello della business logic come oggetto business. Restituirà gli oggetti business dal livello della business logic con cui popolerà una risposta SOAP.

Livello 2: Livello della logica aziendale che implementa la logica aziendale dietro il servizio web. Verranno passati i dati dal Livello 1 e interagiranno con il Livello 3, il livello DAO.

Livello 3: livello DAO che preformerà le operazioni CRUD sul mio DB.

Con la compilazione di oggetti di risposta SOAP nel mio codice, l'implementazione potrebbe essere un po 'caotica in Layer 1, quindi ho trovato le seguenti 3 opzioni.

Opzione 1: tre livelli sono sufficienti, altri livelli sarebbero eccessivi. Gli oggetti SOAP saranno sempre disordinati, passaci sopra.

Opzione 2: crea un livello aggiuntivo tra i livelli 1 e 2. Questo livello prende i dati dalla richiesta SOAP, popola un oggetto business che poi passerà al livello della logica aziendale. Ciò manterrebbe i metodi in Layer 1 puliti e in ordine. Sarebbe simile a questo:

Layer 1  ->  SOAP Request   ->  Layer 1.A  ->  Business Object  ->  Layer 2
Layer 1  <-  SOAP Response  <-  Layer 1.A  <-  Business Object  <-  Layer 2

Opzione 3: non creare altri livelli. Basta creare un oggetto utility con un metodo che accetta una richiesta SOAP e restituisce un oggetto business. Potrei quindi passare l'oggetto business al Layer 2. Lo stesso oggetto utility potrebbe quindi essere usato nel Layer 2 per passare una risposta SOAP al Layer 1. O questo approccio sfoca le linee e rende il mio design meno modulare?

design design-patterns soap

posta T-Pane 25.02.2014 - 16:49

fonte

1 risposta

Leggi altre domande sui tag design design-patterns soap

Non so come capire il tipo di jolly in Java Gestori di eventi di oggetti Global vs Individual

score 2 · Answer 1

Dipende da cosa potresti condividere il layer 2 con. Se la maggior parte dei sistemi backend operano su oggetti business, ha molto più senso convertire i dati in un oggetto business prima di trasferirli agli altri sistemi. Sia la conversione che il semplice pass-through funzioneranno, ma in assenza di requisiti rigorosi suggerirei quale sia più concettualmente locale ai sistemi attuali. Questo è principalmente per motivi di manutenibilità.

L'inclusione di un livello aggiuntivo dipende se si prevede di includere più operazioni / endpoint in una singola chiamata. Il livello aggiuntivo disaccoppia la richiesta SOAP dalle operazioni, consentendo mix / match flessibili e invii di richieste basati sull'identificazione senza metterli nel livello del servizio web. Può essere molto utile se non è possibile trattare tutte le richieste allo stesso modo, per qualsiasi motivo (diversa origine, bilanciamento del carico, ecc.). Se non ti aspetti affatto, dovresti essere in grado di progettare per il caso limitato per chiamata e nix del livello extra.

In entrambi i casi, consiglierei di trasformare il processo di trasformazione in un oggetto di utilità. Non ti costa molto, e trovo / uso il nostro front-end per l'utilità xml dappertutto. (Abbiamo una pletora di formati / canali front-end che accettiamo, ma consolidiamo in un unico formato xml da usare internamente.)