OASIS ebXML Messaging Services TC

In case we have a meeting scheduled this Wednesday: I’d like to put on the agenda 2 topics: 1.        Information about the GITB (Global eBusiness Interoperability Test Bed initiative ) project at: http://www.ebusiness-testbed.eu/publicaties/4752 , that I participated in (a report about Phase 2 / architecture & principles is in review at: http://www.cen.eu/cen/Sectors/Sectors/ISSS/Workshops/Pages/Testbed.aspx .) 2.        Some brainstorming about what it would take to develop an AS4 conformance test suite, how it could be designed, and possible relationship with the GITB and its next phase (implementation, PoC). Thanks, Jacques  

  I did not work on the AS4 spec yet,  as it's still stuck in the OASIS TC Admin queue.   Here is a summary on issues to address, from lessons learned during the Interop and in prototype implementations. The last two (10) and (11) were not on the list I presented verbally on last week's call.   1-   Compression property with value true instead of empty string for XML schema compliance. 2-   MIME type value in property for a compressed attachment required instead of recommended. 3-   Add note that a compressed payload must be in a separate MIME part and not in the SOAP Body because compressed data is binary and base64 encoding it would increase the message size. 4-   In AS4 5.1.8.(a) and 5.1.8.(b), clarify use of receipts with simple SOAP messages, where the SOAP envelope is not in a part with a content identifier, and has no MIME content ID, so here there can be no part identifier.   5-   In AS4 5.1.8.(a) and 5.1.8.(b), note that it is impossible to generate a valid ebBP reception awareness receipt for simple SOAP messages that have no payload parts. 6-   In AS4 5.1.8.(a) and 5.1.8.(b), decide on ebbp:MessagePartIdentifier format for a payload part in SOAP body that is implicitly identified by absence of an href attribute as described in ebMS3Core section 5.2.2.13. 7-   Clarify that an identifier of a payload in the SOAP Body is a stored as an attribute value on the SOAP Body element, not on the contained document root (AS4 interop). 8-   Discuss the format of the identifier (xml:id or wsu:Id). 9-   Bad references to SOAP 1.1 instead of 1.2. 10- Guidelines on values for mpc (message partition channel) attributes.  Pullrequests do not have ebMS metadata, so a partner that sends documents to multiple partners using Pull mode must assign them to different channels, unless we want to require support for the selective pulling feature of Part 2 in ebMS. 11-  Support for Two Way MEPs.   This is not needed for EDIINT,  but in essence allowing an MSH to set the value for RefToMessageId adds minimal complexity to an implementation.   It  allows A S4 to be used also for SOA-style, request/response interactions. Pim From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand Sent: 31 October 2011 19:38 To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] about testing and GITB In case we have a meeting scheduled this Wednesday: I’d like to put on the agenda 2 topics: 1.        Information about the GITB (Global eBusiness Interoperability Test Bed initiative ) project at: http://www.ebusiness-testbed.eu/publicaties/4752 , that I participated in (a report about Phase 2 / architecture & principles is in review at: http://www.cen.eu/cen/Sectors/Sectors/ISSS/Workshops/Pages/Testbed.aspx .) 2.        Some brainstorming about what it would take to develop an AS4 conformance test suite, how it could be designed, and possible relationship with the GITB and its next phase (implementation, PoC). Thanks, Jacques  

Hi Pim On 01 Nov 2011, at 4:17 PM, Pim van der Eijk wrote: <snip> > 10- Guidelines on values for mpc (message partition channel) attributes. Pullrequests do not have ebMS metadata, so a partner that sends documents to multiple partners using Pull mode must assign them to different channels, unless we want to require support for the "selective pulling" feature of Part 2 in ebMS. Agreed. > 11- Support for Two Way MEPs. This is not needed for EDIINT, but in essence allowing an MSH to set the value for RefToMessageId adds minimal complexity to an implementation. It allowsAS4 to be used also for SOA-style, request/response interactions. Why not N-way MEPs covering multiple legs (or a complete B2B business process conversation) ? Then an issue that has come up with interop testing with the JEITA system is a question on whether the application message must be in the soap envelope body part, or as an attachment - I can't find anything specific on this in either the AS4 spec or in the core spec... -- Regards Theo

> 11- Support for Two Way MEPs. This is not needed for EDIINT, but in essence allowing an MSH to set the value for RefToMessageId adds minimal complexity to an implementation. It allowsAS4 to be used also for SOA-style, request/response interactions. Why not N-way MEPs covering multiple legs (or a complete B2B business process conversation) ? Then an issue that has come up with interop testing with the JEITA system is a question on whether the application message must be in the soap envelope body part, or as an attachment - I can't find anything specific on this in either the AS4 spec or in the core spec...Regards Theo Comment: It is always possible for an implementation to support multiple conformance profiles. Rather than add features to the AS4 conformance profile, it might be preferable simply to point out that the additional features can be found in implementations that conform to AS4 and also some selected richer conformance profile. Perhaps there can be a recommendation made by groups needing this additional functionality as to which ebMS 3 conformance profile can provide this additional functionality? At any rate, I think we should resist the temptation to expand the AS4 profile. ebMS3 profiles are available with additional functionality. And using AS4 for cloud interconnect (for example) may benefit from having a mix that spans ebMS3 core (part 1) functionality and selected ebMS 3 advanced (part 2) functionality. Or so it seems to me.

AS4 is not sufficient for those current users of ebMS 2.0 (possibly looking for an upgrade path to a newer protocol) that are using ebMS more in an SOA style, including (asynchronous) request/response exchanges, than in a pure One Way document exchange style.   (BTW t he START protocol submitted to the BDX TC has the same limitation as AS4. START follows the CEN BII concept of business transactions, which are all One Way.).   I also see your point.  To support Two Way,  a   conformant MSH only needs to enable some control over presence and value of RefToMessageId element.  This is trivial for any ebMS 3.0 implementation. So perhaps it will be implemented even though AS4 doesn't use it,because supporting it is so easy. We'll have to see what parts of ebMS 3.0 vendors will implement.   But AS4 is likely to be the first profile of ebMS 3.0 that vendors will support, and for some, it may be the only profile, so that's why I raised the issue. 
Original Message----- At any rate, I think we should resist the temptation to expand the AS4 profile. ebMS3 profiles are available with additional functionality. And using AS4 for cloud interconnect (for example) may benefit from having a mix that spans ebMS3 core (part 1) functionality and selected ebMS 3 advanced (part 2) functionality. Or so it seems to me.