[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [FWD: [ebxml-msg-comment] Public Comment]
-------- Original Message --------
Subject: [ebxml-msg-comment] Public Comment
From: derrick.evans@bt.com
Date: Wed, July 12, 2006 9:04 am
To: <ebxml-msg-comment@lists.oasis-open.org>
Thanks for the opportunity to comment. Sorry this is late.
My comments on the ebXML ms 3.0 spec are as follows.
Section 2.2 MEPs
This section is useful but the problem is how far to go. The document
mentions the use of eb:RefToMessageId
but not conversationId and does not talk about the relation in time
between the various messages.
So I am not sure what role this section plays in a document on the
messaging standard. I suspect that ebBP or some such
would be a better place to talk of these things in terms of the
structure of transaction patterns?
Section 3 - Message Pulling
If the challenges can be met then I see this as a great step forward for
ebXML ms3.0.
In our current communities we have been moving to ebXML ms2.0 from a
mechanism based on XML posted over http with responses being polled by
the client.
The moment we explain that we are moving to push push many of our
partners respond with "it wont work".
Our intention would not be to move to an exclusive push pull model but
rather when outbound messages fail to be received we would take those
messages and
requeue them such that they could be pulled by a partner as part of
their recovery process.
Section 4 - Processing Modes
I think this concept is a very good one. Not sure why the default P-Mode
has no reliability. My view of ebXML ms is that a key feature is
reliable messaging.
Conformance Profiles
Having choices is good however we are in a very diverse community (using
ebMS solutions from three different vendors in the community plus an
open source implementation and
Three home grown ones).
When it came to interop even our use of ebXML CPA/CPP threw some of
them.
It would be useful to try and come of the fence here even if it is to
make a stand on the default first port of choice for all the commercial
vendors.
Thanks for all the hard work on this standard
Derrick Evans
BT OneIT
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]