RE: A different binding example (was RE: Binding)

Mike,

> OK, how about we use an example other than the wretched 
> getLastTradePrice chestnut, one that involves coordination?  
> How about automating some bit of administrivia that we all 
> endure, like submitting expense reports, then getting back an 
> approval (at some future point in time), and a funds transfer 
> at some later point in time.  Assume the information 
> exchanged is sensitive,  and that authentication, encryption, 
> and non-repudiation should be practiced. Also, I'm submitting 
> the expense report over some flaky dialup connection in a 
> hotel somewhere, and I need to ensure that the report is 
> submitted exactly once.  
> 

I am happy to take a stab at it given that this use case is close to the
type of applications and flow our customers develop.

I would create a Web Queue resource (
https://www.collaxa.com/expensereport ). When a developer issue a GET on
that resource, it returns the XML Schema of the expense report XML
document that the queue accepts as input as well as meta information:
- request needs to include a signature header element for authentication
- request needs a callback header element (containing a callback URL).
- request needs a unique correlation set: rule on how the unique
key/message id
  can be computed using data element contained in the request.

Then as a developer I would use my favorite toolkit to craft the message
that fits into the web queue resource, connect over SSL with certificate
based authentication and POST my message to the web queue resource. The
request would return to me a URL either as a header element of 201 HTTP
location.

If I am not sure that the POST was received successfully, because the
connection failed and I did not get the URL, I would POST the same
message again. The server would use a correlation set to determine if
the message has already been received or not.

The server software, implemented in perl, Java, "manual fax" would
process the expense report asynchronously in the background. When it is
completed or if an exception occurs, it would post to the callback
location specified in the request, the confirmation or fault XML
document.

In the meantime, the client can invoke get on the referenceURL and get
the status of the processing.

That URL could also access POST with a cancellation request.

You could extend this implementation to layer a standard business
transaction or cancellation/compensation protocol.

I tried here to leverage the best of the Web:
- All important resources have URI.
- Resource expose a generic interface.

And the best of Web Services:
- XML Schema is used for defining the structure of exchanged
  XML documents.
- SOAP Headers are used to add security, conversation and 
  correlation capabilities.

What do you think?

Edwin

Received on Monday, 6 January 2003 17:20:55 UTC