RE: WS-I and RPC

> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Sunday, January 05, 2003 10:58 PM
> To: 'Assaf Arkin'; 'Mark Baker'; 'Ugo Corda'; 'Champion, Mike'
> Cc: www-ws-arch@w3.org
> Subject: RE: WS-I and RPC
>
>
>
> > (And in this particular case I assume sendMeInvoiceDetails
> > does not return an invoice but actually sends it
> > asynchronously over SMTP or maybe by fax)
> >
> > arkin
> >
>
> Assaf,
>
> One option for implementing your use case would be to decouple the
> client and back office logic/process through a Web Queue resource. You
> could model your interface to the outside world as a set of queues. In
> that specific example, you would have a "RequestInvoiceDetail" queue.

Precisley.

> The client would post an XML document to the web queue and receive in
> response a URI. It could a later time do a GET on that URI to retrieve
> the "status" or post a cancellation request.

What's wrong with the server sending me the information asynchronously?

Most middleware deployements are there as stress relievers. They do so by
ascynrhonously sending messages. Since I don't know when the purchase order
is complete (unless I get asynchronous notification), the alternative would
be to keep polling for the state. That would stress the queue preventing it
from performing it intended function.

I would hate to be the one going to the customer and saying "I know you have
these systems that works by asynchronously delivering message, but we're
going to change it into polling. Please bear with us as your server crumbles
under the load". On the other hand I would be able to sell them more
hardware, routers and bandwidth. So maybe it's actually a good way to boost
the IT economy ;-)


> You might say/ask: "You have just morphed all the operations into
> queues...you have just moved the complexity to another layer". This is
> partially through specially is you focus only on development cost. The
> benefit of decoupling the system through a queue (with a generic
> interface) resides mainly in management and adaptability: A client can
> externalize the URI of the queue/services it is linked in. When a new
> version of the server service is available, you can publish a new queue
> and the client can be updated more easily. In the case you have services
> with multiple methods, each time you chance one method, it impacts all
> the other methods. If you are familiar with COM versioning you will
> realize that this is complex even within the scope of your desktop let
> alone a network or the web.

Queues are wonderful. And I definitely agree with your assesment that
decoupling the two systems by putting a queue in between is going to work
better. And since we've been doing it that way for years, I see no reason
why we can't keep on doing that.

But remember that queues excel when they can offload the work by performing
asynchronous delivery. They don't work all that well if you have to
constantly poll for messages. If I can deliver requests to the service
asynchronously, with a queue in the middle, and the service can deliver
responses to me asynchronously we get the best of both worlds. Decoupling
and scalability.

And we already have infrastructure to do that and a variety of business
applications built exactly that way. So why not make Web services an
interoperable layer on top of that?


> This might look like a very simple/basic design pattern but one that is
> important when you have to manage 1,000,000s of requests across 100s of
> services/queues.
>
> I believe that where REST is weak (and this is one of the reason why raw
> XML over HTTP is not mainstream) is that there are no standards for
> defining the schema of the data produced by a web queue resource, no
> programming abstraction for manipulating easily the XML messages that
> are sent back and forth and coordinating flow and transactions across
> asynchronous requests.

We have an argument here precisely about this point. One camp says that you
need a way to define the schema of the data, another camp argues that you
don't. REST seems to say nothing about this. In fact the issue is orthogonal
to REST. After all, we do use message schemas: when we talk about REST, HTML
comes to mind. I would not say REST is weak but then I do not claim REST
recommends that there should be no message schemas.


> Today's WSDL solves part of the problem but it does it by pushing
> developers towards RPC and encouraging them to build very fragile
> applications.

RPC style is not bad and RPC style does not prevent decoupling. The practice
by which most RPC style service definitions are derived is the problem. It's
simply that bad practice tends to produce RPC style service definitions.

What we are seeing in practice is that all too often developers take the
easy approach. Rather than defining an interface - whether RPC of document
style - that is decoupled from the implementation, they use tools that
produce a service definition directly from the implementation API.
Obviously, as the implementation changes so would every application that
needs to use this interface. Not a Good Thing(tm).

However, nothing precludes you from following best practice, defining an
interface that is decoupled from the implementation, performing mapping
between the abstract interface and the particular implementation, and using
RPC style to represent that abstract interface. WSDL does not say that RPC
has to conform to an API, bad practice makes it happen.

This reminds me of the time I learned how inefficient SQL could be. A fairly
simple query on an extermley large data set took over four hours to
complete. The customer was complaining at the sluggish performance of the
database. All of a sudden SQL didn't look that appealing. After taking a
close look at the query it was rewritten to perform in under 30 seconds.
(Which is not hard to do given a query plan) SQL wasn't to blame, it was a
developer that concluded the query was efficient by testing it over a small
data set.

Lesson learned: it's not WSDL's support of RPC that is to blame. It's the
fact that developers run WSDL generators directly on their object models to
generate a service definition that is fragile.

On the other hand, given that RPC can only express so many schemas, while
document style can express the same set of schemas or more, I find it had to
justify that WSDL needs to have RPC style. I certainly can't see why WSDL
1.2 can't live without it. At any rate you will need conversion from WSDL
1.1 to WSDL 1.2, so you might as well use that to recast an RPC into an XML
Schema group definition (not solving the problem, just avoiding the
redundancy).

arkin

Received on Monday, 6 January 2003 06:28:35 UTC