The A option assumes a predefined process; when it starts, it may not necessary to react to any events except the ones embedded into its own business rules. Option C is triggered by events whenever they happen. To propagate a message caused by the event, I may use any federated messaging sub-systems, even across corporate boundaries, sender and receiver do not need to share the same pub/sub domain.
In the option B, the services are coupled by knowing about each other (OK, in single direction). Transaction management for distributed services is different from the Object transaction management: you still can use distributed 2PC but it is relatively complex and not widely supported; for services we better use Compensation Transaction that allows services to stay independent. - Michael ________________________________ From: htshozawa <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, November 1, 2008 1:44:07 PM Subject: [service-orientated-architecture] Re: Design options in SOA --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > I do agree with you, Dennis about A and C. I am not sure that option C requires sharing the same pub/sub domain because we always have federation of message brokers with adapters for different communication channels (LAN, WAN, etc.) > If you going to transform event to service at the boundary, isn't it the same as A? > I am a bit surprised with Ozawa-san's comment on the option B, however. I still do not get why external client is better with coupled services. Any comments? > Transaction management. It's easier when using async services. :) H.Ozawa
