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
<<image001.jpg>>
<<image002.jpg>>
