I think we should be a little more cautious about the maturity of all these
specs, and have more of an eye to product completeness and maturity, including
ability to protect users from standards variation and flux.

The WS-Coordination and WS-Transaction (later WS-AT and WS-BA) specs have in
fact been out since August 2002 (we implemented them in Cohesions 2.0 in the
ensuing six months, alongside BTP). The specs were revised in September 2003,
and then again in November 2004. They have not changed vastly over these last
two years.

They are therefore not that new, and they unfortunately add very little to the
thinking or functionality of OASIS BTP, which was completed in June 2002 (and
which has the advantage of being a single spec, not two).

We therefore have (including the latest contender, WS-CAF) three families and
six protocols, to do one job: distributed service coordination using a two-phase
outcome approach. This is a symptom of how the standards need to settle down if
we are to see any level of genuine interoperability at work. They are useful
work, but customers need to be protected from this flux to make use of product
in this area.

Another manifestation of the earliness of *interoperable* loosely-coupled
transactions is the status of the specs. Unlike BTP, which has been through an
open standards process to become an OASIS Committee Draft 1.1, and reflects
product implementation experience, the WS-C+Tx specs are still in a proprietary
workshop process, and will have to go through a standards body to stabilize.
Don't expect stable output earlier than twelve or eighteen months from now. The
WS-CAF process also grinds slow, and the specs are changing a lot as they go.

The fact that IBM, Microsoft, IONA, Choreology and Arjuna demonstrated a pretty
reasonable degree of interoperability at a workshop is good, but it's only a
first step.

In fact the issue of interoperability is probably not the main issue when it
comes to useful product.

When looking at vendor offerings I recommend asking a few key questions that
will help evaluate maturity and utility:

0) Does the product look like a literal-minded translation of particular
interoperability specs or does it have a single API that shields the user from
the underlying coordination protocol, thereby insuring the user against
movement, flux and fashion in the immature world of such specs?

1) Does the product easily allow users to define recoverable participant
services, where the application defines how it "prepares" and how it confirms or
cancels? This facility allows the use of compensating underlying transactions,
and should support three models of use: do-compensate, validate-do, and most
generally -- provisional-final.

2) Does it support the concurrent use of predefined XA-compliant resources such
as JDBC drivers or JMS clients, along with app-defined participants within a
single transaction?

3) Does the product seamlessly integrate both single-phase and two-phase capable
resource managers (databases, queues) as persistence mechanisms for
application-defined recoverable participants in such a way as to ensure
application/resource manager synchronization, and therefore end-to-end
integrity.

4) Does the product allow checkpointing, to permit involvement of legacy or
non-transactional services (zero-phase resources), with maximum possible safety
and consistency?

5) Does the product treat atomic transactions and business
activities/transactions as two hermetically sealed worlds, or does it allow the
features of business transaction management (app-defined participants,
business-rule determined selective outcomes) to be combined with the use of
XA-compliant resources?

6) Does the product support a range of underlying transport protocols for
concurrent use within a single transaction, or is it restricted to SOAP
(excluding e.g. MOMs or Java RMI)?

7) Does the product allow the construction of transaction trees such that a
branch or sub-tree can be treated as a sub-transaction, including with
application-control over the outcome of the sub-transaction (e.g. selection of
the best price quote from several offers).

Alastair


Alastair J. Green
CTO and Director
Choreology Ltd
68 Lombard Street
London EC3V 9LJ
www.choreology.com


-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@...]
Sent: 16 March 2005 16:25
To: WS-TX-Workshops@yahoogroups.com
Subject: Re: [WS-TX-Workshops] Solving distributed TX'es through classic ACID,
fashionable WS'es or what?






Andre, you asked whether there were any "shrink-wrapped implementations" of
WS-AT and about momentum of the various standards. I can only speak for the
momentum of the set of standards that this group is focussed on. 5 separate
implementations participated in the interoperability workshop that we held
earlier this year for these specifications - see the summary of this event
posted to http://groups.yahoo.com/group/WS-TX-Workshops/files/
(specifically:
http://f1.grp.yahoofs.com/v1/8Ek4QgDu_IU-pndJARE31OBj1EdSsDI_iyGt5mU9yjkwrfHzBN9\
jUngQ7zDw91BrTCBwatCIqzlG5hx2onRYzGp3lrtueMU/Transaction-InteropResults012605.pd\
f)

