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

["Anders W. Tell" <anderst@toolsmiths.se>]

I would like to continue the important debate about the future of the 
OASIS version of UN/CEFACT:s BPSS.

See comments inline:

>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)
>  
>
True, however its a comparison between apples and lemons. A better level 
of comparison would be between ebMS+XSD vs WS+WSDL

>Does not require a BSI or Agreement		Requires a BSI
>Mechanisms						Requires
>"negotiated" agreements
>  
>
If Im not misstaken there is NO BSI defined in ebXML framework of today 
and ebMS+BPSS works just fine.
In fact in Sweden we are in the process of creating a BasicTransport 
profile using a stripped down ebMS + a small part of BPSS.

In both cases parties need to know details about each other, whether 
that info is captured in a XML or not is another question.

There seem to be no support for above comparison.

>Operation						BT
>Req, Response, Fault*				Request,Response*,
>Fault*
>  
>

If I remember correctly ebMS is based on SOAP so Fault is there. And 
[0..*] response could well be [0..1] or [1..1] and BPSS has Protocoll 
errors.

There seem to be no support for that they are *fundamentally* different.

>No state alignement protocol			Business transaction
>protocol
>  
>
If both parties has the same information they are "aligned". The 
difference between using an signal is 'reliability and certainty and 
that the business community has used confirmation/receipt for a long, 
long time and that is the normal modus operandi in many,many business 
situations whether they are using electronic means or not.
In both cases using realibily features in messaging will increase 
reliability/ probability, adding a business signal adds non repudiation 
etc, using two or more signals makes it even more safe and "evidentiary 
correct".

One of the reasons why the mailbox rule is effective is that it 
shortcircuits the number of signal going back and fort, i.e. almost 
absolute certainty is not required, only resonable, best effort certainty.

"The Mailbox Rule
Once the Acceptance is in the mail…it is binding on the Offeror
· Effect: Even though Offeror does not yet have Acceptance, he is 
already bound
· EXCEPTIONS
· When limits imposed by offer: Date, means, method
· Mistakes in address or postage "

So it seems as if WS is a variant of BT with less business certainty.

BTW isn it dangerous using WS if there is a risk if the parties may not 
share the same view of what has happened?

>Directed (A->B)					No direction specified
>(BTA)
>  
>

A BT is directed since it is asymetrical with and an Initiator and a 
Responder role. When a BPSS is enacted or Instantiated a BusinessPartner 
is bound to a specific side: Initiator OR Responder , Client OR Server. 
If the Busines Partner cannot handle being on either side the BP should 
not take part of a BPSS enactment or very quickly rebuild the business 
system.

So It seems as both BT and WS are directed.

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

Agree, WS is technology is relevant for at least a few more years. And 
it wouldnt hurt to make it business/legally friendly, since it has not 
concept of/support for dispatch, reach , risk allocation etc.

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

Comment: Confusion can be solved/minimized through marketing and 
education. BTW BPSS is already complex.

>Transaction is about state alignment (not
>rollback/compensation - rollback/compensation is a convenience mechanism
>to serve state alignment). 
>

Just a comment: the transaction word is dangerous since it carries soo 
many cannotations and one should keep in mind that business events in 
general cannot easilly be reversed.

>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????). 
>

By following the argumentation: WS -> uncertain outcome AND uncertain 
outcome -> dangerous world
=> We shouldnt be using WS ?

BTW We have been living in an uncertain world for many thousands of 
years and still been able to to business.

>A web service
>operation by itself CANNOT guaranty state alignment in any situation.
>  
>

Disagree: a counter example: if a message actually reached the intended 
addresse => both have same info, state aligned.

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

Disagree: see above argument

>	- cannot be changed via "substitution set mechanism"
>  
>

Dont see the relevance of a XSD argument. By using XSLT all XML based 
specification can be changed even WSDL.

>	- cannot be augmented to use a business transaction protocol
>  
>

Disagree: see above argument

>	- use a different "CPP/A" mechanism
>  
>

Agree: fully specified than CPP/A need to be extended, but as shown 
above BPSS+WSDL works just fine without CPPA.

>	- different exception mechanism (technical failure)
>  
>

Disagree: see above argument

>	-...
>  
>

Please elaborate.


All in all only MINOR changes is needed in BPSS to accomodate 
OperatioInvocationTransaction.

>Making an operation a BT will require that we annotate EVERY aspect of
>BPSS to specify how this works with the operation BT pattern. 
>

Completely disagree, see above argumentation.

>It will
>also limit our ability to use other WS stack spec as we see fit. 
>  
>

Please elaborate this general argument.

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

Since all above mentioned arguments has effectivly been rejected I see 
no need to break the BPSS model. The OperationInvocationTransaction isa 
prefect fit for BT no 7.

Ive tinkered for a good 10 min and got below experiment together, which 
looks like a spec for a 'OperationInvocationTransaction' which should be 
feasible since BPSS has the new Pattern specific XML representation of a 
any BT.
Disclaimer: there a few errors here and there but I wanted to show that 
it is possible with minor changes to accomodate OperationInvocation 
using BT principles.

<OperationInvocationTransaction
name="Check Credit"
isGuaranteedDeliveryRequired="true">

<RequestingOperationActivity
name="checkCredit"

<!-- ********************************* -->
interface="xs:string"
operationname="xs:string"
namespace="xs:anyURI"
<!-- ********************************* -->

isAuthorizationRequired="true"
isIntelligibleCheckRequired="false"
isNonRepudiationReceiptRequired="false"
isNonRepudiationRequired="false"
timeToAcknowledgeAcceptance=" 0"
timeToAcknowledgeReceipt="0">

<DocumentEnvelope
isAuthenticated="persistent"
isConfidential="persistent"
isTamperDetectable="persistent"
businessDocument=" Credit"
businessDocumentIDREF="122A3F8E3"/>
</RequestingOperationActivity>

<RespondingOperationActivity
name="confirmCredit"

<!-- ********************************* -->
interface="xs:string"
operationname="xs:string"
namespace="xs:anyURI"
<!-- ********************************* -->

isAuthorizationRequired="true"
isIntelligibleCheckRequired="false"
isNonRepudiationReceiptRequired="false"
isNonRepudiationRequired="false"
timeToAcknowledgeReceipt="0">

<DocumentEnvelope
isPositiveResponse="false"
isAuthenticated="persistent"
isConfidential="persistent"
isTamperDetectable="persistent"
businessDocument="Credit"
businessDocumentIDREF="122A3F8E3"/>
</RespondingOperationActivity>

</OperationInvocationTransaction>


<BusinessDocument
name="Credit"

<!-- *********** ref to WSDL ******** -->
specificationLocation="http://.../credit.wsdl";
specificationID="http://.../credit.wsdl";
<!-- ********************************* -->

namespacePrefixes="fix">

<ConditionExpression
expressionLanguage="XPATH 1.0"
expression="//@CreditResponse='accepted'"
prefix="fix"/>
</BusinessDocument>


Hope above helps in understanding that BT.
/anders

-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone:  +46 8 562 262 30          /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////