What Color Is Your Parachute? 2017: A Practical Manual for Job-Hunters and Career-Changers

Web Services Applied in Dissect Apache SOAP

Anybody who has an eye opening on the technology world should have heard enough about Web Service. It is a big game now. The server side is becoming a technology-congested area, which is crowded with Web Servers, Application Servers, Transaction Servers, Message Servers, Directory Servers, and Security Servers and so on. Not mention those traditional players that eager to set feet to the server frontier, such as Database Servers, ERP, CRM or PDM systems. In the battleground, the infrastructure technologies or platform technologies are beating up each other too. The fighters in the ring could be found as Java/EJB, CORBA, DCOM and the Microsoft .NET. So, what is Web Service doing with all of these?

Web Service is a peacemaker.

Web Service connects the extensively wired but technologically segmented world regardless the technical religion, technology cult or commercial power. It offers the first but slightly tangible hope that mentioned in the beetle song, Imagine, “imagine there will be no religion, imagine there will be no nations… imagine the world is ONE…”

A New Game

Comparing to the technologies that Web Service serves, the web service itself is much less complex. Web Service is more like a simple agreement on paper than a scientific based technology. We will skip the history part of Web Service, which could be found at first couple of paragraphs in any article about Web Service. To start from the basic, all of the Web Service is defined as a XML Document Type Definition (DTD) file. It defines the messaging protocol in XML format that enabling remote procedure call (RPC).

The buzzword RPC has been around for many years. Under the RPC cloud, blowing with the distributed computing wind, there are several technologies hovering for attention. They are:

OSF DCE – Seems nobody mentions it anymore.

CORBA – It’s been around but could never become a reality. It is just too elite to survive.

DCOM – Microsoft always wants to eat a piece of everyone’s lunch. It will be always in sight.

IIOP/RMI – Here comes Java. Don’t know about Sun, seems people start passing it. It becomes a deep infrastructure technology.

EJB – Can’t call it an infant anymore. May be this is the one finally everyone loves.

Finally, the Web Service - Is it a competitor, or new and different? At the surface, it seemed just another competitor to join the game. But if you look further, you can see the role Web Service plays is different. It opens a door toward a room that nobody is there. It’s a new thing by itself. That is because:

  • It uses XML, which is a thing that nobody has problem with.
  • It brings no new technology. It could be on top of everything. To be more generic and plausible, HTTP is the de facto Web Service message carrier, which is owned by nobody and belonging to everyone.
  • Start from the very beginning, there is no slit of intention from Web Service to compete or replace any establishing technology.
  • It just wants to have a simple and less expansive way to allow everyone talk to each other.

Architecture

Now, let’s take look what the world would be with the Web Service in it.

Four static elements compose the Web Services:

XML

There is XML, then Web Service. All Web Service definition and message are in XML.

Universal Description, Discovery and Integration (UDDI)

UDDI provides the protocol to register and find a Web Service in a public UDDI directory. At the time Business-to-Business application integration is still in the early stage, UDDI is far from reality. A directory such as a LDAP based service is more tangible for sharing Web Service.

Web Service Definition Language (WSDL)

WSDL is again a XML DTD that defines standard way of describe a Web Service. It certainly could document a Web Service in any format such Word document or an Excel file. Then the developer should have no problem start develop an application to access the Web Service based on the documents. However, documenting a Web Service in WSDL provides a big room for future automatic client site Web Service stub generation or using GUI application to configure/plug-in Web Service.

Simple Object Access Protocol (SOAP)

Until now, SOAP = Web Service. SOAP is a XML DTD that defines how message will be sent cross the wire. As long as you sent a service request in SOAP, it does not matter how the Web Service is constructed. It will serve you.

Put them all Together

As a developer, you are not expected to implement the SOAP from scratch. Two pieces of the puzzle will finish the whole picture: SOAP API and Server Side SOAP Module.

SOAP API

For Web Service client developer, you don’t have to know XML and the detail of the SOAP DTD. The SOAP API provides you functions that can be easily used to call a remote Web Service.

For the service side of Web Service, the SOAP API allows the developer expose the service to public without deal with the details of SOAP.

