April 20, 2012, 02:55:50 PM
News: Welcome, charter members, to the CDCL Forum!
Pages: [1]
Print
Author Topic: Multiple Request Coordination  (Read 1052 times)
JimLookabaugh
Participating Member
**
Posts: 31


View Profile Email
« on: February 14, 2008, 02:11:42 PM »

It is not difficult to imagine that, through some orchestration of one or more business processes, multiple requests of a Gatepoint's services may be desired to be effectively coordinated as a virtual, single request.  For a hypothetical example, let's assume the disclosure of a "loan origination request message" is orchestrated together with the disclosure of a "co-signer credit check reply message".  Further assume that this business process orchestration has a requirement that both disclosure service requests must be made of the same Gatepoint instance.  To meet the orchestration requirements, which are actually beyond the scope and beyond the responsibility of the Gatepoint, the orchestrator may need to closely coordinate these two disclosure requests.  As a convenience, I propose the Gatepoint could offer its clients a means by which multiple requests could share a single execution context.

By use of "Gatepoint transaction IDs" (e.g. GUID) and use of a time threshold, a window of opportunity could be given to a Gatepoint client such that multiple requests could be coordinated and share a common Gatepoint execution context.  An interface could be exposed by the Gatepoint that would allow a client to request preparedness on the part of the Gatepoint for such coordination.  This interface would allow the client to pass a collection of unique "transaction IDs" for messages yet to be given to the Gatepoint in forthcoming disclosure service requests.  Gatepoints would not be required to comply with such requests for coordination.  But if a Gatepoint should agree, it would respond with a time period during which its agreement would be honored.

During this time period, the Gatepoint's first encounter per transaction ID with any message from that client, where the transaction ID can be found in the previously supplied collection, would share a common execution context with all other such messages meeting these requirements.
Logged

-Jim Lookabaugh
WIJIS Security Analyst, State of Wisconsin
JimLookabaugh
Participating Member
**
Posts: 31


View Profile Email
« Reply #1 on: April 28, 2008, 05:35:37 PM »

This approach is somewhat complicated, but its advantage is that the entire context of multiple documents, multiple user contexts, and multiple client contexts are not sent over the wire at the same moment.  An alternative approach which would send everything together in a single transaction (thus avoiding the transaction ID management and the accurate management of context information across transactions) is described by WIJIS in its internal documentation.  The WIJIS concept is as straightforward as I've described here - simply sending everything together rather than over separate transactions.
Logged

-Jim Lookabaugh
WIJIS Security Analyst, State of Wisconsin
Pages: [1]
Print
Jump to: