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

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

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

Hum... I thought this spec I was the editor for was called ebXML BPSS not UNCEFACT BPSS.

> If both parties has the same information they are "aligned". 

Of course, but how do you guarantee that they have the same information when I cannot be sure you understand what I am sending you.

BPSS does far more than reliable messaging, it gives you the peace of mind that the message you sent across was "processed" something web services will probably never do if we continue at the current rate of producing broken specifications. This is only when a message is processed that you can claim "state alignment". This is the fundamental contract between a DB and its clients: when the call returns you know that the DB has persisted it somewhere. The state of the DB and the state of its client are (always) aligned. This is what is required to do business, nothing less, nothing more. RM does not give you that, WSDL does not give you that. You simply don't understand what state alignment means. You treat it as a "casual" notion that amounts to as soon as I sent a message the state of the sender and receiver must be aligned. You could not be more wrong in saying that. I can explain the role of RM + Signal plays in achieving that if you need to. Oracle does not work with probability, nor any business I know, period. 


>BTW isn it dangerous using WS if there is a risk if the parties may not 
>share the same view of what has happened?
Of course, this is why I am recommending not to call this a transaction. Would you?

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

> A BT is directed since it is asymetrical with and an Initiator and a 
> Responder role. 
This statement is wrong. The roles are abstract. It is only when used in a BTA when you know the direction. 

WSDL specifies the direction of the operations.


> 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.
This is not what it is at stake here. If you think you are making WS business/legally friendly by wrapping it with BT you are wrong again.


> Comment: Confusion can be solved/minimized through marketing and 
> education. BTW BPSS is already complex.
You are naïve.


>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.
So I don't understand why you want to apply it to something that has NOTHING to do with a transaction, i.e. a WS operation. 

BTW, it is not events that cannot be reversed, it is STATE (that has been aligned -how could you reverse mis-aligned state?)



>By following the argumentation: WS -> uncertain outcome AND uncertain 
>outcome -> dangerous world
>=> We shouldnt be using WS ?
Simply because "interoperable state alignment" is expansive and not always required.

>BTW We have been living in an uncertain world for many thousands of 
>years and still been able to to business.
I can assure you that the day I closed on my house, there was no uncertainty whether the money was out of my pocket and the fact that I gained ownership of the title. Same for cars, ...

Some businesses can leave with some degree of uncertainty (car rental, amazon, ...) airlines don't like many others. Hotels are in the grey area. In any case, what is certain, is that if a customer shows up with a confirmation number, every business does something to provide some level of service. Overall, I really don't understand your point: the uncertainty is never about the commitment, the uncertainty is always about fulfillment. So state is pretty much aligned once the commitment is achieved. 


> Disagree: a counter example: if a message actually reached the intended 
> addresse => both have same info, state aligned.
Do you read English? I have said in ANY situation, it is not because state alignment can be achieved in one situation that state alignment can be achieved in all 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)
>  
>

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.



<JJ>
All right I stop here, this discussion is going nowhere. You have no idea what you are talking about.
</JJ>



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