Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fwd: Re: What does SOAP really add?
 Hello Paul, Paul said: > You haven't described why this is a better way. To me, sending the > template document to the server is a waste of effort and bandwidth. You > could ask the server for the *values* and it could send you XML that you > would combine with your template on the client side using XSLT. Using > this strategy you do not even have to build a template document and you > don't have to send it to the server. All of your templating logic lives > in the XSLT and all of your server-side data is URL-addressable. > Didier replies: OK I accept the challenge ;-) give me some more time and I'll write a more elaborate thesis/document. Here are my first initial though elements and use case. I'll work more on criteria to judge an architecture (like for instance its scalability, its capacity to absorb innovation, its robustness, its security, etc...) and use these criteria to position the solutions proposed. a) assumptions: - The service's "time cost" to prepare the template is irrelevant. The customer wants a service and knows that it will takes time. The other party serves the customer and probably charge for it or consider it as an added value to the customers. - if the same template is used over and over, the customer can post it on the server and this latter can re-use the template for the next transactions. However, due to the implied cost, the server my impose a limit on the number or the size of the templates stored. - The server allows ad-hoc transactions and is as much as possible stateless, since it is more economical and less costly to develop (i.e. no state management). - The server is not aware of the document's format the customer requires, only how to fill the placeholders. - the document returned may be a rendering document but may also be a *data* only document. For instance, an invoice or an account statement (i.e. hierarchical constructs) composed from several tables. The overall format of the invoice or the account statement is provided by the client. b) constraints: - If the query takes too much bandwidth, then it can be compressed on the client side and made HTTP 1.1. compliant. - idem for the reply - The client is not necessary external to the corporation boundaries. - The server' transactions could be restricted to internal usages and external agent not allowed to access it. c) use case: An ad hoc client (i.e a client) given access right to its account perform a transaction (i.e. send a query template), for instance an account statement query template. The account statement is the same as used internally but different than the one used by the vendor. Instead of imposing to the vendor to know the idiosyncratic (from the point of view of the vendor) format, the client provides its own. The returned document is not packaged as a rendering format but is structured according to the XML specifications and represents an account statement (i.e. a virtual hierarchical database fragment). The client stores the document locally and transform it into HTML (or SVG for superior rendering) with an XSLT template. d)Results: - reduced cost from the part of the vendor - potential cooperative process between business partners - the rendition is quite versatile since we use XSLT. This allows to display the result for human consumption in several formats. - the client has a document (i.e. an account statement) that could be locally processed or stored for future usage. temporary conclusion (until I write a more elaborate document): - With the a posteriori web (i.e. the actual web used by million of people) we can realize this scenario. Let's call that as in statistics the null hypothesis or H0 - With the a priori web (i.e. the theoretical web proposed) we cannot realize this scenario. Let's call that the alternative hypothesis or N1. Off course Paul as you noticed I took an utilitarian approach judging the positions on the basis of their utility, cost, versatility and with the capacity to absorb innovations. My last criteria is quite important if we do not want to repeat the errors of the past and fall into the dark ages arguing about the sex of angels :-) Actually based on H1, the use case is not part of the web. According to H0 it is and is probably already in place in several corporations - and no, I am not the author all these implementations :-) cheers Didier PH Martin 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
