Views on Web Services... - Let's take an example

Following up on the discussion between Eric and Mark, I would like to
suggest that we try to address a specific use case and see if that can
create convergence.

I will first try to describe the requirements and then try to apply the
suggestions offer by both camp to suggest a solution/design.

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]].

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.

Design
----------
Now lets take the hat of an architect at Company S in charge of
designing and delivering the application that implements this service.
What do we need to do and how does the Web Service Architecture or a
Service Oriented Architecture help us get there.

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.

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.
* 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.
* 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.

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 
some verbs for cancellation, confirmation, compensation based on what TX
model gets adopted
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.

Like Eric said, some of the challenge and where I would expect the
architecture and infrastructure to help me is: how to I advertise and
implement correlation/callback, same for security (authentication,
encryption and non-repudiation of the messasge) and transaction.

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.

Please feel free to suggest alternative designs!

Best,

Edwin