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.