Open source computing has gained a tremendous degree of momentum in the last few years. Nowhere is this more evident than in the area of web services and Service-Oriented Architecture (SOA). The Apache Foundation alone has more than 20 SOA/WS projects. One of the common obstacles for large enterprises to adopt open source solutions for key systems is the lack of administrative infrastructure and standardized glue for pulling together complementary projects. Essentially, the lack of a true open source "platform" (along with professional consulting and training services) limits more extensive adoption of open source technology. One group that has successfully addressed this open source platform gap is the JBoss Group. Until recently, however, no such group existed to establish a platform around Apache SOA projects. Enter WSO2 (WS "Oh" 2).

This article introduces the WSO2 platform by looking at two key features -- security and reliable messaging. We will begin with an examination of the relevant WS-* standards (WS-ReliableMessaging, WS-Security, WS-SecureConversation, and WS-Trust) followed by a peek into the related Apache projects. Then we will proceed to explore the value-add that WSO2 provides above and beyond the basic Apache projects.

Security and Reliability Service Standards Overview

The field of web service standards is vast and constantly evolving. The security space, in particular, has an extensive set of standards (many of which are defined as extensions of WS-Security). For the purposes of this article, the following service standards come into play:

• WS-Security: Describes a protocol for securing web service message exchanges, addressing identity, integrity, and confidentiality. WS-Security serves as the core specification for service security and leverages two other specifications, XML Encryption and XML Digital Signatures.
• WS-Trust: Building upon the extensibility of WS-Security, this specification defines a means of brokering security credentials among partners within different trust domains.
• WS-SecureConversation: This specification defines extensions to WS-Security and builds on WS-Trust to govern secure communication across multiple message exchanges. It defines a mechanism for sharing security contexts and deriving session keys to tie messages together as a part of a "conversation."
• WS-ReliableMessaging: Describes a protocol for exchanging messages between nodes in the face of network, system, and component-level failures. Message delivery is guaranteed to occur and if a sequence of messages has been sent, they will arrive in the order they were sent.

Securing a single service invocation is fine for simple business scenarios. Modern enterprise messaging architectures require support for more complex scenarios involving multi-message conversations, brokering of security context across trusted domains, and assurance that messages are delivered to their intended destination. In short, modern enterprise architectures must support secure, reliable messaging.

Related Apache Projects

In support of the service standards identified earlier, we will look to several Apache projects that implement these standards. Specifically, we will leverage Apache Axis and several add-on modules (Rampart, Rahas, and Sandesha).

• Axis2 (Service Engine): Apache Axis2 provides the core web services engine and supports SOAP 1.1, SOAP 1.2, and REST-style services. In order to take advantage of increased efficiency, modularity, and the latest standards, we will want to use the new and improved Axis2 engine. The Axis engine is designed as a series of loosely coupled message handlers, which perform pre- and post-processing on messages. This design will be leveraged by the modules described below to perform additional pre- and post-processing on messages in order to support higher-level security and reliability messaging standards.
• Rampart (WS-Security & WS-SecureConversation): Apache Rampart is an Axis2 module that supports various service security standards. Rampart inserts message handlers into the pre-dispatch message processing phase within Axis to support the validation or production of security semantics.
• Rahas (WS-Trust): Apache Rahas provides WS-Trust support and does not currently exist as an independent Apache project. At the time of this writing, it resides as a library that is bundled along with Rampart.
• Sandesha2 (WS-ReliableMessaging): Apache Sandesha implements the WS-ReliableMessaging specification and, like Rampart, is packaged as an Apache Axis module.

While there are many more Apache projects that we could pull into the mix, this short list provides us with a sufficiently robust web service engine complete with a security and reliability framework. Although this project set provides sufficient functionality, it does not represent a cohesive platform. There is a significant amount of work that application developers and system administrators will need to do in order to deploy, connect, configure, and maintain this framework. Next, we will explore how to pull this together into a comprehensive enterprise service platform.

WSO2 Application Server

The Apache web service software outlined above offers solid SOA infrastructure capabilities. What it fundamentally lacks, however, is the concept of a comprehensive platform that is versioned, deployed, configured, administered, and supported collectively. This is where WSO2, the web services "oxygen tank," comes into play (see Figure 1). WSO2 takes release builds from major Apache SOA/WS projects (including those identified above), assembles them into a cohesive framework, wraps them with an intuitive web-based GUI, and simplifies the entire process of deployment and server management.

Figure 1. WSO2 (Click to enlarge.)

Although WSO2 offers several compelling solutions, we will focus our attention on the Web Services Application Server (WSAS). WSAS is open source (under the Apache license) and openly developed on wsas-java-dev at wso2.org. WSAS supports all of the service standards outlined earlier (plus a lot more) through the incorporation of the Axis2 modules identified earlier. WSAS comes in two flavors, one with an embedded Tomcat server (standalone edition), and one that installs directly into an existing J2EE server environment (servlet edition). Installation and deployment of WSAS is a breeze regardless of which edition you select. In either case, you simply download the zip file, extract in the appropriate directory, and you are ready to go. Both editions come with excellent documentation in case you get lost or want to know more about how to administer and configure the server.

Creating Your Services

The development of Axis2-compliant services is beyond the scope of this article (and is detailed nicely in various places all over the Web). You won't find the development process to be any different with WSAS. What is different, however, is the deployment, configuration, and ongoing management of services. WSAS abstracts administrators and developers from low-level XML configuration semantics and provides a convenient web-based GUI for service and module administration.

Making Your Services Secure and Reliable

Normally, service security would require that developers or deployers supply precise configuration details in services.xml and/or axis2.xml deployment descriptors. WSAS abstracts this level of detail and instead provides a web-based administrative GUI for enabling any available modules (rampart, rahas, and sandesha, in our case) either globally or at service operation level. Moreover, the WSAS administrative GUI generates a snazzy graphical view of the Axis2 handler flows (see Figure 2 below). This provides a visual representation of the message processing flows and allows you to graphically see what additional capabilities (such as security and reliability) you are enabling for your services, and where they will fit into the overall message flow.

Figure 2. Axis2 handler flows (Click to enlarge.)

Once you have enabled security and reliability for one or more services, you will need to configure your service clients to support the respective standards. To do this, you will use the Axis2 client API in concert with the other Apache modules outlined earlier. Although WSO2 does not offer convenience utilities to ease client development, it does ship with all of the client APIs and command-line tools that ship with Axis2. For more details, you can either refer to Axis2 documentation, the WSAS documentation, or both.

SOA Success with WSO2

With SOA and web services evolving and maturing so rapidly, demand for enterprise-grade services continues to rise. While various Apache projects offer support for the latest enterprise service standards such as WS-Security, WS-Trust, WS-SecureConversation, and WS-ReliableMessaging, they are developed as separate (albeit complementary) projects. Combine this with the lack of deployment and administrative support offered by this project, and it's no wonder that they are not used more widely in major enterprise deployments. WSO2's Web Services Application Server offers a compelling solution to the mix. From the combination of the solid functionality and standards-compliant implementations offered by these Apache projects with an intuitive service management platform, a robust platform emerges.

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.