OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-msg] Messaging Spec v1.092


Title: RE: [ebxml-msg] Messaging Spec v1.092
That would be my sincerest hope;-)

Burdett, David wrote:
C1E0143CD365A445A4417083BF6F42CC0192B322@C1plenaexm07.commerceone.com">

You can't use WSDL as it does not contain the necessary information. A "take-it-or-leave-it" CPP would work but it is not WSDL. IMO, WSDL and CPP need to converge. Do you think this is possible?

David

-----Original Message-----
From: Martin W Sachs [ mailto:mwsachs@us.ibm.com ]
Sent: Monday, January 07, 2002 12:30 PM
To: Burdett, David
Cc: Burdett, David; David Fischer; Jacques Durand; Arvola Chan; ebXML
Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092



David,

I didn't miss the point at all.  My point is that if you want "simple", you
have SOAP/WSDL.  If you want reliability, security, etc., that's what we
have done that SOAP doesn't have.  However this rich function comes at a
price of some cost for generating compatible configurations.

One way of extending MSG/CPPA for B2C is by allowing a service provider to
publish a CPP (or a CPA template) that is a take-it-or-leave-it CPP. "If
you want to do business with me, you set up this way."  That might be fine
for customers but it probably wouldn't be sufficient for B2B.  However,
many people will ask, why not just use WSDL?

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 01/07/2002 12:45:05 PM

To:    Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
       <david.burdett@commerceone.com>
cc:    David Fischer <david@drummondgroup.com>, Jacques Durand
       <JDurand@fs.fujitsu.com>, Arvola Chan <arvola@tibco.com>, ebXML Msg
       <ebxml-msg@lists.oasis-open.org>, "Ian. C. Jones (E-mail)"
       <ian.c.jones@bt.com>
Subject:    RE: [ebxml-msg] Messaging Spec v1.092



Marty

I think you miss the point. SOAP is not fit for purpose as it does not
include reliability and security. What we really need to do is extend
SOAP/WSDL to include security, reliability, end-to-end acks, etc, but in
the
declarative, take-it-or-leave-it style of WSDL **as well as** the
negotiated
way consisting of the merging of templates that I think you are suggesting.
Remember, I really am not anti-CPA, I just want them to be used in the
right
way i.e. to record the agreement between two parties where they want to
constrain how they do business together.

David

