What is XAML?
Why is XAML important for the delivery of e-commerce solutions?
What kind of applications will XAML enable?
Who is supporting XAML?
Are other participants invited to join this initiative?
When will the work of XAML be made available to the public?
When is initial spec to be completed?
What standards body will XAML be submitted to?
How does XAML support/extend existing transaction monitors?
What is the relationship between XAML and other transaction protocols (XA)?
What is the relationship between XAML and JTS/JTA?
How does XAML relate to other Web Services standards?

How does XAML relate to registries (UDDI)?
How does XAML relate to service description languages (WSDL, XMI)?
How does XAML relate to business process modeling languages (ebXML business process, BPML)?
How does XAML relate to XML-based web service transport protocols (XP, SOAP, ebXML Transport)?
How does XAML relate to ebXML?
How does XAML relate to e-speak?
How does XAML relate to BizTalk/.NET?

What kind of applications will XAML enable?

As plug-and-play e-commerce emerges, businesses are mixing and matching web services from multiple partners to create sophisticated e-business applications. Because these "business webs" consist of loosely coupled web services distributed across the web from multiple businesses, coordination among these web services is imperative, in order to carry out business-level transactions. There needs to be the notion of a transaction at the web service level, as well as a means by which software systems can coordinate the processing of calls to multiple web services to provide higher-level business transactions.

Who is supporting XAML?
Bowstreet, Hewlett-Packard, IBM, Oracle and Sun are leading the XAML initiative to ensure distributed e-business transactions across the Internet. However, XAML is not owned by any one vendor. Instead, the standards proposal will be submitted to an appropriate open standards body to ensure that it remains an open industry standard in which any company and organization can participate.

Are other participants invited to join the initiative?
Once the specification reaches a stage when it can be reasonably submitted to a standards body, such as W3C, OASIS, or IETF, the XAML Group will submit the XAML specification. Any interested company is encouraged to participate in the evolution of XAML via the standards organization selected.

When will the work of XAML be made available to the public?
The target date for submission to a standards body is Jan 15, 2001.

What standards body will XAML be submitted to?
At this time, the XAML group has not determined which standards body is the most appropriate for XAML. However, as the specification evolves, the group will vote on an appropriate organization and submit a draft of the specification.

How does XAML support/extend existing transaction monitors?
XAML will enable web services to expose transactional semantics of the resources providing the services. Given that TP monitors commonly provide some of the management and coordination functions of these resources 'behind the firewall" today, one of the goals of XAML is to enable TP monitors to participate and support the transactional semantics offered by web services. This includes passing of transaction ID's through web service messages, and supporting the XAML web service operations of commit and cancel.

At the level above individual web services, there is a new layer of software providing business-level transactions. This software makes calls to multiple web services, often spanning business boundaries. Given that XAML enables individual web services to support transactional semantics, there is also an opportunity for XAML to specify standard means for coordinating business-level transactions across collections of web services.

To this end, one of the goals of XAML is to define message interfaces and interaction models that help software systems providing the business-level transactions to coordinate the interactions among web services. There is an opportunity to define XML interfaces and interaction models for a new breed of web services that would help software systems at the business transaction level. These services would provide brokering capabilities for managing the interactions among web services, for both web services supporting XAML, as well as web services that do not support XAML. This new breed of web services requires XML interfaces and interaction models that defines how software systems at the business transaction level would interact, to request assistance in shepharding a set of web services towards completion.

What is the relationship between XAML and other transaction protocols?
Classical online transaction management (OLTP) is the process of making simultaneous changes in several places “atomically” - that is, all the changes related to a transaction are made or none of the changes are made.

For example, within a single database connection, the DBMS provides some means of demarcating the beginning and end of a transaction. This demarcation ensures that changes to the database are made atomically.

Sometimes, changes must be made atomically across multiple databases. For example, an insurance company might have to change both its claims information and its audit information at the same time, even though the audit information is in a separate database from the claims information. This multiple-database change would ensure that, during a later audit, the company would know which agent took the first report of the loss.

