RE: WS-I and RPC

> sendMeInvoiceDetails is an object-specific operation.  If you want that
> to happen, you need to do so within the constraints of the architecture.
> In that case you might invoke GET through an intermediary which returns
> the GET response over email or fax.

Kind of a trap. Specific to what object?

Use your imagination for a second. There's no invoice object in the system
yet because my order has not been completely processed. There's a purchase
order pending. I've concluded that I want to receive the invoice details. So
after performing sendMeInvoiceDetails there's also an object representing my
request to receive invoice details. With my address.

Once there's also an invoice object, hopefully I will be recieving my
invoice (assuming the service is not lying). So the service is actually
performing an operation that is decoupled form any specific object. And yes
it does use a few objects to get the job done, and so does an HTTP server.
But it does not represent an object-specific interface.

In contrast, if I was to retrieve the state of the object through a get
operation (SOAP POST, HTTP GET, FTP RECV) that would be an object-specific
operation.


> e.g.
>
> connect to some-intermediary.org 80 and execute;
>
> GET http://example.org/invoice/2384923849732 HTTP/1.1
> Reply-To: mailto:foo@bar.org
>
> where "Reply-To" would be understood and processed by the intermediary
> (of course, SOAP's processing model would come in handy there, but hey,
> it's a GET 8-).

I like instant gratification. Unfortunately, it's not always possible. A lot
of the patterns you will see in business scenarios are based on
asynchronosity. You request that something be done, it could be a retrieval
of information, and it will be done but it might take some time.

Of course this could also be recast in reverse. I could give my URI and the
service could HTTP PUT the invoice to my URI when it's done. But that would
be an object-specific method, i.e. it will require an object to operate on.

arkin


>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>

Received on Monday, 6 January 2003 04:07:51 UTC