----- Original Message -----
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: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