Title: RE: [ebxml-bp] State Alignment and Web Services

JJ,

I like this idea of built-in signals.

Could you suggest a short list of say 4 or 5 of the most common?

That way I can build them into the BPSS model example and show how they can be used.

BTW - OAGi and the IV&I project are grappling with *exactly* this problem - and they are using a confirmBOD to try and do this. Ron White has been leading this.

I would definately like to see how we can use signals to address this whole issue.

Thanks, DW.

----- Original Message ----- From: [1]Jean-Jacques Dubray To: [2]Jacques Durand ; [3]Monica J. Martin ; [4]ebXML BP Sent: Thursday, June 10, 2004 12:58 AM Subject: RE: [ebxml-bp] State Alignment and Web Services

Yes, this is precisely my point. In order to ensure state alignment and offer non-repudiation.

1) RM is mandatory

2) You need the receipt Ack for non repudiation

3) You need the acceptance Ack for confirmation that the message was process-able

You can only achieve that with signals and not messages. This is because signals have a fixed structure and are handled by the BPSS infrastructure so no one can say “I did not understand the signal”. Once you got a signal, you can choose to ignore it, but you can deny that you got it or could not understand it. Signals avoid “acking the acks”.

Without such a scheme in place you can never achieve the appropriate level of state alignment in all cases.

To correct what I have said in my previous email, Systinet and Apache just released a few days ago support for WS-RM (but I am not sure if it is a published spec or not).

JJ-

------------------------------------------------------------------------------

From: Jacques Durand [mailto:JDur...@us.fujitsu.com] Sent: Wednesday, June 09, 2004 8:33 PM To: Jean-Jacques Dubray; Monica J. Martin; ebXML BP Subject: RE: [ebxml-bp] State Alignment and Web Services

This state alignment appears to be above the messaging layer So RM alone - whether in ebXML or WS - would only help, but not suffice: RM would (1) help deliver the message in spite of trouble, (2) but cannot even ensure that: only guarantee that your credit card comp is notified in case the message could not be delivered after all. And if the message is delivered to the end-point, does not mean it has been read indeed.

So if what the credit card company wants (or should have wanted) is a kind of non-repudiation from *you* (not just from your messaging end-point), I think this is precisely where BPSS bus transactions help.

(not sure this would require BTP though).

Jacques

-----Original Message----- From: Jean-Jacques Dubray [[5]mailto:jean...@attachmate.com] Sent: Wednesday, June 09, 2004 5:11 PM To: Monica J. Martin; ebXML BP Subject: [ebxml-bp] State Alignment and Web Services

Yesterday something not so funny happened to me. I talked to my credit card company because two payments on my credit card did not happen. I had set up recurring payments and things went without a glitch for a couple of years.

By talking to them I realized that they had sent me an email in April telling me that they were discontinuing on-line statements and in this email supposedly they were asking me to sign up for on-line payment one more time.

As a result I ended with a bill of over $100 of finance charges. Of course they promptly reverted these charges when I explain that I did not think it was a good way to do business (it is close to a scam if you are me).

So here is precisely what happens when state alignment is not guaranteed. They sent a message in the hope that I would understand it perfectly. They did not expect me to send an ack, nor did I got the information that I HAD to send an ack (signaling an important message for instance).

SMTP has some kind of Reliable Messaging capability. Their message would have bounced back if my email address was not valid anymore, but SMTP cannot tell them that I actually read that email.

The conclusion of this story is that misalignment of state for commitments is a really really really bad idea, it is very costly to rewind (I spend more than an hour on the phone to solve this). Imagine, I send you a PO request for a widget, and you send me an ack but I never receive it or I misinterpret it. I go off and buy the widget from another supplier. Now I receive two widgets. How do we sort that out. Is it preferable to avoid being in this situation?