Server Side SOAP Module

SOAP module is becoming a must-have component of the modern application servers. It listens to the SOAP request, parses it, passes it over the request services and returns the results back to clients.

The benefits and impacts the Web Service brings to the IT world are enormous. It certainly adds an ingredient to the complexity of the enterprise computing architecture. But the techniques of constructing a Web Service and accessing a Web Service are easy and simple. We will look at how the major application server players handling SOAP. Let’s start from the free world, Apache.

The Apache SOAP Project

Before developing a J2EE based application system, a developer should always stop by the Apache Open Source Foundation’s web site. Despite the religion aspect of Open Source movement, it does provide high performance and reliable software system and application development tools.

Apache SOAP is just such an open-source implementation of the SOAP v1.1 and SOAP Messages with Attachments specifications in Java. It is the most simple and powerful SOAP API on the market. To Web Service application developers that don’t want themselves to be nailed to a specific application server platform, Apache SOAP API is a safe choice.

Apache SOAP has all the necessary bolt and nuts to construct either client application accessing a SOAP Web Service or to enable a server side function to be a Web Service.

Apache SOAP Client for RPC Service

In the distributed computing arena, RPC is the most serious word and is everything behind the concept ‘distributed”. At programming level, RPC is just way of calling a procedure, which happens to exist remotely. For Apache SOAP, since the SOAP message is as de facto carried through HTTP, a stateless TCP/IP based protocol, the PRC here is really a reminder of requesting a Web Service in a synchronized fashion. It means that a SOAP RPC client program is waiting and expecting the return result immediately for every request sent to a Web Service.

Writing an Apache SOAP RPC client is a very simple task, provides all the information regarding the Web Service are available, such as the URI of the Web Service, method name to call and parameters for the remote method.

The steps and Apache API involved are showing in the sequence diagram early in this section.

Apache SOAP Client for Messaging Service

Message oriented computing has been around for a while. Message server such IBM MQ Series and the new message queue servers based on Java Message Service Framework from Sun are becoming one type of backbone services in enterprise computing environment. Web Service defiantly should be able to expose the messaging service to remote client via SOAP.

To have access to messaging service, a developer could use Apache SOAP API with more detail granularity. There is a set of lower level classes are provided with Apache SOAP to construct a message sent to server.

Apache SOAP RPC Server

The beauty of Web Service is its simplicity. Apache SOAP brings most of the beauty out of Web Service. There is no programming needed for exposing application functions as a Web Service. It is just the matter of configuration.

Once finished installation of Apache SOAP for application server such as Apache Tomcat, a SOAP Servlet is plugged into the application server, which will filter and parse SOAP message from outside world. To enable a application to be a Web Service, the developer just need create a SOAP deployment descriptor file, which is a XML file just like the standard Servlet deployment descriptor file, web.xml. Once the descriptor file is deployed, the job is done. Currently Apache SOAP support three types of exposition for Java Application (classes), EJB, and server side BSF Script.

The last two steps, Create WSDL file and Register to UDDI Service, are really options.

Apache SOAP Messaging Server

Developing a SOAP messaging server with Apache SOAP is a bit involved comparing to expose a RPC based Web Service. The application function can only be exposed as Web Service by implement Apache SOAP API with predefined function signature. The Web Service should take the responsibilities to parse the SOAP request and return information. After done development, the deployment is no difference from the RPC server. A deployment descriptor file should be created and deployed to Apache SOAP application server module.

The Road Ahead

Since the emerging of Internet, seems everyone has been forced to be in caching-up mode. Web based application architecture is quickly evolved from CGI, Server Side process caching, Server Side Scripting, ASP/DCOM to Application Server, JSP, Servlet and EJB. Building enterprise web application framework architecture is just like buying a computer, once you paid the bill and bring it home, there are immediately better ones loaded on the shelf.

Now again, Web Service promises everything. We all hope Web Service could finally close application integration loop and offer us a stable and long live architecture. However, I doubt the technology will stop just here, there will be always better way to do the job. Therefore, the best you can do is to keep your eyes wide open.

First published: 15 May 2006