[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Public Comment
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.