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

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

Frankly, I think this is really a problem of WSDL. WSDL is poorly
layered. 

Poorly layered because abstract WSDL is not enforceable, it is just a
best practice (I don't know if WSDL 2.0 is changing this). Users can
create spaghetti WSDL that do not rely on an abstract definition. As a
result the technical capabilities of any given providers are
intermingled with the interface definition. 

So I think that the layering defined by ebXML in Vancouver applies to
implementing ebXML on top of "specific" web services, but it does not
necessarily apply in using "any" web services in a collaboration which I
view as two very different things. 

Now I totally agree that there is a layer on top of BPSS and that BPSS
will eventually be totally eclipsed (not replaced) by this layer. I have
no problem with it. 

(I was just kidding about Amazon implementing ebXML - that would be
great though ! I think Amazon can claim having transformed web services
from a toy to a technology that can actually be used -despite all the
marketing efforts of IBSOft).


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

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