Cover Pages: XML Daily Newslink: Thursday, 19 February 2009

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:
Primeton http://www.primeton.com

Headlines

The Problem with Wrapped Notifications
Componentized XML Query Tool Takes a Step Forward
Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition
Higher Standards for Web Standards
OASIS TC to Develop SOA Standards for Telecommunications
Proposed Project: Facts for Consumers about Health IT Service Providers
JCP Election Results and Recent JSR Activity

The Problem with Wrapped Notifications
Gilbert Pilz, Oracle Blog

There are two competing specifications in the "pub/sub and asynchronous-notification map to web services" space: WS-BaseNotification and WS-Eventing. As a member of the WS-Notification "family", the former (Web Services Base Notification 1.3 - WS-BaseNotification) is an OASIS Standard while the later (Web Services Eventing - WS-Eventing) is, as of this writing, just a W3C Member Submission (now being developed by the W3C's Web Services Resource Access Working Group). The two specifications are very similar. They both define a set of operations whereby one party (the Subscriber) can subscribe to a series of asynchronous notification messages (sent in the form of SOAP messages) from another party (the Event Source) and thereafter manage that subscription. Both specifications leverage WS-Addressing for things like specifying where the notifications should be sent, creating unique references for managing multiple subscriptions, etc. However, there are places where the two specifications differ. One of these is WS-BN's use of "wrappers"; a generic XML element that acts as an envelope for the actual event information in the notification. Although WS-BaseNotification supports the use of "raw notifications", most of the specification deals with wrapped notifications. As I will show in the rest of this article, wrapped notifications are one of those ideas that, at first, seem worthwhile but which ultimately cause more problems than they solve... The core of the case against wrapped Notifications lies in the answer to the following question "Why would I use SOAP-based technologies to implement a notification mechanism?" I assert that the answer has to be either (a) because I am invested in web services programming paradigms, tools, and runtimes and I want to continue to use these, and/or (b) because I am interested in interoperability between Event Sources and Event Sinks across different middleware implementations. In either case the value of a SOAP-based approach is diminished if we try to build your notification mechanism "on top of" SOAP rather than "within" SOAP. As I have shown, defining a wrapper message/operation in WSDL creates a situation in which we can't use WSDL to describe the application specific, notification types that are emitted by the Event Source. This means that we can't use our WSDL tools to generate language-specific binding classes and the code that marshals to and from the XML representations of those Notifications. This impacts both the efficiency and the interoperability of our notification infrastructure, which where the reasons we decided to use web services in the first place.

Componentized XML Query Tool Takes a Step Forward
George Lawton, SearchSOA.com

XML has shown great promise as a format for integrating data across SOA applications. But developers face countless challenges when creating apps that mix and match data from real world scenarios containing relational databases, comma delimited flat files, and EDI formats. The applications break every time the data format changes, and then the company has to manage multiple adaptors. Dr. Carlo Innocenti, senior XML program manager for DataDirect Technologies: "Today you end up dealing with a variety of data sources in many enterprises. You may have a need to pull together data that is partly available in XML messages and some data that you are running in house. You end up having to create multiple data access layers that have to pull all of this together into a single logical view. The risk is that you create a lot of code and point solutions that you have to maintain over time. It is a maintenance nightmare." To help address this challenge DataDirect created a suite of tools to replace this complexity with a single XML layer capable of accessing data in a wide variety of formats. This work evolved into the XML Integration Suite that consists of the XQuery engine, XML Converters, and the Stylus Studio IDE. The latest update provides a number of significant upgrades designed to support more formats, and simplify development of cross platform apps drawing on multiple data sources. The Integration Suite creates an abstraction layer that makes everything visible as an XML data source. The developer can use the same style of XQuery statement whether he trying to access an EDI file, XML document, or relational database table. The latest version of the XQuery engine can also act as a Web service, allowing any type of application to query the engine using WSDL. The major improvement to the engine is support for the XQuery Update Facility (XUF), an extension of the XQuery language that allows making changes to data manipulated inside the XQuery. XUF is a W3C standard that adds the ability to change and save XML documents. This feature could allow an organization to transform large XML documents in place without having to generate multiple copies. In previous versions, it was possible to fetch data from these documents, but you could not create them from scratch. It also allows the applications to create zip files, which is required to write OpenOffice documents. Another update to the engine is the XQuery Web services framework integration that exposes XQuery as a web service...

See also: the DataDirect announcement

Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition
Karl Heinz Wolf and Alexander Mayrhofer (eds), IETF Internet Draft

Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have published an updated Internet Draft for the specification "Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition." This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776 ("Dynamic Host Configuration Protocol Option for Civic Addresses Configuration Information"). Furthermore, this document creates an IANA Registry referring to such address consideration documents. Background: The "Presence Information Data Format Location Object" (PIDF-LO) specification (IETF RFC 4119) is an object format for carrying geographical information on the Internet. It extends the XML-based Presence Information Data Format (PIDF) standard. PIDF-LO can be used to convey civic address information, and supports a range of "civic address types" (CATypes) to hold individual attributes of such addresses. In many use cases, PIDF-LOs are populated with data from long-established sources, like postal or governmental building registers, line information databases and yellow / white pages of infrastructure providers, or official residents registers. The structure and format of data from such sources is almost always different from PIDF-LO's CAtypes definition—additionally, structure and format of those sources differs from country to country. To make use of such existing data sources, transposing that data into PIDF-LO format is required. With no guidelines available on how to map source Fields into CAtype Elements, different creators of PIDF-LO documents might end up with different results, even when using the same data source—which reduces interopability and increases the risk of misinterpretation by receivers. Therefore, civic address considerations are necessary to ensure uniform usage of PIDF-LO Elements for such data sources. IETF RFC 4776 explicitly requests such documents to be provided, but does neither define their structure nor a way to publish them. This memo provides documentation on how to create such civic address considerations, and requests the creation of an IANA Registry to store references to such documents... Civic address fields are designed to be generic containers. In some cases, Fields clearly correspond to such a container, however, in some other cases, identifying the correct container might require some approximation. For example, in some countries the RD (road) Element might also be appropriate for other thoroughfares, like waterways or tunnels...

Higher Standards for Web Standards
Steve Martin, MSDN Blog

"Since the emergence of web services in the 90s, we've seen an explosion of standards and standards bodies. Sometimes, they emerge based on new innovations, other times they're created to unblock a stalemate on a similar standard or organization. Occasionally they are created simply to change the technology landscape in a way that is more favorable for certain vendors. A question that I am asked over and over is 'Does Microsoft support standard X?' or 'Is Microsoft going to join standards body Y?' The question we should spend more time debating is 'What are the key technology or interoperability gaps and how do we fill them?' As new initiatives emerge, we research the business and technical need before taking action. We do this by putting ourselves in the shoes of actual developers and IT Pros and asking 'What are the barriers I'm facing today, and what do I need to solve them?' Pragmatism over theory, always. In many cases, the right answer isn't necessarily to define something new, but to instead carefully consider whether technology or initiatives already exist to solve the problem. In the end, we should judge the strength of standards on industry and customer adoption alone. As an example, IBM recently announced a consortium called 'WSTF': Web Services Test Forum which leaves us a tad puzzled. As of today, the WS-* standards are largely complete within W3C, OASIS, WS-I, DMTF, etc. and are widely implemented in infrastructure products and used by organizations all over the world. We were thrilled to participate in the oasis announcement just last week on WS-RX, WS-TX and WS-SX. With regard to testing, we think it is critical that customers be able to propose scenarios that match their real-world interoperability needs. Equally important—both successes and failures must be made public. This is why we're still evaluating our participation in WSTF. Microsoft and other vendors have been participating in a variety of forums for quite some time to help crack the interoperability code. A few examples of forums that have yielded real world results for developers over the years: (1) WS-* specification development at W3C and OASIS... (2) WS-I is the base layer process for integration and interoperability, upon which other, more domain-specific or scenario-specific tests, profiles, and guidance are built and the primary WS-* interoperability testing focus for Microsoft. (3) Interoperability Plug-fests are more informal events at which multiple vendors get together to test interoperability against all other interested attendees, using agreed-upon scenarios for current and forthcoming products... (4) Greg Leake runs one of the largest interoperability labs in the world and publishes results and guidance on WS* / WebSpehere / .NET interop... Separately, but potentially equally interesting: An interoperability project that Microsoft recently joined is the Apache Stonehenge incubator effort. We look forward to expanding our efforts in partnership with other vendors on this front... Do we need additional standards? The answer is almost certainly yes. But before touting a new standard or standards organization, vendors need to be clear about what specific issue is being solved and hold all parties accountable for doing so. Public access is a key criterion we have in mind as we think about WSTF. So what can you do? Continue to contribute at all levels; standards are only as good as the community formed around them..."

See also: the WSTF news story

OASIS TC to Develop SOA Standards for Telecommunications
Staff, OASIS Announcement

OASIS recently announced the formation of a new group to extend the core Web 2.0 and SOA standards stack to support the specific needs of telecommunications operators and providers. The new OASIS SOA for Telecom (SOA-Tel) Technical Committee will develop use cases and define requirements that will make telecommunications services more intelligent, deployable, and easy to consume. This TC operates under the RAND Mode of the OASIS IPR Policy. Statements of support for the SOA-Tel TC have been provided by Nortel, Primeton, and Red Hat. The group's first task will be to identify areas where existing standards don't go far enough to meet the needs of telecom operators. Participants will focus on issues such as testability, scalability, Service Level Agreements (SLAs), and reliability. Support for session and event-based interactions, service ontologies and failure modes will be addressed. The Committee intends to build on work done in other telecommunications-oriented organizations, such as the Open Mobile Alliance (OMA), a standards body for the mobile phone industry, ITU-T, and TM Forum, an industry association that develops management standards for telecoms. Mike Giordano of Avaya, co-chair of the OASIS SOA-Tel Technical Committee: "Current SOA technologies were designed for IT use cases. Applying them to the telecom world is not always straightforward. In telecom, services and network features are often tightly coupled and vertically integrated. Tight coupling limits the ability of operators to develop new composite services that span heterogeneous networks. Vertical integration reduces access to service management functions, making it very difficult to automate operations and business processes across organizations." Abbie Barbir of Nortel, co-chair of the OASIS Telecom Member Section Steering Committee: "Our goal is to make it easy for telecom companies to rapidly deploy new services that leverage their existing infrastructures. The potential for new revenue streams is tremendous."

Proposed Project: Facts for Consumers about Health IT Service Providers
U.S. Department of Health and Human Services, Federal Register

"The Office of the Secretary (OS), Department of Health and Human Services, is publishing the following summary of a proposed information collection request for public comment. Interested persons are invited to send comments regarding this burden estimate or any other aspect of this collection of information. A new health information technology, the personal health record (PHR), seeks to provide consumers with the capability to directly manage their own health information. Although PHRs can exist in different formats or media (i.e., paper or electronic), the term usually refers to an online record containing an individual's personal health information. PHRs typically include information such as health history, vaccinations, allergies, test results, and prescription information. Given the newness of the electronic PHR concept, the different ways to establish PHRs, and the sensitivity of personal health information, the Office of the National Coordinator for Health Information Technology (ONC) is taking steps to establish that useful facts about PHRs and PHR privacy policy information be made available to consumers so they can make informed decisions about selecting and using PHRs. Toward this end, ONC has a project to develop an online model for PHR providers. The model will be developed to: (1) Allow presentation of important PHR facts and policies to consumers, (2) Allow consumers to understand and consistently compare PHR service provider policies with others, and (3) Focus on the key information that may influence decisions and choices of PHR service provider. The project includes iterative rounds of in-depth consumer testing during April-October 2009 to assess and analyze consumer understanding and input about the model. The model will be iteratively revised to design a final template that will allow PHR vendors to convey useful and understandable facts to consumers about their privacy, security, and information management policies.

See also: XML and Healthcare

JCP Election Results and Recent JSR Activity
Patrick Curran, JDJ

The Java Community Process (JCP) annual elections for our Executive Committees (ECs) are now complete... JCP members obviously believe that the large corporations (those who fund most of the development work and the primary implementers of the technologies we develop) need to be represented on the ECs. On the other hand, JCP's members feel the need for an "independent" voice—someone who can represent the broad development community, particularly developers who work independently or in relatively small companies. We also shouldn't forget that 80% of the JCP's membership consists of individuals or non-profit organizations. So it's appropriate that we have at least one member on each EC whose primary purpose is to look out for their interests... Latest JSR News: (1) JSR 293 Final: Location API 2.0, led by Nokia, builds on the low-level location APIs defined by JSR 179, standardizing access to location-based services such as geocoding, mapping, and navigation. (2) JSR 272 Final: Mobile Broadcast Service API for Handheld Terminals, jointly led by Nokia and Motorola, defines APIs that enable client Java applications on mobile devices to receive, display, and interact with content received over a digital broadcast link. (3) JSR 299 for review: Web Beans, led by Red Hat, enables EJB 3.0 components to be used as JSF managed beans. (4) JSR 317 for review: Java Persistence 2.0, led by Sun Microsystems, updates the Java Persistence API first defined in the Enterprise JavaBeans 3.0 specification (JSR 220), providing additional object/relational mapping functionality and query language capabilities... (5) JSR 235: Service Data Objects is particularly interesting. It's the first attempt at developing a standard by having the JCP collaborate with another standards body—in this case OASIS. Technologies for SOA (Service Oriented Architecture) were initially developed by an industry consortium called Open SOA Collaboration. When its work reached a reasonable level of maturity it chose to standardize through OASIS, which has played a major role in developing enterprise-level business process standards. The Java aspects of this work are being standardized simultaneously through the JCP (as JSR 235). Although we recognize that "no standard is an island"—standards build on other standards, often from other standards-developing organizations (see, for example, the wide range of Java standards that build on the work of the W3C)—this is the first time that we've had such a close collaboration between the JCP and another standards organization.


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

Headlines

Sponsors