In this case, the existing XA (Transaction Authority) protocol is useful. XA provides a standard mechanism for coordinating changes to multiple databases (called resource managers or RMs) as an atomic unit of work. Basically, the XA protocol asks each RM to vote on whether a commit will be successful. Once an RM has voted “yes,” it must be able to commit the open unit of work without failure. The commit occurs only if all RMs vote “yes.” This process of obtaining a vote, and then performing a commit, is called a “two-phase commit.”

Resource managers are most frequently databases, but they can also be message-oriented middleware. XA allows completely heterogeneous collections of RMs within a single transaction; for example a transaction can commit across DB/2 and Oracle at the same time. All major database vendors support XA.

What is the relationship between XAML and JTS/JTA?
J2EE includes support for distributed transactions through two specifications, Java Transaction API (JTA) and Java Transaction Service (JTS). JTA is a high level, implementation independent, protocol independent API that allows applications to access transactions. JTS specifies the implementation of a Transaction Manager which supports JTA and implements the Java mapping of the OMG Object Transaction Service (OTS) 1.1 specification using the IIOP protocol. The JTA API allows you to demarcate transactions in a manner that is independent of the transaction manager service or JTS.

While JTA provides an API for demarcating transactions in Java-based application logic, XAML provides an agreed upon protocol or a coordinated process of interaction among transactionally-aware web services over a defined transport. Given this, a web service internally implementing JTA could expose these transactional capabilities using XAML.

How does XAML relate to other Web Service standards?
In order to understand how XAML relates to many of the existing standards, it is first necessary to understand what function each of these standards performs.

When a web service is built, described, discovered and used, there are many elements that will be required. The combination of these many different elements is called a web services architecture. Some categories of these elements are: registries, business process modeling, negotiation, service description and web service transport protocols.

In order to use a web service, the existence of the service must be discovered. This discovery usually takes place in a "phone book" of web services known as a registry. Registries, such as UDDI and the ebXML registry/repository, contain human readable information that can be browsed and searched to find companies and their services.

Once a desired service is located, the terms of use can be reviewed and/or negotiated. The e-speak framework provides an elaborate negotiation mechanism. ebXML addresses the same issue through TPAML (Trading Partner Agreement Markup Language.)

Now that you know which service you need, you still have to know some additional things before you can use the web service; where is it located, what type of input it expects, what type of output it produces, which web service protocols it uses, etc. Service description languages, such as WSDL, provide a standard mechanism to outline all these details about a web service. Typically, for publicly available web services, their service descriptions are also made publicly available. The URI of the service description can be registered with a web service in a registry.

Once you know those details, you can start formulating a message to send to the service. However, some web services will require special packaging wrapped around the message, letting the web service know what to do with the message.

In this situation, an underlying web service transport protocol may need to be used, which can provide:

XML-based web service transport protocols include: SOAP, XP (W3C XML Protocol) and ebXML Transport. Most of these web service transport protocols make use of existing protocols, such as: HTTP, SMTP, TCP, etc., to carry web service requests and responses across the internet.

Another layer in the web services architecture is business process modeling. These languages define the business level descriptions of what needs to be accomplished. For example, they can describe a business scenario such as, "if a purchase order is received by my purchasing web service, the steps that need to be completed are: check inventory; if the inventory is available, ship product; if product ships, let accounting know, etc."

Business process modeling languages determine what needs to be completed and the necessary order of completion. However, they do not control nor monitor the underlying transactions themselves, where XAML is used to initiate, monitor, commit, cancel, retry, or initiate a compensating transaction.

Consider this web services architecture example:

A distributor of groceries needs to process an order from ACME grocery store. Included in the order is an order for 100lbs of fresh tomatoes. The grocery distributor needs to process this order. In order to fulfill this order the web services architecture will be used in a variety of ways.

The first requirement (even before the distributor gets the order) is to discover that Johnny’s Tomato Farm and Jimmy’s Refrigerated Transport provide the necessary business services. Both services are discovered via a registry; in this case, the distributor searched several different registries.

