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] <mailto:thesoftwaresimplist%40gmail.com> >
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
<<image003.jpg>>
<<image004.jpg>>
