Re: [ebxml-bp] FW: Differences between an operation and a BT

["David RR Webber" <david@drrw.info>]

Jean-Jacques,

Excellent posting.  

Clearly what people are wanting is a sweetspot where they
can use ebXML and webservices together.

I have no reservations in saying that BPSS provides the
business-centric model that is applicable for providing
transaction based solutions.

Snag is when you look at the BPEL alternate world - with
compensation handlers, et al - it looks suspiciously like
re-inventing a database system, stored procedure language,
and distributed interactions like Tuxedo, using XML, some
wire and bits of black tape.   It's certainly nothing any 
average business analyst is going to want to learn into 
IMHO.

So how to make these two worlds co-exist?

One way is to work with the ebSOA team - I posted
something there today saying that V3 of BPSS could
be feature enabled to support the ebSOA architecture,
and specifically - using Linking and Switching, choice
points and state management as a neutral external service
that directs how both BPSS and WS components can work.

That's one view.

Also - if you view the WS as just an alternate transport
mechanism to ebMS - then another path is to somehow
(not easy) create WSDL definitions that emulate ebMS.
These would be a limited subset - but could work.

If you see what I've done in the BPSS model - it uses
Exchange Profiles - which you name -  like - Normal, 
ASAP, Required, One Day, and so on - and then
you set the transport characteristics for that profile
entry.  You then deliver a transaction and pick an
exchange profile for it.   We could easily create
WSDL exchange profiles that emulate a subset of
ebMS - and these could be used for non-critical
paths in the BPSS.

A third option is to specify WS calls to specific
service offerings that do something.   So you
may send someone a ProductAvailabilityRequest
as a transaction via ebMS as normal - but add
an annotation to it - with a WS call-out - to be
used to action that - something like - 
"CheckWareHouseStocklevel" with all the 
necessary WSDL glue - that is then used by
the receipient to get the answer... again that
interaction model would have to be well
specified and the use case firmed up.

Some ideas to think about - but basically
I'm reinforcing what JJ is saying - I believe
wholesale changes to BPSS should be a
last resort.  First we need to see use cases
and value propositions that make sense - 
then determine what extensions can support
those.

BPSS looks very good right now for its
intended mission - and our job I believe is
to educate the world to this with outreach,
tutorials, teaching - so people can start
to take advantage of it to document their
business problems and ultimately deploy
software to run those patterns.

Thanks, DW


----- Original Message ----- 
From: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, May 25, 2004 11:29 AM
Subject: [ebxml-bp] FW: Differences between an operation and a BT


Had some problem with email yesterday.

-----Original Message-----
From: Jean-Jacques Dubray 
Sent: Monday, May 24, 2004 12:06 PM
To: 'monica.martin@sun.com'
Subject: FW: Differences between an operation and a BT

Did you get this message?

-----Original Message-----
From: Jean-Jacques Dubray 
Sent: Monday, May 24, 2004 9:37 AM
To: Monica J. Martin
Cc: ebXML BP; kpetrop@01P.gr
Subject: Differences between an operation and a BT

WS Collaboration
Made of several operations without Made of several BT with
an 
Explicit relationship to each other explicit relationship
(chor)

Does not require a BSI or Agreement Requires a BSI
Mechanisms Requires
"negotiated" agreements


Operation BT
Req, Response, Fault* Request,Response*,
Fault*
No state alignement protocol Business transaction
protocol
Directed (A->B) No direction specified
(BTA)


Looking at this set of properties it is legitimate to ask the question
whether we want to make an operation invocation a BT (it clearly looks
like a subset). However, it is not because we can do something that we
should do something. This question is as legitimate (not more) to ask
whether a CORBA call or an RPC should be part of a collaboration. I
don't think I would find many people asking for invoking a method from a
BPSS. The reason why this question is relevant is because, WS is an
internet ready technology and many businesses may decide to expose a 

If we make an operation look like a BT we would
a) bring confusion, "so why do I need all this stuff if an operation IS
A business transaction". Transaction is about state alignment (not
rollback/compensation - rollback/compensation is a convenience mechanism
to serve state alignment). A web service operation does not give you any
kind of state alignment guarantee. ebXML BPSS and the ebXML architecture
has been carefully designed and tested to provide state alignment
capabilities via the concept of signals. Let me know if you need an
explanation on this (the short version is that in the WS, only the
consumer of the service knows the outcome, that kind of works for one of
services like "creditCheck" where the interaction does not depend on
previous states being reached. Imagine a world where we carry out
interactions without being sure of the past????). A web service
operation by itself CANNOT guaranty state alignment in any situation.

b) we will have to hack BPSS pretty much everywhere to explain that a
operation BT does not work like a BT 
- cannot be used in any order (so we have to specify the roles
somewhere)
- cannot be changed via "substitution set mechanism"
- cannot be augmented to use a business transaction protocol
- use a different "CPP/A" mechanism
- different exception mechanism (technical failure)
-...

Making an operation a BT will require that we annotate EVERY aspect of
BPSS to specify how this works with the operation BT pattern. It will
also limit our ability to use other WS stack spec as we see fit. 

I recommend that we keep operation and BT separate and create an
operation activity which has its own behavior totally independent from
the BT behavior. I recognize that this is a hybrid approach, but we are
dealing with technologies that had and will have different paths. 

JJ-



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Monday, May 24, 2004 9:04 AM
To: Monica J. Martin
Cc: ebXML BP; kpetrop@01P.gr
Subject: Re: [ebxml-bp] Webber 5/23/2004: Laura Project Progress in
Europe

Monica,

Thanks I'll contact Kostas direct and provide input back on what I find
out.

DW

Quoting "Monica J. Martin" <Monica.Martin@Sun.COM>:

> David RR Webber wrote:
> 
> > http://www.lauraproject.org/project's%20description.html 
> > <http://www.lauraproject.org/project%27s%20description.html>
> >  
> > Does anyone have contact with this group?
> >  
> > Would be great to get their input into our BPSS work.
> >  
> > DW
> 
> mm1: David, I had seen a post in November 2003 from Kostas Petropoulos

> (kpetrop@01P.gr) on the ebxml-dev list. Your post reminded me today. 
> I've attached the relevant email about the project I had and also cc: 
> Kostas to respond on this project to set up B2B adaptive zones in 
> Greece, Germany, Bulgaria and Europe. We'll see what we can find out. 
> Can you take an action to follow this through? Thanks.
> 


http://drrw.net