Cover Pages: XML Daily Newslink: Wednesday, 14 March 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:
SAP AG http://www.sap.com

Headlines

Updated Version of the Service Modeling Language (SML) Specification
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
An XQuery Servlet for RESTful Data Services
Enterprise Service Bus, Service Implementation and the Return of the EJB
Members Approve WS-SecureConversation 1.3 as an OASIS Standard
RDFa Primer 1.0: Embedding RDF in XHTML
How Sun Sells its SOA Dog Food to its Own Employees
WfMC Counters XPDL Criticism, Argues Three Standards Count

Updated Version of the Service Modeling Language (SML) Specification
John Arwe, Jordan Boucher, et al., Draft Specification

Industry partners have published a revised version of the "Service Modeling Language" (SML) specification, its companion "SML Interchange Format" document, and related resources. The SML Version 1.0 Draft Specification of 28-February-2007 was produced by corporate authors BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun. The Service Modeling Language (SML) is used to model complex IT services and systems, including their structure, constraints, policies, and best practices. SML is based on a profile on XML Schema and Schematron. Models as defined in SML typically include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. Models provide value in several important ways: (1) Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to be functional. (2) Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. (3) Models drive modularity, re-use, and standardization, reducing overall production and operation cost and in increasing reliability. (4) Models represent a powerful mechanism for validating changes before applying the changes to a service/system; models of a service/system must necessarily stay decoupled from the live service/system to create the control loop. (5) Models enable increased automation of management tasks—automation facilities exposed by the majority of IT services/systems today could be driven by software. A model in SML is realized as a set of interrelated XML documents. The XML documents contain information about the parts of an IT service, as well as the constraints that each part must satisfy for the IT service to function properly. Constraints are captured in two ways: [A] Schemas: these are constraints on the structure and content of the documents in a model. SML uses a profile of XML Schema 1.0 as the schema language. SML also defines a set of extensions to XML Schema to support inter-document references. [B]. Rules: are Boolean expressions that constrain the structure and content of documents in a model. SML uses a profile of Schematron and XPath 1.0 for rules. To ensure accurate and convenient interchange of the XML documents that make up an SML model or a portion of an SML model, it is useful to define an implementation-neutral interchange format that preserves the content and interrelationships among the documents. The "SML Interchange Format" specification defines such a standard format called the SML Interchange Format (SML-IF).

See also: the SML Working Group

GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
James Winterbottom (et al., eds), IETF Internet Draft

Members of the IETF GEOPRIV Working Group have released an updated Internet Draft for "GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations." XML-based Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant presence protocols, allowing presence information to be transferred across CPP-compliant protocol boundaries without modification, with attendant benefits for security and performance. The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that must be implemented by applications involved in location based routing. The IETF Geographic Location/Privacy (GEOPRIV) Working Group was chartered to assess the authorization, integrity and privacy requirements that must be met in order to transfer geographic location information, or authorize the release or representation of such information through an agent. Applications needing such information include navigation, emergency services, management of equipment in the field, and other location-based services. But while the formatting and transfer of such information is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but. A key task is to enhance the format and protocol approaches methods to ensure that the security and privacy methods are available to diverse location-aware applications. To date, GEOPRIV has produced eight RFCs which use XML- and GML-based technologies to support location-based services, navigation applications, emergency services, and management of equipment in the field.

An XQuery Servlet for RESTful Data Services
Jonathan Robie, DevX.com

Many web applications exchange data as XML, but that data is usually stored in and queried from relational databases, CRM, ERP, proprietary repositories, and a hodgepodge of other systems. Unfortunately, the languages most commonly used for creating or processing data on the web were designed neither for processing XML nor for integrating data among multiple heterogeneous sources. These are precisely the tasks for which the XQuery language was designed. This paper shows how to use XQuery for data integration, and how to expose an XQuery as a RESTful data service using a Java servlet. As an XML-oriented data integration language, XQuery can be used to access XML, relational, and flat file formats such as EDI to create complex XML and HTML results. To deploy a query, a developer saves the query into a designated deployment directory in a secure location accessible to the servlet. Subsequently, developers can invoke any query in this directory using its REST interface, which requires nothing more than an HTTP GET or POST operation using a URL that represents the query and its parameters. It's not terribly difficult to create an XQuery servlet that implements the Java Servlet API, using XQJ to issue XQueries. But it's a powerful idea, because developers can develop data services by writing queries in XQuery, testing them, and simply copying them to the deployment directory. The servlet makes deployed queries instantly available to users, providing an HTTP interface determined by the query name and its parameters. This development/ deployment simplicity is an extremely productive way to create data services.

