471,049 Members | 1,859 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,049 software developers and data experts.

Async design question - Request IDs

When designing an asynchronous service-based system, generally speaking
whose responsibility is it to determine when a duplicate request is sent -
the system hosting the service or the feeding systems. Are there any best
practices when it comes to determining duplicate requests in an asynchronous
system.

For example, lets say you have an OLTP system that tracks inventory with
several other applications feeding into the OLTP system. The feeding
applications send messages defined by the OLTP via MSMQ. NOTE: I know that
Txn MSMQ will guarantee delivery once, I am not addressing dups in this
sense. I am speaking more generally about determining dups whether or not
MSMQ is used. Technically speaking, this service could be a web service in
which I wouldn't get the delivered once guarantee.

Here is the dilemma:
#1
Should the feeding system - lets an application that allows for inventory
adjustments - be responsible for tracking its own "pending" adjustments
(ones that have not actually been processed by the OLTP). In other words,
the OLTP allows for a generic "FeedingSystemID-External ID" that it will
check on each request. If the incoming request has the same ID as a
previous one it will be considered a DUP by the OLTP. In this scenario the
"dishing" out of request ID is delegated to the feeding systems, leaving the
OLTP "dumb" in this manner.

#2
The other scenario is that the OLTP has a certain set of unique conditions
it checks before considering a request to be a DUP. In other words, the
OLTP checks the RequestDate, SKU and some other criteria for each request to
determine if the request is a DUP. This scenario puts full responsibility
on the service (in this case OLTP).

#2 seems like the better approach but I was curious if there are any best
practices when it comes to determining duplicate requests when designing an
async system.

Thanks,
Kevin
Nov 16 '05 #1
1 1272
#2 sounds best to me Kevin....

The reciever of the message(pay load) can check the for
authenticity\duplicate\invalid data etc, you wouldn't want the sender to
check for any of these (may be the sender might want to do some simple
checking) but to check for anything important then I would let reciever do
this and return a structured response to acceptance of the message (pay
load).
HTH

Ollie
"Kevin C" <kc@noneya.com> wrote in message
news:eR**************@TK2MSFTNGP10.phx.gbl...
When designing an asynchronous service-based system, generally speaking
whose responsibility is it to determine when a duplicate request is sent -
the system hosting the service or the feeding systems. Are there any best
practices when it comes to determining duplicate requests in an asynchronous system.

For example, lets say you have an OLTP system that tracks inventory with
several other applications feeding into the OLTP system. The feeding
applications send messages defined by the OLTP via MSMQ. NOTE: I know that Txn MSMQ will guarantee delivery once, I am not addressing dups in this
sense. I am speaking more generally about determining dups whether or not
MSMQ is used. Technically speaking, this service could be a web service in which I wouldn't get the delivered once guarantee.

Here is the dilemma:
#1
Should the feeding system - lets an application that allows for inventory
adjustments - be responsible for tracking its own "pending" adjustments
(ones that have not actually been processed by the OLTP). In other words,
the OLTP allows for a generic "FeedingSystemID-External ID" that it will
check on each request. If the incoming request has the same ID as a
previous one it will be considered a DUP by the OLTP. In this scenario the "dishing" out of request ID is delegated to the feeding systems, leaving the OLTP "dumb" in this manner.

#2
The other scenario is that the OLTP has a certain set of unique conditions
it checks before considering a request to be a DUP. In other words, the
OLTP checks the RequestDate, SKU and some other criteria for each request to determine if the request is a DUP. This scenario puts full responsibility
on the service (in this case OLTP).

#2 seems like the better approach but I was curious if there are any best
practices when it comes to determining duplicate requests when designing an async system.

Thanks,
Kevin

Nov 16 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Shawn Meyer | last post: by
6 posts views Thread by gabriel.landais | last post: by
4 posts views Thread by Bob Badger | last post: by
6 posts views Thread by Shak | last post: by
3 posts views Thread by Angus | last post: by
7 posts views Thread by =?Utf-8?B?Q2FybG8gRm9saW5p?= | last post: by
3 posts views Thread by Giulio Petrucci | last post: by
1 post views Thread by APA | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.