HTTP based asynchrony

Mark,

Thank you for your insight.

David,

If we consider "protocol independence" as bug rather than a feature,
what do you think of Dave's suggestion for implementing asynchrony?

<<<<
MONITOR http://example.org/stockquote/BigCo HTTP/1.1
Host: example.org
Reply-To: http://foo.example.org/BigCoWatch
[blank line]
<monitor xmlns="http://example.org/2001/06/subscribe">
      <Notify>PRICE</Notify>
      <Notify>VOLUME</Notify>
      <Notify>TIMESTAMP</Notify>
      <When>
        <Price range="GreaterThan">100</Price>
      </When>
</monitor>

response;

HTTP/1.1 201 Created
Location: http://example.org/monitors/23434234
<<<

This would be enough to address the use case below. You mentioned last
time that the correlation id (here encoded as the location of the
response) should not be a uri but a data structure that allows the
server to be stateless. Could you please provide an example of what you
mean?

Thank you,

Edwin

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Mark Baker
> Sent: Sunday, July 28, 2002 4:55 PM
> To: Edwin Khodabakchian
> Cc: www-ws-arch@w3.org
> Subject: Re: Views on Web Services... - Let's take an example
> 
> 
> 
> Hi Edwin, sorry for the delay.
> 
> On Tue, Jul 23, 2002 at 12:32:42AM -0700, Edwin Khodabakchian wrote:
> > Use Case/Requirements:
> > -----------
> > Company S is a hightech manufacturer who wants to expose 2 
> services to 
> > his customer. The first service is about validating a 
> customized BOM 
> > and the second service is about providing a quote to a 
> customized BOM.
> > 
> > The implementation of these services, behind the scene is very low 
> > tech. The received information is saved in a file, printed 
> and faxed 
> > to the department that fullfils the service. The reponse is 
> faxed back 
> > to the web operation department where it is digitized and 
> sent back to 
> > the customer. For the purpose of this example, we are not trying to 
> > streamline the private implementation of this process. We are just 
> > trying to package it and make it available so that it can be easily 
> > used by the customer of Company S.
> > 
> > Given their implementation, both services are asynchronous 
> and might 
> > take anywhere between 1 day to 5 days to complete depending on the 
> > complexity of the BOM. Customer should be given visibility into the 
> > progress on the request. [[Some interesting would be change request 
> > and cancellation, but again to keep the example simple we 
> will ignore 
> > those more advanced requirements]].
> 
> Ok.  I'd model this as two resources, one for each service.  
> The first service is likely safe, so it's in that odd zone 
> where it should probably be done with GET, but may also need 
> the use of POST's ability to carry a body.  But the 
> asynchronocity aspect of the operation suggests that POST 
> would be best.
> 
> I'd manage the asynchronicity by making my interface return 
> either a 201 (Created) or 202 (Accepted) response, depending 
> upon some subtleties that we needn't get into at this point.  
> Then either the Location header (for a 201), or the entity 
> body for a 202 would return with a URI that identified the 
> future results of the operation.  A GET on that would return 
> the results of the operations, eventually.
> 
> > About 5 months after the initial release of the service, 
> the procedure 
> > of Company S changes. Now in order to perform the 
> validation service, 
> > it needs both a BOM and some kind of deadline information. 
> Company S 
> > wants to update/evolve the service while minimizing impact on the 
> > customer that are using the service.
> 
> By that I assume you mean that it will still validate BOMs 
> without the deadline info.  If so, not a problem.  Presumably 
> the BOM-standardization folks have a new version of the 
> schema with the deadline information in it.
> 
> > 1. I would start by modeling all the piece of information that are 
> > exchanged by Company S and a customer of the services: BOM, 
> > ValidationReport, Quote, Deadline would all be defined using XML 
> > Schema. The benefits of Schema is that it is a language 
> neutral way to 
> > model the
> > data: I have tools to design it, I can share it with people, I have
> > tools to parse it, transform it, manipulate it. It seems 
> that both REST
> > and non-REST people agree on that point.
> 
> Sounds about right.  Lots of REST proponents prefer RDF for 
> modelling their data, because it actually offers a modelling 
> language rather than just a syntax, but sure...
> 
> > 2. As an architect, I need to select a representation for 
> the services 
> > that are exposed. Personnaly, the right abstraction is a queue: 
> > something that receives and buffers messages (not a resource, not a 
> > business object). I see several advantages to using a queue (and I 
> > would use 1 queue for each service).
> > * It is simple: Through HTTP post you can deliver a typed 
> message to 
> > the queue and get a reference uri that you can later poll 
> for status.
> 
> Exactly.
> 
> > * It is reliable: The application that process the queue can (1) 
> > process the input at it own pace and (2) go offline for maintenance 
> > without any dammage.
> 
> Yep.
> 
> > * It can easily evolve: Each queue is represent one operation. 
> > Therefore when one of the service evolves, the other one is not 
> > impacted. It is easy to perform side-by-side versioning: you can 
> > create a new queue and let the initial one phase out or create a 
> > dispatcher based on the structure of the message. The one operation 
> > approach already works for servlets (service()), MDB ( 
> onMessage() ), 
> > it enforces isolation and coarse grain communication.
> 
> Mostly, yes.
> 
> > Developer Point of View
> > ------------
> > One of the very important aspect of Web Services is that they are 
> > built for developers: meaning that a service is not 
> interesting until 
> > it is integrated in another application and that will require 
> > programming which means that the abstraction needs to be developer 
> > friendly. The problem is that queues are not! If you look 
> at a JMS app 
> > you will see what I mean: queueA.post( messageA );
> > queueB.post( messageB );
> > Etc...
> > Everything is a queue or a message: no real type checking, 
> intellisense
> > :-), compilation etc.. Things that make development intuive 
> and easy to
> > read.
> > 
> > XMLSchema is a first step in the right direction because it allows 
> > messages to be typed: The schema can be used to generate language 
> > specific representation of the XML message: it is no longer 
> a message 
> > but a BOM which means friendly API and type cheking.
> > 
> > As far as the method name is concerned, my vote would go to 
> limit the 
> > number of verbs queues understand: post to put a message to 
> the queue
> > get to get the status 
> 
> Ok.
> 
> FWIW, the principal value of the generic interface that REST 
> provides is not in the number of methods in that interface, 
> but in their generality.  REST can actually support an 
> arbitrarily large interface, as WebDAV demonstrates.  The key 
> is that all methods are generic to all resources.
> 
> > some verbs for cancellation, confirmation, compensation 
> based on what 
> > TX model gets adopted
> 
> I won't repeat myself by stating my reasoning for this is a 
> bad idea on Internet.
> 
> > Some verb some getting the WSDL of the queue so that the client can 
> > make sur that it is operating against the right XMLSchema 
> (This would 
> > be the equivalent of link checking in the web services world)
> > 
> > I think that REST has proven that limiting the number of verbs is 
> > good.
> > 
> > Where I would be unRESTful is that I would put the 
> method/verb in the 
> > SOAP message so that the same message could be delivered 
> through HTTP, 
> > SMTP, JMS, etc..Once queued, it should be irrelevant how 
> the message 
> > was delivered. I would try to respect HTTP and use GET when quering 
> > the status and POST in the other case.
> 
> I understand this position.  It is quite common with Web 
> services that people think that being "protocol independant" 
> is a feature.  I consider it a bug.
> 
> > Like Eric said, some of the challenge and where I would expect the 
> > architecture and infrastructure to help me is: how to I advertise
> 
> Just write the URI on bathroom walls, etc.. 8-)
> 
> > and
> > implement correlation/callback,
> 
> What I described above goes part way towards that.  Callback 
> is pretty straightforward with an HTTP extension like I 
> described at the bottom of this message;
> 
http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0024

> same for security (authentication,
> encryption and non-repudiation of the messasge) and transaction.

Yep.  HTTP already has an autentication model, and can use several
encryption mechanisms, including XML Encryption.  Transactions are, IMO,
one of the very few areas requiring new standards.

> Transaction is more complex because the use case are not as clear and 
> it is not as crutial because it can be managed by exception.
>
> But correlation/callback and security are painfully missing.

It's funny how much still appears to be missing when "protocol
independance" becomes a goal. 8-) 8-(

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Sunday, 28 July 2002 21:26:34 UTC