Enterprise Service Bus, Service Implementation and the Return of the EJB
Frank Teti, TheServerSide.com

For organizations serious about pursuing an SOA (Service Oriented Architecture), knowing the strengths and weaknesses of your development organization is important to improving the process. BEA and IBM both have online SOA assessment surveys, and I recommend taking those assessments. However, these assessments are, in my opinion, are just marketing tools, but they are free, too. When object technology was considered a new technology, technologist recommended that organizations needed to adopt a mindset that objects needed to be documented and catalogued, which would then foster reuse. An SOA provides reuse in that a single Web service is implemented for say a member or provider lookup for the enterprise, instead of direct JDBC or HTTP access, and published in the UDDI. For organizations that have significant experience with DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) and/or RMI (Remote Method Invocation), which are consider distributed object technologies, reuse and service orientation is fundamental to the model. For those organizations, shifting to a Web service based architecture service-orientation is not at all new. For organizations who have limited experience with any of those technologies, pursuing an SOA will be a steep learning curve. SOA within most organization's architectures is really at a stage where Web (HTTP) servers were in the early days of internet-style computing. In those days, architects were trying to find ways to use Web servers either for serving static pages or basic reporting. In a similar fashion, today's architects are introducing Web services either for looking up reference data or other basic computing constructs. To look at SOA any different than the other distributed object models previously mentioned is a rookie mistake.

Members Approve WS-SecureConversation 1.3 as an OASIS Standard
Staff, OASIS Announcement

OASIS Staff recently announced that the "WS-SecureConversation v1.3" Specification has been approved as an OASIS Standard, congratulating the OASIS Web Services Secure Exchange (WS-SX) TC, with the community of implementers, developers, and users who have brought the work successfully to culmination. The mechanisms defined in WS-Security provide the basic mechanisms on top of which secure messaging semantics can be defined for multiple message exchanges. While WS-Security focuses on the message authentication model, its approach, useful in many situations, is subject to several forms of attack. The WS-SecureConversation specification defines extensions to allow security context establishment and sharing, and session key derivation. This allows contexts to be established and potentially more efficient keys or new key material to be exchanged, thereby increasing the overall performance and security of the subsequent exchanges. The security context is defined as a new WS-Security token type that is obtained using a binding of WS-Trust. The primary goals of this specification are to define how security contexts are established, describe how security contexts are amended, and specify how derived keys are computed and passed. This specification is intended to provide a flexible set of mechanisms that can be used to support a range of security protocols; some protocols may require separate mechanisms or restricted profiles of this specification. Key driving requirements in the specification design were derived keys and per-message keys, and extensible security contexts. The OASIS WS-SX TC is also working on the WS-SecurityPolicy and WS-Trust specifications. WS-SecurityPolicy describes the policy assertions for use with WS-Policy which apply to 'WSS: SOAP Message Security', WS-Trust, and WS-SecureConversation. The WS-Trust specification defines extensions that build on WS-Security to provide a framework for requesting and issuing security tokens, and to broker trust relationships.

See also: the announcement

RDFa Primer 1.0: Embedding RDF in XHTML
Ben Adida and Mark Birbeck (eds), W3C Technical Report

