RE: [ebxml-msg-comment] Public Comment

["David RR Webber \(XML\)" <david@drrw.info>]

Gait,

 

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