|
XML and Web Services In The News - 17 August 2006
Provided by OASIS |
Edited by Robin Cover
This issue of XML Daily Newslink is sponsored by Innodata Isogen
HEADLINES:
Industry Partners Release WS-MetadataExchange Version 1.1
BEA, CA, IBM, et al., Public Draft Release for Review and Evaluation
Seven industry partners have published an updated version of the "Web
Services Metadata Exchange (WS-MetadataExchange) specification. The
contributors include BEA Systems Inc., Computer Associates
International, Inc., International Business Machines Corporation,
Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and webMethods.
This August 2006 Version 1.1 release updates the previous version
published on September 1, 2004. "Web services use metadata to describe
what other endpoints need to know to interact with them. For example,
WS-Policy describes the capabilities, requirements, and general
characteristics of Web services; WSDL describes abstract message
operations, concrete network protocols, and endpoint addresses used by
Web services; XML Schema describes the structure and contents of XML-
based messages received and sent by Web services. To bootstrap
communication with a Web service, this specification defines how an
endpoint can request the various types of metadata it may need to
effectively communicate with the Web service. In response to the
request, this specification defines an encapsulation that contains the
three different ways the metadata may be returned. First, the metadata
itself may be simply included in the response. Second, a URI may be
returned, to which an HTTP GET can then be sent to retrieve the metadata
from that location. And third, a WS-Addressing Endpoint Reference of a
WS-Transfer Metadata Resource may be returned, to which a WS-Transfer
Get may be issued to retrieve the metadata. This specification also
defines how a WS-Addressing Endpoint Reference can be modified to
include this encapsulation.
See also: the 2004 specification
W3C Improving XML
Paul Krill, InfoWorld
The World Wide Web Consortium (W3C) this week published new editions
of four core XML data exchange specifications, featuring corrections
for known errata and clarifications where potential misunderstanding
could have occurred, W3C said. Stability provided by these XML
specifications underlies a steady increased in W3C technologies for
querying, transforming, naming, encrypting and optimizing XML,
according to W3C. Changes to the specifications were described as
minor by W3C representative Ian Jacobs. Specifications include the
fourth edition of XML 1.0 and the second editions of XML 1.1,
Namespaces in XML 1.0 and Namespaces in XML 1.1. XML 1.0 is the main
XML specification while XML 1.1 adds support for internationalization.
Namespaces technology features a mechanism for mixng XML dialects.
W3C has a number of ongoing developments afoot in XML. By the end
of the year, W3C expects to publish W3C Recommendations for XML
Query 1.0 and XSLT 2.0 (Extensible Stylesheet Language
Transformations). W3C also is revising XML Schema, which is used
in SOAP-based Web services, and planning additions to XML Query that
extend beyond version 1.0. The XML Processing Model Working Group
soon will publish a first draft of the XML language for specifying
sequences of operations on XML documents, such as transformation,
validation, inclusion and decryption based on current XML pipeline
products and free and open source designs.
See also: the announcement
Public Release of WS-CIM Mapping Specification
Mark A. Carlson, Management Monogatari Blog
The DMTF has posted the Preliminary (public) release of the WS-CIM
Mapping Specification (DSP0230) for review and implementation. The
goal of the specification is to produce a normative description of a
protocol independent mapping of CIM models to XML Schema, WSDL
fragments, and metadata fragments. Summary: "CIM-based management in
a Web services environment requires that the CIM Schema (classes,
properties and methods) be rendered in XML Schema and WSDL (the Web
Services Description Language). To achieve this, the Common
Information Model (CIM) must be mapped to WSDL and XML Schema via an
explicit algorithm that can be programmed for automatic translation.
This specification will provide the normative rules and recommendations
that describe the structure of the XML Schema, WSDL fragments and
metadata fragments corresponding to the elements of CIM models, and
the representation of CIM instances as XML instance documents. A
conformant implementation of a CIM model to XML Schema, WSDL
fragments and metadata fragments transformation algorithm must yield
an XML Schema, WSDL fragments and metadata fragments as described in
this specification. These CIM models may be expressed in CIM MOF or
in other equivalent ways. This specification illustrates the mapping
from CIM MOF throughout in examples." One of the effects of this work
will be the availability of the CIM Schemas as XML Schema documents &emdash;
but give them some time to convert the existing MOF files over to these
schema documents for the various releases. Sun and others are creating
tools to do this conversion, per the wiseman project. So if WS-CIM is
protocol agnostic, and a protocol such as WS-Management is model
agnostic, what specifies how they fit together? Well, also approved for
release last week is the WS-Management CIM Binding (DSP0227),
essentially an appendix to the WS-Management specification that
normatively defines how to access and mutate instances of the CIM
Schema using WS-CIM over wsman.
See also: the specification
Work with Web Services in Enterprise-Wide SOAs
Judith Myerson, IBM developerWorks
This fifteenth article in a series on Web services in enterprise-wide
SOAs shows how to collaborate Framework for Web Services Implementation
with WS-Resource Framework using IBM Rational ClearQuest and Rational
ClearCase. Consider two OASIS framework specifications that you can use
to build and manage Web services: (1) WS-Resource Framework (WSRF) and
(2) Framework for Web services Implementation (FWSI). The first
specification was recently approved as a standard while the second
specification is a draft. In this article, we consider the differences
and similarities between them. You'll see when to use each individually
and in collaboration with each other. Collaborating between two
frameworks requires planning ahead of time to test if various resources
using a shopping cart or a printer Web service are functioning properly
in a lifecycle without resulting in system overloads. Also in the
planning stage is the determination of how well the Web service is
performing, what the maximum number of resources we can use with Web
services, and how complex the resources should be without creating
overlaps, gaps and holes between the two frameworks. You should
communicate with a team of system administrators, compliance specialists,
and developers on the issues of ensuring the collaborative efforts are
adequate and efficient.
XML Standardization Organizations and Processes
Mike Champion, Blog
Opinion: "Attempts at Design By Committee are generally unsatisfactory.
While one can point to counter-examples, the "good" committee-driven
standards tend to be those based on solid experience (e.g. Atom, which
is essentially a cleaned up version of RSS), or get strong design
guidance from a single expert (e.g. XSLT 1.0 and 2.0). My personal
hypothesis for why the W3C had so much fairly rapid and long-lasting
success in its early years with HTML, XML, and a few other specs is
that they were not really design by committee jobs; the committees
served more to analyze experience, write it down, and translate it to
the Web domain than to do "design". In other words, they exploited the
intellectual capital laid down by government, industry, and academic
efforts that produced the internet, SGML, etc. After a few years, the
job got harder because there were few examples of successful schema
languages, query languages, etc. to build on... The problem with de
facto standards is that they are generally moving targets. Proprietary
ones can be modified by their owners (although the really successful
ones such as MS Word's binary format or Adobe PDF tend to be frozen
for a variety of non-technical reasons). Non-proprietary ones tend to
fork to meet the needs of different sub-communities (RSS .90, .91, 1.0,
and 2.0 being the textbook example). Established and recognized
standards organizations have an important role to play in determining
whether a technology is mature enough to standardize, in providing a
venue for formalizing and testing a proto-standard, and for maintaining
it as bugs are found and new requirements added. The value of one
organization over another for this generally depends more on the
informal community of experts, promoters, and supporters that cluster
around a particular organization, and less on its formal process or
accreditation. Likewise, the organizations themselves evolve as they
gain credibility as purveyors of "real standards".
Migrating EJB 2.x applications to EJB 3.0
Shashank Tiwari, Java World
Enterprise JavaBeans 3.0 is a substantial change from the earlier
specifications in terms of both the change in enterprise bean
implementation models and in the bean location and call paradigm. How
can you migrate legacy EJB code to utilize improvements in the new
specification? This article discusses the strategies, both from a
design and implementation perspective, for migrating existing EJB
applications to the new specification. Migration to EJB 3.0 is a fairly
uncomplicated task and can be carried out in a phased and piecemeal
manner. Some of the migration tasks can be automated, and tools and
IDEs can be leveraged to ease the process. With the current emphasis on
backward compatibility and ease of migration, now may be the best time
to move EJB applications to EJB 3.0. As the EJB specification continues
to evolve, moving legacy EJB code (from version 2.1 and earlier versions)
to the newer specifications may grow more difficult.
Open-Source Licenses Get Categorized, Not Ranked
Peter Galli, eWEEK
The long-delayed and much-awaited Open Source Initiative report on open-
source license proliferation has been released, but the current
licenses have been placed into three broad categories and have not been
ranked beyond that. The License Proliferation Committee was set up in
2005 in response to the growing concern that license proliferation was
harmful to the success of open source. The first draft of the
committee's report, initially expected by the end of 2005, was
submitted to the OSI board late in July, said Diane Peters, the general
counsel for the Open Source Development Labs and a member of the
committee, at an interview at the annual LinuxWorld Conference & Expo
in San Francisco on August 16, 2006. The Licensing Proliferation
committee was also originally tasked with dividing the licenses into
ear that there was no one open-source license that served everyone's
needs equally well. "We struggled with even categorizing the licenses
into three categories and came to the realization that the various
business models had different needs and there needed to be some
flexibility there," Peters said. As such, the report categorizes all
the currently approved OSI licenses into three categories: those that
are popular and widely used or with strong communities; special purpose
licenses; and those licenses that are redundant, which includes those
that are non-reusable and other miscellaneous licenses.
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. |
