Hi,
Michael answered this but will add my 1cent worth of opinion.
It depends on what level of "service" you're thinking of defining.
Option B creates a strong dependency between the 2 services which may 
seem bad, but if you're thinking about creating a service for your 
customer, you probably want your customer just to place an order - 
not register and then reserve a stock.

If the services are to be used within an organization, separating the 
services may allow services to reused.

Option C creates a strong dependency between the two services that 
they have to be in the same pub/sub domain.

In general, I'll consider the followings:
B: if services are for a general public
A: if services are for within an organization
C: if services are for a specified domain.

H.Ozawa

--- In [email protected], Dennis 
Djenfer <[EMAIL PROTECTED]> wrote:
>
> 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/application" sends a message (sync or async) to 
> "registerOrder" on the Order Service.
>   2.  The "process/application" sends another message (sync or 
async) to 
> "reserveStock" on the the Inventory Service.
> 
> B.
>   1. The "process/application" 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/application" 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
>


Reply via email to