The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: June 20, 2007
XML Daily Newslink. Wednesday, 20 June 2007

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:

W3C Publishes Final Recommendations for the Speech Interface Framework
Matt Oshry, Luc Van Tichelen (et al., eds), W3C Recommendations

W3C announced that two new published standards enhance the capabilities and interoperability of voice browsers and speech recognition systems. The W3C Voice Browser Working Group has completed work on both VoiceXML 2.1 and Semantic Interpretation for Speech Recognition (SISR) 1.0, two critical pieces of W3C's Speech Interface Framework. "Voice Extensible Markup Language (VoiceXML) 2.1" is used daily in millions of telephone calls, VoiceXML enables rapid development of audio dialogs. Version 2.1 extends the language with eight commonly implemented features including dynamic access to grammars and scripts. Completely interoperable, VoiceXML 2.0 applications will work under VoiceXML 2.1 without modification. The second specification, "Semantic Interpretation for Speech Recognition (SISR) Version 1.0," defines the process of Semantic Interpretation for Speech Recognition and the syntax and semantics of semantic interpretation tags that can be added to speech recognition grammars to compute information to return to an application on the basis of rules and tokens that were matched by the speech recognizer. In particular, it defines the syntax and semantics of the contents of Tags in the Speech Recognition Grammar Specification (SRGS). The results of semantic interpretation describe the meaning of a natural language utterance. The current specification represents this information as an ECMAScript object, and defines a mechanism to serialize the result into XML. The W3C Multimodal Interaction Activity (MMI) is also defining an XML data format 'EMMA' for containing and annotating the information in user utterances.

See also: the announcement

Enterprise Application Integration with Microsoft BizTalk Server 2006
Rick Garibay,

BizTalk Server has grown beyond just messaging and orchestration to include a Business Rules Engine, Human Workflow Services, Enterprise Single Sign On, and Business Activity Monitoring—all of which are significant components. Part 1 of this article series provides a conceptual overview of BizTalk Server 2006 and how it serves to address the problem domain common in the EAI space. Part 2 introduces a business case for implementing an online ordering and fulfillment system and provides a step-by-step example of how to implement a solution that addresses the problem domain. Microsoft BizTalk Server 2006 is the fourth release of Microsoft's flagship messaging and business process management platform; it provides a messaging solution and complementary toolset for addressing many of the design goals typical in common EAI scenarios. Design goals such as availability and reliability often fall beyond the reach of traditional Web services. Built entirely on the .NET Framework, Microsoft BizTalk Server 2006 (BTS 2006) provides the foundation for business process automation and messaging, two key areas that are common within many integration scenarios. Through its support of messaging and workflow, BTS 2006 is a powerful addition to the EAI space, introducing revolutionary advances in multi-protocol messaging, business process design, management, and debugging. The intuitive Orchestration Designer (installed as part of Visual Studio 2005) provides a glimpse into the future of building modern, workflow-modeled software. At its core, BTS 2006 is comprised of the Messaging Engine and Orchestration Engine. Both components are mutually exclusive and each addresses a very specific, yet complementary aspect of application integration. BizTalk Server 2006 features much more than messaging and orchestration. I will give you a high-level overview of the various messaging and orchestration concepts and corresponding development and deployment-time artifacts before I walk you through an application integration project with BTS 2006...

Tibco Business Studio Software Links BPM with SOA
Paul Krill, InfoWorld

With a new release of its business process management software now available, Tibco Software said it is enabling a tighter link with SOA and delivering a more integrated user experience. Featured in version 10.6 is a suite of application modules designed to provide end-to-end process management. Tighter integration with Tibco Business Studio, for process modeling and design, gives iProcess Suite users the ability to directly deploy business processes built in Business Studio. Fine-grained integration is offered between Tibco's SOA layer, provided by Tibco BusinessWorks, and its BPM layer, with iProcess Suite. Featured is the ability to query for details such as transaction case numbers, make audit-trail entries, graft sub-procedures and step through an SOA layer to a BPM process. More granular process monitoring capabilities are included, with users able to monitor sub-processes. An example of a sub-process could be a credit card check process reused in new account openings. Also included in version 10.6 is iProcess Workspace, which packages user-facing functionality for a more seamless user experience for process designers and participants. Role-based enhancements are offered in the product, determined by user profiling and analysis. Scalability, meanwhile, has been improved to monitor a broad range of business processes. Tibco with the new product also improved in-memory caching, which allows for work items to be assigned out to individuals.

Let's Have a Conversation: MEPS, Choreography, Orchestration, Rules
Gregor Hohpe, IEEE Internet Computing

Defining a conversation policy is important in establishing service contracts between providers and consumers, but doing so can be a complicated task. Luckily, we have several approaches from which to learn. An expressive service should provide sufficient information to ensure smooth interaction between the provider and consumers. This includes a description of which conversations it can support. Is the consumer allowed to resend a request, for example? Does the consumer have to be prepared to receive more than one response message? More generally, in which order can service operations be invoked? A comprehensive service contract should be able to answer such questions in addition to describing the message data format... Patterns - (1) Message-exchange patterns: Given the challenges in creating a correct conversation policy, one approach would be to simply enumerate a few common conversations and have services choose which to implement. WSDL follows this approach with the concept of message-exchange patterns (MEPs). WSDL 1.1 defines four transmission primitives, comprising sequences of input and output operations: one-way, request-response, solicit-response, and notification. (2) Choreography: A conversation policy primarily concerns what happens between communicating parties—that is, who is allowed (or expected) to send messages to whom and in what order. At any point, we can consider the conversation to be in a specific state. Choreography's strength is that it extends well beyond simple two-party conversations. However, because the choreography isn't executable, it is conceptually rather abstract and can be more difficult to test and debug. (3) Orchestration: Most service contracts view the conversation from the provider's perspective, establishing rules that any potential consumer must observe: a process containing send and receive primitives executing inside the service can orchestrate the interaction between the service, its consumer, and potential collaborators. Web Services Business Process Execution Language (WS-BPEL) is currently the most popular language for defining processes in SOA environments. (4) Rules: It might seem natural to define a set of rules that the conversation must obey—for example, 'after sending an invoice, a payment must follow' or 'whenever the service receives a message, it replies immediately with an acknowledgment.' The Soap Service Description Language (SSDL) supports a declarative rule-based approach.

