XML and Web Services In The News - 28 September 2006

Provided by OASIS | Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by Innodata Isogen


 The Relationship Between WS-ReliableMessaging and WS-Polling
 Eric Newcomer on Services Transaction Standards
 Updated W3C Working Drafts for Web Services Policy (WS-Policy) 1.5
 Introducing WSGI: Python's Secret Web Weapon
 Debate: The Future of WS-BPEL
 From EDI to UN/CEFACT: An Evolutionary Path Towards a Next Generation e-Business Framework

IETF Issues New RFC on XML-Based Format for Event Notification Filtering
Hisham Khartabil, et al. (eds), Proposed Standard Protocol
The Internet Engineering Task Force (IETF) has announced the release of a new Request for Comments (RFC) in the online RFC libraries, promoted to a Proposed Standard Protocol. RFC 4661 documents the "Extensible Markup Language (XML)-Based Format for Event Notification Filtering" and was produces by members of the SIP for Instant Messaging and Presence Leveraging Extensions (simple) Working Group. The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. The structure of the filter criteria is described using the XML schema. The filter criteria is presented as an XML document. The XML document contains the user's preference as to when notifications are to be sent to it and what they are to contain. The scope of the "when" part is triggering. The triggering is defined as enabling a subscriber to specify triggering rules for notifications where the criteria are based on changes of the event package specific state information, e.g., for the presence information document, the change in the value of the 'status' element.
See also: the IETF SIMPLE working group

Eric Newcomer on WS Transaction Standards
Eric Newcomer (Interviewed by Stefan Tilkov), InfoQ
In a recent blog post, IONA CTO Eric Newcomer wrote about the OASIS Transaction TC's progress in standardizing the Web services WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity specifications. Eric talked to InfoQ about this particular set of specifications, as well as the standardization process and the role of the big players in general. Q: "Would it be fair to say that WS-CAF and BTP are going to be obsoleted by this new activity, similarly to WS-Reliable Messaging succeeding WS-Reliability?" Newcomer: "... the background is different than WS-Reliability vs WS-Reliable Messaging. BTP was basically dead on arrival. Although it was supported by a very vocal minority, almost no one implemented it. WS-CAF has the same architecture as the WS-TX specs. All of these share a common root in the extended OTS spec we did for the OMG. Several of us who were involved in that are on the WS-TX committee, and two of us were on WS-CAF. The OMG spec was the start of factoring out the coordinator as a generic mechanism with pluggable protocols. WS-CAF started as a complement to WS-Transactions and still contains some things & WS-Context and the business process transaction protocol, among others & that WS-Transactions doesn't have. But certainly the influence of Microsoft and IBM is a big factor. These guys have been leading the web services specifications for several years. Even when WS-CAF was in OASIS and the WS-TX specs were not, customers asked for the WS-TX specs, not the WS-CAF specs. During the last 5-6 years Microsoft and IBM have gotten themselves into a leadership position with Web services for a variety of reasons, including market position. They have also tended to write the best specifications. One solution to the problem I believe you are bringing up, which is vendor domination of the standardization process, is for users to take more control. If you can shift the influence over standardization from what vendors are willing to invest to what users are willing to buy, we might see a change in the current dynamics around this. We might be seeing the start of this with SOA, since customers are starting to understand that SOA isn't something you can buy from a vendor.
See also: the OASIS WS-TX TC web site

Updated W3C Working Drafts for Web Services Policy 1.5
Asir Vedamuthu, David Orchard et al. (eds), W3C Technical Reports
W3C has announced the release of an updated set of Working Drafts for WS-Policy, produced by members of the W3C Web Services Policy Working Group. The "Web Services Policy 1.5 - Framework" document defines a framework and a model for expressing policies that refer to domain- specific capabilities, requirements, and general characteristics of entities in a Web services-based system. A "policy" is a collection of policy alternatives, a "policy alternative" is a collection of policy assertions. A policy assertion represents an individual requirement, capability, or other property of a behavior. A policy expression is an XML Infoset representation of a policy, either in a normal form or in an equivalent compact form. Some policy assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, QoS characteristics). "Web Services Policy 1.5 - Framework" provides a single policy language to allow both kinds of assertions to be expressed and evaluated in a consistent manner. However, "Web Services Policy 1.5 - Framework" does not specify policy discovery or policy attachment. Other specifications are free to define technology-specific mechanisms for associating policy with various entities and resources. The companion "Web Services Policy 1.5 - Attachment" defines such mechanisms, especially for associating policy with arbitrary XML elements, WSDL artifacts, and UDDI elements.
See also: the namespace document

