Bellen van de Orchestrating-laag in SOA?

Question

Bellen van de Orchestrating-laag in SOA?

De Service Oriented Architecture Principles site zegt dat Service Composition een belangrijk onderdeel is van SOA. Maar Service Loose Coupling is ook belangrijk.

Betekent dit dat de "orkestrerende laag" de enige moet zijn die mag bellen naar services in het systeem?

Als ik SOA begrijp, 'lijmt' de 'orkestrerende laag' alle services samen in één softwaretoepassing. Ik probeerde dat weer te geven in Fig.A en Fig.B.

Het verschil tussen beide is dat in figuur A de applicatie is samengesteld uit services en dat alle logica wordt gedaan in de "orkestrerende laag" (alle oproepen naar services worden alleen gedaan vanuit de "orkestrerende laag"). Op Fig.B. De applicatie is samengesteld uit services, maar één service roept een andere service aan.

Is de architectuur in Fig. B in strijd met het "Service Loose Coupling" -principe van SOA? Kan een service een andere service in SOA bellen? En meer in het algemeen, kan de architectuur in figuur A als superieur worden beschouwd aan die in figuur B in termen van service losse koppeling, abstractie, herbruikbaarheid, autonomie, enz.?

Mijn gok is dat de A-architectuur veel universeler is, maar het kan een aantal onnodige gegevensoverdrachten tussen de "Orchestrating-laag" en alle opgeroepen services toevoegen.

SOA service calls

1

toegevoegd 23 juni 2012 op 09:13 de auteur skanatek bewerkt 23 juni 2012 op 09:21

Bekeken: 7

de bron

ja ru fr es pt de ar

1 antwoord

de auteur Robert-Ryan. · Answer 1 · 2012-12-22T04:21Z

Assuming everything below services 1 and 2 is encapsulated behind their contracts then they are loosely coupled. However B does not leverage the orchestration layer's ability to free up Service 1. There is no clear right or wrong of A vs B but there are trade-offs. Fig A requires some more development effort because details of what B returns to A need to extracted up to the orchestration layer - and if there are lists of data involved then B needs to allow a collection of parameters to be passed in as criteria. This however allows svc 1 to know nothing about svc 2. So if the services are owned and managed by two different teams then A is going to allow these team to work autonomously. For example, if svc 1 is a customer information service (CIS) and svc 2 is a payments service then the orchestration layer can stitch CIS data together with Svc 2 to return a list of customer names and their most recent payment data. With Fig A an in-memory join is used in the orchestration layer to do the stitching. Then clients call the orchestration layer. With B the client can call directly into service 1, but if you start to allow services to call into each other you can end up with a nasty dependency graph including the possibility for re-entrant calls. If your team is small and owns both svc 1 & 2 then they can track these dependencies. However when you have different teams you might find the dependencies are not easily known or well managed in B.