I think this demonstrates that there is momentum behind these specs -
remember the specs were only published in Nov 2004. And there certainly are
"shrink-wrapped implementations" - for example WebSphere Application Server
V6 offers WS-AT support as described at:
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websp\
here.nd.doc/info/ae/ae/cjta_wstran.html

With respect to your scenario, the WAS link above describes an architecture
in which a J2EE application server is the IA, initiating a WS-AT
transaction as a consequence of an application making a web service request
while running under a J2EE (JTA) transaction. The partner in the WS-AT
transaction can be any web-service platform that supports WS-AT, which may
of course have a completely different runtime architecture. And WS-AT
interop between different runtime architectures was exactly what was
demonstrated at the interop event.


Regards,
Ian Robinson




              "torkveen"
              <andre.torkveen@s
              ensewave.com>                                              To
                                        WS-TX-Workshops@yahoogroups.com
              15/03/2005 08:39                                           cc

                                                                    Subject
              Please respond to         [WS-TX-Workshops] Solving
               WS-TX-Workshops          distributed TX'es through classic
                                        ACID, fashionable WS'es or what?











Dear fellow transactions-involved professional,

I who write you this am an IT architect working for a Norwegian
electrical energy/utilities company, Statkraft
(http://www.statkraft.com/).  We're in the process of building an
enterprise-wide SOA platform, using middleware from various vendors
(significant players are webMethods and SAP) to realize an ESB between
different Line-of-Business end-nodes.

One of the challenges we face is to come up with a consistent,
reliable and recoverable way of ensuring that end-nodes in our loosely
coupled environment are kept in synch in by some mechanism, - but
without resorting to synchronous means of communications
(participating parties are - and should be - unaware of each other)!

Our first idea was to see if we could «steal» some of the very
good
groundwork laid down through traditional OLTP, but hopefully without
having to employ all the advanced features, simply opting for a custom
implementation of the simplest semaphores.

The following scenario outlines a lightweight custom setup - any
comments would be highly appreciated!

* Either the initiating party (IA) itself or a centralized
    broker facility (equivalent of a resource manager of
    the OLTP era) sends a «BeginTransaction» message with
    a transaction ID to all participating applications (PAs).
    This transaction ID is then referred throughout the
    lifecycle of the following message conversations
* When all PAs have replied that they're listening,
    one or more messages are transmitted (large messages
    may be split up into several pieces, but that's out
    of scope here)
* During the run, one or more of the PAs can submit an
    «Aborted» message.  In that case, the resource manager
    will send a «Rollback» to all parties involved.
    Messages received before this point are then deleted
* If the resource manager doesn't get any «Aborted»
    messages within a defined period of time, the resource
    manager sends a «Prepare» message to all PAs. PAs can
    then open database transactions to their own underlying
    data stores (typically RDBMS'es), handle all received
    messages and answer either «Prepared» or «Aborted» to
    the resource manager. If «Prepared», the described
    RDBMS transaction will remain open
* If the resource manager receives «Aborted» from some
    PAs, «Rollback» is sent to all PAs. Any open transactions
    to underlying RDBMS stores are then terminated
* If the resource manager receives «Prepared» from all PAs,
    «Commit» is sent to all PAs. Open RDBMS transactions will
    then be completed

Then there's a second issue that I'd very much like to understand
better - unclear availability of shrink-wrapped implementations:

We've done a bit of «desktop research» to find a suitable
approach,
and it appears that neither the WS-* stack of specifications
(including WS-AT), the OASIS-promoted WS-CAF (including WS-TXM) or the
older OASIS BTP has gained major momentum.  Meaning there are few - if
any - working real-life product implementations that support any of
these.  I'll be glad to be corrected if I'm wrong!

BTW: The new specifications seem to substitute the old-fashioned ACID
«I»  (isolation) with after-the-fact compensations, and that
appear a
bit scary to many people.  Perhaps this is a contributing reason why
even vendors like webMethods and SAP have put their decisions and
implementations on the wait-and-see list?

Bst rgds,
André Torkveen
Statkraft AS




                            Yahoo! Groups Sponsor



                                ADVERTISEMENT
            (Embedded image moved to file: pic29579.gif)click here


  (Embedded image moved to file: pic26132.gif)




Yahoo! Groups Links
       To visit your group on the web, go to:
       http://groups.yahoo.com/group/WS-TX-Workshops/

       To unsubscribe from this group, send an email to:
       WS-TX-Workshops-unsubscribe@yahoogroups.com

       Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Yahoo! Groups Links

I will be out of the office starting  03/16/2005 and will not return until
03/18/2005.

I am travelling with limited connectivity until Friday
March 18. Please see Kelvin Lawrence or Diane Jordan for anything urgent.

I replied to Andre individually, but since it seems to be the norm to
send to the group ...

Hi Andre. Our product (ATS 4.0) which we demonstrated at the
interoperability workshop with IBM and Microsoft, supports the WS-AT,
WS-BA and WS-CAF specifications. We've sold this to a number of vendors
and are just about to do a press release with a fairly significant
player in the Web services space. Unfortunately I can't tell you at this
stage who they are, but I can say that you have definitely heard of them.

Please visit our Web site (www.arjuna.com) and let me know if you have
any questions.

Mark.

torkveen wrote:

>Dear fellow transactions-involved professional,
>
>I who write you this am an IT architect working for a Norwegian
>electrical energy/utilities company, Statkraft
>(http://www.statkraft.com/).  We're in the process of building an
>enterprise-wide SOA platform, using middleware from various vendors
>(significant players are webMethods and SAP) to realize an ESB between
>different Line-of-Business end-nodes.
>
>One of the challenges we face is to come up with a consistent,
>reliable and recoverable way of ensuring that end-nodes in our loosely
>coupled environment are kept in synch in by some mechanism, - but
>without resorting to synchronous means of communications
>(participating parties are - and should be - unaware of each other)!
>
>Our first idea was to see if we could «steal» some of the very
>good
>groundwork laid down through traditional OLTP, but hopefully without
>having to employ all the advanced features, simply opting for a custom
>implementation of the simplest semaphores.
>
>The following scenario outlines a lightweight custom setup - any
>comments would be highly appreciated!
>
> * Either the initiating party (IA) itself or a centralized
>   broker facility (equivalent of a resource manager of
>   the OLTP era) sends a «BeginTransaction» message with
>   a transaction ID to all participating applications (PAs).
>   This transaction ID is then referred throughout the
>   lifecycle of the following message conversations
> * When all PAs have replied that they're listening,
>   one or more messages are transmitted (large messages
>   may be split up into several pieces, but that's out
>   of scope here)
> * During the run, one or more of the PAs can submit an
>   «Aborted» message.  In that case, the resource manager
>   will send a «Rollback» to all parties involved.
>   Messages received before this point are then deleted
> * If the resource manager doesn't get any «Aborted»
>   messages within a defined period of time, the resource
>   manager sends a «Prepare» message to all PAs. PAs can
>   then open database transactions to their own underlying
>   data stores (typically RDBMS'es), handle all received
>   messages and answer either «Prepared» or «Aborted» to
>   the resource manager. If «Prepared», the described
>   RDBMS transaction will remain open
> * If the resource manager receives «Aborted» from some
>   PAs, «Rollback» is sent to all PAs. Any open transactions
>   to underlying RDBMS stores are then terminated
> * If the resource manager receives «Prepared» from all PAs,
>   «Commit» is sent to all PAs. Open RDBMS transactions will
>   then be completed
>
>Then there's a second issue that I'd very much like to understand
>better - unclear availability of shrink-wrapped implementations:
>
>We've done a bit of «desktop research» to find a suitable
>approach,
>and it appears that neither the WS-* stack of specifications
>(including WS-AT), the OASIS-promoted WS-CAF (including WS-TXM) or the
>older OASIS BTP has gained major momentum.  Meaning there are few - if
>any - working real-life product implementations that support any of
>these.  I'll be glad to be corrected if I'm wrong!
>
>BTW: The new specifications seem to substitute the old-fashioned ACID
>«I»  (isolation) with after-the-fact compensations, and that
>appear a
>bit scary to many people.  Perhaps this is a contributing reason why
>even vendors like webMethods and SAP have put their decisions and
>implementations on the wait-and-see list?
>
>Bst rgds,
>André Torkveen
>Statkraft AS
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>

Andre, you asked whether there were any "shrink-wrapped implementations" of
WS-AT and about momentum of the various standards. I can only speak for the
momentum of the set of standards that this group is focussed on. 5 separate
implementations participated in the interoperability workshop that we held
earlier this year for these specifications - see the summary of this event
posted to http://groups.yahoo.com/group/WS-TX-Workshops/files/
(specifically:
http://f1.grp.yahoofs.com/v1/8Ek4QgDu_IU-pndJARE31OBj1EdSsDI_iyGt5mU9yjkwrfHzBN9\
jUngQ7zDw91BrTCBwatCIqzlG5hx2onRYzGp3lrtueMU/Transaction-InteropResults012605.pd\
f)

I think this demonstrates that there is momentum behind these specs -
remember the specs were only published in Nov 2004. And there certainly are
"shrink-wrapped implementations" - for example WebSphere Application Server
V6 offers WS-AT support as described at:
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websp\
here.nd.doc/info/ae/ae/cjta_wstran.html

With respect to your scenario, the WAS link above describes an architecture
in which a J2EE application server is the IA, initiating a WS-AT
transaction as a consequence of an application making a web service request
while running under a J2EE (JTA) transaction. The partner in the WS-AT
transaction can be any web-service platform that supports WS-AT, which may
of course have a completely different runtime architecture. And WS-AT
interop between different runtime architectures was exactly what was
demonstrated at the interop event.


Regards,
Ian Robinson




              "torkveen"
              <andre.torkveen@s
              ensewave.com>                                              To
                                        WS-TX-Workshops@yahoogroups.com
              15/03/2005 08:39                                           cc

                                                                    Subject
              Please respond to         [WS-TX-Workshops] Solving
               WS-TX-Workshops          distributed TX'es through classic
                                        ACID, fashionable WS'es or what?











Dear fellow transactions-involved professional,

I who write you this am an IT architect working for a Norwegian
electrical energy/utilities company, Statkraft
(http://www.statkraft.com/).  We're in the process of building an
enterprise-wide SOA platform, using middleware from various vendors
(significant players are webMethods and SAP) to realize an ESB between
different Line-of-Business end-nodes.

One of the challenges we face is to come up with a consistent,
reliable and recoverable way of ensuring that end-nodes in our loosely
coupled environment are kept in synch in by some mechanism, - but
without resorting to synchronous means of communications
(participating parties are - and should be - unaware of each other)!

Our first idea was to see if we could «steal» some of the very
good
groundwork laid down through traditional OLTP, but hopefully without
having to employ all the advanced features, simply opting for a custom
implementation of the simplest semaphores.

The following scenario outlines a lightweight custom setup - any
comments would be highly appreciated!

* Either the initiating party (IA) itself or a centralized
    broker facility (equivalent of a resource manager of
    the OLTP era) sends a «BeginTransaction» message with
    a transaction ID to all participating applications (PAs).
    This transaction ID is then referred throughout the
    lifecycle of the following message conversations
* When all PAs have replied that they're listening,
    one or more messages are transmitted (large messages
    may be split up into several pieces, but that's out
    of scope here)
* During the run, one or more of the PAs can submit an
    «Aborted» message.  In that case, the resource manager
    will send a «Rollback» to all parties involved.
    Messages received before this point are then deleted
* If the resource manager doesn't get any «Aborted»
    messages within a defined period of time, the resource
    manager sends a «Prepare» message to all PAs. PAs can
    then open database transactions to their own underlying
    data stores (typically RDBMS'es), handle all received
    messages and answer either «Prepared» or «Aborted» to
    the resource manager. If «Prepared», the described
    RDBMS transaction will remain open
* If the resource manager receives «Aborted» from some
    PAs, «Rollback» is sent to all PAs. Any open transactions
    to underlying RDBMS stores are then terminated
* If the resource manager receives «Prepared» from all PAs,
    «Commit» is sent to all PAs. Open RDBMS transactions will
    then be completed

Then there's a second issue that I'd very much like to understand
better - unclear availability of shrink-wrapped implementations:

We've done a bit of «desktop research» to find a suitable
approach,
and it appears that neither the WS-* stack of specifications
(including WS-AT), the OASIS-promoted WS-CAF (including WS-TXM) or the
older OASIS BTP has gained major momentum.  Meaning there are few - if
any - working real-life product implementations that support any of
these.  I'll be glad to be corrected if I'm wrong!

BTW: The new specifications seem to substitute the old-fashioned ACID
«I»  (isolation) with after-the-fact compensations, and that
appear a
bit scary to many people.  Perhaps this is a contributing reason why
even vendors like webMethods and SAP have put their decisions and
implementations on the wait-and-see list?

Bst rgds,
André Torkveen
Statkraft AS




                            Yahoo! Groups Sponsor



                                ADVERTISEMENT
            (Embedded image moved to file: pic29579.gif)click here


  (Embedded image moved to file: pic26132.gif)




Yahoo! Groups Links
       To visit your group on the web, go to:
       http://groups.yahoo.com/group/WS-TX-Workshops/

       To unsubscribe from this group, send an email to:
       WS-TX-Workshops-unsubscribe@yahoogroups.com

       Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

On Andre's general point:

> Then there's a second issue that I'd very much like to
> understand better - unclear availability of shrink-wrapped
> implementations:
>
> We've done a bit of <desktop research> to find a suitable
> approach, and it appears that neither the WS-* stack of
> specifications (including WS-AT), the OASIS-promoted WS-CAF
> (including WS-TXM) or the older OASIS BTP has gained major
> momentum.  Meaning there are few - if any - working real-life
> product implementations that support any of these.  I'll be
> glad to be corrected if I'm wrong!
>
> BTW: The new specifications seem to substitute the
> old-fashioned ACID <I>  (isolation) with after-the-fact
> compensations, and that appear a bit scary to many people.
> Perhaps this is a contributing reason why even vendors like
> webMethods and SAP have put their decisions and
> implementations on the wait-and-see list?

WS-BA and WS-CAF LRA both use terminology that assumes after-the-fact
compensation (i.e. do it all, then try to go back if not wanted). But
this is an unnecessary self-denying rule - the general case of any
two-round-trip exchange (which all of the protocols in question use)
is to provisionally perform, then EITHER confirm OR cancel. If the
resource/participants are thinking in service-oriented terms, then
it will be their business how they fulfil that contract.  One approach
is indeed to do everything in the provisional stage and compensate it
if cancelled. But you could do it the other way round (just check on the

first stage, perform iff confirmed. Or you could take a middle path -
getting to a consciously provisional state which will be changed again
on confirm or on cancel. And what isolation is applied (who from, to
what degree etc, whether system-enforced or application-enforced) is
also a matter for the service, rather than the client.

OASIS BTP is based on this assumption, as is Choreology's Cohesions
(which means the application compenents have to be restrained when
Cohesions is using WS-BA or WS-AT underneath).

(More on this in the Choreology May 2004 feedback to this group,
accessible under "Files" for the group)

Peter

-----------------------------------
Chief Scientist
Choreology Ltd
68 Lombard Street, London EC3V 9LJ, UK
web: www.choreology.com
phone: +44 8707 390066
mobile:  +44 7951 536168

Dear fellow transactions-involved professional,

I who write you this am an IT architect working for a Norwegian
electrical energy/utilities company, Statkraft
(http://www.statkraft.com/).  We're in the process of building an
enterprise-wide SOA platform, using middleware from various vendors
(significant players are webMethods and SAP) to realize an ESB between
different Line-of-Business end-nodes.

One of the challenges we face is to come up with a consistent,
reliable and recoverable way of ensuring that end-nodes in our loosely
coupled environment are kept in synch in by some mechanism, - but
without resorting to synchronous means of communications
(participating parties are - and should be - unaware of each other)!

Our first idea was to see if we could «steal» some of the very
good
groundwork laid down through traditional OLTP, but hopefully without
having to employ all the advanced features, simply opting for a custom
implementation of the simplest semaphores.

The following scenario outlines a lightweight custom setup - any
comments would be highly appreciated!

  * Either the initiating party (IA) itself or a centralized
    broker facility (equivalent of a resource manager of
    the OLTP era) sends a «BeginTransaction» message with
    a transaction ID to all participating applications (PAs).
    This transaction ID is then referred throughout the
    lifecycle of the following message conversations
  * When all PAs have replied that they're listening,
    one or more messages are transmitted (large messages
    may be split up into several pieces, but that's out
    of scope here)
  * During the run, one or more of the PAs can submit an
    «Aborted» message.  In that case, the resource manager
    will send a «Rollback» to all parties involved.
    Messages received before this point are then deleted
  * If the resource manager doesn't get any «Aborted»
    messages within a defined period of time, the resource
    manager sends a «Prepare» message to all PAs. PAs can
    then open database transactions to their own underlying
    data stores (typically RDBMS'es), handle all received
    messages and answer either «Prepared» or «Aborted» to
    the resource manager. If «Prepared», the described
    RDBMS transaction will remain open
  * If the resource manager receives «Aborted» from some
    PAs, «Rollback» is sent to all PAs. Any open transactions
    to underlying RDBMS stores are then terminated
  * If the resource manager receives «Prepared» from all PAs,
    «Commit» is sent to all PAs. Open RDBMS transactions will
    then be completed

Then there's a second issue that I'd very much like to understand
better - unclear availability of shrink-wrapped implementations:

We've done a bit of «desktop research» to find a suitable
approach,
and it appears that neither the WS-* stack of specifications
(including WS-AT), the OASIS-promoted WS-CAF (including WS-TXM) or the
older OASIS BTP has gained major momentum.  Meaning there are few - if
any - working real-life product implementations that support any of
these.  I'll be glad to be corrected if I'm wrong!

BTW: The new specifications seem to substitute the old-fashioned ACID
«I»  (isolation) with after-the-fact compensations, and that
appear a
bit scary to many people.  Perhaps this is a contributing reason why
even vendors like webMethods and SAP have put their decisions and
implementations on the wait-and-see list?

Bst rgds,
André Torkveen
Statkraft AS

dug,

Could you tell me the password please - hope to have Alf the Sheep's
endpoint up tomorrow.

btw, the status page still has the link to notes from the first day,
including the mis-spelling of Fabrice Matrat's name.

Peter

-----Original Message-----
From: dugibm [mailto:dug@...]
Sent: 28 January 2005 19:36
To: WS-TX-Workshops@yahoogroups.com
Subject: [WS-TX-Workshops] Re: WS-TX Interop Results from Jan.18-19
Workshop




All,
   The status page we used during the interop is now available for
everyone to view.  Each interop participant's status is anonymous (and
the matrix ordering is randomized) unless you login (at the bottom of
the page).  Please update your PA's URL if you have a machine up.  The
status page can be found at:
   http://wsi.alpahworks.ibm.com/wstx/interopStatus.jsp
Ping either Dan or myself for the login password.
-Dug







Yahoo! Groups Links









Choreology Anti virus scan completed

(reposting w/o typos in URL)
All,
   The status page we used during the interop is now available
for everyone to view. Each interop participant's status
is anonymous (and the matrix ordering is randomized) unless you
login (at the bottom of the page). Please update your
PA's URL if you have a machine up. The status page can be
found at:
   http://wsi.alphaworks.ibm.com:8080/wstx/interopStatus.jsp
Ping either Dan or myself for the login password.
-Dug

Hi All,

I'm happy to announce that we held the interop workshop last week.
More complete results and notes from the workshop are contained in
the document Transaction-InteropResults012505 which I will upload
into the file area momentarily.

Meanwhile, here are the first words from that document...

Transaction Interoperability Workshop
18-19 January 2005, hosted by IBM in Raleigh, NC

Attendees:

WS-Transaction Interop Attendee Company name
Tim Bedard  IBM
Dan House  IBM
Thomas Freund  IBM
Doug Davis  IBM
Jorgen Thelin  Microsoft
Jesse Yurkovich  Microsoft
Colleen Evans  Microsoft
Max Feingold  Microsoft
Kirill Gavrylyuk Microsoft
Peter Furniss  Choreology
Fabrice Matrat  Choreology
Eric Newcomer  Iona
Mark Little  Arjuna

Overall Results:

The interoperability testing was successful for the majority
scenarios for both Atomic Transaction (AT) and Business Activity
(BA) scenarios for the participants.  No major specification changes
or issues arose during the testing.   Thanks to all the participants
and we will continue endpoint testing and update the matrix as
appropriate.

Testing

Dan,

Sorry for the dely in responding.  We can commit to participate Jan 18-19, but
we will only have an implementation of WS-AT (i.e. I could not get resource for
WS-BA at this time since it is not in our product roadmap).

Thanks,

Eric

-----Original Message-----
From: Dan House, IBM [mailto:dhouse1570@...]
Sent: Wednesday, December 01, 2004 8:28 AM
To: WS-TX-Workshops@yahoogroups.com
Subject: [WS-TX-Workshops] Rescheduled WSTX interop workshop




We received feedback that attendees would prefer January instead of
December for this event, so we are rescheduling it. We now plan to
hold it January 18-19, 2005, instead of December this year.

The previously uploaded zip file with the invitation, feedback
agreement, and scenarios is still there -- everything in that zip is
still correct except the workshop date.

Sorry to change plans on you if you were planning to attend in
December and hadn't yet let me know. Everyone who contacted me about
attending is OK with the change (or they are unable to make both
December and January).

Regards,
Dan House
IBM







Yahoo! Groups Links

We received feedback that attendees would prefer January instead of
December for this event, so we are rescheduling it. We now plan to
hold it January 18-19, 2005, instead of December this year.

The previously uploaded zip file with the invitation, feedback
agreement, and scenarios is still there -- everything in that zip is
still correct except the workshop date.

Sorry to change plans on you if you were planning to attend in
December and hadn't yet let me know. Everyone who contacted me about
attending is OK with the change (or they are unable to make both
December and January).

Regards,
Dan House
IBM

A zip file was just uploaded containing an invitation to an Interop
Workshop for the WS-Coordination, WS-AtomicTransaction, WS-
BusinessActivity specifications. The workshop will be held Dec. 14-
15, 2004 in Research Triangle Park, NC. It will be hosted by IBM on
behalf of the authoring companies: BEA Systems, IBM, and Microsoft.

Also in the zip file are test scenarios and a feedback agreement.
All participants must sign a feedback agreement.

We hope to see you there!

Dan House
IBM

I've just posted on this group our feedback document, as asked for at
the Bellevue meeting. We sent it to the authors (or a subset of them
whose email addresses we knew) on 20 April, and then a slightly
revised version (more introductory explanation, no technical change)
on 4th May. The version I've just posted is the 4th May one - it's
also at

http://www.choreology.com/resources/2004-05-04.Choreology.WS-C%
2BT.Detailed.Feedback.Revised.Edition.pdf

Not had any response yet.

Peter Furniss

All,
IBM has an Internet endpoint available to test the WS-Tx specifications. The endpoint hosts a
set of tests that show how selected parts of the WS-Tx specifications can be
used. From the web page you can:
- choose which test to run
- see how each party in the test talks to each other
- specify the URL of another participant to use instead of IBM's

Our endpoint can be found at: http://wsi.alphaworks.ibm.com:8080/wstx

On there you'll find more information.

If you have an external endpoint available we encourage you to try testing
it with ours. Each test is described on the web page. If you have any
problems or questions please let us know.

thanks
-Doug

Doug Davis
dug@...

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-TX-Workshops
group.

   File        : /TX-feedback-workshop-minutes-10mar2004.doc
   Uploaded by : jthelin_microsoft <jthelin@...>
   Description : Minutes from the TX Feedback Workshop meeting on 10 March 2004

You can access this file at the URL

http://groups.yahoo.com/group/WS-TX-Workshops/files/TX-feedback-workshop-minutes\
-10mar2004.doc

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

jthelin_microsoft <jthelin@...>

Further to my own message, it would seem the correct url is the one
on the copies sent direct to us, and the only this archived
version of the message has a junk url

Correct url is
http://groups.yahoo.com/group/WS-TX-Workshops/files/tx-workshop-
presentations-2004-03.zip


Peter


--- In WS-TX-Workshops@yahoogroups.com, "Peter Furniss"
<peter.furniss@c...> wrote:
> Jorgen,
>
> this doesn't seem to be the right url - i get page not found
>
> Peter
>
> --- In WS-TX-Workshops@yahoogroups.com, "Jorgen Thelin"
> <jthelin@m...> wrote:
> > Hi Peter,
> >
> >
> >
> > To expedite availability, I have uploaded the presentations to
this
> > group.
> >
> > http://f6.grp.yahoofs.com/v1/gCRXQFi3pdB9bWdIzXZSr1hKPuKOBQVni-
> gPOKdakUW
> > W2GAHWp2-MNJ-APbMp9UbBt2oWoHrD3v1jdiSPsAaoQ/tx-workshop-
> presentations-20
> > 04-03.zip
> >
> >
> >
> > The material will also be available through MSDN, developerWorks
> and/or
> > dev2dev shortly.
> >
> >
> >
> > Jorgen
> >
> >
> >
> > ________________________________
> >
> > From: furniss_p [mailto:peter.furniss@c...]
> > Sent: Monday, March 15, 2004 6:26 AM
> > To: WS-TX-Workshops@yahoogroups.com
> > Subject: [WS-TX-Workshops] Presentations from last week's meeting
> >
> >
> >
> > Jorgen,
> >
> > Thanks for the meeting last week. We are working on the detailed
> > feedback.
> >
> > You said the presentations from last week would be put up on this
> > website. Do you know when ? We'ed like to have a chance to look
at
> > them again for our feedback.
> >
> >
> > Peter

Jorgen,

this doesn't seem to be the right url - i get page not found

Peter

--- In WS-TX-Workshops@yahoogroups.com, "Jorgen Thelin"
<jthelin@m...> wrote:
> Hi Peter,
>
>
>
> To expedite availability, I have uploaded the presentations to this
> group.
>
> http://f6.grp.yahoofs.com/v1/gCRXQFi3pdB9bWdIzXZSr1hKPuKOBQVni-
gPOKdakUW
> W2GAHWp2-MNJ-APbMp9UbBt2oWoHrD3v1jdiSPsAaoQ/tx-workshop-
presentations-20
> 04-03.zip
>
>
>
> The material will also be available through MSDN, developerWorks
and/or
> dev2dev shortly.
>
>
>
> Jorgen
>
>
>
> ________________________________
>
> From: furniss_p [mailto:peter.furniss@c...]
> Sent: Monday, March 15, 2004 6:26 AM
> To: WS-TX-Workshops@yahoogroups.com
> Subject: [WS-TX-Workshops] Presentations from last week's meeting
>
>
>
> Jorgen,
>
> Thanks for the meeting last week. We are working on the detailed
> feedback.
>
> You said the presentations from last week would be put up on this
> website. Do you know when ? We'ed like to have a chance to look at
> them again for our feedback.
>
>
> Peter

Hi,

I've posted the presentation on WS-CAF that I gave at the workshop.
Note that only through Slide 5 was presented during the meeting
because of time constraints.  The remainder of the slides contain
additional details about the WS-CAF specifications.

The presentation includes a formal statement from the WS-CAF TC and a
proposal to discuss potential convergence between the WS-CAF set of
specifications and WS-AT, WS-BA, and WS-C.

The presentation also includes an informal straw horse proposal for
how the specifications might be combined, should there be interest in
doing so.

Please let me know if there are any questions about this, or if
anyone would like further information about WS-CAF.

Thanks & Regards,

Eric

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-TX-Workshops
group.

   File        : /WS-CAF-Feedback-March10.zip
   Uploaded by : e_newcomer <eric.newcomer@...>
   Description : WS-CAF feedback presentation

You can access this file at the URL

http://groups.yahoo.com/group/WS-TX-Workshops/files/WS-CAF-Feedback-March10.zip

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

e_newcomer <eric.newcomer@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-TX-Workshops
group.

   File        : /tx-workshop-presentations-2004-03.zip
   Uploaded by : jthelin_microsoft <jthelin@...>
   Description : Presentations from the TX Workshop on March 10th

You can access this file at the URL

http://groups.yahoo.com/group/WS-TX-Workshops/files/tx-workshop-presentations-20\
04-03.zip

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

jthelin_microsoft <jthelin@...>

The TX workshop mailing list is now fully operational, and everyone
from the workshop last week has been added.

The list archives are available on the web:
http://groups.yahoo.com/group/WS-TX-Workshops/

Jorgen,

Thanks for the meeting last week. We are working on the detailed
feedback.

You said the presentations from last week would be put up on this
website. Do you know when ? We'ed like to have a chance to look at
them again for our feedback.


Peter