Web Services does not have yet an agreed upon WS-RM spec (which is just one part of the problem), I don't know products that support it (e.g. Microsoft just shipped WSE 2.0 without it and probably will have to wait until Indigo comes out, I heard a comment that this would be really hard to support in WSE).

By contract, ebXML and BPSS supports state alignment (aka business transaction) today which rely on ebXML RM and ebXML BTP.

JJ-

-----Original Message----- From: Monica J. Martin [[6]mailto:Moni...@Sun.COM] Sent: Tuesday, June 08, 2004 6:53 AM To: ebXML BP Subject: [ebxml-bp] [ebBP] 6/8/2004: WI-12 WSDL Support - Preparation for Quorate Vote

Discussion|OASIS.ebBP.WI12-WSDL Support; Topic|; Point|Preparation for v2.0 Vote Opening 14 June 2004; Attachment|[7]http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.h tml; Attachment|[8]http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/downloa d.php/7102/ebbp-mtgminutes-mm1-060704.txt;

mm1@ Yesterday, we had a productive discussion with many good ideas about how

to iteratively approach the Operation 'thingy'. As discussed, we've had two detailed proposals from Anders Tell and JJ Dubray, both of which I believe can be supported. . Kenji has also provided some insight that MEP may typically exist below the business transaction constructs (and could be related to DocumentEnvelope). So, we have identified three important criteria for this capability:

* Support the guiding principles from other sources such as UNCITRAL, other UN legal documents and the ebXML eCommerce Patterns (v1.0) [3]. We do anticipate we will be adding more support in a later version. So, this is our first step to lay the groundwork. Ensure that dispatch-reach requirements are understood and considered here. * Provide the capability to support an abstract web service reference (Operation 'thingy') [1]. Ensure we can support monitoring and existing capabilities given this new function - statuses, conditions, transitions, roles, etc. * Ensure the technical specification clearly identifies that there are at least two distinct use case areas for these services: Provide a basis a business agreement and support of an overall exchange. With the latter, we should ensure it is clearly defined and usage is controlled appropriately. As currently understood, ebBP constructs or web services will be used but in separate collaborations. o Specification should indicate that the web service should not used to initiate or fulfill/discharge a business commitment [2]. o Use web services to provide state alignment where parties can't use a robust capability such as those defined in existing business transaction patterns [2]. o Provide constraints in the form of requirements for CPPA for v2.1 errata (which will support web services as well). o For v3.0, create a technical note that addresses how use of web services is accomplished and with more research how that occurs in the context of a constrained business transaction pattern. Further definition defined by the team. In the interim, contact IV&I to see if they could be the test case implementation for this capability. + Extend or continue to develop the functionality to meet the core requirements identified in v2.0 and others that are identified in the interim.

***The vote will open 14 June 2004 (8 a.m. EDT) and close 21 June 2004 (11 p.m. PDT).***

[1] This will be further refined given 7 June 2004 teleconference, submission by Nagahashi, and collaboration with Tell, Dubray, Yunker and

Moberg. [2] Yunker, 7 June 2004

Summary sent 7 June 2004:[9]http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.html Meeting minutes 7 June 2004: [10]http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/7102/ ebbp-mtgminutes-mm1-060704.txt

***KENJI, GIVEN YESTERDAY'S CALL AND THE INPUTS THUS FAR REGARDING YOUR SUGGESTION ON THE DOCUMENT ENVELOPE, YOUR INPUT IS REQUIRED. THANKS!*** @mm1

References

Visible links 1. jean...@Attachmate.com mailto:jean...@attachmate.com 2. JDur...@us.fujitsu.com mailto:JDur...@us.fujitsu.com 3. Moni...@sun.com mailto:Moni...@sun.com 4. ebxm...@lists.oasis-open.org mailto:ebxm...@lists.oasis-open.org 5. mailto:jean...@attachmate.com 6. mailto:Moni...@sun.com 7. http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.h 8. http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/downloa 9. http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.html 10. http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/7102/