Introduction to SOA and Web services

What is SOA?

One possible way of defining SOA is as an architectural framework whose goal is to achieve loose coupling among interacting agents. A service is some work done by a service provider to achieve desired end results for a consumer. This sounds a bit too abstract, but SOA is actually everywhere. Let us look at an example that we encounter in our daily life. Let the service being offered by the service provider be: Satiation of hunger by providing Dosas. Now, the service provider can be your favorite Udupi Hotel, which will give you a Dosa with coconut chutney and sambar and charge 30 rupees for that. Or the service provider can be the swank multi-star hotel that will give you three types of chutneys, two types of sambar and great-personalized service. The Dosa specifications will be more or less the same, only the accompaniments and values of input and output parameters change. 

The basic building block of SOA is the service. A service is a self-contained software module that performs a predetermined task – "verify a customer's credit history," for example. Services are software components that do not require developers to use a specific underlying technology (you don’t care how the Dosa is made as long as its specs are met). As Java developers, we tend to focus on reusing code; thus, we tend to tightly integrate the logic of objects or components within an application. However, SOA promotes application assembly because services can be reused by numerous consumers. For example, in order to create a service that charges a consumer's credit card, we build and deploy only one instance of such a service; then we can consume this service from any number of applications.

Some of the core guiding principles of SOA components are:
· Should be driven by requirements;
· Should be simple to use;
· Should be standards-based and pattern-driven;
· Should be practical;
· Should not become outdated quickly; and
· Should buy/reuse anything existing instead of building it again.

The other key advantage of SOA is that it lets you automate business-process management. Business processes may consume and orchestrate these services to achieve the desired functionality. Thus, new business processes can be constructed by using existing services. For instance, a customer order that has been submitted to shipping can be represented by a business process that can asynchronously interact with the requisite services.

Why SOA?
The first question I have for you is why SOA? How did you hear about it? Why did you pick it? Did you choose it because it sounded cool or techie? Did you feel that it could solve a problem for you? How did you learn about SOA?
Companies inclined to learn about SOA from an EDI/EAI company, tend to focus on data integration projects that connect all of their systems to a new "Enterprise Service Bus (ESB)" (whatever that is ;) ). Companies that learn about SOA from reporting software type companies tend to focus on dashboards and scorecards as their first endeavor into SOA. The amazing thing is that all of those ARE SOA projects, at least in principle! So depending on how your company learned about SOA is probably what they will expect as a first project. The underlying principle in both these examples is the fact that data and processes need adapters so that they can be reused in environments, which were not the original choice of the creators.

Web services
Web services are the SOA enablers of choice. A web service is a software system designed to support interoperable machine-to-machine interaction over a network. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g. between Java and Python or Windows and Linux applications) is due to the use of open standards. OASIS and W3C are the primary committees responsible for the architecture and standardization of web services. Web services have an interface that is described in a machine-processable format like WSDL.

What is WSDL?
The Web Services Description Language (WSDL) is an XML format published for describing Web services. It is commonly abbreviated as WSDL in technical literature and often pronounced "Whiz-Dull". WSDL describes the public interface to the web service. This is an XML-based service description on how to communicate using the web service; namely the protocol bindings and message formats required to interact with web services listed in its directory. The supported operations and messages are described abstractly and then bound to a concrete network protocol and message format.

WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client (program) connecting to a web service can read WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in WSDL.

What is UDDI?
UDDI is the acronym for Universal Description, Discovery and Integration – a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative (sponsored by OASIS) enabling businesses to discover each other and define how they interact over the Internet. A UDDI business registration consists of three components:
· White Pages - address, contact and known identifiers;
· Yellow Pages - industrial categorizations based on standard taxonomies; and
· Green Pages - technical information about services exposed by the business.

UDDI is nominally one of the core Web Services standards. It is designed to be interrogated by SOAP messages and provide access to WSDL documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.
Web services in Axis Ok, enough of this theoretical talk. Let us get down to some coding. In the previous article in this series we had talked about Axis web services. Now, we will write a web service in Axis, publish it and then consume it through a client.

Let us first write a simple java class that implements two methods – add and subtract (Figure 1).



Then we use an Axis deployment descriptor to deploy this service inside Axis. A deployment descriptor contains a bunch of things you want to "deploy" into Axis – i.e. make available to the Axis engine. The most common thing to deploy is a Web Service; so let's start by taking a look at a deployment descriptor for a basic service (Figure 2).



Pretty simple, really! The outermost element tells the engine that this is a WSDD deployment, and defines the "java" namespace. Then the service element actually defines the service for us. A service is a targeted chain (see previous article in this series), which means it may have any/all of: a request flow, a pivot Handler (which for a service is called a "provider") and a response flow. In this case, our provider is "java:RPC", which is built into Axis and indicates a Java RPC service.
We need to tell the RPCProvider that it should instantiate and call the correct class (e.g. Calculator); we do so by including <parameter> tags, giving the service one parameter to configure the class name and another to tell the engine that any public method on that class may be called via SOAP (that's what the "*" means; we could also have restricted the SOAP-accessible methods by using a space or comma separated list of available method names).

Once we have this file, we need to send it to an Axis server in order to actually deploy the described service. We do this with the AdminClient, or the "org.apache.axis.client.AdminClient" class. If you have deployed Axis on a server other than Tomcat, you may need to use the -p <port> argument. The default port is 8080. A typical invocation of the AdminClient looks like in figure 3.

Download the tool Webservice Studio (http://www.gotdotnet.com/team/tools/web_svc/default.aspx). This excellent tool can be used to dynamically invoke web services. Inspect the WSDL of our deployed web service situated at http://localhost:8080/axis/services/Calculator?wsdl. Import this WSDL into the tool and invoke the service by giving two integers to add. Then inspect the request and response messages. These messages can also be viewed through the TCPMon tool, which comes packaged with Axis.

We have achieved some progress today and even implemented a web service in Axis. In the next article of this series, we will look at the different types of web services.

The author is available at: subramnian.sundar@gmail.com.