[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 [mailto:Monica.Martin@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|http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.h tml; Attachment|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:http://www.oasis-open.org/archives/ebxml-bp/200406/msg00053.html Meeting minutes 7 June 2004: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]