xml-dev - XML and integration (was RE: Various presentations)

["Simon St.Laurent" <simonstl@simonstl.com>]

At 10:22 AM 7/5/00 -0500, Bullard, Claude L (Len) wrote:
>Even without network failures, developers should consider:
>
>1.  Occasionally connected systems may be the rule rather than the
>exception.  
>Even with CDPD and spread spectrum, running offline then uploading
>opportunistically 
>is a fit design where bandwidth remains constrained.  Creating usage
>scenarios with 
>the subject matter experts and current users is advised.  

I completely agree with this.  It's funny how so many folks assume the
network is always there, even the parts you don't control.

>2.  Design to also work *off* the Internet or WWW.  There are lots of
>opportunities to 
>apply markup and related technology without using these systems.

Agreed again.  XML is a bit Web-centric in theory, and practice is worse
because very few developers use FPIs on a regular basis.  (I'm only
starting to myself, I should admit.)

>>'Best of Breed' returns    While vendors have tried to use tight
>integration to bolster 
>>weak products with stronger ones, using an open format for connecting parts
>makes it 
>>possible to ignore such marketing-driven connections in favor of approaches
>that more 
>>closely resemble "the right tool for the job." 
>
>The best of breed approach looks better on paper than in an implementation.
>It 
>is the single most expensive approach to medium to large scale systems both
>in 
>the front end implementation and the lifecycle maintenance.  I'd like to say
>it 
>isn't true, but after seeing just how weak a DTD or schema becomes if it is
>made 
>to service both legacy and new requirements, the details can make it almost 
>useless.  

I agree that 'Best of Breed' can be dangerous, if tempting.  My point is
just that XML reduces some of the costs of such development by simplifying
integration and making that integration open enough that it's much easier
to see what's happening when necessary.

Multi-vendor solutions are and have always been difficult - but
single-vendor solutions come with their own pitfalls.

>In effect, we end up breaking down the schemas into much smaller related 
>sets and use system/process constraints to determine their affective scope. 
>Best of breed is hard and expensive.  This is a real world empirical lesson 
>that makes me doubt the long run efficacy of a global semantic web.  I am 
>afraid a lot of resources will disappear down this black hole that could be 
>better applied elsewhere, but like all black holes, it generates a lot 
>of attractive energy.  Some don't see the peril until they are Over 
>The Event Horizon and find out they are now the Wicked Witch of the East:  
>crushed flat by the load, shoeless and with their competitor announcing
>their 
>demise to happy dancing munchkins and a naive development community 
>that now wears their shoes.

I really like the vision of happy dancing munchkins, but I agree that
trying to create 'global solutions' is a black hole.  In general, I don't
think that contradicts the overall claim of the presentation: XML may
actually be more applicable and less dangerous for smaller projects than
for larger ones.

>>More integration work    As customers realize that they aren't stuck with
>single-vendor 
>>solutions any more, maybe even that single-vendor solutions are no longer a
>fruitful 
>>approach, smaller shops and development teams may get back the
>opportunities that the 
>>large software vendors have attempted to claim. 
>
>This will vary enormously by complexity of application.   Caveat emptor.
>What buyers will lose when they try this will be a lot of sleep in exchange
>for a 
>lot of responsibility both managerial and in implementation.   

Agreed.  In large part, how much sleep you lose will depend on how much
control you want to have over your applications.  If you sleep better when
the vendor has the keys, integrating multiple packages is a nightmare.  If
you sleep better when you have the keys, using XML to integrate packages to
your own requirements may be a very pleasant dream.

>Again, best of breed depends tremendously not 
>just on shared vocabulary but shared semantics.  It is incredible how
>resistant 
>the local politic is to the global definitions.   It comes down to the
>calling 
>arguments in a function and dang, if it isn't difficult to get that to
>cohere 
>across more than a few local processes.  Standard object models help here 
>but getting one of these is almost the same as taking all profit out of 
>the product, so only the big guys can afford them, and that of course, 
>nails the small vendors quickly.  Deep pockets help.

That's why I tend to push small vendors toward providing glue for other
people's projects rather than suggesting taking on the big vendors
directly.  Sometimes that glue can be sculpted into something powerful, and
the small vendor becomes big, but it doesn't always happen that way.

>I say this gently but firmly: do not undersell the need to cooperate across 
>the boundaries of viciously competitive information ecologies.  XML is 
>powerless without tedious human contracting processes.  Of internet time 
>downsides, the most dangerous one is its lack of tolerance for the 
>tedious work required to sustain a successful process.

XML can be both powerless and tedious.  Like all technologies, it is
remarkably dependent on the context in which it is used and the strengths
of those applying to succeed.  I certainly hope I didn't give the
impression that XML is a 'silver bullet'.

Thanks for the comments!  I was hoping to get more critical comments at the
presentation itself, but maybe I was just too vague to pin down easily.
There were some great questions regarding different approaches to
scalability, though!


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************