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 20:42:33 UTC