-----------------------------------------------------------------
This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

•  Visit your group "soapbuilders" on the web.
   
•  To unsubscribe from this group, send an email to:
  soapbuilders-unsubscribe@yahoogroups.com
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
  
   
  

  ---

  
   

•  Visit your group "soapbuilders" on the web.
   
•  To unsubscribe from this group, send an email to:
  soapbuilders-unsubscribe@yahoogroups.com
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----------------------------------------------------------------
This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

•  Visit your group "soapbuilders" on the web.
   
•  To unsubscribe from this group, send an email to:
  soapbuilders-unsubscribe@yahoogroups.com
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi again everybody,

First of all I want to thank everyone who has taken time to answer!  Even
more so to those of you who I contacted directly while I was waiting for
my application for admittance to this group to come through.  Too late I
recognized my double effort was a bad idea, and when I told you I had to
finish the independent dialogs and rather share our conclusions with the
entire forum, nobody objected, even though I’d been handed papers that
gave us excellent input!

Conclusion #1 – General:
----------------------------------------
The community spirit still flows!  At a point we felt disturbed about
finding a suitable way for solving this very delicate problem, not to
forget navigating the WS’es maze.  That’s not so much the case any more,
thanks to you guys!

Conclusion #2 - Conceptual solution design:
-------------------------------------------
We’ve considered three different strategies:

A) DON’T GO THERE - avoid the thing completely!
Outside of this forum several people advocate that we should rather try to
work around it, e.g. by performing the various flow steps in sequence
instead of simultaneously; in the simplest cases with only two PAs (one of
them being the IA), it should be absolutely viable.  A strong argument for
this viewpoint is that classic 2PC/XA would effectively work as a poison
pill for a loosely coupled environment like ours; holding resources
through the state transitions is simply not acceptable!

B) LIGHTWEIGHT
This scenario is for those occasions when the A) alternative just won’t
cut it, while the challenge at hand still isn’t too complicated.
In the projects we’ve mapped, the need is to synchronize no more than two
participating systems at the same time, except from in one case where a
3rd system also needs to be updated, but that doesn’t have to happen until
after the other ones have finished.  And long running TX’es are out of
scope, at least for now.  Besides, since we have a MOM with guaranteed
delivery in operation.  So we hope we can cope by emulating a limited
vocabulary/set of semaphores on top of that, as outlined in my first
posting.

C) FULL-BLOWN
Here we’re talking about a centrally managed environment; an advanced
«black box» resource manager runs a tidy ship and coordinates all the
traffic – like the ones several of you guys offer.  Without a doubt, this
is the cleanest act, and on an asynchronous platform I find it downright
impressive that it can be achieved at all!

So, what’s the decision going to be over here at my employers’ then?
Well, my hunch is that we’ll probably settle for the «uncool» solution; a
mixture of the A) and B) approaches above.

Now, it’s important to keep in mind that in such a case we would actually
be doing a custom protocol implementation.  Under such circumstances we
believe that it’s imperative to isolate in-house code so that we’ll be
able to scrap/swap it out when similar functionality becomes available
through standard off-the-shelf offerings from our preferred vendors
(…which may be a couple of years ahead: TX’ing trails second last on
webMethods WS’es to-do list, and as far as I’ve been able to determine,
SAP hasn’t even come out with one of enough detail).

Naturally, there are inherent drawbacks of creating things on your own;
except from the fact that the result will have narrow functional scope
(read: «stiff», not very reusable code), we recognize the escape from
purchase price translates into more risks in terms of internal
housekeeping (read: change/configuration management).  Unless good
routines are in place, embarking on such a route could easily turn into a
maintenance nightmare.  How do you for example handle upgrades of
components that are touched by the custom code?  Besides, we know we
haven’t worked out all the small intricacies yet, but at this point we
don’t see the remaining work holding issues of potentially show-stopping
nature.

