Cover Pages: XML Daily Newslink: Tuesday, 02 June 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

Voice Extensible Markup Language (VoiceXML) 3.0 Published
Using JBoss ESB and JBPM for Implementing VMS Solutions
Up for Ballot: Web Services Dynamic Discovery (WS-Discovery) Version 1.1
Semantics and Syntax for XML Expression
Apache Foundation Announces Release of Apache CXF Version 2.2.2
Recommended Security Controls for Federal Information Systems and Organizations
Java Servlet 3.0 Specification Reaches Proposed Final Draft
Behavior-Driven Development Catches On

Voice Extensible Markup Language (VoiceXML) 3.0 Published
Scott McGlashan, Daniel C. Burnett, Rahul Akolkar, RJ Auburn (et al, eds), W3C Technical Report

Members of the W3C Voice Browser Working Group have published an updated Working Draft for the "Voice Extensible Markup Language (VoiceXML) 3.0" specification. A color-coded diff-marked version of this document is also available for comparison purposes. This 2-June-2009 Second Public Working Draft contains a number of reviewable changes relative to the previous draft. (1) A new Section 9 "Integration with Other Markup Languages" has been added to discuss integration with State Chart XML (SCXML), as in 'Embedding of VoiceXML within SCXML.' (2) Added clarification to the description in "2 Overview" and "3 Data Flow Presentation (DFP) Framework". (3) Added brief description on "Speaker Identification and Verification" functionality to Section "5.4 SIV (Speaker Identification and Verification) Resource". (4) New modules are added in Section 6.11 - 6.14 for Builtin Grammar Module, Data Access and Manipulation Module, External Communication Module, and Session Root Module. (5) Added Section "7.3 Maximal Profile" and Section "7.4 Convenience Syntax (Syntactic Sugar)".

VoiceXML 3.0 is a modular XML language for creating interactive media dialogs that feature synthesized speech, recognition of spoken and DTMF key input, telephony, mixed initiative conversations, and recording and presentation of a variety of media formats including digitized audio, and digitized video. The primary goal of this version 3.0 is to bring the advantages of Web-based development and content delivery to interactive voice response applications. In VoiceXML 3.0, the language is partitioned into independent modules which can be combined in various ways. In addition to the modules defined in this section, it is also possible for third parties to define their own modules. Each module is assigned a schema, which defines its syntax, plus one or more Resource Controllers (RCs), which define its semantics, plus a "constructor" that knows how to create them from the syntactic representation at initialization time. Only DOM nodes that have schemas and constructors (and hence RCs) assigned to them can be modules in VoiceXML 3.0.

Version 3.0 of VoiceXML also introduces the concept of a profile (language) which incorporates the syntax of several modules. For example, a VoiceXML 2.1 profile incorporates the syntax of most of the modules corresponding to the VoiceXML 2.1 functionality which will support most existing VoiceXML 2.1 applications. Thus most VoiceXML 2.1 applications can be easily ported to VoiceXML 3.0 using the VoiceXML 2.1 profile. Another profile omits the VoiceXML 2.1 Form Interpretation Algorithm (FIA). This profile may be used by developers who want to define their one own flow control rather than using the FIA. Profiles enable platform developers to select just the functionality that application developers need for a platform or class of application. Multiple profiles enables developers to use just the profile (language) needed for a platform or class of applications. For example, a lean profile for portable devices, or a full-function profile for servers-based applications using all of the new functionality of VoiceXML 3.0.

Using JBoss ESB and JBPM for Implementing VMS Solutions
Boris Lublinsky, InfoQueue

Vertical Market Solutions (VMS) is an organization within NAVTEQ that provides custom solutions for its clients, including mobility portals and connected navigation systems. These solutions combine both NAVTEQ-provided services and third-party services to deliver composite services and content in the customer-specific forms, including Web services, WAP, portals, etc. The challenge for VMS in responding to numerous sales opportunities as well as anticipating future customer requests requires the development of composable services that can be integrated quickly and easily into complete customer solutions. A middleware that enables the service integration is essential to delivering such systems. This article discusses how JBoss middleware platform, specifically JBoss ESB and jBPM (JBoss Business Process Management) can be used for building such systems.

