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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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

Subject: RE: Competing Specifications - A Good or Bad Thing?

That is ok for the 2 postings.

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: Friday, April 02, 2004 10:12 AM
To: ebxml-dev@lists.ebxml.org
Subject: Competing Specifications - A Good or Bad Thing?

[I sent this earlier today to XML-DEV - apologies for duplicate posting
for those subscribed to both lists. I believe that my inquiry has direct
bearing on ebXML in cases in which, for example, 2 organizations may be
using messaging standards, with one being ebMS and the other not being

I have a theory on the subject of "competing specifications" that I'd
like to present, in hopes of getting some good feedback. I'm thinking
mostly in terms of Web Services specifications - or specifications that
are not intended strictly for Web Services by nature, but have
applicability to Web Services. 

By "competing", I mean 2 or more specifications that cover the same
"functional area" (e.g. reliable messaging, context, transactions, etc.)
and most/all of the same general actions that are applicable to that
functional area (e.g. for reliable messaging, "notify a sender reliable
messaging processor that a message was received out-of-order"). Some
examples of such overlapping specifications (both "open" and emerging)
would be:

* Reliable Messaging: OASIS WS-Reliability, WS-ReliableMessaging
* Transaction/Coordination: WS-Transaction (WS-AT and WS-BA), OASIS
* Identity Management: Liberty Alliance, OASIS SAML 2.0

My theory: Competing specifications are not necessarily a bad thing, as
long as:

(1) The cost to an organization to interoperate with another
organization (or another system within the organization) that implements
a competing specification in a given functional area is either minimal
or 0, and 
(2) The risk is either minimal or 0

One case in which the risk would (in my opinion) be more than minimal,
and possibly quite high, would be in reliable messaging: WS-Reliability,
for example, considers a message ID to be a unique combination of [a
Group ID + a Sequence ID]; if an organization that implemented
WS-Reliability were, for example, to interoperate with an organization
that implemented a reliable messaging standard that did not group
message IDs together (but instead used unique message IDs for each
message), a middle process would be required to pack/unpack groups of
messages between the installations as required. If this "translation"
were to be faulty (due to a software or configuration bug), the whole
messaging interaction could be - pardon the pun - unreliable.

Thoughts? Comments?
Kind Regards,
Joseph Chiusano
Booz | Allen | Hamilton

The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
list archives are at http://lists.ebxml.org/archives/ebxml-dev/
To subscribe or unsubscribe from this list use the subscription manager:






Scott Wiseman

Client Services


Network Consultant Los Angeles
Exchange Consultant Los Angeles
Security Consultant Los Angeles
Americas Best Dating Service

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC