Axis2, the next generation of the Apache Web Service stack, has taken one more step closer to the first production version by releasing another developer version. In this chapter, we will learn more about Web Services, their history, and the standards as well as the components of Web Services. At the end of the chapter, we will discuss the need for a new Web Service engine, and finally how to install and run Axis2.
The era of isolated computers is over; now, "connected we stand, isolated we fall" is becoming the motto of computing. Networking and communication facilities have connected the world in a way they have never done before. The world involves hardware that can support the systems that connect thousands of computers, and those systems have the capacity to wield power that was once only dreamed of.
But, computer science still lacked the technologies and abstraction in order to utilize the established communication networks. The goal of distributed computing is to provide such abstractions. RPC, RMI, IIOP, and CORBA are few proposals that provide abstractions over the network for the developers to build upon.
These proposals fail to consider the critical nature of the problem. The systems are a composition of numerous heterogeneous sub-systems. The above proposals require all the participants to share a particular programming language, or a few of those languages. Web Services provide an answer by defining a common XML-based wire representation for the interactions, thus enabling the different systems to interact.
Web Services define SOAP, the message format. They also define WSDL, which is a common way to describe Web Services. Different programming languages may define different implementations for Web Services, yet they interoperate because they all agree on the format of the information they share.
The Internet is revolutionizing business by providing an affordable and efficient way to link companies with their partners as well as to their customers. However, there are certain issues that reduce the effectiveness of the Internet. Among those issues, incompatible applications and frameworks that cannot interoperate or that cannot exchange business data have become a major concern. The Web Service is a new e-business model that is expected to change in a way in which the business applications are developed, integrated, and interoperated. Web Services are self-describing and self-contained. A Web Service is a modular application that is accessible over the web. It is exposed as an XML interface, and it communicates with other services by using XML messages over standard Web protocols.
W3C, one of the standard bodies of Web Services defines a Web Service as a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable and human readable format called WSDL (Web Services Description Language). Other applications communicate with the Web Service in a manner prescribed by its description using SOAP (Simple Object Access Protocol) messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards.
Increase competition among vendors, resulting in lower product costs.
Ease transition from one product to another, resulting in lower training costs.
Increase the ability for parties to interoperate, resulting in lower maintenance costs.
Ensure a greater degree of adoption and longevity for a standard. A large degree of usage from the vendors and the users leads to a higher degree of acceptance.
One can argue that the Web Service concept is a logical evolution from an object-oriented system to a system of services. As in an object-oriented system, some of the fundamental concepts in Web Services are encapsulation, message passing, and dynamic binding. However, the service-based concept is extended beyond method signatures. The information as to what the service does, where is it located, how it is invoked, the quality of service, and the security policy related to the service can be published in the service interface (WSDL).
There are three main ways in which an organization can move into Web Services. These are as follows:
Creating a new Web Service from scratch. The developer creates the functionalities of the services as well as preparing a document to describe those services.
Exposing an existing functionality through a Web Service. Here, the functionalities of the service already exist. Only the service description needs to be implemented.
Integrating Web Services from other vendors or business partners. There are instances where using a service implemented by another is more feasible than building from scratch. On these occasions, the organization will be required to integrate others' or even business partners' Web Services.
Web Services describe a new model for using the Web. This model allows publication of business functions to the Web and provides universal access to those business functions. Both developers and end users benefit from Web Services. The Web Service model simplifies business application development and interoperation. In addition to that, Web Services serve the users' needs by enabling them to choose, configure, and assemble their own Web Services through an intuitive, browser-based interface.
The fundamental concept behind Web Services is the SOA (Service-Oriented Architecture), where an application is no longer a large monolithic program, but is divided into smaller, loosely coupled programs, and provided services are loosely coupled together with standardized and well-defined interfaces. These loosely coupled programs make the architecture very extensible, as it acquires the ability to add or remove services with limited costs. Therefore, new services can be created by combining existing services.
The Web Services Model consists of basic functionalities such as describe, publish, discover, bind, invoke, update, and unpublish. In the meantime, the model consists of three actors: service provider, service broker, and service requester. The functionalities as well as actors are shown in the figure below:
The Service Provider is an individual (organization) that provides services. The Service Provider's job is to create, publish, maintain, and unpublish their services. From a business point of view, the Service Provider is the owner of the service, whereas from an architectural view, it is a platform that holds the implementation of the service.
The Service Broker provides a repository of service descriptions (WSDL). These descriptions are published by the service provider. Service Requesters will search the repository to identify the needed services, and obtain the binding information for these services. A service broker can either be public, where the services are universally accessible, or private, where only specified sets of Service Requesters are able to access the service.
The Service Requester is a party that looks for a service to fulfill its requirements. A requester can either be a human accessing the service, or an application program (The program could also be another service). From a business view, it is a business that wants to consume a particular service. From an architectural view, it is an application that looks for and invokes a service.
Web Services are one of the key technologies in today's software industry. As a result, we are in a rapid development process and the stack of interrelated standards that characterize the Web Services infrastructure is maturing. The growing collection of WS-* standards, supervised by the Web Services governing bodies defines the Web Service protocol stack, as shown in the figure below. Here, we will be looking at the standards that are specified in the most basic layers: messaging and description and discovery.
The messaging standards are intended to give a framework in order to exchange information in a distributed environment. These standards have to be reliable so that the messages are sent only once, and only the intended receiver receives them. This is one of the primary areas wherein a lot of research work is being done, because everything depends on the messaging ability.
The XML-RPC standard was created by Dave Winer in 1998 with Microsoft. The available RPC systems seemed very bulky. Therefore, in order to create a light-weight system, the developer simplified them by specifying only the essentials, and defining only a handful of data types and commands. This protocol uses XML to encode its calls to HTTP as a transport mechanism. The message is sent as a POST request, where the body of the request is in XML. A procedure is executed on the server and the returned value is formatted into XML. The parameters can be scalars, numbers, strings, or dates, as well as complex record and list structures.
As new functionalities were introduced, XML-RPC evolved into SOAP. Still, some people prefer using XML-RPC because of its simplicity, minimalism, and ease of use.
The SOAP standard was originally designed by four developers with the backing of Microsoft as an object-access protocol. The protocol specifies the exchange of XML-based messages over computer networks in a transport-independent manner. The developers had chosen XML as the standard message format because of its widespread use by major organizations and open-source initiatives. Also, there is a wide variety of freely available tools that ease transition to a SOAP-based implementation.
The concept of SOAP is a stateless, one-way message exchange paradigm. However applications can create more complex interaction patterns, such as request-response, request-multiple responses, and so on. This is done by combining such one-way exchanges with features provided by an underlying protocol and application-specific information. In addition, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner.
It would have been quite useful, if there had been a standard way to express where a message should be delivered in a Web Services network. This could reduce the work load of the developers so they were able to simplify Web Services communication and development, and thus avoid the need to develop costly, ad hoc solutions that are often difficult to interoperate across platforms. WS-Addressing addresses this and enables organizations to build reliable and interoperable Web Service applications by defining a standard mechanism for identifying and exchanging Web Service messages between multiple end points.
Web Services Addressing provides transport-independent mechanisms to address messages and identify Web Services, corresponding to the concepts of address and message correlation described in the Web Services architecture. Web Services Addressing defines XML elements to identify Web Services endpoints, and to secure end-to-end identification of endpoints in messages. This enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
It is important to note that the description of a Web Service is essential for classifying, discovering, and using the service. The description should be understandable for humans as well as applications. A Web Service description is required at the semantic level as well as at the syntactic level. The semantic information has to contain details about the service provider as to what the service does and its characteristics such as reliability, security, and sequencing of messages. The semantic information enables the service requesters to decide whether a service satisfies their needs, or not. Also, brokers can use the semantic information to categorize the service. Syntactic information describes how to use the service, and may also be concerned about the non-functional requirements such as security, as well as authentication.
WSDL, developed by IBM, Ariba, and Microsoft, is an XML-based language that provides a model for describing Web Services. The standard defines services as network endpoints or ports. WSDL is normally used in combination with SOAP and XML schema in order to provide Web Services over networks. A service requester that connects to a Web Service can read the WSDL to determine the functions that are available in the Web Service. Special data types are embedded in the WSDL file in the form of an XML Schema. The client can then use SOAP to call functions listed in the WSDL.
WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as how and where that functionality is offered. WSDL specification defines a language for describing the abstract functionality of a service as well as a framework for describing the concrete details of a service description. The abstract definition of ports and messages is separated from their concrete use, allowing the reuse of the interface. A port is defined by associating a network address with a reusable binding. A collection of ports defines a service. Messages are abstract descriptions of the data being exchanged and port types are abstract collections of supported operations. The concrete protocol and the data format specifications for a particular port type together constitute a reusable binding, where the messages and operations are then bound to a concrete network protocol and message format to define an endpoint.
As shown in the figure below, Web Services consist of a number of activities. These activities can be divided into two layers: a basic layer and a value-added layer. The basic layer consists of the main activities that have to be supported by any Web Service. The value-added layer adds value, and thus enhances the performance of the Web Service.
The first activity is the creation of the Web Service. This can be achieved either by building from scratch, or by integrating existing Web Services. After creating the Web Service, it has to be described so that others can access it. Then, it has to be published on the Web. The discovery of a Web Service can be facilitated by a service broker who will support requirement analysis and description of a requester's need, and then matching the users' needs to available Web Services, negotiation, and binding. After the Web Service has been discovered, and it has been decided to use the Web Service, a number of activities related to contracting takes place. During the life time of a Web Service, it will be updated and maintained throughout by the service provider. If the Web Service description is changed, then it will be updated at the service broker's end. Finally, the service can remain unpublished, if it is no longer available or needed.
Apart from these basic activities, some value-added activities need to take place for a Web Service to function effectively. Activities such as monitoring, billing, reliability, and security have to be implemented.
These Web Service activities can take place only at one site; that is, while some of these activities will take place at the service provider's site, some will take place at the service broker's site, and the rest will be at the service requestor's site. This does not mean that a particular site can only play one role; it can play multiple roles.
The history of Web Services has gone through several iterations during its evolution. The first generation of Web Services were highly controlled interactions, and can be considered mere tests of feasibility. Apache SOAP was one of the notable SOAP engines in the first generation. It was meant mainly to be a "proof of concept", and not at all concerned about performance. The whole idea of the first generation SOAP engines was to convince the world that Web Services are a feasible option.
Soon, the interest in these first generation SOAP engines paid off. More companies started showing interest and the SOA started building up. This stage can be called the second generation of Web Services, and it required better and faster SOAP engines. Aspects such as discovery and definition are already standardized, and SOAP engines are also required to support these standards. Apache Axis was born as one of the second generation SOAP engines.
Now, the second generation of Web Services is also coming to an end. Web Services are becoming highly demanding, and a large number of players have entered into the Web Service arena. Aspects governing different facets of Web Service interactions have been standardized. The third generation of Web Services requires faster and more robust SOAP engines, as the existing Axis is not good enough. Axis2 was made to fill this gap.
As we have discussed earlier, Web Services are growing rapidly and a large number of organizations have moved to the Web Services field. As a result , new requirements have been encountered, and new standards are being defined. At the same time, the organizations are not just looking for Web Services. They also pay attention to the reliability, security, and performance of Web Services. In addition to these requirements, new WS* specifications have been defined, and Web Service engine need to support them.
While considering the Apache Web Service stack, Axis1 is one of the stable Web Service engines. A number of organizations as well as a number of applications use Axis1. So, changing Axis1 architecture to support the new requirements as well as new Web Service standards was not a good idea. In the meantime, software has its own life cycle. It can evolve up to a certain point and after that, a revolution is needed. The same theory was applicable to Axis1 as well. Rather than change the Axis1 architecture, the Apache Web Service development team came up with a new architecture.
In addition to the new requirements and the WS* specifications, performance was another area of major concern. Changing the Axis1 architecture in order to improve its performance was not that easy. Axis1 uses DOM as its XML representation mechanism. As a result, complete messages need to be loaded into the memory before the processing starts. The system slows down and the memory usage also increases. Therefore, one of the key requirements behind the introduction of Axis2 was to improve system performance.
The Apache Web Service community discussed and agreed to introduce a new Web Service engine called "Axis2" with a number of new requirements. It requires a very flexible and an easily extensible architecture that supports WS* standard as well as future standards. As a result, Axis2 or The Apache third-generation Web Service engine came into picture.
Apache Axis2 had a number of releases. Among them, release 1.3 can be considered one of the most robust releases. This book is also based on that particular release. As a result of Axis2 using an incremental development process, there might be compatible issues from one release to another, since there are instances where Axis2 changes its API in order to increase its flexibility as well as usability.
One of the points in an open-source project is that its release consists of source code, which is used to create the binary files by compilation and linking. Each Axis2 release also consists of a source code distribution in addition to its binary distribution.
We can download the latest Axis2 release from http://ws.apache.org/axis2/download.cgi. Each Axis2 release consists of four main release artifacts or distributions:
An Axis2 binary distribution consists of all the relevant third-party libraries, a set of samples, and the Axis2 runtime. Installing a binary distribution involves extracting ZIP archive files into a desired location. Once we download and extract the binary distribution, then we will be able to see a set of subdirectories inside it (
We can use the Axis2 binary distribution to develop and deploy our enterprise-level applications. The distribution consists of all the resources that are required to develop Web Service application with Axis2. Once we develop our Web Service application, we can deploy that in the same distribution. We can use the binary distribution to start a standalone server, or to create a WAR file to deploy in the application server.
Starting Axis2 as a standalone server is just a matter of running either a
bat or a
script file in the
bin directory. Once we run
.bat) and type
localhost:8080/axis2, then we can see a list of available services in the system, which indicates whether the server is up and running.
The Axis2 WAR distribution is useful for deploying Axis2 in application servers such as Tomcat, Jboss, Weblogic, and so on. We can deploy the Axis2 WAR file into an application server, and check whether it works by typing the server address in a browser. As an example, if you deploy the Axis2 WAR file in Apache Tomcat, by typing
http://localhost:8080/axis2, we can figure out whether Axis2 is up and running. However, the Axis2 WAR distribution does not have any Web Services other than the version service. So, by the deploying default WAR file in an enterprise-level application, we will not gain anything.
To add a new Web Service in Axis2, we need to add the corresponding resources into a WAR file. But most of the application servers do not unpack the WAR file. Therefore, when we use a WAR file in a real application, we have to unpack the WAR file, put our resource into it and then deploy it. However, if the application server unpacks the WAR file, then we can drop our new Web Service into the unpack location. We will be learning about Axis2 Web Services in detail, later in this book.
Step 1: Install the application server. If we do not have any application server in our machine, then we need to download and install an application server. Among the available application servers, Apache Tomcat can be considered one of the best application servers. We can download Tomcat (4.x or above) and install it.
Step 2: Depending on an application server, we can find the location where we need to deploy WAR files. If we take Tomcat as an example, then we need to put the WAR file into the
webapps directory. So let's drop the Axis2 WAR distribution into the
webapps directory of the application server.
Step 3: As a final step, open the browser and type
localhost:8080/axis2. Thus, we will be able to view the Axis2 web application homepage (here, the URL might be different depending on the application server).
As the name implies, the source distribution consists of the source code that is used to build the binary distribution. Since Apache Axis2 is released under the Apache license, we are free to use the source code. We can also use the Axis2 source distribution in order to hack Axis2. In addition to that, we can help fix issues in the project and can contribute to the open-source community.
When we develop real-world applications, it is always useful to have the source code in addition to the documentation as that helps to debug an application as well. In the meantime, the source distribution consists of Maven scripts (http://maven.apache.org) and we can use them to create either a binary distribution, WAR distribution, or a JAR distribution.
When we want to develop a Web Service application, then we need to have an Axis2 library. The Axis2 JAR Distribution is the Axis2 library. To develop a Web Service application on Axis2, we need to have Axis2 libraries, meaning Axis2 JAR files. In the meantime, there are a number of projects that depends on Axis2, and they need to have the Axis2 library distribution.
Is the Web Services concept a new revolutionary technology? The idea of splitting large programs into smaller modules is an established principle of higher-level programming languages. Even in assembly programming, procedures were separated from other program parts for better re-usability. Languages such as CORBA can be used to connect programs over a network with a language-independent remote procedure call protocol that already exists with CORBA. CORBA also has an Interface Definition Language (IDL) similar to WSDL. As a fact, the popularity of Web Services is achieved by the standardization of techniques, and by standards that are adaptable to different situations. There a number of solutions exist to realize these concepts of Web Services.