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.)
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? - Michael ________________________________ From: Dennis Djenfer <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, November 1, 2008 3:34:00 AM Subject: Re: [service-orientated-architecture] Design options in SOA Thanks for the discerning answer, Michael. The Order Service and the Inventory Service are autonomic self-contained services. I actually had a case recently that was quite similar to my example (surprise!) and my first decision was to go with design option C because I believe that's the most loosely coupled solution, with the most self-governed services (in a business sense), but with a dependency to the technolog used for pub/sub. However, in the end I decided to go with option A, partly because of the reason you have suggested, i.e. it could be difficult to maintain option C. Another strong reason was that the IT-organization was not ready for option C. They had been touted the message from vendors about ESB and BPM solutions with central control for a long time and couldn't imagine another kind of solution. The company in question did have an installation of IBM Messsage Broker, so option C wouldn't need any additional investment in infrastructure, but I guess culture is harder to change than technology. In the end it is very hard to foresee all of the consequences with regard to option A versus option C, but I do think option C have a slight advantage with respect to more self-governed service which will help business agility. // Dennis Djenfer Michael Poulin wrote: 5776.<SPAN id="misspell-13" class="mark" >indd</SPAN> Interesting and very practical question, Denis. Here is what I would do: 1) I need to identify what kind of services the Order Service and Inventory Service are. That is, if they are aggregate/process services or the basic level business services that are autonomic self-contained (stand alone) services: a) if they are aggregate, I have to continue the full research of the options b) if they are basic services, then option B cannot work - services may not know about each other; only A and C options left 2) Option B represents strong coupling between services while Order Service might be reused for different types of orders not necessary related to stock, i.e. for ordering delivery or reimbursement/ return 3) Just in case, for option A, I would split "process/applicatio n" into the part that accepts external request for order-to-cash and the part that executes 4) the choice between A and C options depends on existing environment - technologies, tools, skills, policies , management, customs, etc. In particular: a) if one takes C over A, there is still a need to have special intermediary that would support event propagation (unless service are not coupled via event again) b) option A represents one place for business logic changes but existing process systems may require to tie the implementation of process actions - services - with the process, i.e. to limit the service flexibility by creating additional dependant - the process. However, the process may be designed with a dynamic invocation of the action implementation via shared meta-data semantics and ontologies. I know only one product that supports such dynamic invocation of services - ... c) option C does not limit the services but represents a 'distributed process control', which, in general, more difficult to maintain. That is, you have to control those who is listening for the event; if a change in the business logic required, some listeners may snick from the modification or even become orphan (if the control is not strong). Plus, security issue is also here - 'whether a listener has rights to listen to concrete event'. All together, even if the event-based architecture may be elegant, it requires several additional efforts to have and keep it right as well as available resources for it. - Michael ________________________________ From: Dennis Djenfer <[EMAIL PROTECTED] se> To: service-orientated- architecture@ yahoogroups. com Sent: Thursday, October 30, 2008 2:20:15 PM Subject: [service-orientated -architecture] Design options in SOA There are different design choices in a SOA, even when you already have identified the services. I have a simple example that I would like to share: Imagine a ordet-to-cash process. One part of that process is to register an order. Suppose we have two services, Order Service and Inventory Service. The task is to register the order and make a corresponding reservation of the stock level. I would be pleased to have the groups view on the following 3 design options (A, B, C): A. 1. The "process/applicatio n" sends a message (sync or async) to "registerOrder" on the Order Service. 2. The "process/applicatio n" sends another message (sync or async) to "reserveStock" on the the Inventory Service. B. 1. The "process/applicatio n" sends a message (sync or async) to "registerOrder" on the Order Service. 2. The Order Service sends a message (sync or async) to "reserveStock" on the the Inventory Service. C. 1. The "process/applicatio n" sends a message (sync or async) to "registerOrder" on the Order Service. 2. The Order Service publishes an "orderReceived" event. 3. The Inventory Service subscribes to the "orderReceived" event . // Dennis Djenfer ________________________________ No virus found in this incoming message. Checked by AVG - http://www.avg. com Version: 8.0.175 / Virus Database: 270.8.5/1758 - Release Date: 10/31/2008 8:22 AM
