[
Lists Home |
Date Index |
Thread Index
]
( .... I like XML-DEV on sundays -- I can actually keep-up ... )
On Sun, 8 Dec 2002, Mike Champion wrote:
> On Sun, 8 Dec 2002 12:43:17 -0500 (EST), Ian Graham <igraham@ic-unix.ic.utoronto.ca>
> wrote:
>
> > On Thu, 5 Dec 2002, Tim Bray wrote:
>
> >> There's a deep tension here that won't go away. Some of us really REALLY
> >> want to be able to deal with the bits on the wire and REALLY like the
> >> open-ness and interoperability that gives us.
>
> > Amen.
> >
> > I am currently working on a Web services implementation in a large
> > financial services company. Other than performance (!) the main concern
> > of the team leads is finding the perfect tool that hides all XML
> > knowledge behind:
> >
> > * an appropriate WSDL spec and schema (designed by a singularly talented
> > and small group of 'experts')
> > * a good code generator that produces framework-specific proxy and
> > template classes (e.g. Iona, Websphere, .NET, weblogic frameworks)
> > * a good code development environment that embraces the corresponding services
> > framework (for use by the app. developers)
>
> I'm not sure who or what you're blessing :-) I doubt if Tim would agree
> with you about hiding the XML behind toolkits, and even I -- infidel that
> I am -- worry when this is done in the name of performance.
Blessed be the XMLer, for they shall see angle brackets ;-)
Philosophically I agree with Tim - I am much more comfortable with
technology I understand, and technology that lets me see what's going on,
and why it works (or doesn't). But I also think this is a purists /
technologists perspective, and one not embraced by application portfolio
managers / developers in non-technology businesses (like financial
services, manufacturing, etc.)
And they're the ones buying all the stuff!
> > On the other hand, I can be convinced that this choice actually makes
> > good
> > business sense. The company doesn't want to be a technology company --
> > that's not their business. They just want the stuff to work
>
> Sigh. I kindof hope that Paul Prescod is listening, because it's
> exactly this point that keeps me from adopting RESTifarianism
> wholesale. I wish I had a good response. I guess I could channel the
> RDBMS purists/zealots such as C.J. Date and Fabian Pascal and point
> out that those who develop systems without understanding the
> fundamentals are doomed to a) be enslaved to the whims of their tool
> vendors; b) end up perpetually fighting fires because they won't learn
> how to turn off the gas; and c) fail. On the other hand, "good"
> systems such as the Internet and Web don't require developers to
> understand the nasty details of TCP/IP or HTTP. Perhaps this will
> happen with XML too, but I personally doubt if it will happen until
> there is a good bit of refactoring and simplification. For example, I
> will be astonished if the average Office developer can learn to use
> W3C XML Schema language effectively for documents. I fear that the
> complexity of all this will just encourage them to become thralls of
> the tools in the name of "performance," "business sense", etc.
Perhaps the world was lucky with TCP/IP and HTTP, that there was no
commercial clamoring for products before the specs were mostly baked. The
same, for good or bad, can not be said for XML.
Making mistakes is a necessary side-effect of developing new technologies.
Inevitably, some of the XML technologies will be seen as mistakes, but
it's only after implementation failures that these mistakes are seen,
yielding better and more appropriate designs..
I'm sure this happened in the early days of TCP/IP, SMTP, escalator
design, whatever ... -- but we didn't have the whole world (and companies
with market capitalization well in excess of $100 billion) watching!
> I personally think that the best *business* strategy is to make sure that
> you working with just those bits of the Web and XML infrastructure that
> they can understand and develop with without necessarily
> requiring the toolkits, and choose toolkit vendors who automate the tedium
> rather than hiding the architecture of the infrastructure.
Yes, but companies rarely sell a 'best bits of XML' toolkit.... ;-(
Indeed, it would be a really hard sell -- most companies purchasing
development technology want an all-in-one solution (or all in a few), and
if company X's product lacks one of the features on the Gartner or Giga
checklist - then it's off the shortlist.
Basically, the don't want to think too hard about technology -- they want
the tool developer to do all that for them.
The fact that -- for what they are specifically implementing -- the chosen
toolkit may not be the best and may have lots of extras they never use,
doesn't really matter. From their perspective they've reduced risk by
purchasing something that does what they want, and can do other stuff,
with no need for new tooling and training.
Ian
|
