OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: CPPA and migration from ebMS2 to ebMS3


 
Hello,
 
I have a question related to our discussion on support for ebMS3 in CPPA.  Perhaps we can discuss this at our informal meeting next week, or during some future TC meeting.
 
Assume a community (there is an actual case behind this, but it seems like a general enough issue to discuss in the TC) is currently evaluating various alternatives for a B2B-type message exchange, and ebXML is one of the options.   Today ebMS2 supports their needs (reliability, security), but what about two/three years from now?  It might functionally still meet their needs, but other specifications will have emerged and/or matured.  Do they then face another migration?  Shouldn't they just wait until the dust settles?
 
To alleviate concerns, CPPA support for ebMS3 would be great, if they could just update their ebMS2 CPAs and continue their trading relation, once their ebMS2/CPA2.0 software suppliers add support for ebMS3 and CPA3 to an existing ebMS2/CPA2 supporting product.   Migration costs could be fairly minimal.  If the CPAs are derived from templates (with fixed parameter combinations for syncreplymode, reliability and security), use commonly selected options (e.g. syncreplymode "none" or "mshSignalsOnly", not an unusual value like "responseOnly")  and vary only in business process-related areas (services, actions, timings), the conversion could even be automated using e.g. an XSLT stylesheet.
 
While ebMS3 is not finished and CPA is dependent on that, do you feel the statement in the preceding paragraph is likely to be correct?  I'm not looking for a scientific (or legally binding) answer, just for some well-informed opinions.  It would give users confidence that they are safe to use ebMS2 now, and have an clear migration path to a future spec. As that spec (ebMS3) converges (in its reuse of WS modules like WS Security) with specifications often presented as alternatives to ebMS, that would further reduce concerns.
 
Pim
 
 
 



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