RE: programming model for document-style SOAP

Hao He <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
Message-ID <686B9E7C8AA57A45AE8DDCC5A81596AB046AE23A@sydthqems01.INT.TISA.COM.AU>
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.  Is this "separation of concerns" promoted by IBM?
 
Hao 

-----Original Message-----
From: Christian Hoertnagl [mailto:[email protected]]
Sent: Thursday, January 09, 2003 12:41 AM
To: [email protected]
Subject: programming model for document-style SOAP



Greetings, 

1st: I enjoy the currently interesting discussion in this group about REST
and whether prior knowledge resides in XML schemas and/or WSDL and all that
... I'm new to this so this is good stuff. 

2nd: Can you please advise me on the following: given one uses
document-style SOAP, what kind of programming model and tools would one
adopt? What are the current best practices?  (I guess use of document-style
SOAP will coincide with asynchronous invocation in many cases.) 

With RPC-style SOAP there are WSDL-to-stub generators and all that; I guess
a document-centric approach requires sg. different and less "brittle" like
perhaps callback handlers for certain (optinal) parts of SOAP documents. I
guess having each and every client/server do all the document processing
purely on the DOM level would not cut it. 

Thanks, 
Christian
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.