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

> > I would create a Web Queue resource (
> > https://www.collaxa.com/expensereport ). When a developer
> 
> How critical is the Web Queue resource to the scenario?  It
> would be nice, for the purposes of the WSA document, to have 
> a "pure" REST approach sketched out. [Not that I mind the 
> plug for your product :-) ]

I believe that a basic Web Queue resource could be implemented in a pure
REST approach. For example:
 - GET returns WSDL
 - POST validates the posted XML document, computes correlation id and 
   verifies that request is not duplicate, queues it and returns a URL:
   For example: https://www.collaxa.com/expensereports/exr-10002

The queuing could be done using file system, relational database, XML
database or existing messaging services depending on the needed
performance, reliability, searchability and cost trade off. Collaxa does
not actually sell any of those products so I do not have a sales hat on
here. 

> 
> > 
> > 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 "correlation set" is mentioned as a bit of an
> afterthought.  It would be nice if it were more closely 
> integrated into the sketch of the solution. Would the 
> correlation set be, or be based on, the URI returned from the 
> original POST?  
>

Let's imagine that the expense report XML document is a complex
structure and it contains a 'email' field and a 'period' field . As the
designer of the service, I can choose that the union of those 2 keys
creates a unique key and therefore assume that if 2 messages are posted
with this key, then the second one should be ignored. As the designer of
the service, I can publish that information as part of the profile of my
web queue resource. (Note: BPEL4WS also uses correlation sets).

Please note that the correlation id computed using the correlation set (
"edwink@collaxa.com" , "2002/15/01" ) does not need to be related to the
URL (https://www.collaxa.com/expensereports/exr-10002) returned by the
server.

Another way to solve this problem if there is no way to create a unique
key based on the posted data structure would be to require the client to
post as part of the request header a unique correlation id (Similar to
what DavidO/BEA what promoting in the WS-Conversation spec). We/Collaxa
would prefer this approach but we have grown to learn that this is not
always doable in legacy environment where the notion of correlation id
does not exist explicitely.

I hope that it makes sense.

Edwin

Received on Tuesday, 7 January 2003 00:06:21 UTC