What you just described, Udi, may sound like a Sales Aggregate Service, which is the facade itself. However, if you embed all mentioned events, reactions to them, and interactions with other services, you can compromise the principle of separation of concerns. In such case, I think, it is my clearer if you create a real 'empty' Facade Service (aggregate or process-based) and keep your Sales service concentrated on Sales' functions. This Facade Service may have its own UI or it may be represented by an aggregating UI, you choose the solution based on your conditions.
- Michael ________________________________ From: Udi Dahan <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, November 3, 2008 7:37:36 AM Subject: RE: [service-orientated-architecture] Re: Design options in SOA In the example I gave, the customer is placing the order only with Sales. The fact that it raises events, and receives events from other services isn’t seen by the customer. In short, you don’t need a façade – it’s not like there’s any explicit orchestration going on anyway. The way the customer would find out about their order is similar to what occurs with Amazon – you get emails. After your order’s been shipped, you get a tracking number into the Shipping service, you don’t need some kind of façade or to go through the order service. The “detailed internal business processes” are actually the description the actual technical events and data that flow through the various systems. Does that make sense? -- Udi Dahan - The Software Simplist From:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of htshozawa Sent: 02 November 2008 14:05 To: service-orientated- architecture@ yahoogroups. com Subject: [service-orientated -architecture] Re: Design options in SOA 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 service-orientated- architecture@ yahoogroups. com, "Udi Dahan" <thesoftwaresimplist @...> 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 OrderTentativelyAcc epted 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 InventoryAllocatedT oOrder 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 > InventoryAllocatedT oOrder event. > > > > Sales, which is subscribed to the InventoryAllocatedT oOrder 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: service-orientated- architecture@ yahoogroups. com > [mailto:service-orientated- architecture@ yahoogroups. com] On Behalf Of Dennis > Djenfer > Sent: 30 October 2008 16:20 > To: service-orientated- architecture@ yahoogroups. com > 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 > 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: 02/11/2008 09:51
