Cover Pages: XML Daily Newslink: Wednesday, 08 August 2007

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com

Headlines

Service-Component Architectures: A Programming Model for SOA
XForms Extensions to XPath
A Common Schema for Internet Registry Information Service Transfer Protocols
Widgets and Rich Internet Applications: Lightweight Client Apps
Create Portable Database Representations with PHP PEAR Package
Google Joins Open-Source Patent Network
ETags, ETags, ETags

Cover Pages

W3C Member Submission: Web Services Policy Attachment for Endpoint Reference (EPR)

Service-Component Architectures: A Programming Model for SOA
Arunava Chatterjee, DDJ

This article examines Service-Component Architectures (SCA) as a means to implement Service-Oriented Architectures (SOA). The SCA Programming Model addresses the engineering details of SOA by providing an approach to the development, assembly, and deployment of services. In keeping with SOA principles, SCA supports heterogeneous implementations by being metadata driven, language independent, and container independent. So long as a mapping from the SCA specification to a technology can be defined, SCA can be implemented. Consequently, SCA has been bound to multiple languages and containers; most recently a C-language specification has been drafted. While not part of the SCA Model proper, Service Data Objects (SDO) are the de facto SCA data architecture. SDOs are based on the concept of disconnected data graphs. The SDO architecture maintains a tree or graph of data objects that can be accessed via APIs. The architecture allows both strong-typed and weak-typed data models, thus supporting static and dynamic data access strategies... By adding metadata, SDOs also support runtime exploration of the data graphs. Since the architecture was designed with XML in mind, it provides a rich mechanism for manipulating XML. In fact, for practical purposes, the underlying data structure for SDOs may well be XML documents. SCA attempts to create a simple, robust programming model based on SOA concepts. Its value lies in a conceptually simple, declarative approach to assembly and QoS. Through assembly-time and runtime wiring and loosely coupled policies, SCA addresses the issue of creating a service without foreknowledge of the underlying components. This, in turn, lets service component and integration developers act independently. Combined with SDO, a vendor-neutral approach to SOA is possible—the model designers appear to have learned from weaknesses of earlier models—by providing a clean separation between assembly and QoS. If the Apache Tuscany Project is an indication of SCA's viability, then the outlook for a straightforward (though not necessarily simple) way to implement SOA is promising

XForms Extensions to XPath
Elliotte Rusty Harold, IBM developerWorks

XForms uses XML Path Language (XPath) as its basic function and evaluation language. XForms adopts the familiar XPath expression language for two purposes. First, it uses it as a query language for addressing and identifying fields within the form and the user-submitted data. In particular, it uses XPath expressions to bind input controls to particular parts of the form's data model. Second, it uses XPath as its basic calculation language for output, bind, and setvalue elements. The focus of this article is mostly on the second usage, though some of these functions are useful for binding as well. XPath was designed to be extensible both by users and implementers. XPath 1.0 defines a basic set of functions such as count and translate that are suitable for a broad range of purposes. Languages such as XSLT, XQuery, XML Pointer Language (XPointer), XML Signature, and XForms that adopt the XPath expression language are expected to expand on this basic set with additional functions. XForms takes advantage of this by introducing new functions useful in forms processing. In particular, XForms adds functions for math, dates, times, Booleans, and XForms-specific operations. You may never see these functions in an XSLT stylesheet or a Jaxen program, but you can use them today in any XForms 1.0 document. The X in XPath stands for extensible: XForms has extended XPath to provide extra power and unique features that are worth learning. While XForms supports the full range of XPath 1.0 you're used to from XSLT, it has quite a bit more. Some of these functions like days-from-date() and now() are just nice to have. Others like if() and instance() are critical components of any non-trivial XForm. More XForms use these functions than don't.

See also: XML and Forms

A Common Schema for Internet Registry Information Service Transfer Protocols
Andrew L. Newton (ed), IETF Internet Standards Track Protocol

