Public Comment

[Gait Boxman <gait.boxman@tie.nl>]

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.