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

[Kenji Nagahashi <nagahashi@fla.fujitsu.com>]

Hi,

It is a little bit late to jump in, but let me clarify whatI said during 
the last call.

In summary, I completely agree with JJ and Dale in that BT and WS 
operation are the different thing.
However, I'm unconfortable with OperationActivity because it promotes 
low-level concept (WS ops) to first class component of BPSS.
I believe CPPA's WSDLBinding should provide a way to accommodate Web 
services into ebXML.

I may have missed some important TC discussions, please let me know if any.

Detailed description follows:
-----
1) BT in general maps to multiple Web services operation.

I said "mapping from a business transaction to web service operations 
could be defined" in the last call.
There, I didn't mean either "web service operation IS business 
transaction" or "let us make WS ops BT", but did mean "business 
transaction can be realized by *multiple* web service operations: 
Request (and Response), and signals. BT maps to multiple WS operations 
in general. I said "maps" out of the view that WS ops and BT live in 
different layer of abstraction.
(This have already been articulated by JJ and Dale many times, I guess)

2) In certain cases, BT can be as simple as one WS operation, but still 
they are diffferent things

As anders pointed out, WS operation can realize a BT. I agree.
	- trading partner may not need any signals to be sure state is aligned
	- WS operation can notify requester of successful state alignment by in 
response.
But still, BT and WS operation are the different things.

3) By adding operation activity to BPSS, we may be promoting WS 
operation to a first class component of BPSS.

I believe WS operations lives in lower layer than BCs and BTs.
If we put WS ops at the same level as BPSS components, users could abuse 
operation activities to write miserably low level description of 
business process --- as done with other choreography languages. Uses 
could describe the logically same processes quite differently just 
because one is implemented with ebMS and the other with WS. What if one 
uses RosettaNet payload over WS, with some additional "signal" 
operations? I like to have one BPSS description with different 
collaboration-to-messaging bindings.

5) Binding in CPA can do the job

Here's a BPSS component hierarchy:

BC -> BT -> BusinessAction -> DocumentEnvelope -> BusinessDocument

DocumentEnvelop maps to message exchange with ebMS.
Since WS ops are lower abstraction than ebMS, it is below DocumentEnvelope.

If we accept WS ops as a (component of) realization of BT, we can simply 
rely on CPPA's WSDLBinding work.
If we want some more WSDL support within BPSS, DocumentEnvelope is the 
place to extend, I believe.
(I don't have concrete proposal of this extension, but I could make one 
if this makes sense).

Regards,
Kenji

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