Thanks for the detailed internal business processes. The question now is, if you were a customer ordering some parts from a company, do you want to contact sales, inventory, and shipping separately and keep track of transaction between these contacts or do you just to contact sales to just place an order? That is, have sales "fascade service" act as a fascade to internal business services.
H.Ozawa --- In [email protected], "Udi Dahan" <[EMAIL PROTECTED]> wrote: > > If we were to view this example in light of business services, maybe we'd > get a different perspective. > > > > Here's my 2c: > > > > Three business services, Sales, Inventory, and Shipping. > > > > In Sales, many applications and people may operate, including the person and > the application he used to submit the order. > > > > When the order is submitted and goes through all the internal validation > stuff, Sales raises an OrderTentativelyAccepted event. > > > > Inventory, which is subscribed to this event, checks if it has everything in > stock for the order. > > > > For every item in the order on stock, it allocates that stock to the order > and publishes the InventoryAllocatedToOrder event for it. > > > > For items/quantities not in stock, it starts a long running process which > watches for inventory changes. > > > > When an InventoryChanged event occurs, it matches that against orders > requiring allocation - if it finds one that requires stock, based on some > logic to choose which order gets precedence, it publishes the > InventoryAllocatedToOrder event. > > > > Sales, which is subscribed to the InventoryAllocatedToOrder event, upon > receiving all events pertaining to the order tentatively accepted, will > publish an OrderAccepted event. > > > > When Inventory receives the OrderAccepted event, it generates the pick list > to bring all the stock from the warehouses to the loading docks, finally > publishing the PickListGenerated event containing target docks. > > > > When Shipping receives the PickListGenerated event, it starts the yard > management necessary to bring the needed kinds of trucks to the docks. > > > > ** > > > > I could go on, talking about things like the maximum amount of time stock of > various kinds can wait to be loaded on trucks, subscribing to earlier events > to employ all kinds of optimization and prediction algorithms, having a > Customer Care service notifying the customer about what's going on with > their order (probably different for different kinds of customers and > preferred communication definitions). > > > > It turns out that many business domains map very well to this join of SOA > and EDA. > > > > At least, that's been my experience. > > > > Hope that helps, > > > > -- > > Udi Dahan - The Software Simplist > > > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Dennis > Djenfer > Sent: 30 October 2008 16:20 > To: [email protected] > 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/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 > > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.5/1756 - Release Date: 30/10/2008 > 07:59 >
