|
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
HEADLINES:
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.]
See also: UN/CEFACT CCTS
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. |
