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


Help: OASIS Mailing Lists Help | MarkMail Help



   Competing Specifications - A Good or Bad Thing?

[ Lists Home | Date Index | Thread Index ]

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS