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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
