The answer is of course that you create a virtual service (or a facade) which presents a view to the customer but in itself doesn't actually deliver the RWE but acts as a proxy to the RWE.
Virtual services are the enterprise UI for integration. Steve 2008/11/2 htshozawa <[EMAIL PROTECTED]>: > 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 >> > >
