ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
September 28, 2006
- Music publishers seek to silence guitar tablature sites
- Making music
Fedora Core 5
- Jamendo: Music the way it was meant to be
- Edward Felten debunks DRM
- Introduction to web services
- Ask Shadowman
- More tips & tricks
- RSS how-to: Get your feed on
- Edward Felten defends your freedom to tinker
- Frysk: Debugging in real time
- Red Hat Speaks: Aaron Darcy and the application stack
- Fedora status report
- Tips & tricks
- >> more
Introduction to web services
by Rajith Attapattu
"Web services" is a common buzzword in computing circles, but it is one of the most misunderstood technologies. Since becoming involved with web services, I have come to learn how much I--and many others--have misunderstood about what this technology is and how it can be used effectively. The motivation behind this article is to simply promote a better understanding of web services. By understanding the "big picture," how the key specifications fit together, you can better implement web services to fulfill your computing needs. While writing this article, I corresponded with Dr. Sanjiva Weerawarna to obtain expert advice on several topics and issues and am grateful for his assistance.
What are web services?
According to the web services architecture document published by W3C, "A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
Web service specifications are open, XML-based standards that are agreed upon through industry-wide participation in standard bodies like W3C or OASIS. The architecture section will describe what these specifications are and how they all fit together to form the big picture.
Why are web services gaining so much momentum and hype?
Web services bring a unique characteristic to the table, namely interoperability. Why is this property flaunted so much in marketing literature and why is there such a rush for vendors to support web services? The world is a heterogeneous place and different organizations (and sometimes different departments within large organizations) will choose a wide variety of technologies and platforms to use in building their applications. As long as these applications operate as standalones it doesn't matter. However, when you need to collaborate with different applications within the same organization or a different organization, integration becomes a nightmare. One application might be using J2EE (EJB, etc.) while the other is a legacy application that's written using C/C++ or a .NET application. These may run on different operating systems, making things even more complicated.
This is where web services add value. The interoperability will ensure that these heterogeneous systems can interact with each other in a standard way, thus reducing some of the ugly issues faced when integrating heterogeneous systems. It is often a mistake to think that web services are the silver bullet to all problems faced in integrating heterogeneous systems, but web services offer by far the most promise in this area, provided the technology survives vendor politics.
Technology and provider abstraction
Organizations can expose their systems using web services and publish only the WSDL. This way they don't need to worry about giving out too much information about the implementation, as the users will be able to interact successfully as long as they implement their systems based on the WS standards and adhere to the contract defined by the WSDL. For example, Amazon Simple Queue Service or a hotel chain could expose their booking system using web services.
Loosely coupled components (systems)
Coupling is defined as the degree to which components (or systems) are dependent on a certain factor. This could be (but is not limited to) another component, a technology, a service provider or simply an application state. While it is impossible to define systems which are completely decoupled, using web services minimizes coupling in systems in several ways. Vendor- and platform-neutral messaging is one excellent decoupling point that web services promote. Technology and provider abstraction allow web services to minimize dependency on a given technology, service provider, or platform. Stateless messaging (where possible) will decouple application state from components.
While the above factors are not the only reasons why web services are popular, they have no doubt contributed to the huge interest generated within the industry.
Common misconceptions about web services
Before going any further and looking into the web services architecture, I think it's important to point out some of the misconceptions that I have heard about web services. Understanding clearly what web services are and what they are not will be valuable when you start designing your systems. Especially as misconceptions can severely affect your systems architecture.
"Web services are distributed-object technology."
This misconception may have begun because web services were originally more oriented towards RPC (Remote Procedure Call). Also, SOAP was initially an acronym for Simple Object Access Protocol, which no doubt added to the misconception of web services being object-centric. Web services have a message-oriented architecture, not an object-centric architecture. A web service produces and consumes messages (documents). It does not have any of the semantics usually associated with the object world. For instance, there is no notion of an object reference. On one end you could have a Java object that produces a message and on the other end you can have a C procedure that consumes that message. Trapping yourself in the object-centric myth will restrict your options and creativity when it comes to leveraging web services.
"Web service interactions are synchronous and request/response style in nature."
For starters, web services interactions can be either synchronous or asynchronous. Thinking only in terms of synchronous request/response-style interactions will keep you from harnessing the flexibility and scalability you can achieve using asynchrony and other message exchange patterns. WSDL 2.0 defines eight Message Exchange Patterns commonly referred to as MEPs . It's important to familiarize yourself with this by reading the document included in the reference section before you start designing your web services system.
"Web services are SOAP over HTTP."
This is by far the most popular misconception, as a lot of people think that web services are only supported over HTTP. Web services are transport agnostic. Currently, HTTP is the most widely used transport due to its common availability as an infrastructure, which in turn is due to the wide use of the Internet. But SOAP messages can be delivered over other transports as well. For instance, Apache Axis2  supports several transports in addition to HTTP, such as SMTP, JMS and TCP/IP.
"Service Oriented Architecture and web services are the same."
People often talk about web services and Service Oriented Architecture (SOA) in combination. But there's more to it than that. Service Oriented Architecture is an abstract architectural concept , while web services are only one approach in realizing that Service Oriented Architecture concept.
"Web services are not secure."
People think "web" and they are already a bit skeptical about the quality of security. Then somebody mentions that SOAP messages are XML-based and they panic. They think that XML is human-readable and wonder about the confidential information being exchanged. That's why they defined WS-Security, a family of security-related specifications. Strong security support can be provided to web services to ensure secure exchange of information without being compromised during transmission.
"Web services are not reliable because the Internet is not a reliable network."
No network is really reliable. That is where WS-ReliableMessaging adds value. It defines a reliable means of communication for mission-critical applications that need to guarantee the delivery and order of messages.
"Web services can be thought of as objects."
This is a common mistake that people make when writing a WSDL. A web service should be more coarse-grained and the design should start at a higher level. The implementation, however, can be mapped to more fine-grained components (objects as we deal mostly with OO languages). Thinking in terms of a web service as an object right at the start will give the wrong picture about granularity. It also gives the impression that the only way to interact with a service is with a blocking request/response pattern. A web services interaction should be envisioned beyond the semantics of a method call.
For example, picture an interaction that waits for two inputs from two distinct service requesters and produces an output to an entirely different node. This goes beyond our usual synchronous request/response-style of method semantics. This scenario wouldn't be possible if we think about a web service as an object, unless we think of the service from a higher-level point of view.
The web services architecture
Let's look at the web services architecture more closely. The following diagram depicts the layered architecture of the web services stack.
A brief description of each layer along with the relevant specifications are provided below. These specifications are very broad and discussing them in detail is outside the scope of this article. The purpose of the article is more or less to introduce them and describe what value each adds to the web services stack. However, links are provided in the reference section for interested readers to get more detailed information.
The transport layer is responsible for carrying the SOAP message. As pointed out previously, web services are transport agnostic and web services stacks like Apache Axis2 support several transports.
SOAP is a specification defined by W3C . It is the fundamental messaging framework for web services. An important point to note is that from SOAP 1.2 and on, it is no longer an acronym. SOAP supports both document-literal and RPC programming models. A SOAP message consists of a single envelope and contains zero or more headers. The SOAP body contains business information commonly referred to as the payload. The SOAP specification does not define the actual contents of these headers or of the payload, but rather how it should be processed. The content is determined by the application that produces the SOAP message. Another important point is that, while the SOAP body is mandatory, the SOAP headers are optional. If an error is encountered while processing a SOAP message, it will result in a SOAP fault.
The optional SOAP headers provide the extensibility of the SOAP messaging structure. By specifying new headers you could compose new specifications based on SOAP. For example WS-Addressing is specified by defining new SOAP headers.
WS-Addressing provides transport-neutral mechanisms to address web services and messages . It defines the concept of an "endpoint reference," which encapsulates all the information that is required to reach a service endpoint at runtime. The value of WS-Addressing is that it provides a uniform way of identifying addressing information--such as where the message is going, where to return the response, or where to return an error without having to rely on the underlying transport mechanism. This also gives a standard way of routing messages over multiple transports. For example, a message could be sent for placing a purchase order over HTTP and after fulfilling the order the response can be sent over email (SMTP).
Web Services Description Language (WSDL)  describes what your service is and how and where to access a service implementation. It is basically a contract between a service implementor and a service requester. A WSDL document defines two distinct parts. First, there is an abstract, reusable, implementation-independent section which describes the Service Interface. Then there's a concrete service-implementation description where the service is located. With WSDL comes the topic of Message Exchange Patterns, commonly referred to as MEPs. This topic will be discussed in a separate article.
WS-Policy  provides important information about your web service which is not captured within a WSDL. It defines a general framework that can be used and extended by other web services specifications to describe a broad range of web services policies. WS-Policy defines a policy as a set of valid "policy alternatives." A policy alternative is a combination of policy assertions, which are individual capabilities or requirements. An example would be the type of security tokens that a service is capable of processing. Operators are defined to work on these policy alternatives, such as "ExactlyOne," "OneOrMore," and "ALL." Together they form a powerful framework to help two web services exchange configuration information at runtime to ensure their interoperability.
QoS (Quality Of Service) layer
WS-Security  family of specifications address the all-important aspect of security. These specifications ensure the authenticity, integrity, and confidentiality of the SOAP messages. WS-Trust defines extensions that build on WS-Security to provide a framework for requesting and issuing security tokens and to broker trust relationships. WS-SecureConversation build on WS-Security and WS-Trust to provide secure communication across one or more messages.
WS-RM (Reliable Messaging)  provides a specification to guarantee delivery and ordering of messages. This is archived via the concept of a Sequence and Sequence Acknowledgment. It defines semantics such as "AtMostOnce," "AtLeastOnce" and "InOrder." This is an important specification that adds reliability to your web services.
WS-Coordination  provides a framework for coordinating the outcome between inter-operating web services. WS-Atomic Transactions  and WS-Business Activity  specify atomic and business transaction protocols that can be used with WS-Coordination. These specifications provide transaction support to web services to guarantee reliable and agreeable outcomes in distributed applications.
The layers below the component layer can be regarded as the infrastructure. The component layer consists of the web services (components) created by the application developer that capture the business logic. These components could be atomic or composite. WS-BPEL (Business Process Execution Language)  is an extensible work-flow language that aggregates services by choreographing service interactions. In simpler terms, it's a model for defining how individual web services can collaborate together to create more complex and reliable business processes.
Applicability of web services
It is important to note that web services are not the magic cure for all problems. The technology has its own advantages and disadvantages that have to be carefully factored when determining the applicability of web services as a solution to a given problem. Below are some general guidelines, but remember that these are only general recommendations. Common sense should prevail, as it should with most situations where there is no rigid set of rules that can be used to determined applicability.
Do you operate in a homogeneous environment where your applications are static and mostly standalone? If that's the case, then the investment of taking a web services approach may not yield significant benefits.
Is your application very sensitive to response times? If so, web services may not be an appropriate choice. Processing of XML messages is both time- and memory-intensive.
Is your application designed with the intention of supporting/communicating with various partners/customers that are not yet clearly identified? If so, a web services approach may reap rich benefits because you don't know the target platform, vendors, or technologies your intendant partners or customers use. The web services approach will help you provide a technology- and platform-independent interface for your prospective partners or customers.
As with most technologies, it is important to understand web services from a "big picture" perspective in order to better leverage the advantages the technology has to offer.1 Web services architecture document
2 Message Exchange Patterns
3 Apache Axis2
4 Service Oriented Architecture
9 WS- Security
11 WS-Coordination, WS-AT, WS-BA