5776.indd
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
