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

["Yunker, John" <yunker@amazon.com>]

JJ, regarding layering...

I support several business collaborations that have multiple implementations including WS, EDI, and manual invocation of many business transactions.  

BPSS currently supports these just fine, with the BPSS declaring the business interaction and the implementation guidelines declaring how each transaction is implemented in different technology.

I agree that formal layering and binding between BPSS and UBAC (above) and WS (below) will come in 3.0, but I also assert that the conceptual layering has been intact since the ebXML Vancouver meeting.

Re: "Now, are you telling us that Amazon is developing an ebXML equivalent to its web services?", that will depend on ebXML adoption in specific business communities.  While it is true that many of Amazon's web services are made available to a large community with minimal administrative overhead, these uses are still governed by a binding agreement.  Also note that we use web services for both simple services and complex supply chain relationships, with very different business and technical complexities.

That is why I think your use cases and Ander's are orthogonal, and that supporting both use cases is not necessarily a bad thing.

John


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


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