Currently, NAVTEQ provides all of the functionality required for such solutions, including powerful location-based services such as Geocoding and Routing, traffic-related services such as information about accidents, traffic jam factors calculation and traffic alerts for a given route, and general ecommerce functionality including purchasing, authorization, and entitlements management.

The combination of JBoss ESB/jBPM provides a very powerful, extensible and flexible platform for the creation of service-oriented solutions based on the existing enterprise assets. It provides all the major components for implementing such solutions, including: (1) Flexible ESB platform, allowing easy combination of existing functionality with additional business and infrastructure processing required for service implementation (service pipelines). (2) Powerful transformation engine (Smooks), simplifying implementation of transformation from proprietary data models (provided by existing functionality) to semantic data models used by the solution. Tooling that supports visual definition of the transformation further simplifies such implementations. (3) Lightweight extensible jBPM implementation facilitates building composite services that are based on existing NAVTEQ functionality. The JBoss middleware assessment, presented in this article, is based on a several VMS solutions prototypes built within NAVTEQ. The prototype was based on the domain-specific model for management users, locations and routes and included several ESB services, implemented as both wrappers of existing Web services, and services implemented directly inside the SOA platform itself.

Up for Ballot: Web Services Dynamic Discovery (WS-Discovery) Version 1.1
Vipul Modi (Microsoft) and Devon Kemp (Canon), eds; OASIS Committee Specification

Members of the OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) Technical Committee have submitted a TC-approved draft of "Web Services Dynamic Discovery (WS-Discovery) Version 1.1" for consideration as an OASIS Standard. Voting by the OASIS membership will take place June 16, 2009 through June 30, 2009.

The OASIS WS-DD Technical Committee was chartered to define: (1) A lightweight dynamic discovery protocol to locate web services that composes with other Web service specifications; (2) A binding of SOAP to UDP (User Datagram Protocol), including message patterns, addressing requirements, and security considerations; (3) A profile of Web Services protocols consisting of a minimal set of implementation constraints to enable secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints.

The WS-Discovery Version 1.1 Committee Specification defines a discovery protocol to locate services. The primary scenario for discovery is a client searching for one or more target services. The protocol defines two modes of operation, an ad hoc mode and a managed mode. In an ad hoc mode, to find a target service by the type of the target service, a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client. To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client.

To minimize the need for polling in an ad hoc network, when a target service joins the network, it sends an announcement message to the same multicast group. By listening to this multicast group, clients can detect newly available target services without repeated probing. To scale to a large number of endpoints and to extend the reach of the protocol beyond the range of an ad hoc network, this specification defines a managed mode of operation and a multicast suppression behavior if a discovery proxy is available on the network. In managed mode, target services send unicast announcement messages to a discovery proxy and clients send unicast probe and resolve messages to a discovery proxy. To reduce multicast traffic, when a discovery proxy detects a probe or resolution request sent multicast on an ad hoc network, it sends an announcement for itself. By listening for these announcements, clients detect discovery proxies and switch to a managed mode of operation and send unicast probe and resolve messages directly to a discovery proxy. However, if a discovery proxy is unresponsive, clients revert to an ad hoc mode of operation.

To support networks with explicit network management services like DHCP, DNS, domain controllers, directories, etc., this specification acknowledges that clients and/or target services can be configured to behave differently than defined herein. For example, another specification may define a well-known DHCP record containing the address of a discovery proxy, and compliance with that specification may require client and target services to operate in a managed mode and send messages to this discovery proxy rather than to a multicast group. While the specific means of such configuration is beyond the scope of this specification, it is expected that any such configuration would allow clients and/or target services to migrate smoothly between carefully-managed and ad hoc networks.

See also: the announcement

Semantics and Syntax for XML Expression
Edmund W. Schuster and Hyoung-Gon (Ken) Lee, MIT Technical Report

