Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
This FAQ deals with ways of enabling the SOA functionally in your organization. We discuss three key approaches—existing messaging system, plain old XML, and web services. We then look at the standard bodies of web service and the web service model. Finally, we discuss Apache Axis2 and how to download and use it.
|Read more about this book|
(For more resources on Apache Axis2, see here.)
Q: How did SOA change the world view?
A: 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 as never before. The world has hardware that could support the systems that connect thousands of computers, and these systems have the capacity to wield power that was once only dreamed of.
Yet, computer science lacked the technologies and abstraction to utilize the established communication networks. The goal of distributed computing is to provide such abstractions. RPC, RMI, IIOP, and CORBA are a few proposals that provide abstractions over the network for the developers to build upon.
These proposals fail to consider one critical nature of the problem. The systems are a composition of numerous heterogeneous subsystems, but these proposals require all the participants to share a programming language or a few languages. Service Oriented Architecture (SOA) provides the answer by defining a set of concepts and patterns to integrate homogenous and heterogeneous components together.
SOA provides a better way to achieve loosely coupled systems, and hence more extensibility and flexibility. In addition, similar to object-oriented programming (OOP), SOA enables a high degree of reusability. There are three main ways one can enable SOA capabilities in their systems and applications:
- Existing messaging systems: for example, JMS, IBM MQSeries, Tibco, and so on
- Plain Old XML (POX): for example, REST, XML/HTTP and so on
- Web services: for example, SOAP, WSDL, WS-*
Q: What are the shortcomings of Java Messaging Service (JMS)?
A: Among the commonly used messaging systems, Java Messaging Service (JMS) plays a major role in the industry and has become a common API for messaging systems. We can find a number of different message types of JMS, such as Text, Bytes, Name-Value pair, Stream, and Object. One of the main disadvantages of these types of messaging systems is that they do not have a single wire format (serialization format). As a result, interoperability is a big issue: if two applications are using JMS to communicate, then they must be on the same implementation. Sonic, Tibco, and IBM are the leaders in the commercial markets, and JBoss, Manta, and ActiveMQ are the commonly used open source implementations.
Q: What is POX and how does it serve the web?
A: Plain Old XML or POX is another way of exposing functionality and enabling SOA in the system. With the widespread use of the Web, the POX approach has become more popular. Most of the web applications expose the XML APIs, where we can develop components and communicate with them. Google Maps, Auto complete, and Amazon services are a few examples of applications that heavily use XML APIs to expose the functionality. In most cases, POX is used in combination with REST (Representational State Transfer). REST is a model of an underlying architecture of the Web, and it is based on the concept that every URL identifies resources. GET, PUT, POST, and DELETE are the verbs that are used in the REST architecture. REST is often associated with the theoretical standpoints, and for this reason, REST is generally not used for complex interactions.
Q: What are web services?
A: The fundamental concept behind web services is the SOA where an application is no longer a large monolithic program, but it is divided into smaller, loosely coupled programs. The provided services are loosely coupled together with standardized and well-defined interfaces. These loosely coupled programs make the architecture very extensible due to the possibility to add or remove services with limited costs. Therefore, new services can be created by combining existing services. To understand loose coupling clearly, it is better to understand the opposite, which is tight coupling, and its problems:
- Errors, delays, and downtime spread through the system
- The resilience of the whole system is based on the weakest part
- Cost of upgrading or migrating spreads
- It's hard to evaluate the useful parts from the dead weight
The benefits a web service provides are listed below:
- Increased interoperability, resulting in lower maintenance costs
- Increased reusability and composablity (for example, use publicly available services and reuse them or integrate them to provide new services)
- Increased competition among vendors, resulting in lower product costs
- Easy transition from one product to another, resulting in lower training costs
- Greater degree of adoption and longevity for a standard, a large degree of usage from vendors and users leading to a higher degree of acceptance
Q: What contributes to the popularity of web services?
A: Among the three commonly used methods to enable SOA, a web service can be considered as the most standard and flexible way. Web services extend the idea of POX and add additional standards to make the communication more organized and standardized. There are several reasons behind the web services being the most popular SOA-enabled mechanism, as stated here:
- Web services are described using WSDL, and WSDL can capture any complex application and the required quality of services.
- Web services use SOAP as the message transmission mechanism, as SOAP is a special type of XML. It gains all the extensibility features from XML.
- There are a number of standard bodies to create and enforce the standards for web services.
- There are multiple open source and commercial web service implementations. By using the standards and procedures, web services provide application and programming language-independent mechanism to integrate and communicate. 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.
Q: What are the standard bodies for web services?
A: In web services, there are three main standard bodies that helped to improve the interoperability, quality of service, and base standards:
Q: How do organizations move into web services?
A: There are three ways in which an organization could possibly use to move into the web services, listed next:
- Create a new web service from scratch. The developer creates the functionalities of the services as well as the description (i.e., WSDL).
- Expose the existing functionality through a web service. Here the functionalities of the service already exist. Only the service description needs to be implemented.
- Integrate web services from other vendors or business partners. There are occasions when using a service implemented by another is more cost effective than building from the scratch. On these occasions, the organization will need to integrate others' or even business partners' web services.
The real usage of web service concepts is for the second and third methods, which enables other web services and applications to use the existing applications.
Web services describe a new model for using the web; the 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.
Q: How does a Web services model look like?
A: Web service model consists of a set of basic functionalities such as describe, publish, discover, bind, invoke, update, and unpublish. In the meantime, the model also consists of three actors—service provider, service broker, and service requester. Both the functionalities as well as actors are shown in the next figure.
- Service provider is the individual (organization) that provides the service. The service provider's job is to create, publish, maintain, and unpublish their services. From a business point of view, a service provider is the owner of the service. From an architectural view, a service provider is the platform that holds the implementation of the service. Google API, Yahoo! Financial services, Amazon Services, and Weather services are some examples of service providers.
- 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 required service and obtain the binding information for these services. Service broker can be either public, where the services are universally accessible, or private, where only a specified set of service requesters are able to access the service.
- Service requester is the party that is looking for a service to fulfill its requirements. A requester could be a human accessing the service or an application program (a program could also be a service). From a business view, this is the business that wants to fulfill a particular service. From an architectural view, this is the application that is looking for and invoking a service.
Q: What are web services standards?
A: So far we have discussed SOA, standard bodies of web services, and the web service model. Here, we are going to discuss more about standards, which make web services more usable and flexible. In the past few years, there has been a significant growth in the usage of web services as application integration mechanism. As mentioned earlier, a web service is different from other SOA exposing mechanisms because it consists of various standards to address issues encountered in the other two mechanisms. The growing collection of WS-* (for example, Web Service security, Web Service reliable messaging, Web Service addressing, and others) standards, supervised by the web services governing bodies, define the web service protocol stack shown in the following figure. Here we will be looking at the standards that have been specified in the most basic layers: messaging and description, and discovery.
The messaging standards are intended to give the framework for exchanging information in a distributed environment. These standards have to be reliable so that the message will be sent only once and only the intended receiver will receive it. This is one of the primary areas where research is being conducted, as everything depends on the messaging ability.
Q: Describe the web services standards, XML-RPC and SOAP?
A: The web services standards; XML-RPC and SOAP are described below.
XML-RPC: The XML-RPC standard was created by Dave Winer in 1998 with Microsoft. That time the existing RPC systems were very bulky. Therefore, to create a light-weight system, the developer simplified it by specifying only the essentials and defined 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 in which the body of the request is in XML. A procedure is executed on the server and the value it returns is also formatted into XML. The parameters can be scalars, numbers, strings, dates, as well as complex record and list structures. As new functionalities were introduced, XML-RPC evolved into what is now known as SOAP, which is discussed next. Still, some people prefer using XML-RPC because of its simplicity, minimalism, and the ease of use.
SOAP: The concept of SOAP is a stateless, one-way message exchange. However, applications can create more complex interaction patterns—such as request-response, request-multiple responses, and so on—by combining such one-way exchanges with features provided by an underlying protocol and application-specific information. SOAP is silent on the semantics of any application-specific data it conveys as it is on issues such as routing of SOAP messages, reliable data transfer, firewall traversal, and so on. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible 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 the transition to a SOAP-based implementation.
Q: Define the scope of Web Services Addressing (WS-Addressing)?
A: The standard provides transport independent mechanisms to address messages and identifies web services, corresponding to the concepts of address and message correlation described in the web services architecture. The standard defines XML elements to identify web services endpoints and to secure end-to-end endpoint identification 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. Thus, WS-Addressing enables organizations to build reliable and interoperable web service applications by defining a standard mechanism for identifying and exchanging Web Services messages between multiple end points.
Q: What is Web Services Description Language (WSDL)?
A: 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 to provide web services over networks. A service requester who connects to a web service can read the WSDL to determine what functions are available in the web service. Special data types are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to call functions listed in the WSDL.
The standard enables one to separate the description of the abstract functionality offered by a service from the concrete details of a service description such as how and where that functionality is offered. This 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 these definitions.
eBook Price: $23.99
Book Price: $39.99
|Read more about this book|
(For more resources on Apache Axis2, see here.)
Q: Describe a typical Web Service framework lifecycle?
A: As shown in the following figure, web services consist of a number of activities. These activities can be divided into two layers: the basic layer, which consists of the main activities that have to be supported by any web service, and the value-added layer, which brings value and enhances the performance of the web service. A web framework lifecycle is as follows:
- Create: The first activity in the service life cycle is the creation of the web service. This can be achieved either by building from scratch or by integrating existing web services.
- Describe: After creating the web service, it has to be described so that others can access it.
- Publish: After the description, it has to be published on the Web.
- Discover: Discovering a web service can be facilitated by a service broker, which will support requirement analysis and description of requester's need, matching needs to available web services, negotiation, and binding. As an alternative to discovery, often commercial agreements are made based on a supplied WSDL. This forms part of the contract between organizations.
- Invoke: Once the service is discovered, use tools and procedures to invoke the service.
- Unpublish: Finally, the service can be unpublished if it is no longer available or needed.
After the discovery is made and it is decided to use a certain web service, a number of activities related to contracting take place. During the lifetime of a web service, it will be updated and maintained throughout by the service provider. If the web service description is changed, this will be updated at the service broker's end.
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.
Q: Can web service activities be distributed?
A: Web service activities can take place only at different sites, that is, some of these activities will take place at the service provider's site, while some will be at the service broker's site and the rest will be at the service requester's site. This does not mean that a particular site can only play one role; it can play multiple roles.
Q: What is Axis2?
A: Apache Axis2 is the most recent and the next generation web service framework from Apache. The Apache software foundation started Apache SOAP as its first web service framework. Next, they developed Apache Axis, which became one of the very successful projects at Apache and is still used heavily in the industry. Due to rapid changes in the industry and demands from the user community, Apache Axis alone was not able to fulfill those requirements, thus the Apache Web Service community initiated Apache Axis2 project in 2004. In a short period of time, Apache Axis2 has become the de facto open source Java Web Service framework, which is now heavily used in both the industry and in academia. Axis2, the next generation of the Apache Web Service stack, takes one more step closer to the first production version, by releasing another developer version.
Q: What are the salient features of Axis2?
A: Axis2 comes with many new features, enhancements, and industry specification implementations:
- Speed: Axis2 uses its own object model and StAX (Streaming API for XML) parsing to achieve significantly greater speed than earlier versions of Apache Axis.
- AXIOM: Axis2 comes with its own lightweight object model, AXIOM, for message processing, which is extensible, performs highly, and is developer-convenient.
- Hot deployment: Axis2 is equipped with the capability of deploying web services and handlers while the system is up and running. No server shutdown required.
- Asynchronous web services: Axis2 now supports asynchronous web services and asynchronous web services invocation using non-blocking clients and transports.
- MEP support: Axis2 now comes handy with the flexibility to support Message Exchange Patterns (MEPs) with in-built support for basic MEPs defined in WSDL 2.0.
- Flexibility: The Axis2 architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, and so on.
- Stability: Axis2 defines a set of published interfaces, which change relatively slowly, as compared to the rest of Axis.
- Component-oriented deployment: You can easily define reusable networks of Handlers to implement common patterns of processing for your applications or to distribute to partners.
- Transport framework: Axis2 has a clean and simple abstraction for integrating and using Transports (that is, senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, and so on), and the core of the engine is completely transport-independent.
- WSDL support: Axis2 supports the Web Service Description Language (versions 1.1 and 2.0), which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis2.
- Add-ons: Several web service specifications have been incorporated, including WSS4J for security (Apache Rampart), Sandesha for reliable messaging. Kandula is an encapsulation of WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity.
- Composition and extensibility: Modules and phases improve support for composability and extensibility. Modules support composability and can also support new WS-* specifications in a simple and clean manner. They are, however, not hot deployable, as they change the overall behavior of the system.
Q: What is the improvement in Axis2 over Axis1?
A: Axis1 uses DOM as its XML representation mechanisms. As a result of that, complete messages need to load into memory before starting to process, which slows down the system as well as increases the memory usage. Therefore, one of the key challenges was to improve the XML processing and from that improve the overall processing time and memory footprint. To provide better support and faster processing of XML, Axis2 introduced new XML processing framework known as Axiom. It uses pull parsing technology to achieve its requirements.
Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has integrated support for the widely popular REST-style of web services. The same business logic implementation can offer both a WS-* style interface as well as a REST/POX style interface simultaneously. More importantly, one can extend Axis2 to support new standard specification with zero changes to the core.
Q: What are the types of Apache Axis2 software available?
A: There are three types of software: free software, open source software, and commercial software. The main idea of free software is that you can download the software for free; however, you do not get access to the source code or the development work. On the other hand, open source software is designed and developed by an open community; anyone can participate in the discussions and contribute to the project, and finally, once the product is released, the user can have access to both the product and the source code. The user can modify the source code, fix issues, redistribute, and so on. As Axis2 is also an open source project, you can download Axis2 and get access to both binary and source codes. However, in the proprietary software, the license agreement is very restricted, and usually the user does not get to see the source code; the user only gets the binary.
Q: Where can I download Apache Axis2?
A: You can download the latest version (or 1.5) from the Axis2 official website or any mirror site. The download link is shown here:
Once you go the download page, you can find four different distributions (artifacts):
- Binary distribution
- WAR distribution
- Source distribution
- Document distribution
In addition, you can also download IDE plugins from Axis2's official website (IDE tools include both Eclipse and IntelliJ IDEA).
Q: How to proceed with the installation of Binary distribution?
A: Axis2 binary distribution consists of all the relevant third-party libraries, a set of samples, and Axis2 runtime. Installing binary distribution is just a matter of extracting ZIP archive files into a location where you want. Once you download and extract the binary distribution, you will be able to see a set of subdirectories inside it (bin, lib, samples, repository, webapp, and conf). A typical structure of an extracted binary distribution is shown below.
Axis2 binary distribution is a complete package where you can deploy services and expose them using SimpleAxisServer. SimpleAxisServer is a fully functional server that can be used as the backend server to expose the web service. It supports all the features that the servlet version supports, including session management, thread management, auto WSDL generation, and others.
We can also use Axis2 binary distribution to invoke remote services. For this you need to add Axis2 and other related libraries into the class path and use Axis2 Client APIs to invoke the service. One of the commonly used approaches is to add those libraries into your IDE and client applications developed from that.
Binary distribution can also be used to generate Stubs and Skeleton from a given WSDL or to generate WSDL from a given Java class. Starting Axis2 as a standalone server is just a matter of running either .bat or a script file in the bin directory. Once we run the axis2server.sh (or .bat) and type http://localhost:8080/axis2, we can see the list of available services in the system, and these indicate the server is up and running.
Q: How to proceed with the installation of WAR distribution?
A: Installing WAR distribution consists of the following few steps:
- Install application server: If you do not have any application server in your machine, then you need to download and install the application server. Among the available application servers Apache Tomcat can be considered as one of the best application servers (does not support all the features of J2EE). So let's download Tomcat (5.x or above) and install.
- Depending on the application server, you can find the location where you need to deploy the WAR files. If you take Tomcat as an example, you need to put the WAR file into the webapps directory. So let's drop Axis2 WAR distribution into the webapps directory of the application server.
- As the final step, open a browser and type http://localhost:8080/axis2. We can see Axis2 web application (as shown in the figure) home page (here the URL may differ, depending on the application server).
If everything has gone well, you will get the following page:
Q: What is Source distribution?
A: As the name implies, source distribution consist of the source code that is used to build binary distribution. As Apache Axis2 is released under Apache license, we can do anything with the source code. The idea is that the user can use Axis2 and modify to suit their requirements. Additionally, if they think that a modification is useful for other people, they can submit a patch and ask the project community to merge the changes to the main source repository.
When we develop a real application, it is always useful to have the source code around in addition to the documentation that helps to debug the application as well. In the meantime, source distribution consists of maven scripts (http://maven.apache.org) and we can use them to create either binary distribution, WAR distribution, or even JAR distribution.
Q: What is Document distribution?
A: The document distribution provides all the necessary resources to understand the different features and functionality in the project. It provides Java documentation and tutorials, explaining how to use different features.
Q: What is JAR distribution?
A: One of the key steps of a web service is developing the Services and Clients. In that stage, we need to have access to the Web Service framework and their libraries. To access the APIs and other relevant resources, it is a common practice to add the required libraries into the Integrated Development Environment (IDE). Axis2 JAR distribution provides a convenient way to download and embed Axis2 runtime into the IDE. You can download Axis2 library files separately from the following links, or you can get those from Axis2 binary or WAR distribution:
The popularity of web services is caused by the standardization of techniques and by the standards that are open enough to be adapted to different situations. So the developer is not committed to a concrete realization of these concepts. There always exist more solutions to realize the concepts of web services.
- Apache Axis2 Web Services: Writing an Axis2 Module [Article]
- Looking into Apache Axis2 [Article]
- Handler and Phase in Apache Axis2 [Article]
- Debugging REST Web Services [Article]
- SOA with Java Business Integration [Article]
eBook Price: $23.99
Book Price: $39.99
Resources for Article :
Apache Axis2 Web Services, 2nd Edition by Deepal Jayasinghe and Afkham Azeez