See also: SOAP Service Description Language

Using UML Service Components to Represent the SOA Architecture Pattern
Prithvi Rao, IBM developerWorks

As an architect, you are often challenged by client enterprise architects and IT stakeholders to articulate Service-Oriented Architecture (SOA) patterns and service components in a nonproprietary, product-agnostic way. This article shows how to use Unified Modeling Language (UML) models to describe the SOA architecture pattern and its associated service components. You also learn about the service components of the SOA pattern in the context of industry-standard UML formats to help stakeholders to better understand the components that constitute an SOA. In its simplest form, the SOA pattern consists of a decoupled Enterprise Service Bus (ESB) that connects and provides interactive services among the requestors and providers. ESB also provides the common connectivity and virtualization of services. To address the latest business application demand, the ESB leverages the Service Component Architecture (SCA) programming model. The ESB uses a mediation component (module) that is based on SCA modules to mediate messages between service requestors and service providers. The mediation services in the ESB can thus be tailored to form complex mediation patterns that implement virtualization in the form of location and identity transparency. They can also improve upon the quality of service (QoS) requirements such as performance, encryption/decryption of messages, and reliable and secure content delivery and transactions. Process services use the business processes and mediation modules to accomplish its business flow requirements. Process services may use the SCA programming model to model the business services that consume and produce business data. SCA components consist of interfaces, references, and an implementation. Service components can have interfaces either in Java or WSDL port types. The processes can be long or short running; the short-running processes are called micro flows. The long-running business processes can interact with multiple partners, with interactions performed through standard, stateless Web service calls. The process model is validated using an extended XML schema for syntax and a comprehensive set of rules applied for semantic constraints, as defined by the BPEL specification.

Using Smidump to Convert MIB to XSD
Yan Li (ed), IETF Internet Draft

The IETF Internet Draft "Accessing MIBs using NETCONF" describes a simple mechanism for accessing the Management Information Base (MIB), using the existing NETCONF (RFC 4741) RPC infrastructure. The MIB is a standard data model that most internetworking device vendors already support to provide interoperable management for their products. The Network Configuration Protocol (NETCONF) 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 NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Vendors could use the MIB, expressed in XML, as one type of data model for NETCONF. The libsmi tools already have an option to convert MIB modules into corresponding XML Schemas, so this will make it easier to use MIB data with netconf. MIB modules are written using an adapted subset of Abstract Syntax Notation One, ASN.1, which is called the Structure of Management Information (SMI). NETCONF encodes configuration data in XML, and the data model of NETCONF should be described using XML DTD or XML schema or other XML schema language. At the time of this writing, XML schema is preferred. Those MIB modules to be used with NETCONF should be rewritten in XSD, and for interoperability the resulting XML schema written by different people should have the same format. "Accessing MIBs using NETCONF" uses XML Schemas (XSDs) generated by smidump as data model. This memo depicts how the smidump tool converts a MIB to an XSD, and what the XSD looks like. Mapping of the Datatypes: Smidump provides an XSD file named smi.xsd, which selects some primitive types from SMI and maps them to the XSD bulid-in datatypes or its derived datatypes. Other types, even the types defined in the SMIv2, are derived from these primitive types, such as Counter32, TimeTicks. Appendix A in this memo provides the Smi.xsd File.

See also: Accessing MIBs using NETCONF

Call for Participation: W3C Workshop on XML Signature and Encryption
Staff, W3C Announcement

Position papers are due 14-August-2007 for the W3C "Workshop on Next Steps for XML Signature and XML Encryption," to be held September 25-26, 2007 in Mountain View, California, USA, hosted by VeriSign. Attendees will discuss next steps for the XML Signature and XML Encryption specifications and share their experiences implementing and developing these standards. the workshop is expected to investigate the following areas: (1) Interoperability and robustness issues, such as spurious validation errors; (2) Performance aspects of implementations of the XML security specifications; (3) The interaction of the existing suite of specifications with XML 1.1; (4) The effect of the ongoing work on Efficient XML Interchange on the XML security specifications; (5) Use cases and requirements that are either not addressed or are insufficiently addressed by the current suite of specifications, including legal requirements for digital signature formats; (6) Experience and consequences of building other specifications or standards with the XML Signature and XML Encryption suites of specifications as a basis; (7) Insights into the interaction of the XML Security specifications with the evolving XML environment. The Workshop is expected to give its recommendations to the XML Security Specifications Maintenance Working Group, chartered through December 2007. The Workshop is free and open to all; however, submission of position papers is required of all participants.

See also: W3C Workshops


XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc.
IBM Corporation
Sun Microsystems, Inc.

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: