RE: Competing Specifications - A Good or Bad Thing?

["Scott Wiseman" <scott@intercore.net>]

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
ebMS]

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
WS-CAF
* 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
Associate
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:

<http://www.oasis-open.org/mlmanage/>


 

Regards,

 

 

Scott Wiseman

Client Services

 

Network Consultant Los Angeles
http://www.InterCore.net
 
Exchange Consultant Los Angeles
http://www.Avidware.com
 
Security Consultant Los Angeles
http://www.FastForwardMarcom.com
 
Americas Best Dating Service
http://www.AboutSingles.net