XML Developer Tip
(Receive this column in your inbox,
click Edit your Profile to subscribe.)
Developer tools: Hard choices must be made
One of the most interesting developments of late in the developer side of the XML marketplace has been the emergence of major "power suites" of developer tools. IBM's got WebSphere and a whole host of free and licensable tools at www.alphaworks.ibm.com. Sun's got Java and XML goodies galore, including all kinds of tools, class libraries, and so forth, at the Java XML Pack page, not to mention Sun's Java Developer Connection. And then of course, there's the whole Microsoft .NET developer initiative, which is just as XML-centric as any of the other options mentioned (or omitted) here (www.microsoft.com/net/ or www.microsoft.com/net/develop/default.asp).
Indeed at each of these sites -- and many others like it around the Web -- there's a certain breathless enthusiasm about the synergy that results from the combination of power, object-oriented programming languages (like Java or C#) and the sheer descriptive power and self-describing notations that XML can support. Then, too, there's the heady notion that XML is platform- and language-neutral, so there might even be some hope that these various initiatives can find some ways to co-exist, and perhaps even to interoperate on an as-needed basis.
Alas, the promise and reality all too often diverge. And while the theory might be that these various development environments and others like them could interoperate, the fact is that making them do so is often possible only through the exertion of heroic efforts. Even given XML's self-describing capabilities, the sticking point all too often occurs in translating behaviors and capabilities that are part and parcel of one development environment into similar but different behaviors and capabilities that are part and parcel of another.
This is the fundamental issue involved in building real-world applications: At some point, developers have to pick a set of tools, stop designing, and start building code. Given that each of the Sun, IBM, and Microsoft toolsets has its pluses (and minuses), its adherents (and detractors), and its hard-core developers, it's almost inevitable that allegiances, factions, and "ways of developing" that are not always compatible will emerge from this wealth of possible choices.
And although XML does offer the hope that real users -- who may want to combine Sun Web servers with IBM databases or services with Windows clients and .NET services -- can lash these various technologies together, the practice will perforce lag behind the theory for some time to come. It will be quite interesting to watch as these services environments mature, as developers become more familiar and comfortable with them, and as enterprise- (or perhaps even Internet-) class applications and services begin to compete for market share. One can hope that "hybrid vigor" of a sort may allow these various options to harmonize and interoperate but the inevitable tendency of developers to use what tools and technologies they know may also weight against this tendency. All we can do is wait, and watch, and hope for the best.
About the Author
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).
For More Information:
- For insightful opinion and commentary, read our Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column avoids the hype.
- Looking for more time-saving XML Developer Tips or .NET Developer Tips?
- Visit our huge Best Web Links for Web Services for editor-selected resources.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.