CHAPTER 3: DEFINING WEB SERVICES AND THEIR CURRENT STATUS
3.4 Barriers to Interoperability
3.4.4 Toolkits
Many current web-service toolkits promote distributed object technologies, particularly on the RPC-style of web-service exchanges (discussed in Chapter 4), at the expense of a data- or document-centric approach, perhaps because it is felt that developers will feel more comfortable in a familiar environment than in dealing with raw XML. Provost draws an only partly
humorous picture of such vendors:
"Web services are a cinch," they'll say. "Just write the same code you always do, and then press this button; presto, it's now a web service, deployed to the application server, with SOAP serializers, and a WSDL descriptor all written out."…Sales and marketing folks want to be able to demonstrate that little or no coding and a lot of code generation add up to a complete web service. [Provost, 2003].
Problems arise not only from this thin disguise of the very different distributed-object technologies sometimes used to implement web services, but also from different
implementations of standards in different web-service toolkits. These are pinpointed in a serious comment made by the company MindReef, the developers of SOAPscope (a Java-based tool for testing SOAP services) and winners of the InfoWorld 2005 Technology of the Year Award:
Microsoft broke rank from the other toolkit vendors when they introduced the notion of a Wrapped Document/Literal message having the name of the operation as the root element of the message content. They also stepped outside of the schema specification for
serializing their DataSet type. Other toolkits have had to reverse engineer the techniques to remain compatible. With the behavior of toolkits diverging in various ways,
interoperability has become a major concern [MindReef, 2004].
The significance of the different message types, including the wrapped and document/literal styles, will be discussed in greater detail in Chapter 4, but it is worth emphasizing at this point that the behaviour of major companies responsible for web-service toolkits has in the past been to try to force the web-service community to adopt their standards rather than to conform to those ratified by the standardizing bodies.
Apart from the servers and toolkits used in this study, which will be discussed at greater length in Chapter 7, other web-services toolkits available in late 2005 and freely available for
non-commercial development include:
• SUN's Java Web Service Developer Pack15 (in late 2005 at version 1.6), which is meant to be installed within either a (Sun-configured, non-current) version of Tomcat or one of the available Sun web servers. Reasons for not including this toolkit in the study are given in section 7.1.1 of Chapter 7.
• MICROSOFT's Office XP Web Services Toolkit16, which may be used from an Office 2003 program and uses the inbuilt VB Editor to create a proxy object.
• KAPOW's RoboSuite17, linked to BEA WebLogic, which uses a point and click wizard to send and return objects and their attributes, stored in a database-type format, using existing web sites as a handle for the web-service creation. The demo does not even mention the use of a WSDL file, although it displays the SOAP messages that it constructs and sends.
• CAPE CLEAR's free SOA Editor18, renamed from their earlier WSDL Editor (the renaming indicating the shift of emphasis towards SOA, which is more clearly
15 See http://java.sun.com/webservices/jwsdp/index.jsp [Sun, 2005a].
16 See http://www.microsoft.com/office/previous/xp/webservices/toolkit.asp [XP Toolkit, 2005].
17 See http://kdc.kapowtech.com/presentations/IntegrationBEA_viewlet_swf.html for an interactive demo [Kapow, 2005].
18 See http://www.capescience.com/soa/index.shtml [Cape Clear, 2004].
embodied in their commercial offering, Cape Clear 6, advertised as the latest version of their Enterprise Service Bus). The editor enables graphical WSDL editing, still biased towards the SOAP encoding of SOAP version 1.1, towards RPC-style, and with a customized SOAPAction element. It has not been updated since 2004 and it produces indecipherably complex error messages, sometimes the length of a page. The errors it lists do not appear as errors in more recent validating XML editors such as XMLSpy and the Java-based Oxygen, but it does offer a basic starting point for WSDL creation, the files created through its graphical interface are fully editable elsewhere and its help files are excellent. It also observes the requirement (discussed in section 4.3.1.1) that the WSDL targetNamespace be dereferencible to a WSDL document.
• ORACLE offers several free and commercial products which include web-service toolkits, such as its Application Server 10g19.
• IONA has a free product, Celtix20 which, like Cape Clear 6, is a version of an Enterprise Service Bus. It is a companion to their commercial offering, Artix, which replaced their original XMLBus, a toolkit specifically for web services. It is a work in progress, requiring Java 5, Apache Ant and the latest available release of JAX-WS. It is therefore one of the most standards-compliant toolkits, providing
implementations of SOAP 1.2 and MTOM. The developers have produced an Eclipse plugin and are collaborating with the Apache Synapse project (still in its very early stages) which aims to provide a framework for web services.
• The Apache Beehive Project, contributed by BEA, which
uses the metadata facilities offered by Java 5 to construct web services and offers a simpler approach to enterprise applications. It uses metadata to turn any Java class into a web service, but does not yet implement JAX-WS.
19 See http://www.oracle.com/appserver/java_edition.html [Oracle, 2005]
20 See http://celtix.objectweb.org/ [Celtix, 2005]. The CTO of Celtix is Eric Newcomer, a prolific writer on SOA and referenced elsewhere in this thesis.
• IBM is a major contributor to web-services development Although normally a commercial product, WebSphere is freely available to educational institutions.
• Systinet is also a major contributor to web-service development and its Server for Java version 6 includes an implementation of SOAP 1.2. It has also
produced a verision of Eclipse bound to this server. It does not yet implement JAX-WS.
As may be seen from the products listed above, many of the toolkits form part of a complete web-services development environment, that often comes linked to or including a server.
A general problem with toolkits is that some of them rely on versions of classes which, as versions change, may differ from those used in the web server, resulting, in Java, in an
IncompatibleClassChangeError, which was experienced when switching, in May, 2005, from Axis 1.2 RC3 to version 1.2 Final inside Tomcat. The solution was to upgrade Tomcat to the latest version. The error showed itself only when calls were made by different client programs and not when the application was actually deployed on Tomcat.
Are toolkits to be dismissed out of hand because some of them flout the standards and others (probably all of them) have versioning issues? Not necessarily. Interoperability is not the only feature that should be considered in this context. The present state of web-services technology means that it is highly desirable that, in industrial use, the time to development be not protracted while developers come up to speed with current specifications, not to mention the APIs and type systems. Standards-compliant toolkits are one way of achieving this. Although they are aware that those who believe a web service should be created from code will not agree with them, the authors of the Overview to the Cape Clear SOA Editor emphasize the need for service designers to be able to "define the service interface without reference to existing technical APIs" [Cape Clear, 2005a]. They consider the advantages of starting from a schema, over a code-first approach, to be a more strongly-typed WSDL end-product and significantly greater chances of
interoperability21. The advantages of a WSDL-first approach are discussed in more detail in section 4.3.3. Chapter 4 considers the significance of starting from a schema, which is also a natural approach when creating a REST web service, described in more detail in Chapter 5.
A balance between machine-generation of code and hand-coding is, of course, desirable, in which fine-tuning may be enabled without too steep a learning curve. Shah and Apte suggest a workable compromise:
Auto-generating a key artifact such as the interface should not be an option for systems in production because this technique forces the enterprise to depend on the convenience tools for service interfaces. On the contrary, a process must be put in place by the enterprise to manage interface definitions and their future enhancements. The auto-generated WSDL merely serves as a starting point to build the WSDL manually for production-ready services [Shah and Apte, 2004a].
3.5 Summary
Consideration of the preceding issues reveals that interoperability is not lightly achieved, and that there is a significant distinction between the ability to communicate and the meaningfulness of the communication. Meaning depends greatly on context. Shirky contended in 2001 that most of the web services available then already had a shared context and that the instances of web services given as examples in the specifications either depended upon a context that was already widely known or were too trivial to require one. He gave a whimsical but telling depiction of this problem with the following account:
Two old men were walking down the street one day, when the first remarked to the second, "Windy, ain't it?"
"No," the second man replied, "It's Thursday."
"Come to think of it," the first man replied, "I am too. Let's get a coke" [Shirky, 2001].
21 Formerly known as the WSDL Editor and built for the Java platform, the renamed SOA Editor offers no support yet for WSDL 2.0