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:
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/application"
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]>
*To:* [email protected]
*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