The second action is to make sure the distributor's business web understands how to talk with each of these web services. This is done by downloading a service description for each of the two services. The registry entry indicated that Jimmy's Refrigerated Transport is described as an e-speak service; whereas, Johnny's Tomato Farm services are based solely on SOAP. An XML description is retrieved for the e-speak service and a WSDL document is retrieved for the SOAP service. Links to the service description documents were found in the registry entries.

An additional action must also happen before the order is placed. The business process model of a purchase order must be executed. 1)check to make sure that the person ordering is authorized to order; 2)check to make sure the ordering company has paid their last invoice; and 3)proceed to order the merchandise by ensuring that both services get managed using XAML. This entire business process is defined by an ebXML business process model. Some additional models may need to be set up…. If the item is perishable, then verify the transport availability, etc.

Now, the grocery distributor is ready for action and can accept a tomato order from ACME grocery store.

The order from ACME grocery store is taken via the distributor’s business web, and according to the business process model, the person is authorized and the finance department gives the approval. The transaction is begun on a business level. Because Tomatoes are marked as perishable, the "perishable food" model is initiated.

This model determines the business logic which states that transport must be arranged before tomatoes can be officially ordered. This logic is then used by the software that coordinates the calling of the relevant web services. The calling system prepares a message directed to a web service at Johnny's Tomato Farm using SOAP, along with XAML to specify initiation of the transaction. In like manner, the system requests a web service at Jimmy’s Refrigerated Transport to supply the truck and driver, again using XAML to stage the request. Once both web services have responded confirming availability, the calling system interacts with the web services using XAML to facilitate the completion of the business process.

How does XAML relate to registries (UDDI)?
UDDI defines a registry for companies and their services. In a typical scenario using UDDI, a user/program would browse through categories (like in a yellow pages) for a particular service. Once the desired XML service is found, the 'service description' for that service can be used to retrieve the details of calling that service (see service description languages section.) The ‘service description’ (WSDL, etc), defines the semantics of calling a specific service.

As with any other type of service, XAML services will be able to be registered and located within UDDI registries. UDDI can register XAML services.

How does XAML relate to service description languages (WSDL, XMI)?
Services description languages define the details that are needed to use a web service. Typically that includes: schema for the input, schema for the output, URI of the service, type of transport used (SOAP, XP, HTTP GET, ...) The XAML group will consider providing binding information to service description languages.

How does XAML relate to business process modeling languages (ebXML business process, BPML)?
BPML covers dimensions of business process modeling that are specific to processes internal to the enterprise, including business rules, security roles, distributed transactions, and exception handling. XAML is targeted at coordinating business transactions that span web services crossing corporate boundaries.

How does XAML relate to XML-based web service transport protocols (XP, SOAP, ebXML Transport)?
XAML is designed for the coordination of transactional web services, not XML transportation and packaging issues. XAML will work with standard XML-based service transport protocols, including W3C XML Protocol (XP), SOAP and ebXML transport protocol.

How does XAML relate to ebXML?
ebXML is an OASIS/UN initiative to define all the layers in the web services stack. That includes categories such as registries, business process modeling, service descriptions, and transport/packaging/messaging. Please refer to the above explanation for details on how XAML relates to each of these categories.

How does XAML relate to e-speak?
E-speak is an open software platform designed for supporting the description, registration, and discovery of e-services, the ability to compose multiple e-services into higher-level e-services, the ability to negotiate among e-services, and the ability to manage e-service interactions. XAML will enhance the e-speak platform for the coordination and processing of online business transactions involving e-services. XAML provides e-speak with a standard set of XML message formats and interaction models for e-services to use to provide business level transactions that span across companies over the Internet.

How does XAML relate to BizTalk/.NET?
BizTalk/.Net is a Microsoft initiative to define all the layers in the web services stack. That includes four categories, registries(UDDI), business modeling languages (X-Lang), service descriptions (WSDL), and transport/packaging/messaging(SOAP). Please refer to the above explanation for details on how XAML relates to each of these categories.