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

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

Jean-Jacques Dubray wrote:

>>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. 
>
<awt>
Im cetainly not saying that they are aligned with "absolute certainty" 
what Im saying is that business reasons may dictate that "resonable 
certainty" or "best effort certainty" is enough. And if the message 
happily gets through they are aligned.
<awt>


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

<awt>
Interesting to hear: In the business world we have Risk and Insurance 
etc how does that fit your scenario?
In eCommerce law there is also the consideration of risk allocation, who 
has the risk of sending a data message, the sender or receiver ?
<awt>

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

<awt>
What about the InformationDistribution BT pattern ? and that you can set 
timetoReceiptAck to zero (0)?
<awt>

>>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. 
>  
>
<awt>
yes, the roles are abstract. Its only when you start/enact/initiated the 
BPSS when thay become concrete or real. But still a BT is asymetrical 
with an abstract direction. When fitted into a BPSS using a proxy BTA 
construct the abstract roles becomes bound to higher level roles through 
the performs element in BTA. THis process is recursive all the way to 
the top. i.e BPSS.
<awt>

>WSDL specifies the direction of the operations.
>  
>
<awt>
Same as BT,  it is only when enacted the prescibed WSDL direction 
becomes real.
<awt>


>>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.
>  
>
<awt>
Sorry to hear this, isnt adding state aligmnment signals to WS a good 
thing? Isnt adding business semantics and legally relevant sememantics a 
good thing ?
<awt>

>>Comment: Confusion can be solved/minimized through marketing and 
>>education. BTW BPSS is already complex.
>>    
>>
>You are naïve.
>  
>
<awt> Personal remark so I let is pass: <awt>

>>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 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. 
>  
>
<awt>
It would be interesting to review above argument in a discussion with a 
Riskmanager at a financial institution and a laywer. Im not sure we all 
agree on the risk part.
<awt>

>>Disagree: a counter example: if a message actually reached the intended 
>>addresse => both have same info, state aligned.
>>    
>>
>Do you read English? 
>
<awt>Personal remark, Ill let it pass<awt>

>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?
>  
>
<awt>
If you onvoke a webservice with some IN argument and get some values 
back, on the same open HTTP connection, in the OUT argument and the one 
of OUT argument is a Receipt. Isn this a good way of ensuring that both 
parties have the same info?

Actually when I come to think of, its very similar to Notification BT 
pattern
<awt>

><JJ>
>All right I stop here, this discussion is going nowhere. You have no idea what you are talking about.
></JJ>
>  
>
<awt>
Sorry to hear this, I have tried to meet all your arguments, one by one, 
in order to show that BT is a perfect fit for an OperationXXX. I think I 
have shown that OperationXXX can with simple means be fitted into  BT no7.

Thanks
/anders

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