Since we’re deciding on issues of this importance, we wanted guidance and
second opinions from externals.  Being a Gartner client we asked for a
conference with an analyst proficient in both XA and WS’es.  Luckily, we
got to speak with the very competent Yefim Natis
(http://www.gartner.com/AnalystBiography?authorId=7256) who confirmed our
findings, strongly advocating sobriety or «proceed with caution», much in
line with Alastair Greens posting dated the 16th.

Conclusion #3 - Standards and product offerings:
------------------------------------------------
We’re fascinated about how the WS-* specifications have sliced the natures
of short running (WS-AT; all-or-nothing, like the name suggests) and
longer running (WS-BA; after-the-fact compensation) scopes neatly between
themselves.  But being emotionally in favor of open organization-supported
instead of vendor-driven specifications, I must admit that the OASIS
WS-CAF still isn’t quite clear and convincing to me; I can’t say I’ve
gathered how they intend to support a span of varying requirements –
except from by employing the more proven but far less «sexy» approach of
BTP.  Then again, since everyone touts WS’es nowadays, I believe it would
be far more difficult to convince decision makers to go for a perceptional
«old fashion thing».  And at the end of the day, stuff like that can make
the whole difference!

We were a bit skeptical because we had the [FUD’ed?] impression that the
only viable alternative in terms of WS-* product implementations would be
the very proprietary WSE2 (now) and  «Indigo» (someday), with the only
true contenders being the upcoming versions of the spooky huge WebSphere &
WebLogic families - following somewhere in Microsofts wake.

	 Shame on me!

But actually, I’d say that the same could go for you guys as well; please
tell me WHY standards-compliant, neatly pluggable packages like ArjunaTS
and Cohesions are «well kept secrets» to simple soles like me?

I should add that Eric Newcomer told me Artix can provide the same
capabilities, but I must say that my perception of IONA inclines more
towards the complete stack offering; would it really be natural to
purchase, learn and integrate a floor-to-ceiling offering like Artix into
a running webMethods-based infrastructure like ours, just for the sake of
TX’ing?  I’m sorry to say so, but the way we tend to see things around
here, I think not – from our point of view IONA is more in the league of
the aforementioned larger suites (…so if I was looking for a full-blow
framework Artix would appear on THAT list instead).

On the other hand, I think we would have been able to drop any of Arjunas
and Choreologys offerings into our environment - without having to
reconsider/redesign fundamental aspects of our existing platform.
Beautiful!

- Further comments, anyone?

Thanks again,
André T.


-------------------------------------------
This mail was sent through Freewave AS Webmail
http://www.freewave.no/

Solving 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

Mark Little sent:

> Green, Alastair J. wrote:
>
> >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).
> >
> >
> I think it's fair to say that the WS-AA/WS-BA specifications have been

> around in one form or another since before BTP began. Their genesis as

> Web Services specifications predates BTP by several months. However, I

> think that is less important than the fact that they are based on well

> founded technologies and protocols that go back to the 60's (WS-AA)
and
> the late 80's (Sagas) - it's even arguable that it goes back earlier
> with Jim Gray's seminal paper on Sphere's of Control, while at IBM. I
> believe it is unfair to try to imply that the specifications are
> immature compared to something else (anything else for that matter).

There's a distinction to be made between the underlying assumptions and
models
and the specifics of a protocol specification.  On the model aspect, all
of the
specifications were devised in the light of ideas going back a long way.
How
much of those ideas actually impacts the protocol is less obvious - BTP,
for
example, which can certainly be used for pure-compensation, Saga-style
cases,
can also be used for atomic (since it's underlying assumption is that
the
protocol does NOT constrain the internal behaviour of the service,
though
other agreements can) - there is nothing in the WS-BA specification
that defines the behaviour above the level of one participant, so it
could
handle several compensation-only approaches (though not any applications
where real effects must not escape).


> >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.
> >
> >
> I believe the dust is beginning to settle. If you check out what
> analysts and other "luminaries" in the business are saying, they are
> talking about the transaction approach in WS-CAF and the IBM/MSFT/BEA
> specifications. These two approaches are sufficiently similar that,
> hopefully, some amalgam of them will be what the industry
> moves forward with.

I'm not quite clear what the "transaction approach" is. The only
commonality is
really that they both have a context/registration mechanism that other
things can layer on, and that one of the things is a atomic/acid
protocol.
And perhaps that the atomic protocol should be a direct translation into
the
ws-specs du jour of a previous protocol (thus allowing distribution of a

transaction between tightly-coupled applications in a single
trust/management
  domain using ws protocols). That's scarcely
a transaction approach for SOA, though it has utility.

On the wider question of how to provide appropriate transactionality for

loosely-coupled systems, the dust is nowhere near settling. The WS-CAF
committee hasn't even started consideration of its WS-TXM layer, and,
based on changes it has made elsewhere, the chances of the LRA and BP
specs coming out as they went in is negligible.  There has never been
open discussion on this list about the vices and virtues of the
compensation-only
approach of WS-BA (for vices, see Choreology feedback :-) ).

