|
XML and Web Services In The News - 22 December 2006
Provided by OASIS |
Edited by Robin Cover
This issue of XML Daily Newslink is sponsored by Sun Microsystems, Inc.
HEADLINES:
Last Call: Canonical XML 1.1
John Boyer and Glenn Marcy (eds), W3C Technical Report
W3C's XML Core Working Group has published a Last Call Working Draft
for "Canonical XML 1.1". Canonical XML 1.1 is a revision to Canonical
XML 1.0 to address issues raised while producing the "xml:id"
specification. Any XML document is part of a set of XML documents that
are logically equivalent within an application context, but which vary
in physical representation based on syntactic changes permitted by "XML
1.0" and "Namespaces in XML". This specification describes a method
for generating a physical representation, the canonical form, of an XML
document that accounts for the permissible changes. Except for
limitations regarding a few unusual cases, if two documents have the
same canonical form, then the two documents are logically equivalent
within the given application context. XML canonicalization is designed
to be useful to applications that require the ability to test whether
the information content of a document or document subset has been changed.
This is done by comparing the canonical form of the original document
before application processing with the canonical form of the document
result of the application processing. For example, a digital signature
over the canonical form of an XML document or document subset would
allow the signature digest calculations to be oblivious to changes in
the original document's physical representation, provided that the
changes are defined to be logically equivalent by the XML 1.0 or
Namespaces in XML. During signature generation, the digest is computed
over the canonical form of the document. The document is then transferred
to the relying party, which validates the signature by reading the
document and computing a digest of the canonical form of the received
document. The equivalence of the digests computed by the signing and
relying parties (and hence the equivalence of the canonical forms over
which they were computed) ensures that the information content of the
document has not been altered since it was signed.
See also: Known Issues
NETCONF Configuration Protocol
Rob Enns (ed), IETF Network Group Proposed Standard Protocol
The IETF RFC-EDITOR announced that a new 'Request for Comments'
document is now available in online RFC libraries as RFC 4741. The
specification has been produced by members of the Network Configuration
Working Group of the IETF (NETCONF), and is now a Proposed Standard
Protocol. The Network Configuration Protocol (NETCONF) defined in this
document provides mechanisms to install, manipulate, and delete the
configuration of network devices. It uses an Extensible Markup Language
(XML)-based data encoding for the configuration data as well as the
protocol messages. The protocol allows the device to expose a full,
formal application programming interface (API). Applications can use
this straightforward API to send and receive full and partial
configuration data sets. The NETCONF protocol uses a remote procedure
call (RPC) paradigm. A client encodes an RPC in XML and sends it to a
server using a secure, connection-oriented session. The server responds
with a reply encoded in XML. The contents of both the request and the
response are fully described in XML DTDs or XML schemas, or both,
allowing both parties to recognize the syntax constraints imposed on
the exchange. A key aspect of NETCONF is that it allows the
functionality of the management protocol to closely mirror the native
functionality of the device. This reduces implementation costs and
allows timely access to new features. In addition, applications can
access both the syntactic and semantic content of the device's native
user interface.
See also: the IETF NETCONF WG Charter
The WS-Policy Story
William Brogden, SearchWebServices.com
As the concept of XML-based "Web services" has grown from the simple
days of XML-RPC things have gotten a lot more complicated. The
pioneering developers communicated service requirements in text
documentation, sample code and user mailing lists. Then came SOAP and
more formal documentation such as WSDL and UDDI. Now the list of formal
specifications related to Web services and generated by a variety of
organizations is astonishingly long. The Web Services Policy Framework
is intended to provide a basic general purpose model and XML syntax
for describing policies related to a Web service. Policies can be
defined, not only for a given Web service, but also by potential
clients of the service. For example, your company might require that
developers only access Web services using digital signatures. WS-Policy
functions as an addition to WSDL, UDDI and other WS-* specifications.
A WS-Policy document expresses rules that may be as simple as a
requirement to use WS-Addressing in SOAP headers or as complex as
giving a list of "assertions" about alternate message signing
algorithms which the service can recognize. Essentially, WS-Policy
attempts to formalize in both machine- and human-readable form aspects
of Web service communication that might otherwise require extensive
text documentation or direct person to person communication. For me the
question is: will WS-policy prove to be the solution to the obvious
problem of helping developers coordinate all of the various
specifications related to Web services or will it join the ranks of
elegant specifications that everybody admires but few people use?
See also: the Guidelines
WS-Engineer: A Rigorous Approach to Engineering Web Service Compositions
Howard Foster, XML 2006 Presentation
We believe the issues in designing complex web service compositions and
choreography can be eased by modelling the required interactions in an
accessible and concise notation which can then be used to verify and
validate not only web service workflows but choreography behaviour over
cross-domain services. This paper presents an engineering approach to
designing, implementing and maintaining web service behaviour
specifications, as XML documents, covering the current web service
standards stack. We present a rigorous approach to formally specifying,
modelling, verifying and validating the behaviour of web service
compositions with the goal of simplifying the task of designing
coordinated distributed services and their interaction requirements.
Through the use of our Eclipse plug-in tool, known simply as
'WS-Engineer', we firstly provide examples of designing service
interaction behaviour models using UML style Message Sequence Charts,
and describe how these can be used to generate XML specifications,
which are then used to generate formal models of system behaviour. Web
Service standards are used as an implementation example, with models
generated from the XML of BPEL4WS and WS-CDL, that represent web
service orchestrations and choreography respectively. Through the use
of formal model verification techniques, the behaviour specified in
these XML documents can be checked for service interaction violations
between design and implementation, between processes (as service
conversations) and by the role of the processes. Obligations analysis
considers how each service either fulfills or falls short of providing
sufficient interactions in service choreography.
See also: the abstract
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)
Richard Schwerdtfeger, R. Schwerdtfeger, J. Gunderson; W3C WD
W3C announced that its Protocols and Formats Working Group has
published updated Working Drafts for the WAI-ARIA suite of
specfications which describes accessibility of rich Web content
using interactive technologies such as AJAX and DHTML. The
Protocols and Formats Working Group (PFWG) Charter has been updated
to allow the group to publish Recommendation-track documents.
Accordingly, WAI-ARIA Roles and States and Properties are now intended
to become W3C Recommendations; the Roadmap remains a draft Working
Group Note. The "Roadmap for Accessible Rich Internet Applications"
(WAI-ARIA Roadmap) addresses the accessibility of dynamic Web content
for people with disabilities. The roadmap outlines the technologies to
map controls, AJAX live regions, and events to accessibility APIs,
including custom controls used for Rich Internet Applications. The
roadmap also outlines new navigation techniques to mark common Web
structures as menus, primary content, secondary content, banner
information and other types of Web structures. These new technologies
can be used to improve the accessibility and usability of Web
resources by people with disabilities, without extensive modification
to existing libraries of Web resources. "Roles for Accessible Rich
Internet Applications" defines a simple way for an author to make
custom widgets (new interactive elements) accessible, usable, and
interoperable. The role attribute defined in the XHTML Role Attribute
Module is the preferred way to expose these roles in XHTML
applications. This specification provides an ontology of roles that can
be used to improve the accessibility and interoperability of Web Content
and Applications. "States and Properties Module for Accessible Rich
Internet Applications defines a syntax for adding accessible state
information and author settable properties for XML.
See also: the Suite Overview
Security Concepts, Challenges, and Design Considerations for Web Services Integration
Gunnar Peterson and Howard Lipson, BuildSecurityIn
Security risks are inherent in all integration technologies. The
emergence of web services as an integration pattern presents new threats
and opportunities for a system's security. Beyond the initial hype,
where web services were viewed as a security pandemic, lie both real
risks and new security paradigms. Web services evolved after
object-oriented programming and component programming models were
already in place, but web services represent a fundamentally different
approach based on a document-oriented model designed for
interoperability at a document, typically XML, level. Hence, security
and software architects must consider message schemas, types, values,
and message exchange patterns in their designs. Standards are
increasingly important because web services can traverse organizational,
geographical, and technical boundaries. Since message exchange is a core
part of web services? architectural design, a high level of security
must be built into the messages from the outset, as well as into the
services and systems. Protecting the messages that the services and
systems operate on is a central aspect of web services security and will
be a major focus of this document. Unfortunately, this is not the only
security issue that web services developers must be concerned with, and
so guidance on other issues will be presented as well. For example,
issues of trust relating to services and systems that are not in your
direct control pervade the web services landscape and must be addressed
early in the development life cycle through security policies and
building in a monitoring capability for security violations. The central
theme of this article is that web services developers must address
security concerns as early as possible in the system development life
cycle so as to 'build security in' rather than attempt the often futile
task of patching security onto a system after security problems are
manifested in the field.
A Conversation with John Hennessy and David Patterson
Kunle Olukotun (Interviewer), ACM Queue
The Berkeley-Stanford duo who wrote the book (literally) on computer
architecture here discuss current innovations and future challenges.
Excerpt: "We're really in the early stages of how we think about
[parallel computing]. If it's the case that the amount of parallelism
that programmers will have to deal with in the future will not be just
two or four processors but tens or hundreds and thousands for some
applications, then that's a very different world than where we are
today. On the other hand, there's exciting stuff happening in software
right now. In the open source movement, there are highly productive
programming environments that are getting invented at pretty high
levels. Everybody's example is Ruby on Rails, a pretty different way
to learn how to program. This is a brave new world where you can rapidly
create an Internet service that is dealing with lots of users. In the
RAMP community, we've been thinking about how to put this in the hands
of academics. Maybe we should be putting a big RAMP box out there on
the Internet for the open source community, to let them play with a
highly scalable processor and see what ideas they can come up with. I
guess that's the right question: What can we do to engage the open
source community to get innovative people, such as the authors of Ruby
on Rails and other innovative programming environments? The parallel
solutions may not come from academia or from research labs as they
did in the past.
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. |
