Steve, I remember seeing that blog post of yours and at the time it further strengthened my belief in the cohesiveness of business services.
-- Udi Dahan - The Software Simplist > -----Original Message----- > From: [email protected] [mailto:service- > [EMAIL PROTECTED] On Behalf Of Steve Jones > Sent: 28 November 2008 11:32 > To: [email protected] > Subject: Re: [service-orientated-architecture] Re: van Hoof on Self- > Contained Messages > > Udi, > > Have a look at the Value Network stuff from the likes of Verna Allee, > they've moved on from Value Chains into a world that fits business > services even better. > http://service-architecture.blogspot.com/2008/03/networked-economies- > require-services.html > > Steve > > > 2008/11/27 Udi Dahan <[EMAIL PROTECTED]>: > > David, > > > > > > > > Billing has no implied knowledge of Fulfilment when it publishes the > > CustomerBilled event. Any number of subscribers can listen to that > event. > > > > If Fulfilment needed to know the order information in order to later > handle > > the CustomerBilled event, it would save that information as it came > in on > > the OrderAccepted event from Sales in its own database - so there are > no > > external dependencies. > > > > > > > > You are correct about the race condition, though. > > > > > > > > Let's say that Billing was extremely fast and more highly available > than > > Fulfilment. Billing could have received the OrderAccepted event, > processed > > it, and published the CustomerBilled event before Fulfilment had > received > > the OrderAccepted event. In short, the CustomerBilled and > OrderAccepted > > messages could be out of order in Fulfilment's queue. > > > > > > > > What would Fulfilment do when trying to process the CustomerBilled > message > > when it doesn't have the order information? > > > > Well, it knows that the world is parallel and non-sequential, so it > does NOT > > return/log an error, but rather puts that message in the back of the > queue > > to be processed again later (or maybe in some other temporary holding > area). > > This enables the OrderAccepted message to be processed before the > > CustomerBilled message is retried. When the retry occurs, well, > everything's > > OK - it's worked itself out over time. In the case where we retry > again and > > again and things don't work themselves out (maybe the OrderAccepted > event > > was lost), we move that message off to a different queue for > something else > > to resolve the conflict (maybe a person, maybe software). If/when the > > conflict is resolved (got the Sales system / messaging system to > replay the > > OrderAccepted event), the conflict resolver returns the > CustomerBilled > > message to the queue, and now everything works just fine. > > > > > > > > As all of this is occurring, the only thing that's visible to > external > > parties is that it happens to be taking longer than usual for the > > OrderShipped event to be published. In other words, time is the only > > difference. > > > > > > > > We may have another Business Activity Monitoring service which is > listening > > to all of these events and notices that the end-to-end time for that > order > > has exceeded a certain threshold, so it publishes it's own event > > TimeToProcessOrderExceededThreshold. Our Customer Care service may be > > subscribed to that which would internally have someone in the call > center > > call the customer and apologize ahead of time for their order being > delayed > > and offer them some kind of gift/future discount/whatever. > > > > > > > > Notice that in all of this, we don't need to have a single central > > system/DB/MDM/whatever that contains everything, that everybody is > dependent > > upon, that everything uses at runtime to make decisions, that becomes > a > > bottleneck, that is costly to scale, etc. This SOA/EDA combo is > robust in > > the face of failures and temporal issues and allows for the full > autonomy of > > each service Business Service, in multiple dimensions - design time, > run > > time, technology choices, and business requirements. > > > > > > > > If it sounds like this style is not very congruent with BPM style > business > > analysis ("A business process is a collection of related , structured > > activities that produce a service or product that meet the needs of a > > client"), that's true. It eschews the activity oriented thinking for > looser > > event-oriented thinking. The Value Chain model is a business analysis > style > > that fits much better (and they'd probably tell you the BPM guys were > wrong > > to begin with, but I'm not jumping into that pond). BTW the > activities in > > the value chain are a very good match to business services - the > syntactical > > similarities to BPM activities are misleading. > > > > > > > > Well, it turns out that I can't talk about self-contained messages > without > > getting into business services without getting back to EDA. > > > > > > > > Anyway, hope that clears something (anything?) up. > > > > > > > > -- > > > > Udi Dahan - The Software Simplist > > > > > > > > From: [email protected] > > [mailto:[EMAIL PROTECTED] On Behalf Of > David > > Stanek > > Sent: 27 November 2008 00:36 > > To: [email protected] > > Subject: Re: [service-orientated-architecture] Re: van Hoof on > > Self-Contained Messages > > > > > > > > On Wed, Nov 26, 2008 at 1:49 AM, Udi Dahan > > <[EMAIL PROTECTED]> wrote: > >> > >> In my example of EDA/SOA (from a previous email), I described a > Sales > >> service, a Fulfilment service, and a Billing service. > >> > >> Sales publishes an OrderAccepted event when it accepts and order, > >> containing > >> all order information. > >> > >> Both Fulfilment and Billing are subscribed to this event. > >> > >> After Billing has billed the customer, it publishes a CustomerBilled > event > >> containing all billing information and the Id (or multiple Ids) of > the > >> order(s) billed. > >> > >> [This is not a self-contained message as it doesn't contain the full > order > >> information] > >> > >> Fulfilment is also subscribed to the CustomerBilled event, and only > ships > >> orders to customers that have been both accepted and billed. > >> > >> Even though Fulfilment doesn't receive the order information in the > >> CustomerBilled event, it can easily do the correlation between the > events > >> using the order Ids. > >> > >> > >> > >> In this case, the non-fully-self-contained message doesn't lead to, > or > >> imply > >> any architectural problems. > >> > > > > The way I understood the original post is that the data reference was > > to a different system. So passing an order number that would be used > > to look up the order in another system. > > > > A customer ID might be a better example. If you only pass an ID in a > > ObtainSomeResource event message you could hit a timing issue. When > > the customer requested the resource they were entitled to it. > However, > > by the time the message was processed their subscription was no > longer > > valid. The service processing the ObtainSomeResource message would > > look up the customer and deny the request. Or maybe the customer's > > address or email changed. > > > > In your example the full message was sent out earlier and probably > > stored by the Fulfillment service. The CustomerBilled message then > > triggers the Fulfillment service to act on a prior message. > > > > The thing that stands out in your example is that the Billing service > > has some implied knowledge about the Fulfillment service. It knows > > that either the Fulfillment service is subscribed to the > OrderAccepted > > message or knows how to lookup the order. Can this be a bad thing? > > > > -- > > David > > http://www.traceback.org > > > > No virus found in this incoming message. > > Checked by AVG - http://www.avg.com > > Version: 8.0.176 / Virus Database: 270.9.10/1812 - Release Date: > 26/11/2008 > > 20:53 > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.9.10/1812 - Release Date: > 26/11/2008 20:53
