XMLSPY Deepens Ties with J2EE, .NET Devs
Altova Inc. continues to broaden its outreach for XMLSPY to both the Java and .NET devs. This week, IDN looks in-depth at news Altova will integrate XMLSPY with BEA Weblogic Workshop, as well as Altova's plans for later this year to marry its XML technologies with Microsoft's .NET tools and platforms. We also take a long-range look at why vendors are becoming more and more interested in XMLSPY and other XML development tools.
This week, Altova Inc., creator of the leading XML dev environment XMLSPY 5, announced it will bundle its tool with BEA System's WebLogic Workshop. This is the latest in a series of moves Altova has made to broaden XMLSPY's outreach -- and utility -- as the company continues to ratchet up partnerships with leading vendors on both the Java and .NET sides. .
XMLSPY 5 includes an XSLT debugger, a WSDL editor, HTML-to-XML conversion utilities, and XML Schema-driven code-generation features.
In BEA's case, Altova has actually worked with BEA engineers to integrate XMLSPY with BEA's WebLogic Workshop 8.1 J2EE tools. The result? XMLSPY is integrated with BEA's XML Beans technologies to ease the creation of consistent XML Schemas for Java/J2EE developers, Altova's Technical Director Larry Kim told IDN. However, in this first version of the integrated products, developers will continue to use the XMLSPY interface to retrieve and edit their XML code, as XMLSPY will not be available directly through Workshop's user interface.
On the .NET frontier, Altova is also working to improve its ties to Microsoft .NET tools and servers, Kim said, which will be demo'ed at Microsoft's upcoming Professional Developers Conference in Los Angeles in October.
While Kim would not comment on the details of Altova's work with Microsoft, sources familiar with the Altova/Microsoft relationship said the new work is directed at increasing the roles XMLSPY will play in describing, storing and transmitting information used throughout the Microsoft.NET framework, as well as numerous Microsoft products and servers such as SQL Server 2000, CMS 2002 and Office 2003.
At least one web services analyst says the momentum for Altova could continue to grow in both the Java and .NET communities.
"Altova has simply done an excellent job of producing one of the best interfaces for working with and manipulating XML, and XMLSPY has done a better job of getting developers to use their tool than any other XML editing tool. That's why BEA and Microsoft and others want to partner with them -- they have considerable developer mind-share," said Ronald Schmelzer, co-founder of web services analysis firm ZapThink.
Using XML To Overcome Java Objects Limitations
"In the end, this partnership is a realization that all web services are still XML-based technologies and rely on XML Schema, as well as other XML technologies such as WSDL, SOAP and UDDI. So, our partnership with BEA is meant to acknowledge that many Java developers would like easier-to-use XML technologies," Kim told IDN.
"Web services technologies can be very hard to implement in J2EE, and so this [integrated] approach offers the WebLogic developer community easier ways to build their base XML services."
With this partnership, WebLogic developers can use XMLSPY 5 to edit XML files and define XML schema definitions for use in BEA WebLogic Workshop. Combined with WebLogic Workshop's XMLBeans technology, developers can more easily define the format of their XML data using XMLSPY, and leverage it within a WebLogic application.
The theme of making it easier for Java and J2EE developers to work with XML directly is one of the driving factors for BEA. Carl Sjogren, BEA senior product manager, noted two instances:
1. "Although the XML Schema spec[ification] is pretty rich, tools like XMLSPY will make it easier to build schemas and introduce the business rules into the schema file," Carl Sjogren told IDN.
2. Then, there's the problem of addressing certain limitations in using Java classes for loosely coupled applications, he added. "Say you're building a web service to exchange a purchase order. Today, the developer needs to define the PO by defining a bunch of Java objects or classes and then define the XML schema. The problem with using a Java clas approach is that once you build those classes and define the schema, any other user [not already defined] will break the application," Sjogren said. By using XMLSPY to build the schema, which can then be dragged and droped into BEA's XMLBeans, a developer could pass these objects (in XML, not Java) between any user, he added.
For his part, Altova's Kim noted another benefit to integration: "Whenever you encounter an XML artifact in Workshop, you can load the file into XMLSPY from within the Workshop tool and presumably work on it and save it, and continue to work. Workshop does some XML generation, but the problem is that what's generated isn't always what you want. Having XMLSPY integrated [with BEA] will make it easier for a developer to customize."
The joint BEA WebLogic Workshop 8.1 with XMLSPY 5 solution is available today. Developers can download a free developer license of WebLogic Workshop 8.1 with a free copy of XMLSPY5 WebLogic Edition, including a 30-day evaluation license for XMLSPY 5 Enterprise Editionhere.
This ability to generate clean XML Schema in development will not extend to runtime, at least in this edition. "Our tool is a design-time tool," Kim explained, "so we won't tell you if an XML message got through or not. We do have testing and debugging tools, however, so our SOAP debugger can debug and inspect the request and the responses."
What Should Devs Look Out for Next?
What is the broader implication for developers from Altova bundling with BEA? Is XML really that complicated, or are there business forces at play?
ZapThink's Schmelzer shared some very provocative opinions on the deal with IDN, looking at it from both the developer and the vendor perspective. Overall, his concern is that even as life gets easier for Java/J2EE devs, they should be on the alert for the possibility that they will get locked-in to specific Java tools.
"There's quite a bit of activity by a wide variety of companies looking to attract developers to their respective platforms," Schmelzer said. In particular, the J2EE vendors including BEA, IBM, Borland and others see developers as the linchpin of their growth strategies going forward. Why such an emphasis on the developer?
The reason is simple, Schmelzer said: "The application server and other components of the J2EE runtime stack are rapidly becoming commoditized." And, for this reason, these vendors are trying to find ways to work their way "up the stack" to more strategic and less easily-commoditized application components, including portals, business process applications, service-oriented integration and other areas traditionally in the realm of application development, rather than runtime. As a result, many of these vendors have to court developers with whom they've had little interaction in the past.
So, Schmelzer says, there is a broader significance behind the Altova/BEA partnership that Java/J2EE developers should notice:
"How will BEA attract scripting-level and business-level developers to their portal and business process orchestration applications? How can IBM attract non-data center administrators to their developer-centric web services management platform?
"XML and Web Services, in particular, is key to this transition to higher-level business applications," Schmelzer added. Since XML and web services are used to address key integration challenges by smoothing system dependencies and proprietary descriptions, it can be used as the method to snag developers who might otherwise not be interested in developing for a "proprietary" platform.
This challenge means that the platform vendors will increasingly partner with, if not outright acquire, many of the developer-centric organizations. Perhaps even Borland might be swallowed up sometime soon.