-----Original Message-----
From: Martin W Sachs [ mailto:mwsachs@us.ibm.com ]
Sent: Monday, January 07, 2002 9:11 AM
To: Burdett, David
Cc: David Fischer; Jacques Durand; Arvola Chan; ebXML Msg; Ian. C. Jones
(E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092



Sorry to repeat myself:

There is already a simple protocol that requires no prenegotiation.  It's
called Simple Object Access Protocol.  All the MSG team has to do is throw
out all the ebXML add-ons and you have SOAP and we can all go home.

Similarly, if what you want is for some Web service to dictate the IT terms
and conditions to anyone who wants to do business with it, all you need is
WSDL.  If that's the world you want, again, no re-inventing is needed.

In other words, there already exists what is needed for SMEs.  We could
subset ebXML down to the equivalent of SOAP/WSDL or we could decide that
our space is really B2B.

Regards,
Marty

****************************************************************************

*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************

*********



"Burdett, David" <david.burdett@commerceone.com> on 01/07/2002 11:39:38 AM

To:    Martin W Sachs/Watson/IBM@IBMUS, David Fischer
       <david@drummondgroup.com>
cc:    Jacques Durand <JDurand@fs.fujitsu.com>, Arvola Chan
       <arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>,
       "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
Subject:    RE: [ebxml-msg] Messaging Spec v1.092





Marty

You said ...

>>>MWS:  See my first comment above.  You cannot avoid the runtime database
unless you think that you can legislate a single software and middleware
configuration that everyone is required to use on pain of ...<<<

I agree you cannot legislate, but you should be able to define default
parameters for sending a message reliably, for example, which does not
require prior negotiation.

What we need to do, is make a decision early-on in the development of the
next spec on whether we are going to develop:
1. A Negotiation Protocol, which leads to the agreement of a CPA, which
then results in the exchange of messages according to the ebMS spec (which
is what I think you are suggesting Marty), or

2. A lighter weight spec which allows messages to be sent without prior
negotiation but which can reference a negotiated agreement if it exists
(which is what I am suggesting).

Currently I think there are some who think the first approach is overkill
and won't be used by SMEs or the Web Services community, and some who think
the second approach won't work. Either a way decision on the way forward
has to be made.

David

-----Original Message-----
From: Martin W Sachs [ mailto:mwsachs@us.ibm.com ]
Sent: Sunday, January 06, 2002 3:50 PM
To: David Fischer
Cc: Jacques Durand; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092


David,

Some comments below.

Regards,
Marty

****************************************************************************

*********


Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************

*********



"David Fischer" <david@drummondgroup.com> on 01/06/2002 05:23:55 PM

To:    Martin W Sachs/Watson/IBM@IBMUS, "Jacques Durand"
       <JDurand@fs.fujitsu.com>
cc:    "Arvola Chan" <arvola@tibco.com>, "ebXML Msg"
       <ebxml-msg@lists.oasis-open.org>, "Ian. C. Jones \(E-mail\)"
       <ian.c.jones@bt.com>
Subject:    RE: [ebxml-msg] Messaging Spec v1.092


I disagree.  If the specs were truly loosely coupled then we would not have
discussions concerning discrepancies between the header fields and the CPA.
Errors concerning such discrepancies would be implementation dependant.  We
would not worry about aligning Messaging and CPA.  We would not have
continual
problems with having to remove fields from the Messaging headers because
they
are already specified in the CPA (in fact, many fields would exist both
places).

MWS:  You are missing the point, David.  Everything in the CPA is there for
a
reason - to ensure that the two parties are configured compatibly.  The
configuration
information has to be in both parties' systems or they cannot communicate.
You cannot
avoid that requirement.  The only question is whether the two parties get
together
on a a single configuration description or separately type in the
information
through their own GUIs.

We even voted at the last F2F that there MUST be an agreement in place --
no
allowance for spontaneous eCommerce.

MWS:  CPA does not preclude spontaneous eCommerce. Eventually there will be
an
automated composition/negotiation process in place that will allow the
configuration
setup to be fast enough for spontaneous eCommerce. The CPPA team is taking
the
first steps toward this now.  Lack of a CPA is what precludes spontaneous
eCommerce because that guarantees that the relationship has to be
configured
manually.

There has been constant discussion that
there MUST be either a CPA or a "virtual CPA", which simply means a
database
containing all the CPA fields and structures even though there may not be
an
actual XML document anywhere.  Quotes from the spec to the contrary are
simply
my lack of diligence in removing them since the last F2F.

MWS:  See my first comment above.  You cannot avoid the runtime database
unless you
think that you can legislate a single software and middleware configuration
that
everyone is required to use on pain of ...

If we could move back to a time when we did allow non-agreement (with or
without
CPA) type eCommerce, then that would remove my objection -- but I don't
think
that is where we are now.

MWS:  Non-agreement means non-communication if there are any configuration
variables,
and today there are plenty.

Our original charter was to focus on the SME needs in
eCommerce.  I would argue the SME's need something more akin to B2C rather
than
traditional B2B (I don't mean Web based but I do mean spontaneous).  My
objection is that our (very good) system is largely a rehash of what has
gone
before (and maybe somewhat of an improvement) but it does NOT adequately
address
the needs of SME's.

MWS:  If you want extreme simplicity, SOAP and WSDL have already done it,
so maybe
we should fold up shop and let Web Services take over.

Now, someone else please take the SOAP box  ;-).

Regards,

David Fischer
Drummond Group.


-----Original Message-----
From: Martin W Sachs [ mailto:mwsachs@us.ibm.com ]
Sent: Friday, January 04, 2002 10:39 PM
To: Jacques Durand
Cc: 'David Fischer'; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092


Jacques,

I agree with you that the MSG spec is NOT tightly coupled to the CPA. The
words you quote are exactly the words that eliminate dependence on the CPA.
However, information that can be encoded in the CPA is still needed to
enable to partners to exchange messages.  Without a CPA,  that information
is entered separately into each partner's system via a GUI tool.  That's as
loosely coupled as you can ask for.

****************************************************************************

****


*****

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************

****


*****


Jacques Durand <JDurand@fs.fujitsu.com> on 01/04/2002 07:21:24 PM

To:    "'David Fischer'" <david@drummondgroup.com>, Arvola Chan
       <arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>,
       "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
cc:
Subject:    RE: [ebxml-msg] Messaging Spec v1.092



David:

No  problem with V2.0, agree that "1.1" is misleading with regard to
backward  compatibility.

The adoption of an (early) incompatible new version can still be helped if
the  upgrade is such that it
allows for an upgraded  MSH implementation to handle in parallel the two
"incompatible" versions

during  a transition period, (in case running two different MSH  instances
on same site is problematic).

That  is quite possible using version # in header, if the incompatibility
is  mostly in the packaging format,
with  no conflicting MSH behavior . This would permit a smooth transition,
not  needing
all  trading partners to upgrade at same time.

"Tightly" integrated with CPA? Just reading V1.092  I did  not have this
impression:

"...However, the method used by a specific  implementation of the MSH does
not mandate the existence of a discrete instance  of a CPA.
... This specification does not  prescribe how the CPA information is
derived, stored, or used:
it  only states specific information items must be available for the MSH to
achieve  successful operations."

My understanding is that some (actually small) subset  of CPA needs be
available in some form.
That still sounds like loose coupling to  me...

Regards,

jacques Durand
-----Original Message-----
From: David Fischer  [ mailto:david@drummondgroup.com ]
Sent: Thursday, January 03, 2002  5:48 PM
To: Arvola Chan; ebXML Msg; Ian. C. Jones  (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec  v1.092

Comments inline.

Ian,
We still have a couple of unresolved issues -- most notably the  signature
problem Sanjay pointed out.  There is also the issue (item 6  below) that
SyncReply does not work with Intermediate Acknowledgments.   We are
supposed to start voting tomorrow.  What shall we do?  If you  would like,
I can go ahead and post as version 1.093?

I want to thank everyone for all the help on editing/reviewing the
specification.  I think this is a much better spec than v1.0.  That  said,
I will also say I plan to vote *no* on this spec for two reasons:   1) Our
charter was to create a v1.1 spec with "fixes and clarifications only"
which we have failed to do (if we could name this spec v2.0, as the  RegRep
team did, then this objection would go away),  and  2) Our  original
charter was to create a set of "orthogonal ebXML specifications"  which we
have failed to do (we have tightly coupled Messaging with  CPPA).  I would
like to urge everyone to consider a version number of  v2.0 since v1.1 has
the connotation of backward compatibility which we  certainly have not
achieved.  Our next version could then be  v3.0?

