[June 06, 2001] XLANG is a "notation for the specification of message exchange behavior among participating web services" supporting especially the automation of business processes. XLANG "is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows. XLANG is an "XML business process language which provides a way to orchestrate applications and XML Web services into larger-scale, federated applications by enabling developers to aggregate even the largest applications as components in a long-lived business process. XLANG has a two-fold relationship with WSDL. An XLANG service description is a WSDL service description with an extension element that describes the behavior of the service as a part of a business process. XLANG service behavior may also rely on simple WSDL services as providers of basic functionality for the implementation of the business process." The draft specification for XLANG (2001-05) uses an informal BNF style for the abstract syntax. A complete 'XSD Schema' is provided in Appendix A.
From the 2001-05 draft:
Motivation: "There are two trends coming together in the world of e-commerce that are creating enormous opportunities and pressures for automation of business processes across business boundaries. One is enabling technology: the XML-based open protocols, and description and discovery standards that are growing up around SOAP. Programmatic service integration based on XML, SOAP, WSDL, and UDDI is clearly going to become increasingly seamless as interoperable implementations become commonplace. . .The other trend is a business imperative: the pressing need to truly realize the potential and promise of e-commerce by creating virtual enterprises, networks of applications that automate business processes across enterprise boundaries... One key requirement in actually making cross-enterprise business process automation happen is the ability to describe the public/contractual aspects of these business protocols in a standard form that can be consumed by tools for process implementation and monitoring. Enterprise workflow systems today support the definition, execution and monitoring of long-running processes that coordinate the activities of multiple business applications. But they do not separate internal implementation from external protocol description... As business protocols proliferate and evolve more rapidly, the social processes necessary for dissemination, common understanding, and enforcement of paper protocols will break down as a result of their inability to scale. Progress in business process automation will be halted unless the specification of protocols is formalized to the point where their enforcement can be automated. Such protocol specifications must serve as the basis for automated protocol enforcement engines that can track the state of protocol instances and detect protocol errors in message flows. This is the primary motivation driving the development of XLANG."
Goal: "...the goal of XLANG is to make it possible to formally specify business processes as stateful long-running interactions. Business processes always involve more than one participant. The full description of a process must show not only the behavior of each participant, but the way these behaviors match to produce the overall process. The focus is on the publicly visible behavior in the form of messages exchanged. Each participant clearly implements its behavior using some private means. The details of these private implementations are not a part of the business protocol, and XLANG provides no means to specify them. XLANG aims to specify all the behavior and only the behavior that the participant explicitly wants partners to understand in designing their own service processes. The specific high level feature categories that define the scope of XLANG are listed below. (1) Sequential and parallel control flow constructs; (2) Long running transactions with compensation; (3) Custom correlation of messages; (4) Flexible handling of internal and external exceptions; (5) Modular Behavior Description; (6) Dynamic service referral; (7) Multi-role contracts.
References:
XLANG: Web Services for Business Process Design. By Satish Thatte (Microsoft). Abstract and status: "Automation of business processes based on web services requires a notation for the specification of message exchange behavior among participating web services. This document specifies such a notation. We call it XLANG. XLANG is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows. This is an initial public draft release of the XLANG specification that focuses on the language constructs used to define the behavior of an individual web service that participates in business processes. We also address the approach to combining such services into multi-party business processes. This release does not provide detailed examples and tutorial exposition. We anticipate a number of extensions to the feature set of XLANG that are discussed briefly at the end of the document." [cache 2001-06-06]
XLANG XSD Schema. [Extracted from the 2001-05 draft]
"Microsoft Continues Web Service Leadership With New XML Specs." By David Smith [Gartner Internet Strategies]. 25-May-2001. ['Microsoft's posting of specifications for three XML technologies again shows its leadership in developing Web service standards and may herald another cooperative effort with IBM to get a new standard approved by the World Wide Web Consortium (W3C)'] "...The announcement of these new specifications indicates Microsoft's continued leadership in XML standards development. Microsoft has previously demonstrated with SOAP, WSDL and, to some extent, UDDI that its first step toward standardization of these technologies is to post the specifications publicly. Six to 12 months later Microsoft submits the specifications to a standards organization, typically the W3C. That body's working group for XML Protocols (XMLP), which focuses on standardizing specifications for Web service technologies, is scheduled to produce its final recommendations by August 2001 and to disband by April 2002. Gartner believes Microsoft's introduction of these three technologies will convince W3C to extend the XMLP Working Group to focus on additional technologies and will extend the group by at least one year (0.8 probability). The addition of SOAP-RP allows SOAP to be routed through intermediate transports. Although SOAP 1.1 was already independent of HTTP transport, a single transport was required for an entire SOAP interaction. DIME allows for richer binary content such as images and audio to be more efficiently handled in an infrastructure optimized for XML text-based payloads. XLANG, the language implemented in BizTalk, which allows orchestration of Web services into business processes and composite Web services, is perhaps the most important of the three new specifications. Microsoft previously achieved recognition for WSDL by working with IBM. History may repeat itself here since IBM now has a similar technology to XLANG: In April, IBM published WSFL (i.e., Web Services Flow Language). Gartner expects IBM and Microsoft to jointly agree to submit a proposal to W3C that combines XLANG and WSFL by year-end 2001 (0.7 probability)..."
"Microsoft Publishes XML Web Services Specifications." 2001-06-06.
"Web Services Description Language (WSDL)" - Main reference page.
[November 24, 2000] "Talking in XLANG." By Eric Binary Anderson. In ent - The Independent Newspaper for Windows NT Enterprise Computing [Online] Volume 5, Number 19 (November 22, 2000). "Despite the bevy of features for manipulating messages, the most interesting feature for developers is BizTalk's ability to create long-running business processes. Microsoft created a new language called XLANG -- pronounced slang -- for describing any business process. XLANG is a complete language that uses XML as the written format for the definition. Interestingly, Microsoft claims it chose XML so businesses can share process definitions across multiple platforms, presumably even non-Microsoft platforms. Although you can read and edit XLANG code in any editor, you'll most likely work with it using the BizTalk Application Designer. The designer is a graphical business process flow-charting tool that produces executable XLANG schedules. It is refreshing to finally see analysis, design, and coding converge into a simple process. While most complex desktop applications still defy efforts to use modeling tools in place of manual coding, I found that integrating business processes works naturally in the BizTalk environment. The added bonus of using a visual designer to create a business process is that the resulting design is self-documenting. XLANG schedules execute inside the BizTalk Orchestration engine. The orchestration engine is a finite-state machine that can process the various operations coded in XLANG. These operations include decisions, loops, forks, joins, actions, and transactions. BizTalk has an interesting concept of a transaction. Transactions are typically groups of all-or-nothing events. Many of us have been trained that executing transactions across enterprises requires a two-stage commit, requiring all involved applications to ensure that they can commit individually before the overarching transaction can commit. However, a two-stage commit can cause performance bottlenecks and force applications to stop functioning if any dependent process is unavailable... BizTalk has the potential to rewrite the rules of business process automation. However, as mentioned in our review of BizTalk last issue, it is not a simple product to install or manage. You won't necessarily want to choose BizTalk to simply replace a handful of .BAT files. However, if you have a need to automate both internal and external processes, primarily on Windows and Internet platforms, BizTalk will soon have you talking in XLANG."
See also: "Web Services Flow Language (WSFL)."