This report was produced by members of MIT's Laboratory for Manufacturing and Productivity (LMP), an interdepartmental laboratory in the MIT School of Engineering devoted to exploring new frontiers in manufacturing. The laboratory seeks to establish a rational foundation for manufacturing based on a systematic understanding of the complex interactions among the many areas of manufacturing. Research along those lines has led to innovation in manufacturing processes and better understanding of planning, design, and production operations. The document "Semantics and Syntax for XML Expression" is a new presentation on linking data and mathematical models, representing many years of work at the MIT Data Center Program.

Vision: Eliminate the boundaries between the Internet and Enterprise computing. The Internet Evolution incolves a Web of Information (HTML, static web pages), a Web of Things (Linking physical objects together, RFID, EPCglobal Network), and a Web of Abstractions (Interoperability, data and mathematical models; Computer languages and protocols for connections; Software as a Service - SaaS). Each year, the amount of data grows by as much as 40 - 60 % for many organizations. In 2004 alone, shipments of data storage devices equaled four times the space needed to store every word ever spoken during the entire course of human history... Industry needs a new form of organization for data to speed search and make connections quickly. Models are the means of analyzing data... Research, design, and implement a system for data and model integration that solves practical problems. The focus is manufacturing, agriculture, defense, and other industries...

Our research goals are to Solve the issue of semantics and syntax for XML; Achieve interoperability for data and mathematical models; Create an auxiliary language to integrate models/data; Apply to industry. Philosophy: Integrate IT standards with innovations — XML, Web Services, legacy data, and the M Dictionary. Internet transfer of data using XML requires prior agreement on semantics and syntax between the sender and the receiver of the data. This is a major limitation for XML. No universal standard exists, resulting in many forms of XML... Multiple standards make it difficult to merge data. Versioning occurs within the same standard. Over time, versioning is a significant problem.

The M Language is conceptually simple, consisting of three parts -- words, the dictionary, and rules. In M, words take on a new form that allows for easier machine understanding. The M dictionary provides the definitions for words, the relationships between them, and auxiliary information about them.Rules provide guidelines about how to place words together for representing data or models in a common format that is interoperable... The M Dictionary is a list of words that combines traditional definitions with semantic relationships and well-defined data formats. The source for the original definitions and relationships were obtained from the Princeton University WordNet. We have since modified the dictionary structure, added new terms and relations, created an editing user interface and built various tools and web services needed for an inter-networking language..."

Apache Foundation Announces Release of Apache CXF Version 2.2.2
Daniel Kulp, Apache CXF Team Announcement

Members of the Apache CXF Development Team have released version 2.2.2 of the CXF open source services framework. This is mostly a patch release to fix problems and issues that users have encountered with 2.2.1 resolving 23 JIRA items. However, this release is also the first release to pass the JAX-RS 1.0 TCK thus providing a complete JAX-RS 1.0 implementation.

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.

CXF includes a broad feature set, but it is primarily focused on the following areas: (1) Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security. (2) Frontends: CXF supports a variety of "frontend" programming models. CXF implements the JAX-WS APIs (version 2.0 will be TCK compliant). It also includes a "simple frontend" which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java. (3) Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more. (4) Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.

See also: the CXF FAQ document

Recommended Security Controls for Federal Information Systems and Organizations
Patrick D. O'Reilly, NIST Announcement

NIST has announced the release of a final public draft for Special Publication 800-53, Revision 3, "Recommended Security Controls for Federal Information Systems and Organizations." Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology (NIST). The Public comment period is June 3, 2009 through July 1, 2009. "For the first time, and as part of the ongoing initiative to develop a unified information security framework for the federal government and its contractors, NIST has included security controls in its catalog for both national security and non national security systems. The updated security control catalog incorporates best practices in information security from the United States Department of Defense, Intelligence Community, and Civil agencies, to produce the most broad-based and comprehensive set of safeguards and countermeasures ever developed for information systems.