Introducing WSGI: Python's Secret Web Weapon
James Gardner, XML.com
The recent Python 2.5 release features the addition of the Web Server Gateway Interface Utilities and Reference Implementation package (wsgiref) to Python's standard library. In this two-part article, we look at what the Web Server Gateway Interface is, how to use it to write web applications, and how to use middleware components to quickly add powerful functionality. Python is a great language for web development. It is straightforward to learn, has a broad and powerful standard library, and benefits from an active community of developers who maintain a range of XML and database tools, templating languages, servers, and application frameworks. In 2003, when the Web Server Gateway Interface specification was drawn up, the Python community also had one major problem. It was often easier for developers to write their own solutions to web-development problems from scratch rather than reusing and improving existing projects. This resulted in a proliferation of largely incompatible web frameworks. If developers wanted a full and powerful solution, they could use Zope, but many of them coming into the community in search of a lightweight framework found it hard to know where to start. Developers within the Python community quickly recognized that it would be preferable to have fewer and better-supported frameworks, but since each framework had its strengths and weaknesses at the time, none stood out as a clear candidate for adoption. The Web Server Gateway Interface (often written WSGI, pronounced "whiskey") was designed to bring the same interoperability that the Java world enjoyed to Python, and to go some way toward unifying the Python web-framework world without stifling the diversity. Most Python web frameworks today have a WSGI adapter, and most server technologies (Apache, mod_python, FastCGI, CGI, etc.) can be used to run WSGI applications, so the vision of web-application portability is fast becoming a reality.
See also: XML and Python

Debate: The Future of WS-BPEL
Stefan Tilkov, InfoQ Article
With the recently released public review draft of the WS-BPEL 2.0 specification, an interesting debate has started about the relative merits of BPEL in general and issues surrounding portability, interoperability, and compatibility. From among the several comments, Paul Fremantle says: "While I admit I haven't caught up with all the details of BPEL 1.1 vs 2.0 [...] I think there is clearly one significant advantage and one significant failure of BPEL. The advantage? The ability to visually map out business processes in a form that will be executed. The fact that there is a standard model for designing processes that can be shared with the business process owners graphically is absolutely the #1 benefit of BPEL. The disadvantage? The fact its almost impossible to write BPEL without a tool. We've seen many technologies fail because they were too complex to submit to a text editor. EJB 3.0 are a prime example of a technology that is too painful to handle without good tool support. I love tools, but having to download [more than] 100Mb of code to get started with BPEL is a big inhibitor to many developers. What will sway it? I think the key for many organizations is how well they implement the lower layers -- in an organization with many available services, BPEL will succeed. If a company has to first go and implement many many services before they have critical mass to start choreography, then thats going to be a significant inhibitor." Steve Hoffman: "The biggest challenges to the BPEL projects I do are: (1) service interfaces in flux; and (2) folks don't understand their own process requirements, even when simply accessing or replacing existing (often mainframe) logic. BPEL is definitely most useful to folks who already have their act together. As usual, the rich get richer..."
See also: the OASIS WSBPEL TC web site

From EDI to UN/CEFACT: An Evolutionary Path Towards a Next Generation e-Business Framework
Christoph Schroth, Till Janner, et al., SAP Technical Report
Modern e-Business frameworks have evolved from traditional EDI technology. The evolutionary development towards current e-Business stacks like RosettaNet led to an increased degree of integration and operational efficiency. Nevertheless, significant shortcomings still exist. Especially on the semantic level of data and process engineering further improvements are expected to harmonize the diversity and redundancy of existing e-Business stacks. UN/CEFACT's standardization efforts are a promising solution towards next generation e-Business frameworks. The authors intend to provide a picture of the future of e-Commerce by evaluating three cornerstones of e-Business standard evolution: EDI, RosettaNet and a novel combination of specifications issued by UN/CEFACT.... Conventional EDI Technology, except from the criteria of maturity, obviously stays back behind the other frameworks. The comparison between RosettaNet and UN/CEFACT is more complex: RosettaNet on the one hand, definitely scores higher on maturity and comprehensiveness of the stack as well as regarding the current degree of dissemination. RosettaNet offers a solution that spans the whole communication stack and, as opposed to UN/CEFACT, defines a technical framework for implementation. The most relevant advantage of the UN/CEFACT e-Business stack over its competitors is its capability to dynamically incorporate and adapt to individual user needs instead of providing a limited and pre-defined set of data and process descriptions. In the context of UN/CEFACT, both business data and processes can be assembled of basic building blocks that either already exist or are created and published by the users themselves during the modeling process. The main goal of UN/CEFACT is to establish sustainable business content which can be used by different technical frameworks. [Note: This paper was prepared for presentation at the Fifth Internation Conference on e-Business 2006 - NCEB 2006.]

XML.org is an OASIS Information Channel sponsored by BEA Systems, Inc., IBM Corporation, Innodata Isogen, SAP AG and Sun Microsystems, Inc.

Use http://www.oasis-open.org/mlmanage to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml for the list archives.

Bottom Gear Image