Introducing Web services and SOAP
While the Internet wave has brought about a revolution in IT and business alike, it could be argued that new enterprise needs are now strongly influencing the evolution of the technologies that shape the Internet itself.
Over the past few years, we have witnessed the transition from the basic serving of static documents using HTTP and HTML, to ever-increasing levels of interactivity and integration, and to the concept of Web applications. The advent of new technologies and products -- most notably, application servers -- has made it possible to create a new generation of distributed, multi-tiered Web applications that feature a high level of interactivity, are able to deliver tailored, dynamic content, and permit access to back-end enterprise systems over the Internet.
More recently, technologies such as XML have been playing a key role in facilitating the exchange of information between heterogeneous systems, such as content syndication between business partners. As for integration with back-end systems, so far this has been typically achieved by means of asynchronous communication using message-oriented middleware (MOM) products, and technologies such as JMS (Java Message Service).
Today, the demand for tighter, seamless integration and interoperability between heterogeneous business systems (such as those of a buyer and a supplier), and the need for synchronous communication, is driving the development of the Web towards a service-oriented model where individual processes within disparate, remote systems can communicate with each other in a transparent and synchronous fashion. In this model, a system can expose individual application functions, or services, that can be called by other services from different systems, much in the same way as programmers make function calls within a program. In effect, this constitutes an implementation of remote procedure calls at Web level, and allows for complex, distributed applications to be assembled from disparate components on the Internet.
In order to achieve this new programming model and tie these services together so they can be coordinated, a common interconnection protocol must be defined. Though a number of distributed component technologies such as CORBA already exist, most of them are not ideally suited to the task of implementing Web Services, as they rely on complex and symmetrical object models, meaning that applications that wish to communicate with each other must use similar, heavy-weight protocols and object models at both ends. An additional issue is the fact that nowadays, most protocols apart from HTTP tend to be blocked by firewalls, so as to alleviate potential security attacks.
Departing from complex object models and protocols, the Simple Object Access Protocol (SOAP) was developed by Microsoft, DevelopMentor, and Userland Software. The rationale for developing this new protocol was to circumvent the aforementioned issues by using the Web's 'lowest common denominator' protocol, that is, HTTP, as the underlying transport layer. In addition, SOAP relies on custom HTTP headers and uses another widely-accepted standard -- XML -- to embed the inter-application protocol messages and data into the HTTP stream.
SOAP therefore aims to provide an elegant, light-weight, and universal alternative to inter-application communication that smoothly and seamlessly facilitates the implementation of Web services.
SOAP 1.0 was submitted to the IETF and adopted as a draft recommendation, and the base specification was completed in 1998. The number of vendors supporting SOAP is on a steady increase, with big names such as IBM, Lotus, Intel, and Compaq. The 1.1 specification was submitted to the W3C in May last year, though it has not been adopted yet as a W3C recommendation.
One of the main design goals of SOAP is simplicity, and although the specification defines a standard but extensible communication protocol and payload (data) format, it avoids any higher-level and more involved aspects of a distributed object system. Simplicity has its downside however, and organizations such as the W3C have objected in particular that SOAP did not address security considerations and that the scheme for object marshaling was not explicit enough. On the downside too, one must keep in mind that a communication channel as unreliable as HTTP does not lend itself well to guaranteed reliability of synchronous, RPC-like communication.
Integration with SOAP
Although iPlanet Application Server does not ship with any built-in SOAP implementation, complete instructions are provided for integrating Apache SOAP with the application server. Apache SOAP is an open-source SOAP implementation in Java based on SOAP4J, a framework initially developed by IBM and later donated to the Apache Software Foundation. Thanks to the continued involvement and contribution of the Apache community, the project has evolved into one of the mainstream SOAP implementations. Despite restrictions as regards support for some SOAP 1.1 protocol features, Apache SOAP currently provides the best solution available for the J2EE platform.
In order to add SOAP support to iPlanet Application Server, a number of libraries must be downloaded and installed, and a few changes to the server configuration must be made. Fortunately, the instructions provided by iPlanet are clear enough to ensure that this operation can be smoothly performed. Basically, the whole process translates into the series of steps summarized below:-
- Download the Apache SOAP 2.0 binary distribution file from the Apache XML Web site, along with the Xerces XML parser and Xalan XSLT processor. To alleviate potential trouble with different releases of these frameworks, iPlanet recommend downloading the specific versions of Xerces and Xalan that they have tested, though newer releases should not pose any problems in theory. Additionally, if planning to make use of server-side scripting languages for implementing Web services, then the Bean Scripting Framework libraries are also required (one of the sample applications bundled with Apache SOAP requires these libraries).
- Extract and copy selected Java libraries from the downloaded archive files to a specific location within the iPlanet Application Server installation directory.
- Use the iPlanet Registry Editor to make necessary changes to the server's CLASSPATH, and restart the application server so the changes can be effected.
- The final step is to deploy the SOAP-Admin Web application included with Apache SOAP, a task that is greatly facilitated by the user-friendly iPlanet Deployment Tool.
The SOAP-Admin application serves as the main facility for listing, adding, and removing registered Web services on the server. It also includes an option to check that installation was successful by verifying the correct operation of the SOAP RPC router.
Next, iPlanet provides instructions for exercising SOAP functionality with sample applications. As part of the Apache SOAP distribution, three samples are provided:
- AddressBook, a simple service that allows the user to query and populate an address book stored on the server.
- StockQuote, a service that allows clients to retrieve delayed stock quotes. Two clients are provided for this sample, and demonstrate the use of SOAP over SMTP as well as HTTP for transport.
In addition to these samples, iPlanet provide two custom sample applications that demonstrate how SOAP and EJB can be combined, by showing how to access EJBs from a Web Service:
- Soap-HelloWorld is a basic sample demonstrating access to a stateless session EJB from a Web Service.
- Soap-ShoppingCart is a more advanced sample that demonstrates access from a Web Service to a stateful EJB deployed as part of a Web application. In effect, it illustrates how to wrap EJB business methods into a Web Service that can then act as a 'server-side proxy' to the EJB component. Using this approach, it is possible to allow any SOAP client access to EJB functionality exposed through a service. Finally, this sample also features two client access modes: through a Web application, and through a Java command-line client. However, when it comes to deploying Web services that access components from other applications, this sample displays a rather annoying trait. Although the accessed EJB is registered in the server, the path to the EJB JAR file must still be manually added to the application server's CLASSPATH using the iPlanet Registry Editor, so that the SOAP service application can 'see' it. All samples also come with Ant-based build scripts and documentation that describes the functionality of the applications, as well as instructions for building and deploying them to iPlanet Application Server. While these instructions lack clarity in places, and a few difficulties were experienced, the documentation is being fully revised and streamlined for the upcoming SP3 release of iPlanet Application Server.
Web services authoring and development tools
On the productivity side, iPlanet does not currently provide any tools suited to the design, development, testing and deployment of Web Services. However, work is underway to provide integrated development and runtime support of Web services within iPlanet Application Server and Forte or Java. The upcoming Forte or Java, Enterprise Edition product will have built-in Web services authoring support.
On the Web services front, SOAP support is satisfactory even though it requires separate installation of Apache SOAP.
It should also be noted that, while the version currently supported is Apache SOAP 2.0, the upcoming SP3 release of iPlanet Application Server will include updated instructions for integrating with Apache SOAP 2.2. This will bring further benefits, such as improved security (with support for HTTP authentication and SSL), and support for HTTP proxies.
On the subject of productivity though, the iPlanet offering currently lags behind when it comes to providing tools suitable for creating, assembling and deploying of Web Services. Fortunately, as previously mentioned, this is likely to be remedied in the near future with the release of the new version of Forte or Java, Enterprise Edition.
In the meantime, the Ant toolset and sample build scripts provided, along with the Apache SOAP Admin console and TCP tunnel/monitor tool, address the basic requirements for developing, assembling, deploying, and debugging Web services with iPlanet Application Server.
Copyright 2002 TechMetrix Research. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.
For More Information
- For the Best Web Links for Web services, click here.
- What do you think about this article? If you'd like to send feedback, you can E-mail the Editor.
- Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
- Ask the Experts! Our Web Services, XML, .NET, Java, EAI, and App Server gurus answer your toughest questions.