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] | [List Home]

Subject: RE: [ebxml-msg-comment] Public Comment

Thanks for the comments.  I've cc:d the main list so others can comment here.
The one item I'm familiar with is the "stage delivery" support for push/pull.
I agree that you can do this today with v2 - but its not directly supported - so implementations are not consistent.  Therefore the need is to provide a formal mechanism in v3 here.
Again - application practice has shown we do need this - particularly for large payloads - or to avoid peak surges overwhleming central systems - so non-time-critical deliveries can be picked up at times when the receiver has slack capacity.  As you note it does require longer message persistence by the sender - but again - this can be an essential part of the process - e.g. the sender has fulfilled legal requirement to submit by a deadline - and locked their submission package - but the actual payload delivery can be deferred.  Clearly you have to have agreement on the CPA for the staged delivery responsibilities and timings.  I believe there is enough parameters here to accomplish those settings between two partners so timings and delivery responsiblity is not an issue.  As always - probably some example would help clarify the exact details.
That is just one use case from my experience - I know others have more too.
Anyway - the bottom line is that real world applications have shown us the need to have support in v3 for this formal push/pull mechanism.
Hope that is enough clarification on the rationale behind it. 
Thanks, DW

-------- Original Message --------
Subject: [ebxml-msg-comment] Public Comment
From: Gait Boxman <gait.boxman@tie.nl>
Date: Mon, July 10, 2006 5:13 am
To: ebxml-msg-comment@lists.oasis-open.org

Please find below some concerns on the draft ebMS 3 specification.

Unfortunately I was not able to go into detail, and can only comment on
some high-level issues based on a feature list from Jacques.

- Section 3 introduces a 'message pulling' feature on the SOAP level to
overcome limitations such as availibility of static IP
I find it strange that one would need such a feature, since ebMS 2
already provides SMTP/POP3 based transport which already covers such a
need. The main issue with this is shifting responsibilities. A sender is
now required to keep the message available for the recipient on his
server, rather than dropping it in the realm of the recipient when
ready. This blurs the division of responsibility and leads to issues
with message turnaround times.
- Section 2.2 introduces 'message exchange patterns', which attempt to
tightly couple business process with a particular message exchange. This
shouldn't be part of ebMS as it introduces too much dependency between
process and messaging. The problems with sync and async messaging
modules wrt to MEP already indicate you're not on the right path here.
Please stick to the reftomessageid for linking messages and allow
business process to design the message patterns for the process. All we
need to do here is making sure people 'can' relate messages if they need to.

- Section 5,7,8 - changing the header formats to comply with WS*.
The main issue is backwards compatiblity. While I learned from Jacques
that SwA is still the way to go, moving critical information about in
the SOAP Envelope will require recoding at the core. This will hamper
migration from ebMS 2 to ebMS 3 environments, if not block them
completely, leaving the communities on an island and requiring
implementers to maintain two versions.

- Processing Modes.
Having a concise set of data for processing modes is a good idea. In the
past, we've seen people struggle with CPA's to configure their MSH's.
Whether or not we need a 'formal' PM document is another issue, I
believe the content is already inside the ebMS2 spec, it just needs to
be elevated into a concise document essentially detailing the various
parameters that one may set.

- Conformance Profiles.
Using a conformance profiles document seperate from the main spec or
embedding it doesn't make a lot of difference. However, allowing choice
on things like the version of SOAP or WSS introduces options that may
hamper interoperability on the larger scale. IMO, It would be in the
interest of the market (both developers and users) to fix versions of
underlying protocols as much as possible in order to avoid flexibilities
that may divide the market. Even when e.g. SOAP 1.2 is backwards
compatible with SOAP 1.1, it is better to decide on SOAP 1.1 or SOAP
1.2, rather than leaving it open. It simply reduces the number of
*possible* interoperability issues and the amount of test sets we need
to add for interoperability.
If ebMS 3 doesn't decide on SOAP 1.1 or 1.2, it probably also doesn't
decide pro or against SOAP 1.3, which may be not so backwards
compatible. This extends to all the underlying protocols, and the
combinatorial exponent of them..

HTH, kind regards.
Gait Boxman.

To unsubscribe, e-mail: ebxml-msg-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ebxml-msg-comment-help@lists.oasis-open.org

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