Please let me know what you want to do.

David.
-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com ]
Sent: Wednesday, January 02, 2002 2:34  PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg]  Messaging Spec v1.092

David:

Here are some belated editorial comments. I  hope they can be fixed without
too much trouble:

   Line 18: Don't  we have to wait for a calendar quarter boundary before
   the spec can be  presented to the OASIS membership for consideration as
   an OASIS  specification?
   <df>Fixed --  this means we will submit on April Fools Day   ;-)
         We still don't have anything  under the *This Version*
   heading</df>
   Line 311: The reference to [ebREQ] cannot be  found among the
   Non-Normative References (see line  2761).
   <df>Added  Reference</df>
   LIne 896: The permissible values for  duplicateElimination in the CPA
   are perMessage, never, and always.  Therefore, replace "set to false"
   with "set to never" on line 897. Note:  this is with respect to the 1.1
   CPP/A spec. Do we need to add a reference  to the forthcoming 1.1 CPP/A
   spec?
   <df>done</df>
   Line 1384: The schema says that this is a  REQUIRED attribute. It must
   be set to the value " http://schemas.xmlsoap.org/soap/actor/next ".  It is
   somewhat different from being declared as a FIXED attribute in the
   schema. Line 1384 seems to suggest the latter. Excerpts from the SOAP
   1.1  spec: "The SOAP actor global attribute can be used to indicate the
   recipient of a header element. The value of the SOAP actor attribute is
   a  URI. The special URI " http://schemas.xmlsoap.org/soap/actor/next "
   indicates that the header element is intended for the very first SOAP
   application that processes the message. This is similar to the
   hop-by-hop  scope model represented by the Connection header field in
   HTTP. Omitting  the SOAP actor attribute indicates that the recipient is
   the ultimate  destination of the SOAP message. This attribute MUST
   appear in the SOAP  message instance in order to be effective (see
   section 3 and 4.2.1)."
   <df>Changed "fixed" to  "REQUIRED"</df>
   Line 1389: CPP/A attribute names start with a  lower case. SyncReplyMode
   should be globally repaced with  syncReplyMode.
   <df>done</df>
   Line 1412: I like to point out that a  SyncReply element is not
   compatible with an AckRequested element that is  targeted at the next
   MSH.
   <df>No  resolution yet.</df>
   Line 1491: I think an errorCode of  Inconsistent should be accompanied
   by a severity of Error rather than  warning. Didn't we decide that
   inconsistency between the CPA and the  message header must always result
   in an error being  returned?
   <df>This might  not be an inconsistency with the CPA (perMessage).  If
   we say this  must be an Error then we must also say the To Party MSH
   MUST NOT deliver  to the Application.  IMO This needs to be a
   Warning.</df>
   1502: The statement "An Error Message MUST NOT  contain an AckRequested
   element" is not correct and should be struck out.  Please see
   http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html
   (Resolution  of issues in the issues database), IssueId 73, and/or
   http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc ,
   Issue 73.
   <df>We have gone  back and forth on this several times.  I think the
   latest was to  change to *no Ack on Error*.  If we go back to *no Error
   on Ack* then  I need to go back through the spec and make several
   changes.  See  *[ebxml-msg] Ack on Error, or Error on Ack* thread
   starting  12/10/01.</df>
   Line 1557: I think it is inconsistent to ask  for a signed
   Acknowledgment if the original message is not  signed.
   <df>Why?  I  agree it sounds strange but I can't think of any reason it
   would be  inconsistent.  Someone might want NRR but there is no reason
   to  sign.</df>
   Line 1579: It will be useful to point out that  parameters that are not
   found in the message header are to be obtained  from the CPA.
   <df>??? It  already says this?</df>
   Line 1584: Replace "value of  duplicateElimination in the CPA is false"
   with "value of  duplicateElimination in the CPA is never".
   <df>done</df>
   Line 1591: I think it may be problematical for  the recipient to do
   duplicate elimination when no DuplicateElimination  element is present.
   What happens if SyncReply is present and AckRequested  is not present.
   If the incoming message is not passed on to the  application, should any
   reply be returned to the sender?
   <df>Resolved between Arvola and  Doug</df>
   Line 1602: It will be useful to point  out that the Retries parameter
   comes from the CPA.
   <df>done</df>
   Line 1605: It will be useful to point out that  the RetryInterval
   parameter comes from the CPA.
   <df> done </df>
   Line 1616: It will be useful to point out that  the PersistDuration
   parameter comes from the CPA.
   <df> done </df>
   Line 1625: As mentioned earlier, SyncReplyMode  should be spelt as
   syncReplyMode. Also, I just noticed the following  statement in the 1.0
   CPP/A spec. "If the delivery channel identifies a  transport protocol
   that has no synchronous capabilities (such as SMTP) and  the
   Characteristics element  has a syncReplyMode attribute  with a value
   other than "none", a response SHALL contain the same content  as if the
   transport protocol did support synchronous responses." which
   contradicts the statement on line 1625: "The SyncReplyMode parameter
   from  the CPA is used only if the data communications protocol is
   synchronous  (e.g. HTTP)."
   <df> Resolved </df>
   Line 1646: The sentence is missing a closing  period.
   <df> done </df>
   Line 1678: This seems to contradict the  statement on line 1589.
   <df> deleted </df>
   Line 1684: There is an invalid reference to  section 0.
   <df>   deleted </df>
   Line 1733 and line 1738: These  two bullet points assume that
   syncReplyMode in the CPA is not used with an  asynchronous communication
   channel. This is in conflict with the 1.0  CPP/A spec statement quoted
   in item 15 above. I think this is a minor  technical issue that may
   require some discussion.
   <df>  Resolved  </df>
   Line 1772: Since one MSH is not allowed to  place more than one
   AckRequested element in the SOAP Header (according to  line 1469), this
   matrix represents what an intermediary MSH or the To  Party MSH may
   receive, not what the From Party MSH may send.
   <df> Does this mean 1468/9 is wrong?    It already says *SHOULD* so
   maybe no change is  needed.</df>
   Line 2098: I think the statement "The  Receiving MSH MUST NOT send an
   Acknowledgment Message until the message  has been delivered to the Next
   MSH" is not correct.  This does not  correspond to store and forward
   behavior (see line 2043). The Receiving  MSH cannot know for sure that
   the message has been delivered to the Next  MSH until it receives an
   Acknowledgment from the latter. The prescribed  behavior defeats the
   purpose of intermediate Acknowledgments.
   <df> What would be more correct?  Should it  say *The Receiving MSH MUST
   NOT send an Acknowledgment Message until the  message has
   been persisted?*  Actually, I don't see a problem as  it is.  What
   should I do? </df>
   Line 2619: This comment seems  unnecessary. Would it constitute an
   unrecognized MIME header?
   <df> Yes, this is unnecessary.  No this is  not illegal.  Everything
   between the first blank line and the first  boundary is ignored.  It is
   common for vendors to put  advertising info in this space -- identify
   the product or vendor software  producing this  message. </df>

Regards,
-Arvola

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "ebXML Msg" <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, December 20, 2001 7:25  PM
Subject: [ebxml-msg] Messaging Spec  v1.092

> This is the spec as it stands now.  I think everyone's  comments are
included
> (I'm mad at Doug for sending pages and pages  of very good comments AT
THE LAST
> MINUTE  ;-)
>
>  Please get any last minute comments to me quickly.  Please no large
changes at
> this point.
>
> Ian, I still need to resolve  the copyright issue.  Also, we need to
decide on
> the problem  Sanjay described (I added the change as hidden text if
anyone wants
>  to look at it).
>
> If anyone needs this in PDF, please let me  know.
>
> Regards,
>
> David Fischer
>  Drummond Group
> ebXML-MS Editor.
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC