2011-01-11 9 views

risposta

3

Sicuramente sì. Questo modello SOA viene comunemente chiamato coreografia in cui un servizio Web viene elaborato e quindi trasferito il messaggio a un altro in una pipeline di elaborazione. Google e troverete alcune buone referenze.
Un altro caso può essere una ragione più tecnico come il routing, in cui si dispone di webservices frontend che instrada il tuo messaged ai vari servizi di back-end basati sulla politica di sicurezza, il contenuto, il ponte tecnologia diversa o protocollo di trasporto, ecc

5

non riesco a pensare a nessun motivo per cui non. Posso pensare a più motivi per cui un servizio potrebbe chiamare un altro servizio. Ho architettato e implementato più servizi che lo fanno. Sono anche a conoscenza di altre architetture che configurano questo tipo di sistema.

+0

voi non pensate che, considerando l'architettura dovrebbe essere tagliata verticalmente in modo appropriato, che ciò creerebbe un'architettura spaghetti? – iwayneo

+0

Penso che se gestisci le seghe in verticale attraverso i tuoi server, avrai altri problemi da affrontare. Penso anche che la pasta farà male agli interni. Hai esempi concreti di quali problemi potresti pensare? – Mark

+0

un problema che ho è che per esempio se sul mio sito web, chiamo un servizio wcf, che chiama un servizio wcf, che potenzialmente potrebbe chiamare un servizio wcf ... ecc. Ecc. – iwayneo

0

pensare all'obiettivo architettonico della "separazione delle preoccupazioni". invece di ogni servizio sapendo come fare tutto, può contare su altri servizi specializzati per funzionalità condivise

+0

Non sono affatto d'accordo. Uno dei principi fondamentali di Service Orientation è che i servizi sono autonomi. Stai creando dipendenze su altri servizi Web se "fai affidamento" su altri servizi specializzati per parti condivise di funzionalità. – user1431072

0

Ho qualche scenario diverso. Cosa succede se si desidera implementare il clustering del livello di servizio nella SOA? Ad esempio, supponiamo che il servizio di persistenza risieda su una macchina ed è responsabile della gestione di tutte le attività di persistenza nel cluster. Quindi, su un'altra macchina che richiede funzionalità di persistenza, è necessario connettersi solo a quella macchina (ignora il failover factor).

Al momento dell'accesso, se il servizio utente ha direttamente l'istanza del servizio di persistenza, non sarà possibile implementare il clustering a livello di servizio.

Abbiamo il nostro middleware SOA e ho chiamato direttamente il servizio gli uni dagli altri. Ma quando abbiamo implementato il clustering a livello di servizio utilizzando JMS/ActiveMQ, abbiamo affrontato il problema per quei servizi interconnessi.

3

La risposta a questo è come sempre "dipende ..." lasciami spiegare cosa intendo.

Chiamare un altro servizio in una SOA è ovviamente una cosa totalmente accettabile, è al centro di SOA essere in grado di comporre nuove cose dai servizi esistenti.

La parte più importante è il modo in cui si chiamano i servizi, si consideri un sistema SOA in cui più servizi collaborano in una chiamata alla catena chiamano ciascuno l'altro nell'ambito della transazione. Fare questo genere di cose senza un'attenta pianificazione avrà un impatto enorme sulle prestazioni del tuo sistema. La stessa catena di chiamate progettata utilizzando servizi partizionati ottimali con ambito nell'unità di lavoro corretta subisce meno.

Considerare la robustezza del sistema, in un'architettura tipica, un servizio tende a diventare più popolare di altri e finisce con l'avere molti altri servizi che lo chiamano. Un fallimento di questo servizio abbatte l'intero sistema a causa del fatto che tutti gli altri servizi dipendono dalla chiamata a questo servizio.

Considerare la differenza tra chiamate sincrone e asincrone, quando si utilizza cosa? Questo è l'impatto di ciascuno?

Come progettare e partizionare i servizi per limitare i costi di attraversamento del limite del servizio per ogni chiamata?

Un sacco di domande, ma se guardate in giro ci sono molti posti in cui trovare le risposte, suggerisco di iniziare con queste.

Ti suggerisco di leggere gli articoli di Thomas Erl e Roger Sessions, questo ti darà una solida idea su cosa sia la SOA.

Building a SOA

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss

WCF Service Performance

Problemi correlati