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:JDurand@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 [mailto:jeanjadu@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 [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