A posting from the IETF Rfc-Editor announces the publication of a new Standards Track Request for Comments (RFC) docuument, available in online RFC libraries. The 'Common Schema' document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. The document defines an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. IRIS has two transfer protocols, LWZ (lightweight using compression) and XPC (XML pipelining with chunks), that share common negotiation mechanisms. Both transfer protocols have a need for the server to provide rich status information to clients during protocol negotiation. In many cases, this status information would be too complex to describe using simple bit fields and length- specified octet sequences. This document defines an XML Schema for this rich status information and describes the usage of conformant XML for conveying this status information. This document defines five types of information used in the negotiation of protocol capabilities: version, size, authentication success, authentication failure, and other information. The version information is used to negotiate the versions and extensions to the transfer protocol, the application operations protocol, and data models used by the application operations. Size information is used to indicate request and response size capabilities and errors. Authentication success and failure information is used to indicate the outcome of an authentication action. Other types of information may also be conveyed that is generally a result of an error but cannot be corrected through defined protocol behavior.

See also: XML Pipelining with Chunks

Widgets and Rich Internet Applications: Lightweight Client Apps
Dana Moore and Ray Budd, Dr. Dobb's Journal

Rich Internet Applications (RIAs) increasingly developed as solutions to problems traditionally solved by applications executing on the client. Complex programs such as wordprocessors, spreadsheets, and e-mail clients are now maintained online, and executed entirely within the confines of web browsers. Consider the popularity of sites like Gmail, Google Maps, and Flickr. Desktop widgets are lightweight client applications that can be used in conjunction with a RIA to incorporate the advantages of both the client and server. The advantage widgets offer for a RIA are the ability to interact with client systems, and to use resources available only on clients while avoiding the overhead required to develop a complete application from scratch. Examples of client interactions that are possible with widgets include: (1) Client filesystem interactions such as reading/writing files on client systems; (2) System analysis, such as examining the amount of CPU or memory in use; (3) Interacting with iTunes or other applications running on client systems; (4) Examining the number and power level of batteries connected to client systems. Although there are different desktop widget engine implementations, they do have similarities. The engine provides a framework that reduces the code required for a widget. A widget specification is interpreted rather than compiled, and consists of a combination of a markup language (such as XML or HTML), a scripting language (such as JavaScript), and sometimes CSS. The RIA model is a powerful model for developing applications. Integrating a RIA with small desktop applications can greatly enhance the overall user experience, but it is often impractical to develop a fully functional utility program from scratch. A desktop widget can alleviate these concerns by providing a low-cost approach to developing small effective desktop utilities that bridge the gap between the RIA and the desktop.

Create Portable Database Representations with PHP PEAR Package
Vikram Vaswani, IBM developerWorks

Switching to a new RDBMS thus requires the application developer to thoroughly check the code tree of the application for non-standard SQL or RDBMS-specific features, and then re-engineer these to work with the new RDBMS. This re-engineering might be as simple as resetting field data types, or as complex as rewriting SQL queries and stored procedures in a format more suitable to the new database engine. Database configuration settings and variables might also need to be optimized for maximum performance. MDB2_Schema, a package from the PHP Extension and Application Repository (PEAR), can help you reduce some drudge work in moving from one RDBMS to another. The MDB2_Schema package provides an API to extract entities and records from an RDBMS, store them in a vendor-neutral XML format, and use this XML to recreate the original database and records in a different RDBMS. It supports most commonly-used database systems, and thus provides an easy and efficient way to quickly port your data from one system to another. MDB2_Schema depends heavily on two other PEAR packages, the MDB2 database abstraction layer and the XML_Parser package. MDB2, in turn, further requires that you install database-specific drivers and corresponding PHP extensions for the different database engines to be supported. As of this writing, MDB2 drivers are available for MySQL, SQLite, PostgreSQL, Firebird, Interbase, MS-SQL and Oracle. The example in this article demonstrates use of the MDB2_Schema package by porting MySQL's sample world database, which provides various pre-populated and linked tables containing city and country data, to PostgreSQL. It pre-supposes that both MySQL and PostgreSQL are installed, and that the world database is correctly installed.

Google Joins Open-Source Patent Network
Matthew Broersma, CNET News.com

