- From: Hao He <Hao.He@thomson.com.au>
- Date: Thu, 9 Jan 2003 11:55:14 +1100
- To: "'Christian Hoertnagl'" <hoe@zurich.ibm.com>, www-ws-arch@w3.org
- 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:hoe@zurich.ibm.com] Sent: Thursday, January 09, 2003 12:41 AM To: www-ws-arch@w3.org 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
Attachments
- text/plain attachment: InterScan_Disclaimer.txt
Received on Wednesday, 8 January 2003 19:54:11 UTC