OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Web Services Framework Interoperability (Was Re: [xml-dev] Web Services

[ Lists Home | Date Index | Thread Index ]

Yesterday I was discussing the topic of Web Services framework
interoperability with a vendor - and I wonder if we're headed down a
challenging path here.

[Please note that my usage of 2 specific Web Services frameworks here is
not in any way a criticism of either framework, or a statement that they
cannot interoperate. I am simply using them for example purposes.]

Consider this: Two organizations are using 2 separate Web Services
frameworks, and would like to inteoperate. Let's say for example that
one is using GXA (Global XML Web Services Architecture), and the other
is using WS-CAF (described below). Let's also assume that we've moved
ahead X time periods, and both are widely available in various vendor
products.

Both of these frameworks contain "transactional specifications" - GXA
has WS-Transaction (which utilizes WS-Coordination), and WS-CAF has
WS-TXM (which builds on WS-CF). As an example, WS-TXM defines three
transaction models that address different use cases in current
business-to-business interactions - these are:

(1) ACID transaction: Uses a traditional 2-phase commit protocol with
rollback capability
(2) Long running action: Does not necessarily possess ACID properties
(3) Business process transaction: Responsible for performing some
application-specific work

GXA's WS-Transaction/WS-Coordination contain roughly similar models.

So my observation is this: 

- Suppose a process based on GXA wants to interact with a process based
on WS-CAF;

- Suppose further that the WS-CAF process is in the midst of (for
example) rolling back a transaction, so it is "not available" for the
brief time being to interact with the GXA-based process

How can the GXA-based process recognize that the WS-CAF process is in
the state that it is in (or would this not be necessary because a new
thread would be created on the WS-CAF side)? It must know what it is
required to recognize that the WS-CAF process is in the midst of rolling
back a transaction, because (presumably for this example) the
representation of a "rollback state" for the WS-CAF might be different
that that of GXA.

Is this a concern for interoperability? It seems to me that some sort of
middleware product that translates between the two frameworks might be
required.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton


Chiusano Joseph wrote:
> 
> Just across the wire [1] - a new Web Services framework called "WS-CAF":
> 
> <Excerpt>
> A draft set of specifications for the Web Services Composite Application
> Framework (WS-CAF) has been published by Arjuna Technologies Limited,
> Fujitsu Software, IONA Technologies PLC, Oracle Corp and Sun
> Microsystems. WS-CAF is an "open, multi-level framework for standard
> coordination of long-running business processes across multiple,
> incompatible transaction processing models and architectures. WS-CAF is
> compatible with current related specifications and does not require the
> implementation of a new transaction protocol."
> </Excerpt>
> 
> This framework appears to overlap with several aspects of GXA (Global
> XML Web Services Architecture), of which OASIS WS-Security is a part.
> The following three specifications comprise WS-CAF:
> 
> (1) Web Service Context (WS-CTX):
> 
> A lightweight framework for simple context management that helps enable
> all Web services participating in an activity share a common context and
> exchange information about a common outcome.
> 
> (NOTE: This appears to be similar to the "coordination context" that is
> passed between message exchange participants as part of GXA's
> WS-Coordination specification)
> 
> (2) Web Service Coordination Framework (WS-CF):
> 
> A sharable mechanism that manages context augmentation and lifecycle and
> provides the notification of outcome messages to Web services
> participating in a particular transaction.
> 
> (NOTE: This appears to be similar to the general nature of GXA's
> WS-Coordination and WS-Transaction specifications)
> 
> (3) Web Services Transaction Management (WS-TXM): Comprised of three
> distinct, interoperable transaction protocols that can be used across
> multiple transaction managers. WS-TXM supports multiple transaction
> models to help enable participants to negotiate outcomes with each other
> and make a common decision about how to behave, especially in the case
> of failure, regardless whether the execution environment is CORBA,
> Enterprise JavaBeans (EJB), .NET, Java Message Service (JMS), or some
> combination.
> 
> (NOTE: In addition to GXA's WS-Coordination and WS-Transaction
> specifications, this appears to have aspects that are similar to GXA's
> WS-ReliableMessaging specification)
> 
> Kind Regards,
> Joe Chiusano
> Booz | Allen | Hamilton
> 
> [1] http://xml.coverpages.org/ni2003-07-29-a.html
> 
>   ------------------------------------------------------------------------
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS