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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Ontolgies, Mappings and Transformations (was RE: WebServic

[ Lists Home | Date Index | Thread Index ]

Miles Sabin wrote:
> Michael Champion wrote,
>>At some point, we know that the "just write a few lines of code"
>>approach breaks down.... or at least that is the conventional
>>explanation for why Enterprise Application Integration didn't live up
>>to its hype a few years ago.  (N x N little adapters turns into a big
>>job as N gets large ...).
> Except that it isn't O(n^2), because when n gets large it's very rare 
> that everybody needs to be able to talk to everybody else. I have no 
> evidence to back this up, but I conjecture that the scaling is much 
> more like O(n log n) or better.

The real complication I've seen in integration is that you don't know 
who's going to need to talk to each other in the future, not that you 
need to cater for everyone talking to each other. In reality everyone is 
not talking to everyone else, but O(n^2) tends to stay on the agenda.

> OTOH, I believe that the effort involved in getting n parties to agree 
> on a common schema or ontology or API scales at O(n^2) or worse. I 
> haven't much evidence here either (other anecdotal from experiences on 
> too many working groups of one kind or another), but intuitively it's 
> due to a mixture of conflicting interests and the fact that the common 
> schema/ontology/API would be hard to change if adopted, so has to be 
> finessed for flexibility and extensibility far more than would be even 
> faintly reasonable for a more local and partial solution.

I would say a real issue is that parties are best described as 
self-interested agents even where they need to co-operate with each 
other. Optimizing an ecosystem according along macro-economic lines is 
not what they care about. This is a major distinction between single 
administration (distributed) and multi-administration (decentralized) 
integrations. If assuming the network is reliable is a technical 
fallacy, then assuming parties are cooperative is a social fallacy.

Incidentally, this points to a significant non-technical benefit of 
using XML. With XML, the mean time to allocate responsibility for a 
defect is shortened.



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

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