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

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

John:

Just some clarification. The requirement that we have selected for 2.0
(for 3.0 the requirements will be expanded) is that a partner that is
only capable of web service invocation be able to participate in a
collaboration (typically MPC). The invocation can be both inbound or
outbound (the ebXML partner is either a requester or a provider of web
services). 

I think that the layering that you are suggesting refers to a potential
3.0 requirement by which you could assemble and bind a series of
operations into an ebXML business transaction (e.g. associate an
operation to receipt Ack, another one to acceptance Ack and yet another
one for request response). I think that this is not a goal for 2.0. 

>> I also know that I would probably never use it, opting for a business

>> transaction instead.
Of course from a state alignment perspective, I agree with you 100%.

However... I thought that the paper industry had adopted ebXML for its
exchange (not sure), assuming they have, I could easily see a book
publisher consuming Amazon's inventory service and specifying a
replenishment collaboration involving paper producers, shippers, Amazon,
... Amazon could not care less how and why requesters are using its
inventory service. I don't think this service requires to be a
"transaction" per say. 

Now, are you telling us that Amazon is developing an ebXML equivalent to
its web services?

JJ-

-----Original Message-----
From: Yunker, John [mailto:yunker@amazon.com] 
Sent: Wednesday, June 02, 2004 10:06 AM
To: Dale Moberg; Jean-Jacques Dubray; ebxml-bp@lists.oasis-open.org;
anderst@toolsmiths.se
Subject: RE: [ebxml-bp] FW: Differences between an operation and a BT

I like Dale am still trying to work through the message traffic, and
even more importantly understand how the arguments being made relate to
each other...

If we are not to treat Operation Activity as a specialization of
Business Transaction, then we MUST recognize that the Operation Activity
lives at a layer of the stack BELOW the business transaction (e.g. the
only reason for an operation activity is to support a business
transaction).

If a partner has the responsibility to perform an action, then this is
constrained by the business agreements, and previous transactions, and
is for the purpose of discharging a business responsibility, and in
essence is a business transaction (fulfills that business
responsibility).

Most of the uses of the word "business" in web services today are merely
marketing veneer on a technical capability.  The BPSS is the best
opportunity to provide both 
	- a business understandable expression of the process
dependencies between partners
	- a basis for binding business agreements to technical
implementation and execution

I can see why having the operations activity makes it easier to build a
web services based collaboration.  You don't need a complete
understanding of the business dependencies to build the interaction
model (although at that point I might stop to use of the word "business"
- my opinion only - I'm for a strict segregation / layering of business
and technical).

It appears to me that there are many good reasons for accepting the
operations activity.  I also know that I would probably never use it,
opting for a business transaction instead.

That said, I see no reason NOT to allow the operations activity in the
BPSS, and be able to not choose to use it if it  doesn't fit the
business semantics or partner community. 

John

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] 
Sent: Wednesday, June 02, 2004 9:09 AM
To: Jean-Jacques Dubray; ebxml-bp@lists.oasis-open.org
Subject: RE: [ebxml-bp] FW: Differences between an operation and a BT


I am still working through the extensive message traffic on ebXML BP
list last week. Sorry to be slow. 

I find JJ's reasons for not treating OperationActivity (or whatever we
finally call it) 
as a specialization of BusinessTransaction persuasive.

At the moment, I think the 2.1 extensions in the CPPA (to support WSDL
and SOAP 1.1 & 1.2 header blocks) treat WS as another implementation
option for transactions. One question I have is how CPPA should provide
support for or align with OperationActivity?

Should the alignment with other CPPA/Messaging concepts (like
Service,Action) be maintained? CPPA really only needs this alignment if
ebMS is used (because it supplies the values to be used in the ebMS
header for Service, Action, and Role). But presumably, an
OperationActivity would never (not usually?) be implemented via ebMS,
would it?

Also, I am assuming that OperationActivity "combines" in a choreography
like a BTA or a CollaborationActivity (that is, it will be a "state" we
can transition to or from.) Will it make sense to use the
DocumentEnvelopeNotation? Will there be "statuses" from the state to
check against @conditionGuard attributes? 

Also will there be a Role binding via the Performs construct (at least
that is how I have been doing it in 2.x schema draft)?

Given the very preliminary state of WS and ebXML integration, I
definitely prefer introducing a construct with the least commitment
possible until, for version 3.0, we can see how it makes sense to
integrate these into combined business state alignment descriptions. 

Dale Moberg



-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
Sent: Tuesday, May 25, 2004 8:29 AM
To: ebxml-bp@lists.oasis-open.org
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