The standardized set of management, operational, and technical controls provide a common specification language for information security for federal information systems processing, storing, and transmitting both national security and non national security information. The revised security control catalog also includes state-of-the-practice safeguards and countermeasures needed by organizations to address advanced cyber threats capable of exploiting vulnerabilities in federal information systems. The important changes in Special Publication 800-53, Revision 3 are part of a larger strategic initiative to focus on enterprise-wide, near real-time risk management; that is, managing risks from information systems in dynamic environments of operation that can adversely affect organizational operations and assets, individuals, other organizations, and the Nation. The final publication of Special Publication 800-53, Revision 3 is targeted for July 31, 2009.

Java Servlet 3.0 Specification Reaches Proposed Final Draft
Charles Humble, InfoQueue

A major goal of the Servlet 3.0 specification is to allow the deployment of servlets, filters and listeners without needing to resort to manual editing of an application's web.xml file. New features include: (1) Use of annotations for filters and servlets which may be deployed without the need for a web.xml entry. (2) Support for "web fragments", through which developers can supply configuration information without requiring the manual editing of the 'web.xml' file. XML fragments are placed in '/META-INF/web-fragment.xml' and can contain almost all the same elements that the web.xml descriptor uses. The XML fragments are processed by the container during deployment and the final descriptor is assembled. (3) Programmatic configuration of filters and servlets from ServletContextListeners, which are potentially discovered in '/META-INF/*.tld' files within jars.

At the Early Draft Review stage these features proved controversial, with some expert group members concerned that the possible deployment of unintended filters and servlets, either accidentally or as a consequence of deliberate obfuscation, represented a serious security risk. In a highly critical blog expert group member Greg Wilkins described the specification as "a poor document and the product of a discordant expert group (EG) working within a flawed process." The Proposed Final Draft has addressed the majority of these concerns with the ability to specify an absolute ordering of jars, which also allows individual jar files to be excluded.

As well as these ease of use features, JSR-315 adds support for Asynchronous requests allowing the thread to return to the container and perform other tasks. This too proved controversial as the expert group struggled to make the existing RequestDispatcher handle asynchronous redispatch. The resulting API, which added 20 methods and 3 new interfaces to the specification, was widely criticized for complexity at the public review stage. The Proposed Final Draft defines a specific dispatch type, AsyncContext.dispatch, which is used for asynchronous requests and has simplified the API considerably.

Behavior-Driven Development Catches On
Paul Krill, InfoWorld

Behavior-driven development (BDD), which helps users get more involved in describing an application's intended behavior, is becoming popular with developers, who are now latching on to tools that fit into the BDD vein. It's particularly relevant to agile application development approaches. In BDD, application stakeholders as well, analysts, and testers are brought together to determine requirements. BDD features tests written in plain text. "Test-driven development, BDD, executable specifications—all of that is becoming more popular and is the future," says agile development coach Warren Elliott. How behavior-driven development works: BDD is an evolution of test-driven development that brings the customers into the picture, says Aslak Hellesoy, creator of the Cucumber BDD tool and a consultant at Norway's Bekk Consulting. BDD lets the customer write tests that everyone understands with assistance from developers and testers.

Dan North of ThoughtWorks is credited with coining the term "BDD" around 2003. "The BDD approach holds that an idea for a requirement can be turned into an implemented, tested, production-ready code as long as the requirement is specific enough that everyone knows what is going on... To do this, a way to describe the requirement is needed so that everyone from businesspeople to analysts, developers, and testers have a common understanding of the scope of the work. Parties agree on a common definition of "done." In the BDD approach, a BDD "story" is developed, featuring a description of a requirement, a business benefit, and criteria for completeness. A story could be developed, for example, for an application for withdrawing cash from an ATM.

Aslak Hellesoy advises against using BDD in a traditional, waterfall method of application development. "I would only use it on an agile project," he says, because BDD treats the specification as a living, changing document. "You can't possibly come up with it up front," he says, which methods such as waterfall require. Tools leveraging BDD concepts include Cucumber, RSpec, JBehave, and FitNesse. They focus on different aspects of application development and testing, so can be complementary.


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

Headlines

Sponsors