Dennis,
> when the Order Service receives a message with an order that is above a certain value, it will send a message to a queue that the Customer has a new status. While that may seem reasonable in this specific example, customer status logic often is much more involved. As such, putting that in the Order Service seems suspect. Orders could alternatively publish an OrderAccepted event - to which the CRM subscribes. As that event arrives, and the CRM does its logic, it in turn could publish a CustomerStatusChanged event. This would avoid the cross-service transaction issue. > the Order Service has a cache of Customer data. That may be necessary for Orders autonomy (ability to accept orders even if CRM momentarily unavailable), yet should not change the allocation of responsibility for business rules. -- Udi Dahan - The Software Simplist From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Djenfer Sent: 19 September 2008 02:59 To: [email protected] Subject: Re: [service-orientated-architecture] Re: SOA over a Domain Model Colin, I didn't say that I find updates to multiple (entity) services rare. What I sad was "Updates to multiple services in one work unit is something that I try to avoid. Usually it is not necessary". Your example with an Order Service and a Customer Service where an Order over a certain value would promote a Silver Customer to a Gold Customer is a good example. There are many ways to solve this problem, but you need to define the business rule somewhere and then you need to enforce it, either in the same place as it's defined or somewhere else. Lets say that the above business rule is enforced by the Order Service (but it could also be enforced by a service in a higher layer or by the the order-to-cash process). Do we need to update both the Order Service and the Customer Service as one unit? It depends, but in most cases I don't think it's important that the Customer gets updated with the new status promptly. Hence, when the Order Service receives a message with an order that is above a ceratin value, it will send a message to a queue that the Customer has a new status. The queue manager will eventually deliver the message to the Customer Service. If the queue manager should fail (which happens very rarely) there must be routines in place to handle this. It could involve manual routines. How does the Order Service know that the Customer should be updated with a new status? Because the Order Service has a cache of Customer data. The Customer Services publishes information about changes that other services and applications could be interested in. The Order Service subscribes to this information. // Dennis Djenfer Colin Jack wrote: One of these services would probably be a Customer Service. In the modeling effort we would identify the core properties of the Customer object, and other objects that are related to the Customer and belongs to the same Service. This core set of properties would be the first version of the Specification of the Customer Service. However, it would be the demand for customer information in strategic processes that would be the trigger to actually go ahead and build the Customer Service. I think I understand now, seems like you have a more lightweight and more flexible alternative to what Erl is suggesting. I was however surprised in your other post when you said that you find updates to multiple (entity) services are rare though, I'd have thought it happens relatively regularly. For example if a pending credit check fails we will update the credit check itself and probably the related Customer, likewise if the Customer places (and pays for) a large Order we might update the Customer to indicate they should get special treatment. In both cases you've probably got two entities (or two entity services) being updated in one "transaction", how do you manage this? -Colin Jack ------------------------------------ Yahoo! Groups Links _____ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1679 - Release Date: 2008-09-18 17:03 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1672 - Release Date: 18/09/2008 17:03
<<image003.jpg>>
<<image004.jpg>>
