XML Protocol (XMLP) provides simple protocols that can be ubiquitously deployed and easily programmed through scripting languages, XML tools, interactive Web development tools, etc. The goal is a layered system which will directly meet the needs of applications with simple interfaces (e.g. getStockQuote, validateCreditCard), and which can be incrementally extended to provide the security, scalability, and robustness required for more complex application interfaces.
Specifically, the XML Protocol Working Group is chartered to design the following four components:
- An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility.
- A convention for the content of the envelope when used for RPC (Remote Procedure Call) applications. The protocol aspects of this should be coordinated closely with the IETF and make an effort to leverage any work they are doing, see below for details.
- A mechanism for serializing data representing non-syntactic data models such as object graphs and directed labeled graphs, based on the data types of XML Schema.
- A mechanism for using HTTP transport in the context of an XML Protocol. This does not mean that HTTP is the only transport mechanism that can be used for the technologies developed, nor that support for HTTP transport is mandatory. This component merely addresses the fact that HTTP transport is expected to be widely used, and so should be addressed by this Working Group. There will be coordination with the Internet Engineering Task Force (IETF), see Blocks Extensible Exchange Protocol (BEEP).
Furthermore, the following two general requirements must be met by the work produced by this Working Group:
- The envelope and the serialization mechanisms developed by the Working Group may not preclude any programming model nor assume any particular mode of communication between peers.
- Focus must be put on simplicity and modularity and must support the kind of extensibility actually seen on the Web. In particular, it must support distributed extensibility where the communicating parties do not have a priori knowledge of each other.
The Working Group shall start by developing a requirements document, and then evaluate the technical solutions proposed in the SOAP/1.1 submission against these requirements. If in this process the Working Group finds solutions that are agreed to be improvements over solutions suggested by SOAP 1.1, those improved solutions should be used.
More information: XMLP page on the W3C website
Related Articles for XML Protocol (XMLP)
More detail for the current topic: XML Protocol (XMLP)
- Asynchronous Application Service Protocol (ASAP) for SOAP
- Message Service Specification (MSS)
- Representational State Transfer (REST)
- RosettaNet Business Message
- Web Distributed Data Exchange (WDDX)
- Web Services Addressing (WS-Addressing)
- Web Services Eventing (WS-Eventing)
- Web Services Notification (WSN)
- Web Services Reliability (WS-Reliability)
- Web Services Reliable Messaging (WS-ReliableMessaging)
The Savvy Manager's Guide
Douglas K Barry is also the author of a book that explains Web Services, service-oriented architecture, and Cloud Computing in an easy-to-understand, non-technical manner.
Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (Second Edition)
by Douglas K Barry with David Dick
This is a guide for the savvy manager who wants to capitalize on the wave of change that is occurring with Web Services, service-oriented architecture, and—more recently—Cloud Computing. The changes wrought by these technologies will require both a basic grasp of the technologies and an effective way to deal with how these changes will affect the people who build and use the systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of both the changes that we are now seeing and ways to deal with issues created by those changes.