 No transfer mechanismXML is being used in the design of many new protocols (BEEP, SOAP, Jabber, JunoScript, JXTA, ...). Some of these developments are quite generic, and to that extent may leverage the generic capabilities of XML. But there is a concern that this use of XML means that XML-based protocols are becoming confused with XML itself. XML is just a generic data format: it has no inherrent concept of process, or state transfer, or other semantics that are associated with data transfer protocols. It seems that there is a proliferation of protocols based on XML. Why is this? Is it because there is a recently discovered need for all these new protocols. Is it because XML makes it easier to design such protocols? Or is it something about XML that spurs the need for such new protocols? I suspect it is a combination of all three of these. There is little more to say about the first point. Issues arising from the second point are well covered by [4] . Which leaves the third... Many traditional IETF applications involve independent communications between pairs of entitities. Such applications often fit the client-server pattern: one party initiates a transaction with another, and the protocol state machines guide the transaction to completion. Email, Web, News, printing, network management, and other applications can be characterized as a composition of many such simple interactions. By providing a uniform syntactic framework for application data, XML makes it easier to contemplate applications that are distributed among a broader range of components. We have already seen, over the past several years, the emergence of multi-tier client-server application frameworks where application-level transactions involve the cooperation of three or more different process components. As the number of interacting component types increases, the number of possible interaction patterns increases (I think exponentially), so the number of possible new protocols increases accordingly. The technology for such multi-tier deployments has been available for a long time in both standard and proprietary forms, but the take-up seems to have been quite limited. I speculate that the cost of developing these new complex applications has been too high, where all the parts need to be designed and integrated as a coherent whole. I further speculate that having a uniform platform for application data exchanges (i.e. XML), and generic tools to handle some of the application devekopment effort, has meant that a new breed of complex multi-component applications is becoming more popular. With that popularity comes new recognition of recurring application patterns and a desire to standardize them as a platform for even greater things to come. [4] S. Hollenbeck, M. Rose, L. Masinter, Guidelines for the Use of XML within IETF Protocols. http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-06.txt . |
