Todd Biske wrote:
> Just because it's internal, doesn't mean we don't need it sent
> reliably. Chances of a failure are probably far less, but if it's a
> mission critical order processing system, reliability is important.
>
> One thing that must be considered, however, is that the whole thing
> must be reliable. It's only as reliable as it's weakest point.
> Therefore, if I use reliable messaging for the front end to talk to
> the order entry system, but my front end is web-based, I still have
> issues to deal with. If the browser request when I hit "Place Order"
> times out, I have no idea what the state of the system is anymore.
> In this case, designing the interfaces so they handle repeat
> submissions properly is very important.
The power of idempotent service interfaces is something that a lot of people
still are struggling to understand. One of the other important issues is
tracking. If the front end is a web interface, it's much better to create a
submission record, close to the web servers up front that can track with the
users experience there, and then forward that record through the network.
Using
sequence/tracking numbers to understand when data is missing is also important.
It might be perfectly valid for a user to cancel their order and a tracking
number to not be used. But, you should be able to have all of the users state
progressions and tracking numbers together so that you can understand what
really happened when their order was not processed.
Transactional behavior can be created without transactions. Transport
protocols
such as TCP use sequence numbers to make sure all data is received and ordered
appropriately. When you design streaming or flow based services, you should
think about order of delivery and guarenteed delivery. But, only the entities
in the system that need these attributes should be a part of implementing those
semantics. The intermediate parts of the system can provide logging and
tracking of flow, but burdening them with those details only makes the system
more fragile, not more dependable.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> 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/
