Newletter Sign Up
Posts on the
Design Decomposition Blog
Iridium Satellite Collision in Space
You might have seen the recent news reports about the collision between U.S. and Russian communication satellites. The U.S. satellite was one of the Iridium satellites. What wasn’t reported and you probably don’t know is that an object database management system (ODBMS) is an important part of the Iridium system. Even though ODBMSs are a [...]
February 13, 2009
(The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services
I am now also posting on the Cutter Blog. My initial posting is (The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services. It is a response to Anne Thomas Manes’ SOA is Dead; Long Live Services on her blog at the Burton Group.
January 9, 2009
Atomicity
The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition: A task (for business process diagrams) or a process (for data flow diagrams) is atomic if every input relates to every output [...]
December 3, 2008
Well-Formed Business Process Diagrams
My last posting referenced the criteria for a well-formed business process diagram mentioned in Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. I am going to expand on their criteria to create a more comprehensive definition of a well-formed business process diagram. To start, here are three criteria from [...]
November 18, 2008
Recent Business Process Modeling Books
I recently received two new books on business process modeling. Both books looked interesting because they had great titles. As it turns out, one book is great and the other not so good. The not so good book is Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. There are [...]
October 9, 2008
The Design Decomposition Blog
is written by Doug Barry.
Let people know
Email page link Print page Delicious Digg StumbleUpon More destinations
Get HTML code
>>Link code for page >>Link code for site

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:

  1. An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility. 
  2. 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. 
  3. 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. 
  4. 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) (new window). 

Furthermore, the following two general requirements must be met by the work produced by this Working Group:

  1. 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. 
  2. 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.

Organization: W3C

More information: XMLP page on the W3C website (new window)

Related content for: XML Protocol (XMLP)

More detail for the current topic: XML Protocol (XMLP)

More on the general topic: Messaging specifications

Read more free articles on this site

There are nearly 400 pages of articles on this site with over 130 pages on Web services and service-oriented architecture.

Search this site for more articles

Custom Search

Browse this site for more articles

Click on the topics below to browse the articles on this site. You can see more detail by clicking on the arrows. This highlights the location of the current article: XML Protocol (XMLP).