Members of the W3C XHTML2 Working Group and the Semantic Web Deployment Working Group jointly have published an updated Working Draft of the "RDFa Primer 1.0: Embedding RDF in XHTML." RDFa is a syntax for expressing structured 'web page' data in XHTML. The rendered, hypertext data of XHTML is reused by the RDFa markup, so that publishers don't repeat themselves. RDFa is designed to work with different XML dialects, e.g. XHTML, SVG, etc., given proper schema additions. In addition, RDFa is defined so as to be compatible with non-XML HTML. The underlying abstract representation is RDF, which lets publishers build their own vocabulary, extend others, and evolve their vocabulary with maximal interoperability over time. The expressed structure is closely tied to the data, so that rendered data can be copied and pasted along with its relevant structure. Current web pages, written in HTML, contain significant inherent structured data. When publishers can express this data more completely, and when tools can read it, a new world of user functionality becomes available, letting users transfer structured data between applications and web sites. An event on a web page can be directly imported into a user's desktop calendar. A license on a document can be detected so that the user is informed of his rights automatically. A photo's creator, camera setting information, resolution, and topic can be published as easily as the original photo itself, enabling structured search and sharing. RDFa syntax supports the expression of the structured data using a set of elements and attributes that embed RDF in the HTML. The RDFa draft is a companion to the XHTML 2.0 specification. XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the World Wide Web. To this end it does not attempt to be all things to all people, supplying every possible markup idiom, but to supply a generally useful set of elements.

See also: XHTML 2.0 references

How Sun Sells its SOA Dog Food to its Own Employees
Rich Seeley, SearchWebServices.com

The first thing Mike Ricigliano, senior manager for integration services at Sun Microsystems Inc., tells his counterparts at other companies is that he faces the same problems and pressures as any other Sun customer. As one of the managers charged with Sun's implementation of service-oriented architecture (SOA) using the company's Java Composite Applications Platform Suite (JCAPS), one might imagine that all the business users would be on the bandwagon. Wrong. "What I tell customers when I go talk to them is that it doesn't really matter that we work for Sun," Ricigliano said. "I have the same problems any other customer has. We have to keep our systems up. Messages have to continue to flow otherwise we don't make any money." We want to consolidate that using SOA into one place where we have common consistent processes across the company. So we're using one business process model. It will give flexibility around workflow and interaction, but it won't be another stovepipe system." While he can enthuse about the virtues of the JCAPS tools to solve this, one of his main problems has nothing to do with software at the bits and bytes level but everything to do with SOA. He has to get the elusive business user buy-in for the projects he is championing. What might be called the office politics issues of SOA implementation is something he has learned not from weekend seminars, but from the school of hard knocks. So his team began using business process demos. The trick is not to show business users how SOA works, but how SOA can work for them.

WfMC Counters XPDL Criticism, Argues Three Standards Count
Jason Stamper, Computer Business Review

The chair of the Workflow Management Coalition, Jon Pyke, has refuted the suggestion in a recent Computer Business Review article that the WfMC's XPDL standard has been a failure. Pyke pointed out that to date there are over 50 major business process management and application vendors that support the XPDL standard, including IBM, Oracle, BEA, Fujitsu, Tibco, and Global 360. Advertisement Pyke argued that the Workflow Management Coalition's XPDL standard, which is a standard for the storage and exchange of business process diagrams, is often incorrectly perceived to be competitive with the business process execution language, BPEL, standard. "There are only three key standards to really take notice of [in the business process modeling and notation space]," he said. "They are BPMN, XPDL, and BPEL. But just having three to focus on still manages to cause some concern and confusion." "Business process modeling notation is a standardized graphical notation for drawing business processes in a workflow," Pyke said. "BPMN's primary goal is to provide a standard notation that is readily understandable by all business stakeholders. BPEL is an 'execution language', the goal of which is to provide a definition of web service orchestration, the underlying sequence of interactions and the flow of data from point to point." As for XML process definition language, XPDL—a format standardized by the Workflow Management Coalition, WfMC—Pyke said its primary goal is to: "store and exchange the process diagrams, or specifically to allow one tool to model a process diagram, and another to read the diagram and edit, another to 'run' the process model on an XPDL-compliant BPM engine, and so on."

See also: XPDL references


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

Headlines

Sponsors