Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Adding Traditional Middleware Features
Because Web services are based on markup languages, the solution to adding traditional middleware functions to Web services has to be derived from extending the document-processing model on which XML is based rather than by extending any of the existing distributed computing technologies. That's why Web services are different, and that's why people have a hard time understanding them. They are neither really true extensions of existing document processing technology nor extensions of existing distributed computing concepts, but a marriage of the two—or perhaps a mapping of the two remains a better word for it.
If in your pre-Web services life you have understood one world or the other, you are unfortunately in for a challenge as you must now understand the other world or the worlds will not be bridged, and Web services will fail to reach their potential due to irreconcilable differences.
The program that receives and interprets the Web services message is not the same program as the one that executes the logic being requested, or at least there must be an initial stage of parsing the XML, inputting the associated Schema, validating the document, and extracting the data from the document.
Web services are an attempt to modify document-processing technologies for distributed computing concepts. This is naturally resulting in a lot of conflict, disagreement, and education as people from markup language and distributed computing backgrounds come together to try to reach agreement on how this can reasonably be done.
For example, the SOAP, WSDL, and UDDI specifications define Web services to use HTTP POST to transfer documents to their destination. A typical markup language interaction starts with an HTTP GET instead, and carries the method or operation name within the URI for greater efficiency.