Colombo: lightweight middleware for service-oriented computing.

INTRODUCTION

Middleware and applications supporting Web Services specifications and standards are now being offered by every major software vendor. Solutions utilizing these technologies can be found throughout the Information Technology (IT) industry. As the framework of Web Services specifications (1,2) progresses toward consolidation and standardization, a new distributed computing paradigm is slowly being established. Web Services provide an XML (Extensible Markup Language) realization of the service-oriented computing (SOC) paradigm, and the progressive deployment of applications based on Web Services has the potential to make service-oriented architecture (SOA) the main architectural paradigm in the industry.

Service-oriented applications have specific characteristics that distinguish them from traditional distributed applications. (3) First, they must be able to operate in a natively cross-organizational setting; they interact with each other as peers, over bidirectional, stateful channels, following standardized protocols that allow them to operate in highly heterogeneous environments. They declaratively define their functionality and quality-of-service (QoS) requirements and capabilities in agreed-upon, machine-readable formats in order to enable dynamic and automated service discovery. Finally, service-oriented applications are, in one way or another, created as compositions of services. (4)

The adoption of Web Services technologies does not necessarily mean that SOA principles are being embraced. At this stage, middleware interoperability; that is, the ability to support interoperation among incompatible middleware platforms, is probably the main factor driving Web Services adoption. Web Services allow Enterprise Java ** and Microsoft .NET ** to interact and proprietary messaging middleware to connect over bridges of standardized protocols. In this initial adoption stage, the architectural impact of Web Services is likely to be limited.

Extended interoperability contains the seed of wider changes, however. As more and more existing and new applications are Web-Services enabled, the prospect of quasi-universal interoperability becomes closer to reality, and with it, the ability to access any number of services deployed anywhere (inside or outside the enterprise). A business model built on service access and reuse (including in particular "pay per use") is a direct consequence of this increased level of interoperability. Even without assuming a significant transformation of the business model, application development is likely to be profoundly transformed by this new focus on code reuse through remote service access. Applications developed in this environment can take full advantage of Web Services composition models, dynamic service discovery, explicit interaction contracts encoded in standards-based dialects, and so forth. Moreover, the componentization brought about by SOA advances will likely bring the design of software components much closer to the business components they are intended to support, helping bridge the gap between business knowledge and IT. Thus, one may expect that, in time, service-oriented principles will naturally follow the Web Services framework in an unstoppable advance through the IT industry.

