RE: programming model for document-style SOAP

hi, Anne,

I agree that either approach is ok and one does not have to use either if
they don't want to.

The difference (or question to explore) is:" how much value does the RPC
model and proxy generation provide when compared with the cost they incur? "

My point is that at coarse grained level, the RPC approach is not cost
effective.

In your PO example, the additional cost of using SOAP for the submitPO
method and generating proxy is just far greater than POSTing a PO XML
directly to the server.

Processing the received XML is a different issue. I agree that you may be
able to generate some code for processing the XML if there is a stable
processing pattern (not XML parsing) available.  However, due to the nature
of extensibility of XML (and the nature of business), the incoming PO will
evolve and so will the processing pattern itself.  This would make code
generation quite difficult if not impossible.  


Hao

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Wednesday, January 15, 2003 1:00 PM
To: Hao He; 'Christian Hoertnagl'; www-ws-arch@w3.org
Subject: RE: programming model for document-style SOAP


Hao,

I don't think that the difference between the RPC and DCA programming model
in Web services is quite so cut and dried. While I agree with you that
method-based RPC invocation is fine grained, I disagree that you can't do
(or that it's inconvenient to do) coarse-grained invocations with an
RPC-style programming model. You can use late binding with an RPC-style
programming interface, and you can design your client and server to deal
with variable content. For example, you can design your input and output
messages to support the <choice> construct, directing the request off to
different methods based on the information supplied. The point is, you can
let the tools generate a lot of the code for you. As long as you have schema
definitions for your message structures, I don't see why you need to write
your own parsing code.

Let's say that you have an order processing application. It accepts purchase
orders, and depending on what's being ordered, the purchase order might be
in a variety of formats. You create a WSDL description for this service, and
the PO is described in XML Schema, using <choice> to indicate the variable
formats. In your service you map each of the choices to a different method
for processing, but the individual methods aren't exposed through the Web
service API. There's just one API, which is submitPO. You should be able to
generate a client proxy from that WSDL file and then invoke operations on
that proxy (e.g., submitPO). It should generate the appropriate SOAP message
structure based on the object graph of your PO.

Now, or course, if you prefer to do your own XML processing, that's up to
you. My point is that you don't have to if you don't want to.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hao He
> Sent: Tuesday, January 14, 2003 6:48 PM
> To: 'Christian Hoertnagl'; www-ws-arch@w3.org
> Subject: RE: programming model for document-style SOAP
>
>
> The central problem here is the level of granularity.  IMO, RPC is more
> suitable for fine grained processing while Document-Centric Approach (DCA)
> is more suitable for coarse grained processing.  Yes, you can use either
> approach to do both but the cost would be higher than necessary.
>
> With a RPC approach, by its nature of tight coupling, it makes sense to do
> early bindings, things such as stub generation with strong typing.
>
> By contrast, you want to do late bindings with DCA.  A typical design
> pattern here is layering, with each layer being specialized in solving one
> particular problem.
>
> Hao
>
>  -----Original Message-----
> From: Christian Hoertnagl [mailto:hoe@zurich.ibm.com]
> Sent: Tuesday, January 14, 2003 9:02 PM
> To: www-ws-arch@w3.org
> Subject: RE: programming model for document-style SOAP
>
>
>
>
> Anne, Hao,
>
> I agree with Anne's reply indicating that the choice between RPC or
> document-style does not mandate a particular client programming style. The
> WSDL spec e.g. specifically says that "This information _may_ be used to
> select an appropriate programming model".
>
> However, while I understand that you can do document-style messaging using
> normal stubs, I'm also interested in scenarios where the messages
> have more
> variable format (an unknown number of documents, each with optional
> attachment, say) than is typical for RPC (three integer parameters, say).
> For handling sg. like this an approach with callback handlers (like Hao
> seems to indicate as well) seems like an attractive option to me. I'd be
> curious to learn more about existing approaches esp. of this kind.
>
> Regards,
> Christian
>
> Hao He <Hao.He@thomson.com.au> wrote on 01/09/2003 01:55:14 AM:
>
> > We are using a strategy pattern in our implementation: you have
> a generic
> > reader which decomposes the document to various parts that can
> be handled
> by
> > various handlers.  Perhaps  this is similar to your handler as
> well?  The
> > cool thing about this approach is that each handler only needs to under
> one
> > aspect of the document.
>
>