>           There are differences, to be sure, but as we've just seen
with
> OASIS WS-DM being adopted as a standard despite the fact that the
> specifications it references aren't finalised yet, there is customer
> demand for these protocols now. Jumping in the water with something
> based on WS-AA/WS-BA and/or WS-CAF is a good approach IMO. There are
> certainly more commercial implementations of these
> specifications than
> any other Web Services transaction protocol.

Well, there are around 2 and half commercial implementations of WS-AT,
with the
ability to link into database resources in the participants to actually
do something useful. Since WS-AT is just existing ACID semantics in SOAP
messages, that isn't a big deal.  There are 6 (commercial organisation)
implementations of WS-AT, and 5 of WS-BA that can send the right
protocol
messages to each other, but they don't all have real transaction
capability behind
the endpoints. (there are some academic implementations too).  Are there
any WS-BA, WS-LRA, WS-BP commercial implementations that allow
integration
with database and other resources in the participants, other than
our Cohesions configured to use WS-BA ?

> >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.
> >
> >
> See above. This is FUD (Fear, Uncertainty and Doubt).

An interoperable protocol spec needs to have a lot more finality than
just a conceptual model based on previous work. And the loosely-coupled
case is not stable.  One could take the view that whatever comes forth
from the WS-BA authors will be the final word, but if it goes into a
standards body it is unlikely to be rubber-stamped in three months.
(what
would be the value of such an endorsement). Since
WS-CAF hasn't started on WS-TXM (surely the larger part of its work), it
would seem unlikely to reach committee draft stability in less time than
it has taken so far (since October 2003).

Obviously not 100% objective.
Peter

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

Green, Alastair J. wrote:

>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).
>
>
I think it's fair to say that the WS-AA/WS-BA specifications have been
around in one form or another since before BTP began. Their genesis as
Web Services specifications predates BTP by several months. However, I
think that is less important than the fact that they are based on well
founded technologies and protocols that go back to the 60's (WS-AA) and
the late 80's (Sagas) - it's even arguable that it goes back earlier
with Jim Gray's seminal paper on Sphere's of Control, while at IBM. I
believe it is unfair to try to imply that the specifications are
immature compared to something else (anything else for that matter).

>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.
>
>
I believe the dust is beginning to settle. If you check out what
analysts and other "luminaries" in the business are saying, they are
talking about the transaction approach in WS-CAF and the IBM/MSFT/BEA
specifications. These two approaches are sufficiently similar that,
hopefully, some amalgam of them will be what the industry moves forward
with. There are differences, to be sure, but as we've just seen with
OASIS WS-DM being adopted as a standard despite the fact that the
specifications it references aren't finalised yet, there is customer
demand for these protocols now. Jumping in the water with something
based on WS-AA/WS-BA and/or WS-CAF is a good approach IMO. There are
certainly more commercial implementations of these specifications than
any other Web Services transaction protocol.

>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.
>
>
See above. This is FUD (Fear, Uncertainty and Doubt).

<Stuff deleted.>

I hope that the industry can compete on implementations and not
standards, so it's right (as Alastair suggests) that any potential user
needs to ask questions. The questions suggested by Alastair aren't
necessarily all written from an objective standpoint, and I'm not going
to comment on them further, or even try to come up with my own set
(which admittedly may not be 100% objective either). But users asking
questions of vendors is nothing new and it's a good thing for the
industry as a whole, since it's a great way (though definitely not the
best way) of getting user feedback into this kind of process.

Mark.

I am still struggling to understand the relationships between WS-
BusinessActivity, WS-AtomicTransaction and BPEL.

BPEL has a concept of compensation handlers. From what I understand,
if the parent activity of the compensation handler is invoked, the
state of the process is saved at that point. If the compensation
handler is triggered, that saved state is made available to the
compensation handler which can then use it to effect
the 'compensation'.

With multiple BPEL processes interacting in a B2B collaboration, you
would want the right compensation handlers to be triggered more or
less simultaneously. The idea is that you want state changes across
business partners to be synchronized (all-or-nothing).

WS-BA/WS-AT provide the protocols to synchronized state changes. How
exactly are these hooked to BPEL is still unclear (to me).


Faisal
http://objectpeddler.blogspot.com/

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@...>