This assumption raises the question of whether the architecture and the programming model associated with today's middleware platforms is always the most appropriate for supporting applications executing in a service-oriented environment. Today's most successful Web Services platforms are fundamentally built by layering a veneer of Web Services protocols on top of existing middleware (consider, for example, Microsoft's Web Services Enhancements, WSE 2.0, and the suite of Java Specification Requests [JSRs] supporting the use of Web Services from a Java 2 Enterprise Edition [J2EE **] platform). The eventual success of this approach is not in question because it provides proven reliability and scalability with a new protocol suite, and it is also a progressive approach that ensures quick adoption with little disruption of existing projects and applications. Nonetheless, the question is whether this layering model is always appropriate as a longterm approach to service orientation.

The Colombo project at IBM Research is an attempt to understand the consequences of the service-oriented paradigm on the programming model and the runtime and the type of competitive advantage that a platform based natively on SOC principles can provide in terms of simplicity, performance, and developer productivity. With the Colombo approach, an experimental SOA platform is built from first principles, SOC principles, and its characteristics are evaluated with respect to performance, scalability, the process of development and deployment, application management and maintenance, and other aspects.

The Colombo project is a Web-Services-centric, lightweight approach to service orientation. Web Services are, after all, the only realization of SOC with a sufficient level of adoption to support realistic field tests and comparisons. The Colombo "platform" is still under development, but it already provides a very lightweight implementation of most of the Web Services (WS) stack, with the notable exception of service and meta-data discovery specifications. Thus, the Colombo runtime natively provides transactional, reliable, and secure interactions among services based on SOAP (Simple Object Access Protocol). (5) Colombo defines a multilanguage service programming model that supports, among others, Java and Business Process Execution Language for Web Services (BPEL4WS) service composition, and offers a radically simplified development and deployment model based on standards (Web Services Description Language [WSDL] (3) and WS-Policy (6)).

In this paper we describe the design principles behind Colombo, focusing on its service-centric programming model (the "servicelet" model) and the architecture of its runtime. The rest of this paper is organized as follows. The next section briefly describes the principles of SOAs that have driven the design of the Colombo runtime and programming model. The third section introduces the Colombo programming model in detail, including deployment, development models, and the realization of that model in Java and BPEL. The fourth section describes the Colombo runtime, focusing on the Colombo message-processing engine, the component manager architecture that supports the servicelet multilanguage programming model, and the QoS policy framework. We conclude in the fifth and sixth sections with a discussion of future work and a summary of the paper.

SOA PRINCIPLES AND REQUIREMENTS IN COLOMBO

The Colombo project is directed at exploring the technical characteristics that differentiate SOA middleware. There are in fact many distinguishing aspects of SOAs that might be expected to have an effect on the design of SOA-centric middleware. Because the Web Services specification framework defines the only protocol stack built on SOA principles to date, the Colombo effort has focused on providing a faithful realization of the Web Services stack. The discussion in this section in particular is thus very much derived from the key characteristics of the Web Services stack.

The main components of the Web Services framework are depicted in Figure 1. (See Reference 3 for an in-depth discussion of these components.)

[FIGURE 1 OMITTED]

The Colombo platform described in this paper supports the complete stack shown here except for the mechanisms for discovery of services and negotiation. This implies in particular that there is no support in Colombo for Universal Description, Discovery, and Integration (UDDI) (7) or WS-MetadataExchange. (8)

As in all middleware architectures, the interaction model, runtime architecture, and programming model are intimately connected in SOAs. The interaction model in Web Services is built around the SOAP messaging model, and this has two main implications: the centrality of XML as the data serialization model and a natively asynchronous interaction model that can also support synchronous interactions. The WS-Addressing specification (9) in particular introduces a set of SOAP headers and a simple processing model to seamlessly support both synchronous and asynchronous exchanges of SOAP messages. The runtime architecture in Colombo is thus built around an efficient XML parser supporting a SOAP processor that can deal with synchronous and asynchronous message exchanges.

A second characteristic of Web Services interactions is the central role of QoS requirements. In an SOA, QoS requirements are explicitly stated in machine-readable format and become part of the interaction contract between providers and requestors. QoS requirements are used to configure the interaction channel between service partners, and they are encoded in the form of explicit service policies, in the case of Colombo using the WS-Policy language. WSDL service descriptions published and consumed by Colombo applications are annotated with policies stating those requirements. Correspondingly, the Colombo runtime provides a policy handler framework on top of the message-processing engine, supporting the three QoS specifications currently in the Web Services stack: atomic transactions (WS-AtomicTransactions (10)), reliable messaging (WS-ReliableMessaging (11)), and the suite of Web Services security mechanisms defined by the Web Services security standard. (12)

Explicit meta-data in the form of machine-readable service descriptions, including functional and nonfunctional QoS characteristics, is a central aspect of Web Services. (13) The Colombo development and deployment models are completely driven by this meta-data. Code generation, deployment, and runtime configuration are all driven by the WSDL and WS-Policy descriptions of the services being authored or consumed. The goal is to avoid generating a gap between the internal representation of service capabilities and the external, interoperable service view that is defined by the service contract.

SOAs in general and Web Services in particular have a distinct component orientation. (4,14) Services are software components that allow remote access over standard protocols and provide declarative descriptions of their requirements and capabilities. In this component-centric environment, the main task of the application developer is the integration of service components into new applications; that is, service composition is the distinctive characteristic of development in SOAs. The programming model for SOA middleware needs to provide native support for service creation and composition. The Colombo programming model defines primitives for providing and reusing services in a language-independent manner, which allows Colombo to support a variety of composition models. Java and BPEL (15) are the two languages currently supported for composing services.

We can summarize the preceding discussion by enumerating the main aspects of the service-oriented model that drives the design of Colombo:

* Native support for a SOAP asynchronous interaction model

* Policy-enabled interactions supporting the business-enabling QoS requirements: transactions, reliable messaging, and security

* Meta-data-driven development and deployment models

* First-class support for service composition

The details of how the Colombo programming model and runtime support these requirements are discussed in the following sections.

THE COLOMBO PROGRAMMING MODEL

In this section, we discuss the Colombo programming model. Given that the term "programming model" can have many meanings, we begin by defining what we mean by a programming model. A programming model is the set of abstractions, conventions, and contracts to which the programmer must adhere when writing applications. It also includes the set of services that the system provides to the programmer.

The SOA programming model

A distinguishing characteristic of service-oriented applications is that of composition: services are often built by taking existing services and combining them with some compositional logic. As such, we identify four critical characteristics of a minimal SOA programming model. There must be a mechanism

1. to access other services,

2. to encode the compositional logic,

3. to encapsulate the composition as a new service, and

4. to state the QoS characteristics that should be followed when interacting with other services.

We illustrate this model in Figure 2. As indicated in the figure, the composition logic is the centerpiece and serves to orchestrate, and add value to, the functionality provided by the "Used" services to offer a set of "Provided" services to its clients. The terms and conditions under which the services are used are indicated by policies associated with interactions between the composition and external services, …