Stile SOA - Condivisione dei dati

Question

Sto considerando un'architettura SOA per un set di servizi a supporto di un'azienda per la quale mi sto consultando, in precedenza abbiamo utilizzato l'integrazione del database in cui ogni applicazione individuava ciò di cui aveva bisogno da un database MS SQL condiviso e funzionava con esso ecc. Avevamo varie app che si integravano con il database dei mostri incluso l'accesso java, .net e microsoft, c'era integrità referenziale in quanto tutto era strettamente accoppiato.

Sono un po 'confuso su come supportare la condivisione dei dati tra servizi.

Consente di usufruire del Servizio prodotto che si trova sulla base di un database prodotto fornito dal grossista ogni mese. Costruiamo un modello di dominio e lo inseriamo nel database con Hibernate o quant'altro, per quanto riguarda l'impianto il prodotto è un grande oggetto grafico, date le informazioni fornite dal grossista sul prodotto.

Ora diciamo che il servizio di revisione, il servizio prezzi, il servizio di spedizione e il servizio stock si iscriveranno a ProductUpdated, ProductAdded, ProductDeleted. Il problema è che ogni servizio richiede solo una parte o alcune parti delle informazioni sul Prodotto. La spedizione potrebbe richiedere solo le dimensioni e il peso. Il prezzo potrebbe richiedere solo l'ID del prodotto, il costo all'ingrosso, lo sconto sul volume, il prezzo effettivo fino ad oggi. La revisione potrebbe richiedere l'ID del prodotto, il nome del prodotto, il produttore.

È prassi normale pubblicare solo l'intero prodotto (adatto a contratti specifici non abbonati, ad esempio ProductUpdated, e uno schema adatto - che rappresenta tutto il grafico dell'oggetto prodotto) e consentire agli abbonati di mappare tutto ciò di cui hanno bisogno sui loro modelli di dominio (o diamine fare quello che vogliono con, potrebbe anche non avere un modello di dominio) ...

O mentre scrivo questo sto pensando forse: Pubblica

Product Service ProductAdded messaggio (non incluse dettagli prodotto solo un ID del prodotto e forse un timestamp)

Prezzo su bscribes a ProductAdded e pubblica RequestPricingForProduct messaggi

Product Service Pubblica messaggio ResultForPricingForProduct

Hmm .. sembra un po 'meglio ... ma ci si sente come sto costruendo il contratto per il servizio del prodotto sulla base di quello di altri servizi che posso identificare e ciò di cui avranno bisogno, forse in futuro il servizio XYZ richiede qualcosa di diverso. Mi fermerò qui perché penso che sia più chiaro dove sono confuso ... forse quanto sopra funzionerà perché dovrei esporre un modo per restituire ciò che dovrebbe essere pubblico, giusto.

Qualsiasi commento o direzione molto apprezzato. Scusa se questo sembra cotto a metà.

Answer 1

Ero di recente nella sua posizione. Il problema con l'esposizione diretta dell'oggetto sottostante attraverso il servizio è che si aumenta l'accoppiamento tra i livelli, e diventa poco utile utilizzare un'Achitecture orientata ai servizi. Non sarebbe possibile modificare questi oggetti o regole aziendali senza influire sul servizio web.

Sembra che tu sia sulla strada giusta. Se si desidera seriamente separare i layer, il modello più comune consiste nel creare un nuovo set separato di classi di messaggi solo per il servizio Web, potenzialmente per ciascun servizio, e tradurre gli oggetti interni avanti e indietro.

Per un esempio su come impostare il livello di servizio in questo modo, vedere il modello "Interfaccia di servizio". Sul lato client del servizio, c'è uno schema opposto chiamato "Gateway di servizio".

L'Application Architecture Guide 2.0 ha un intero capitolo dedicato ai tipi di decisioni che state prendendo (http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines). Vorrei scaricare l'intera guida.

Ecco la parte più pertinente per voi. Per farla breve, se si prende il tempo per creare nuovi metodi di grana grossa, e gli oggetti dei messaggi-based, si ritroverà con un servizio molto migliore web:

Considerate le seguenti linee guida quando si progetta un interfaccia di servizio : Considerare l'utilizzo di un'interfaccia a grana grossa per le richieste batch e ridurre al minimo il numero di chiamate sulla rete. Progettare interfacce di servizio in modo tale che le modifiche alla logica aziendale non influiscano sull'interfaccia. Non implementare regole di business in un'interfaccia di servizio. Considerare l'utilizzo di formati standard per i parametri per garantire la massima compatibilità con diversi tipi di client. Non fare supposizioni nella progettazione dell'interfaccia sul modo in cui i client utilizzeranno il servizio. Non utilizzare l'ereditarietà degli oggetti per implementare il controllo delle versioni per l'interfaccia di servizio.

Answer 2

In realtà penso che la soluzione a questo problema è NON condividere i dati. SOA significa che i dati sono di proprietà di un servizio - è l'autorità tecnica di tali dati. Suggerisco di leggere alcuni articoli di Pat Helland, come ad esempio Data On The Inside, Data On The Outside.

L'unica cosa che deve essere condivisa tra questi diversi servizi è la chiave primaria - il ProductId nel tuo esempio. Altrimenti, per ogni servizio, i dati che devono essere coerenti con le transazioni vanno insieme.

Non è necessario essere un "Prodotto". Ogni servizio può avere una visione diversa del prodotto nel loro servizio. Per il servizio Prezzi, hai un prodotto e un prezzo. Per il servizio di revisione, un productId e una recensione. E così via.

Dove questo inizia a confondere le persone è come visualizzare questi dati nell'interfaccia utente se proviene da tutti questi servizi disparati. Come si può mostrare un elenco di recensioni per un prodotto che ha il nome del prodotto dal ProductService e il testo di revisione da ReviewService?

La risposta è quella di comporre l'interfaccia utente da tutti i diversi servizi. Ottenere il prodotto dal servizio del prodotto e ottenere i dati di revisione dal servizio di revisione e combinare i dati nell'interfaccia utente.