The Open Invention Network, an organization created to help take the pressure of patent litigation off Linux developers, has added Google to the ranks of its contributors. The move is a major progression for the OIN: Google is not only one of the world's biggest users of open-source software, but it is also the group's first end-user member. The network's other members, including IBM and Red Hat, are all vendors selling products based on open-source software. Google's membership of the group means that it will, like other OIN members, agree to cross-license open source-related patents to other OIN members free of charge. The idea is that member companies can then freely collaborate on open-source projects with less of a burden, in terms of dealing with intellectual-property issues. Google's Chris DiBona pointed out some of the high-profile ways in which Google has given back to the open-source community, such as through the open source-oriented Summer of Code training program and by funding external projects such as the Ubuntu Developer Summit and the Linux Foundation Collaboration Summit. Google continues to submit Linux patches and has open-sourced more than a million lines of code. The OIN was founded by IBM and others in response to a growing sense that software patents could derail the progress of vital open-source software projects such as Linux and Samba. In March 2007, Google reached a software contributor agreement with the Free Software Foundation that has since enabled Google to increase its contributions to open-source projects, according to DiBona.

See also: the 2005-11 story

ETags, ETags, ETags
Mark Nottingham, Blog

"I've been hoping to avoid this, but ETags seem to be popping up more and more often recently. For whatever reason, people latch onto them as a litmus test for RESTfulness, as the defining factor of HTTP's caching model, and much more. So, let me counter: they're not all that. In fact, there are a number of pitfalls you need to be wary of if you use them. First, depending on how they're generated, you might find different boxes in a farm producing different ETags, with unfavourable results for caching. Or, you might find that your implementation doesn't really understand HTTP very well, so it gives the same ETag to two different representations of the same resource, causing downstream caches to bend over backwards to accommodate your broken server. It can happen to the best of us. If you're trying to be a good guy and both compressing your content and hashing it to calculate the ETag, beware; the gzip file format has a timestamp in it that means the ETag will change every time you re-compress it. Oops. Even if you get the whole ETag thing right, there's no guarantee that a cache will use it; although recent versions of Squid understand and use ETags, lots of older implementations don't. Another mistake is to think that ETags are only used for caching. If you hand out ETags and your resource supports methods like PUT or DELETE, you'd better be ready to properly handle conditional headers like If-Match on requests; otherwise, they'll end up doing the wrong thing... While ETags are a fine validation mechanism, Last-Modified is also perfectly fine in many situations. Even better, avoid the round trip altogether and give your response some freshness information with Cache-Control: max-age."

See also: Tim Bray's blog

Selected from the Cover Pages, by Robin Cover

W3C Member Submission: Web Services Policy Attachment for Endpoint Reference (EPR)

The World Wide Web Consortium has acknowledged receipt of a WS-PAEPR Member Submission from Axway, BEA Systems, Inc., JBoss Inc., Nokia, Oracle, and Progress Software Corporation. The Web Services Policy Attachment for Endpoint Reference (WS-PAEPR) specification as contributed defines a mechanism to attach policies written using the W3C Web Services Policy 1.5 - Framework specification to an endpoint reference, defined by the Web Services Addressing 1.0 - Core Recommendation. Background: The W3C WS-Addressing Recommendation defines an XML Infoset-based representation for specifying endpoint references. The corresponding XML syntax involves an EndpointReference element with contained elements Address, ReferenceParameters, and Metadata. The Metadata element allows child elements from any namespace. Such metadata can be used to define the 'the behavior, policies and capabilities of the endpoint.' Typically, these are used to include WSDL definitions that apply to that endpoint as well as Policies or Policy References that apply to that endpoint. The Web Services Addressing 1.0 - Metadata specification defines how to include WSDL metadata in an EPR's metadata section. The contributed Web Services Policy Attachment for Endpoint Reference (WS-PAEPR) specification "defines how to include Policies and Policy References within the Metadata element as well as the semantics of such inclusion. It also addresses the semantics of Policies and Policy References directly included within the Metadata element in combination with Policies and Policy References included within WSDL definitions that are also included in the Metadata element."


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Cover Pages

Sponsors