RE: programming model for document-style SOAP

Hao He <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
Message-ID <686B9E7C8AA57A45AE8DDCC5A81596AB046AE259@sydthqems01.INT.TISA.COM.AU>
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:[email protected]]
Sent: Tuesday, January 14, 2003 9:02 PM
To: [email protected]
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 <[email protected]> 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.
InterScan_Disclaimer.txt (text/plain, 438 B)
=====================================================================
WARNING -This e-mail, including any attachments, is for the 
personal use of the recipient(s) only.
Republication and re-dissemination, including posting to news 
groups or web pages, is strictly prohibited without the express
prior consent of
Thomson Legal & Regulatory Limited
ABN 64 058 914 668
=====================================================================
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.