colombo: lightweight middleware for so computing

8/14/2019 Colombo: Lightweight middleware for SO computing

1/22

Colombo: Lightweight

middleware for service-orientedcomputing

&

F. CurberaM. J. DuftlerR. Khalaf W. A. NagyN. MukhiS. Weerawarana

Colombo is a lightweight platform for developing, deploying, and executing service-oriented applications. It provides optimized, native runtime support for the service-oriented-computing model, as opposed to the approach of layering service-orientedapplications on a legacy runtime. This approach allows Colombo to provide highruntime performance, a small footprint, and simplified application development anddeployment models. The Colombo runtime natively supports the full Web Services(WS) stack, providing transactional, reliable, and secure interactions among services. Itdefines a multilanguage service programming model that supports, among others,Javae and Business Process Execution Language for Web Services (BPEL4WS) servicecomposition, and offers a deployment and discovery model fully based on declarativeservice descriptions (Web Service Description Language [WSDL] and WS-Policy). In this

paper we describe these and other aspects of the architecture, design principles, andcapabilities of the Colombo platform.

INTRODUCTIONMiddleware and applications supporting WebServices specications and standards are now beingoffered by every major software vendor. Solutionsutilizing these technologies can be found throughout

the Information Technology (IT) industry. As theframework of Web Services specications

1,2pro-

gresses toward consolidation and standardization, anew distributed computing paradigm is slowly beingestablished. Web Services provide an XML (Exten-sible Markup Language) realization of the service-oriented computing (SOC) paradigm, and the pro-gressive deployment of applications based on WebServices has the potential to make service-oriented

architecture (SOA) the main architectural paradigmin the industry.

Service-oriented applications have specic charac-teristics that distinguish them from traditionaldistributed applications.

3First, they must be able to

operate in a natively cross-organizational setting;they interact with each other as peers, overbidirectional, stateful channels, following standard-

Copyright 2005 by International Business Machines Corporation. Copying inprinted form for private use is permitted without payment of royalty providedthat (1) each reproduction is done without alteration and (2) the Journalreference and IBM copyright notice are included on the rst page. The titleand abstract, but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based and otherinformation-service systems. Permission to republish any other portion of thepaper must be obtained from the Editor. 0018-8670/05/$5.00 2005 IBM

IBM SYSTEMS JOURNAL, VOL 44, NO 4, 2005 CURBERA ET AL. 799


2/22

ized protocols that allow them to operate in highlyheterogeneous environments. They declarativelydene their functionality and quality-of-service(QoS) requirements and capabilities in agreed-upon,machine-readable formats in order to enable dy-namic and automated service discovery. Finally,

service-oriented applications are, in one way oranother, created as compositions of services.

4

The adoption of Web Services technologies does notnecessarily mean that SOA principles are beingembraced. At this stage, middleware interoperabil-ity; that is, the ability to support interoperationamong incompatible middleware platforms, isprobably the main factor driving Web Servicesadoption. Web Services allow Enterprise Java** andMicrosoft .NET** to interact and proprietary mes-saging middleware to connect over bridges of

standardized protocols. In this initial adoption stage,the architectural impact of Web Services is likely tobe limited.

Extended interoperability contains the seed of widerchanges, however. As more and more existing andnew applications are Web-Services enabled, theprospect of quasi-universal interoperability becomescloser to reality, and with it, the ability to access anynumber of services deployed anywhere (inside oroutside the enterprise). A business model built onservice access and reuse (including in particular

pay per use

) is a direct consequence of thisincreased level of interoperability. Even withoutassuming a signicant transformation of the busi-ness model, application development is likely to beprofoundly transformed by this new focus on codereuse through remote service access. Applicationsdeveloped in this environment can take full ad-vantage of Web Services composition models,dynamic service discovery, explicit interaction con-tracts encoded in standards-based dialects, and soforth. Moreover, the componentization broughtabout by SOA advances will likely bring the designof software components much closer to the businesscomponents they are intended to support, helpingbridge the gap between business knowledge and IT.Thus, one may expect that, in time, service-orientedprinciples will naturally follow the Web Servicesframework in an unstoppable advance through theIT industry.

This assumption raises the question of whether thearchitecture and the programming model associated

with todays middleware platforms is always themost appropriate for supporting applications exe-cuting in a service-oriented environment. Todaysmost successful Web Services platforms are funda-mentally built by layering a veneer of Web Servicesprotocols on top of existing middleware (consider,for example, Microsofts Web Services Enhance-ments, WSE 2.0, and the suite of Java SpecicationRequests [JSRs] supporting the use of Web Servicesfrom a Java 2 Enterprise Edition [J2EE**] platform).The eventual success of this approach is not inquestion because it provides proven reliability andscalability with a new protocol suite, and it is also aprogressive approach that ensures quick adoptionwith little disruption of existing projects andapplications. Nonetheless, the question is whetherthis layering model is always appropriate as a long-term approach to service orientation.

The Colombo project at IBM Research is an attemptto understand the consequences of the service-oriented paradigm on the programming model andthe runtime and the type of competitive advantagethat a platform based natively on SOC principles canprovide in terms of simplicity, performance, anddeveloper productivity. With the Colombo ap-proach, an experimental SOA platform is built fromrst principles, SOC principles, and its character-istics are evaluated with respect to performance,scalability, the process of development and deploy-ment, application management and maintenance,and other aspects.

The Colombo project is a Web-Services-centric,lightweight approach to service orientation. WebServices are, after all, the only realization of SOCwith a sufcient level of adoption to support realisticeld tests and comparisons. The Colombo plat-form is still under development, but it alreadyprovides a very lightweight implementation of mostof the Web Services (WS) stack, with the notableexception of service and meta-data discovery spec-ications. Thus, the Colombo runtime nativelyprovides transactional, reliable, and secure inter-actions among services based on SOAP (SimpleObject Access Protocol).

5Colombo denes a multi-

language service programming model that supports,among others, Java and Business Process ExecutionLanguage for Web Services (BPEL4WS) servicecomposition, and offers a radically simplieddevelopment and deployment model based on

CURBERA ET AL. IBM SYSTEMS JOURNAL, VOL 44, NO 4, 2005800


3/22

standards (Web Services Description Language[WSDL]

3and WS-Policy

6).

In this paper we describe the design principlesbehind Colombo, focusing on its service-centricprogramming model (the servicelet model) and

the architecture of its runtime. The rest of this paperis organized as follows. The next section brieydescribes the principles of SOAs that have driven thedesign of the Colombo runtime and programmingmodel. The third section introduces the Colomboprogramming model in detail, including deploy-ment, development models, and the realization of that model in Java and BPEL. The fourth sectiondescribes the Colombo runtime, focusing on theColombo message-processing engine, the compo-nent manager architecture that supports the ser-vicelet multilanguage programming model, and the

QoS policy framework. We conclude in the fth andsixth sections with a discussion of future work and asummary of the paper.

SOA PRINCIPLES AND REQUIREMENTS INCOLOMBOThe Colombo project is directed at exploring thetechnical characteristics that differentiate SOA mid-dleware. There are in fact many distinguishingaspects of SOAs that might be expected to have aneffect on the design of SOA-centric middleware.Because the Web Services specication framework

denes the only protocol stack built on SOAprinciples to date, the Colombo effort has focused onproviding a faithful realization of the Web Servicesstack. The discussion in this section in particular isthus very much derived from the key characteristicsof the Web Services stack.

The main components of the Web Services frame-work are depicted in Figure 1. (See Reference 3 foran in-depth discussion of these components.)

The Colombo platform described in this papersupports the complete stack shown here except forthe mechanisms for discovery of services andnegotiation. This implies in particular that there isno support in Colombo for Universal Description,Discovery, and Integration (UDDI)

7or

WS-MetadataExchange.8

As in all middleware architectures, the interactionmodel, runtime architecture, and programmingmodel are intimately connected in SOAs. The

interaction model in Web Services is built around

the SOAP messaging model, and this has two mainimplications: the centrality of XML as the dataserialization model and a natively asynchronousinteraction model that can also support synchronousinteractions. The WS-Addressing specication

6in

particular introduces a set of SOAP headers and asimple processing model to seamlessly support bothsynchronous and asynchronous exchanges of SOAPmessages. The runtime architecture in Colombo isthus built around an efcient XML parser supportinga SOAP processor that can deal with synchronousand asynchronous message exchanges.

A second characteristic of Web Services interactionsis the central role of QoS requirements. In an SOA,QoS requirements are explicitly stated in machine-readable format and become part of the interactioncontract between providers and requestors. QoSrequirements are used to congure the interactionchannel between service partners, and they areencoded in the form of explicit service policies, inthe case of Colombo using the WS-Policy language.WSDL service descriptions published and consumedby Colombo applications are annotated with policies

stating those requirements. Correspondingly, theColombo runtime provides a policy handler frame-work on top of the message-processing engine,supporting the three QoS specications currently inthe Web Services stack: atomic transactions (WS-AtomicTransactions

10), reliable messaging (WS-Re-

liableMessaging11

), and the suite of Web Servicessecurity mechanisms dened by the Web Servicessecurity standard.

12

Figure 1The Web Services stack

Discovery,Negotiation

Messaging

Qualityof Service

Transport

Description

ComponentsComposite Atomic

Transports

SOAP XML Non-XML

Interface + Bindings Policy

SecurityReliableMessaging

Transactions

Coordination



4/22

Explicit meta-data in the form of machine-readableservice descriptions, including functional and non-functional QoS characteristics, is a central aspect of Web Services.

13The Colombo development and

deployment models are completely driven by thismeta-data. Code generation, deployment, and run-

time conguration are all driven by the WSDL andWS-Policy descriptions of the services being auth-ored or consumed. The goal is to avoid generating agap between the internal representation of servicecapabilities and the external, interoperable serviceview that is dened by the service contract.

SOAs in general and Web Services in particular havea distinct component orientation.

4,14Services are

software components that allow remote access overstandard protocols and provide declarative descrip-tions 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 characteristicof development in SOAs. The programming modelfor SOA middleware needs to provide native supportfor service creation and composition. The Colomboprogramming model denes primitives for providingand reusing services in a language-independentmanner, which allows Colombo to support a varietyof composition models. Java and BPEL

15are the two

languages currently supported for composing ser-

vices.

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

Native support for a SOAP asynchronous inter-action model

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

Meta-data-driven development and deploymentmodels

First-class support for service composition

The details of how the Colombo programmingmodel and runtime support these requirements arediscussed in the following sections.

THE COLOMBO PROGRAMMING MODELIn this section, we discuss the Colombo program-ming model. Given that the term programming

model can have many meanings, we begin bydening what we mean by a programming model. A programming model is the set of abstractions,conventions, and contracts to which the program-mer must adhere when writing applications. It alsoincludes the set of services that the system providesto the programmer.

The SOA programming modelA distinguishing characteristic of service-orientedapplications is that of composition: services areoften built by taking existing services and combiningthem with some compositional logic. As such, weidentify four critical characteristics of a minimalSOA programming model. There must be a mech-anism

1. to access other services,2. to encode the compositional logic,3. to encapsulate the composition as a new service,

and4. to state the QoS characteristics that should be

followed when interacting with other services.

We illustrate this model in Figure 2. As indicated inthe gure, the composition logic is the centerpieceand serves to orchestrate, and add value to, thefunctionality provided by the Used services tooffer a set of Provided services to its clients. Theterms and conditions under which the services areused are indicated by policies associated withinteractions between the composition and externalservices, whether they are used or providedservices. Policies are declarations of expected oroffered QoS characteristics, as described later. Notethat interactions between the composition logic and built-in or system services are not specialtheytoo are modeled as service interactions.

The servicelet programming modelIn keeping with the simplicity objectives of Colom-bo, the programming model was designed to be assimple as possible yet powerful enough to writeservice-oriented applications. In Colombo, we dene service as follows: A service is a stateless messageprocessor supporting exactly one interface and withassociated interaction-specic information, said tobe context. Thus while the service logic itself isstateless, it does have access to a context that maycontain state associated with a particular interactionbetween the service and a client or partner service.



5/22

The unit of development and deployment inColombo is called a servicelet . As Figure 3 shows,the servicelet concept is a direct mapping of the SOAprogramming model illustrated in Figure 2 withstate represented as the servicelet context.

A servicelet provides one or more services and mayuse more services to implement the providedservices logic. We call the implementation of theprovided services business logic. Although thebusiness logic itself is stateless, each interactionbetween any service of the servicelet and a client or

partner results in the creation of a servicelet contextassociated with, and shared by, the entire servicelet.Interactions between the servicelet and other ser-vices (whether they are with a partner service bymeans of a stub or with a client service by means of an adapter) represent conversations with their ownpolicies as well as a conversation context local tothat conversation.

We model interactions between an applicationservicelet and the Colombo runtime also as serviceinteractions. This uniform approach for all inter-

Figure 3Servicelets

Servicelet

ClientService

ClientService

ClientService

ServiceletContext

ServiceletContext

ServiceletContext

ServiceletContext

ServiceletContext

Adapter

In

terface

Adapter

Interface

Adapter

Interface

Stub

Interface

Stub

Interface

StatelessBusiness Logic



Policies

Policies

PartnerServicePolicies

SystemServicePolicies

Policies

Figure 2SOA applications as service compositions

Provided

Interface

Provided

Interface

Provided

Interface

ClientService Used

Interface

Used

Interface

Composition Logic

Policies

ClientService Policies

PartnerServicePolicies

SystemServicePolicies

ClientService Policies



6/22

action with a servicelet simplies the programmingmodel by not forcing the programmer to learn twodifferent sets of abstractions.

All the services in a single servicelet share acommon servicelet context for each instance of the servicelet. However, we note that with ourdenition of service, there is really no concept of aservice instance. Instead, there are stateful conver-sations with a service. Thus, every usage orsequence of usages (a session) with a service resultsin one stateful conversation. A stateful conversationwith any of the services of the servicelet results inthe creation of a single servicelet context that isshared by the entire servicelet. Thus, in effect, theservicelet context instance represents the instance

of the servicelet.

Servicelet context data is not persisted by theruntime system. The decision in Colombo that thesystem would not provide any kind of automaticpersistence was carefully considered, as our expe-rience indicated that such automatic persistencecomes at a heavy price with questionable benet.Thus, if any application-sensitive data is stored inthe servicelet context, the application is responsiblefor treating such data only as a cache and for storingit persistently by using the system data service.

Thus, a servicelet can migrate in between invoca-tions to a different location by migrating the contentof the servicelet context.

When implementing the actual business logic,programmers are offered a set of system servicesthat they can rely on (the system services currentlyprovide access to stubs for invoking services,creating user-managed transactions, access to thedata service, and logging). As these services aremodeled as Web services, the business logic can beimplemented with any programming paradigm thatsupports Web-service interactions. Thus, we do notmake any assumption about how the serviceletbusiness logic itself is implemented; that is, theservicelet programming model is designed to allow aservicelet to be implemented as a single Java class, acollection of Java classes, a BPEL script, a collectionof XSLT scripts, and so forth. The serviceletprogramming model is intended to be an abstractprogramming model that can be mapped to specicimplementation approaches for servicelets.

Stubs and adaptersIn Figure 3 we refer to stubs and adapters. When theservice is invoking another service (i.e., when it actsas a client to another service), we say that theinteraction is through a stub. This is a logicalconcept; that is, there is no requirement that all

service interactions be through a statically type-mapped interface (as is required in JAX-RPC

16). The

stub exists to bridge between the business logic andthe Colombo runtime, which is actually responsiblefor delivering the message to the called service.

The adapter concept is similarly logical. An adapteris simply the bridge between the incoming messageand the actual business logic. Depending on theimplementation platform of the business logic, thestub may do anything, ranging from nothing tocompletely static type mapping.

Servicelet life cycleThe life cycle of servicelets is dened by three states:initialize, process, and destroy. The servicelet isinitialized as the rst message arrives to theservicelet, or equivalently, when the serviceletcontext is created. This initialization step allows theservicelet to cache any useful information into theservicelet context, for example.

After initialization, when messages arrive via any of the published service interfaces, they are delivered

to the servicelet, along with the appropriate ser-vicelet context, for processing. The servicelet con-text associated with a message is determined byusing information in the incoming message (e.g.,using WS-Addressing reference properties).

During the execution of the servicelet, a transientstate may be stored in the servicelet context.However, any persistent state must explicitly bestored by the application by using the system dataservice.

When the servicelet is deemed to be complete ornished, it is destroyed by destroying the associatedservicelet context. Note that due to the difculty of identifying when a servicelet is nished ingeneral, there is no assurance that a serviceletcontext will ever be destroyed.

ConversationsA conversation is an interaction between a serviceletand its client or partner services. Note that by



7/22

denition every servicelet instance participates in atleast one conversation with the sender of themessage that started the interaction. Each servicelet instance may hold only a single conversation withany given partner at a time (a property of theColombo programming model inherited from

BPEL4WS).

The conversation concept is abstracted in Colombobecause of the need to compute QoS parameters on aper-conversation basis. That is, at the start of aconversation the policy that will apply to theconversation is determined, possibly through anegotiation protocol (such as WS-MetadataExchange), and then that policy is used forthe duration of that conversation.

Conversations are characterized by a pair of

communicating endpoints and have context associ-ated with the conversation. (In fact the conversationpolicy is part of that context.) However, theprogramming model does not expose this conver-sation context to the application programmer. Theconversation context is maintained by the runtime,and the application affects the behavior of theconversation by asserting specic policies.

PoliciesAs just mentioned, all aspects of a conversation aregoverned by policies, including whether the con-versation can take place at all. Colombos policy

infrastructure uses the WS-Policy family of speci-cations.

Policies can be applied at different levels. When aColombo system is deployed, system-wide policiesmay be dened. When a servicelet is deployed,servicelet-wide policies may be dened as well.Similarly each service of a servicelet may have itsown policies.

The policies that are applicable to a particularconversation are determined at runtime by com-

bining all the system-wide policies, the servicelet-wide policies, and service-specic policies. Thiscomputation is performed at runtime, at the start of a conversation, as explained in the previous section.Policy granularity and calculation of effective policyis explained in detail in the section Policy frame-work.

It is also useful to mention that the enforcement of certain policies applied to a conversation may not

necessarily be reected in the actual messagesexchanged. In particular, privacy is an example of apolicy that does not have an on-the-wire (explicitmessage) representation.

The system services currently provide access to

stubs for invoking services, creating user-managedtransactions, getting access to the data service, andlogging.

Servicelet packaging and deploymentBefore a servicelet can be deployed into a Colombosystem, the constituent parts of the servicelet mustbe assembled and packaged together. Colombo usesthe familiar JAR (Java archive) le mechanism as apackaging mechanism, yet does not force the use of it; that is, Columbo expects that its dened con-ventions have been followed rather than that every-thing has actually been deployed as a single JAR.

The base servicelet package has the followingstructure:

example.car/

META-INF/

servicelet.xml

policies.xml

*.wsdl for service denition

certicates.ks

classes/

object and source les

lib/

shared library les

The basic objective of this structure is to simplify thedeveloper experience by providing a relativelyfamiliar structure (something similar to the JavaWeb application archive format) and one that isintuitively explainable. In order to deploy a ser-vicelet one clearly needs some meta-datathedescription of the servicelet itself (e.g., which codeartifacts constitute the implementation of the busi-ness logic), the policies that must be applied, andthe WSDL descriptions of the interfaces of theservicelet. If there are security aspects, then a keystore is needed to record the keys.

In addition to this meta-data, one also needs todeploy the code artifacts located in classes andlib. The classication of code artifacts betweenclasses and lib is a logical one. For example, if theservice were implemented in PHP,

17then the PHP



8/22

les would be inside the classes directory, eventhough strictly speaking PHP les are source and notcompiled classes. The lib directory exists to containdependent libraries.

Note that Colombo does not require that every oneof these parts be present. The objective is to requireabsolutely minimal information and to expect theruntime to deduce, derive, or compute whatever ispossible to be inferred. Furthermore, the author isallowed to deploy the packaged le or the complete

directory structure; thus allowing developers to runthe system directly from their working environmentwithout having to copy any les.

The servicelet descriptor itself is also designed to beintuitively obvious once the developer understandsthe servicelet programming model concept. Thestructure of the servicelet.xml le is given inFigure 4.

Every servicelet has a name provided by theapplication developer. The name is used to generatethe uniform resource identier (URI) where the

Colombo runtime makes the servicelet available bymeans of some access protocol (such as HTTP). Forexample, if the servicelet is published by theColombo runtime by means of HTTP, then the URIaddress of the servicelet is http://hostname/serviceletname. Thus, the name represents atransport-independent name for the entire servicelet.

For each service that the servicelet publishes, thereis a single hprovides i element describing that

service. At a minimum, each service has a name(which can be concatenated to the end of theservicelet name URI to get the full address of thespecic service) and some way to indicate how theservice is implemented. The specic implementa-tion technology used will select exactly how the

code is executed (see the section

Runtime archi-tecture ).

Servicelet developmentTypical development in Colombo begins with aWSDL document (Colombo supports only the WSDLdocument/literal style, believing this is the directionin which the industry is headed and this is the mostconsistent model from a Web Services architectureperspective). Data types are described by using XMLSchema, and WSDL port types represent serviceinterfaces.

Colombo tools generate mappings from XML Sche-ma data types into Java data types, generatingcustom classes for reading, writing, and manipulat-ing the data from the service implementation(Colombo structs ) to enable future support of alternative data denition languages (such asRELAXNG schema language for XML for example).Colombo does not strictly follow any of the existingconventions for mapping Java and XML Schematypes because strictly following any of the conven-tions would signicantly detract from the simplicity

of the mapping of Colombo

structs

to Java types.The serialization and deserialization code is built ontop of a pull parser

18interface.

In addition to mapping data types, Colombo toolsgenerate code artifacts that allow servicelets toprovide or to consume Web Services interfaces(corresponding to the required and provided inter-faces of the deployment descriptor). To provide aWeb Services interface, a skeleton and an adapterare generated out of the WSDL port type: theskeleton denes the Java interface that must beimplemented by the service author, and the adapteris the class that coordinates all the reading or writingof the message payload (not including the transportand protocol headers) and contains logic to invokethe desired method on the skeleton.

To invoke a service a stub is generated from theWSDL port type. The stub is similar to the adapter inthat it coordinates the reading or writing of thepayload; however, instead of invoking methods

Figure 4A servicelet.xml file


9/22

directly on an interface, the stub makes use of aservicelet manager to make the calls.

Policies may be attached to the binding sections of the WSDL documents for required and providedservices, indicating QoS policies that are required for

the interactions. At deployment, these policies areextracted and factored into the computation of theeffective policy of the servicelet. (See the section Policy framework for additional details.)

Servicelets in JavaServicelets dened in Java currently support onlyone provided system service and may support oneor more required services. A servicelet implemen-tation consists of regular Java code, usually imple-menting a generated skeleton. The skeleton mayprovide access to the payload of incoming messages

in one of three possible ways: (1) raw incomingXML stream as pull parser events, (2) XMLinformation set (infoset) preserving a form such asthe document object model (DOM), or (3) staticallymapped Java data types. Whatever the choice, acorresponding generated adapter provides the linkbetween the servicelet implementation and the restof the platform. The return value of each methodconstitutes the response to the operation.

Because the servicelet programming model itself isstateless, every method in a servicelet implementa-

tion takes a servicelet context as input in addition tothe payload of the incoming message. By the time acall arrives at the implementation code, the systemhas already looked up its servicelet context anddeserialized the payload into whatever format isrequired by the skeleton. The servicelet context hasaccess to any instance-specic data values. Inaddition, it looks up the stubs of both requiredservices and system services. The servicelet imple-mentation can then simply invoke these services bycalling the corresponding Java operations directlyon the stubs.

Consider a servicelet that offers an address bookservice address by means of an addAddress oper-ation. Implementation of this operation invokesanother service that manages a directory of phonenumbers. The corresponding code snippet is shownin Figure 5.

The endpoint of the invoked service is specic to thecontext passed in. Therefore, different calls of this

method (by different servicelet instances) may sendthe phone message to different implementations of the phone service, with different policies applied.We will discuss endpoint management, policies, androuting in subsequent sections of this paper.

A Java servicelets deployment descriptor extendsthe basic one described earlier. It adds the Java classcontaining the implementation and the class con-taining the adapter to the provided service. It addsthe Java class containing the stub to each requiredservice. Note that the adapter is not relevant to thedeveloper.

Servicelets in BPELWeb Services can be authored using the BusinessProcess Execution Language for Web Services(BPEL4WS, to be renamed WS-BPEL by the OASISe-business standards consortium, and usuallyreferred to as BPEL ). A BPEL process containsa set of partnerLinks that model bidirectionalconversations between the process and other ser-vices. A partnerLink can specify two WSDLportTypes, the rst provided by the process and asecond provided by the partner service. The busi-ness process is encoded by providing control logicthat uses a set of primitive activities for messageexchange, data manipulation, and so forth.

A BPEL process embodies some of the prominentcharacteristics of servicelets: it is inherently con-versational due to partnerLinks, and its compositionmodel is based purely on portTypes instead of actualphysical endpoints. It therefore allows for special-ization of particular instances through the charac-teristics (policies, endpoints) of their conversations.

The implementation of the servicelet is the BPELprocess itself, and its runtime consists of a BPELprocessing engine. The state of a BPEL serviceletinstance consists of the values of its variables andthe state of the process navigation. The conversa-tions of a BPEL servicelet are dened by partner-Links. A one-sided partnerLink becomes aninbound-only or outbound-only conversation, and atwo-sided partnerLink becomes an inbound-and-outbound conversation. The portTypes provided bythe process are all those whose partnerLinks havean inbound component. Conversely, the servicesused by the process are all those whose partnerLinkshave an outbound component. As in the Java case,



10/22

the outbound conversations must be provided withan endpoint reference before they can be invoked atruntime. There are multiple ways in which this canoccur: (1) at deployment time, to be used by each

created servicelet instance as a default endpoint; (2)on an instance-by-instance basis at some later timeeither by means of a ReplyTo in an incomingmessage or by means of the explicit copying of anendpoint in the BPEL process through the BPELassign activity; or (3) a combination of the two inwhich the default endpoint for each outboundconversation is used as long as it is not overwrittenin a particular instance using (2).

A BPEL process instance uses correlation sets toallow message exchange activities to correlate

messages sent and received by specic serviceletinstances. These are elds of application datapresent in the messages that maintain constantvalues during the interaction with a particularservicelet instance. This property allows the BPELruntime to use those correlation set values formessage routing. To clarify the interplay of correla-tion-based routing and WS-Addressing-based rout-ing (using endpoint reference data), a set of precedence rules must be introduced. In Colombo,correlation set routing is used only if middleware-based routing is unable to nd an instance.Correlation set values are veried and updatedregardless of the mechanism used to route amessage, because the BPEL specication requiresthat an application-level error be signaled if theinstance found using middleware-based routing hasdifferent correlation values.

To summarize, a BPEL servicelet consists of multi-ple conversations that provide and consume anumber of services, a single implementation con-

sisting of the BPEL process denition, and anyendpoints and policies for these conversations.

RUNTIME ARCHITECTURE

The Colombo runtime architecture consists of threemajor components: a SOAP-based message-pro-cessing engine, a set of servicelet managers, and apolicy framework. The message-processing engine isthe backbone of the Colombo runtime, providing themeans by which data is transferred to and fromservicelets and QoS policy is enforced. The service-let managers connect the Colombo message engineto the individual servicelets, helping isolate theservicelet programming model from implementationartifacts and transport details. Finally, the policyframework is responsible for managing and enforc-

ing QoS characteristics for services running inside of Colombo. The following subsections describe eachof these components in more detail.

The message-processing engineLike most other middleware platforms, Colombo isat its core a message processing engine. Messagesow into the system via a communications channel,and are examined and dispatched to the intendedrecipient according to a set of predened rules.

Interactions are discussed in this section from thepoint of reference of the servicelet. The term request refers to a request directed to a Colombo-hosted service (a servicelet). The term response

refers to the message sent by a servicelet to answer arequest. The term invocation indicates a message(other than a response) sent by a servicelet toanother service, while invocation response refersto the response message coming back to theservicelet, which is triggered by the invocation

Figure 5Address book service code

public void addAddress(ComponentContext myContext, NameAndAddress nameAddr) { PhoneNumberServiceStub pns = (PhoneNumberServiceStub)myContext.lookup(phoneService); PhoneAdditionInput pai = new PhoneAdditionInput ( ) ; pai.setName(nameAddr.getName( ) ); pai.setNumber(nameAddr.getNumber ( ) ); PhoneAdditionReturn par = pns.addPhoneNumber(pai); }



11/22

message (we assume here the operation invokedwas a request/response operation).

The term channel, unless otherwise noted, refersto the messaging protocol and transport used totransmit Web Services messages, for example SOAP

or HTTP. In the case of Colombo, there is anassumption that SOAP denes the messaging andserialization format, whereas typically HTTP carriesthe XML envelopes. Colombo allows replacement of the underlying communication protocol (replacingHTTP by TCP/IP for example), although the onlycommunication protocol currently available isHTTP.

Message context refers to contextual informationassociated with a specic message, such as theoriginator of the message, and is not to be confused

with the servicelet context that was mentionedearlier, although both are used during the process-ing of a message.

Colombos message-processing pipeline implementsa one-way messaging model. While Web services, ingeneral, support other types of interaction patterns,such as synchronous or asynchronous request/response, the Colombo architecture does not assumeany particular message exchange pattern (MEP).(See References 3 and 5 for typical Web-serviceexchange patterns.) On top of the one-way core

message-processing engine, Colombo uses WS-Addressing9

mechanisms to build support for thecommon request/response MEP. Other MEPs can bebuilt on top of this framework once the appropriatesupport mechanisms (message headers typically)are provided.

Colombo partitions all exchanged messages into twosets and creates a separate execution path for eachone of them. The rst execution path processesincoming messages, including requests and invoca-tion responses, while the second processes outgoingmessages: responses and invocations. This factor-ization is sufciently generic to potentially enablethe execution of arbitrary MEPs, and supports therequirements of generic message-based QoS proto-cols, such as atomic transactions, reliable messag-ing, or security. The result is to decouple theprogramming-model-level decision of which MEPsare more suitable when using a particular pro-gramming language for a particular application fromthe architecture of the runtime message processor.

The same benet applies when we consider specicQoS protocols instead of MEPs.

As a result, the programming model exposed byeach servicelet realization (e.g., Java or BPEL)remains consistent across communication mecha-

nisms. For example, the current invocation patternsupported by Java servicelets ts naturally with thesynchronous request/response characteristics of HTTP, but works consistently when asynchronousresponses are demanded (according to the use of theReplyTo header in WS-Addressing, for example).BPEL servicelets are able to support both synchro-nous and asynchronous request/response opera-tions and can take explicit advantage of theexibility of the platform (both are also, of course,able to perform one-way invocations, which is notnatural to HTTP). The more complex interaction

patterns are layered on top of the one-way messag-ing model, and the issues involved are isolated inthe channels and in the servicelet managers. Thechannels are responsible for managing the details of the transport and protocol; for example the SOAP/HTTP channel is responsible for managing the factthat HTTP is a synchronous request/responsecommunication protocol.

Inbound message processingFigure 6 shows the message ow into a Colomboservicelet and represents the executing path fol-

lowed when a new request or an invocationresponse is received. When one of these messages isreceived, (1) the incoming connection is handed off to an available worker thread or queued up if noneis available. When a worker is available, thetransport headers (e.g. HTTP headers) are strippedfrom the stream and processed and (2) a newinstance of the XML parser representing the SOAPmessage is handed over to the SOAP headerprocessor (the parser instance is passed along themessage-processing path because it contains andrepresents the SOAP envelope). The header infor-mation is extracted and stored (3) into a messagecontext structure by using preregistered objectmappings. By mapping SOAP headers to Javaobjects in advance, each of the consumers of theheader information is directly presented with thisinformation in a well-dened, communication-pro-tocol-independent format.

The SOAP message body is not read until themessage is actually delivered to the servicelet, thus



12/22

avoiding unnecessary parsing and data mapping incases when the message is not delivered to theapplication because of the action of intermediateQoS protocol handlers. In some instances, however,

it is not possible to delay the complete parsing of themessage because complete information is demandedby an intermediate policy processor, such as whendigital signatures are validated.

After SOAP headers are extracted, the message ispassed off to a dispatcher module (4) where routingand processing information is retrieved from WS-Addressing message information headers. The in-formation retrieved from these headers is used toidentify the target service instance and to retrievethe policy conguration that applies to the con-versation.

Once the target service has been identied and theconversation details have been accessed, conguredpolicies are enforced. The policy handlers (describedin the subsection Policy enforcement ) may ap-prove the delivery of a message, reject the delivery,or defer further processing. For example a reliable

messaging handler may delay delivery of a messageif earlier messages in the sequence have not yet beenreceived. Policy handlers generally operate solely onthe message context provided. If the message

adheres to all of the applicable policies, it isdelivered to the appropriate servicelet manager (6)for dispatching to the actual servicelet implementa-tion and instance (7).

The servicelet manager may at this point decide thatthe connection to a channel is no longer required,based on the MEP within which the message hasbeen exchanged; for example, if the operation is aone-way MEP or a response has already beentransmitted. In this case the manager noties thechannel, which may decide whether to close downthe outstanding connection or to continue process-ing further messages, such as in the case of apersistent HTTP connection.

Outbound message processingOutgoing messages, responses (including most faultmessages), and service invocations follow a similar,but reversed, path. This is shown in Figure 7 .

Figure 6Inbound message flow in Colombo

SOAP/HTTPChannel

Dispatcher ServiceletManager

Servicelet

SOAP HeaderProcessor

(4)(1)

(7)(6)

(3)

(2)

HTTPProcessor

PolicyFramework

(5)

Figure 7Outbound message flow in Colombo

ServiceletManager

DispatcherServicelet

SOAP HeaderProcessor

HTTPProcessor

PolicyFramework

SOAP/HTTPChannel(4)(1)

(7)(6)(3)

(2)(5)



13/22

Invocations and responses originating in a serviceletinstance (1) are passed on to the outbound messagepipeline by the servicelet manager (2). As withincoming messages, outgoing messages have mes-sage context associated with them, some of whichmay be derived from previously received messages,

as is the case with responses, or from the cong-uration and state pertaining to the conversation onwhich the message was exchanged. Outboundmessages undergo policy-enforcement-routine pro-cessing as dened by the channel conguration (3);just as in the incoming case, the policy handlers mayinterrupt the processing if appropriate. If themessage passes inspection, it is sent over theappropriate channel for transmission (4). Informa-tion contained within the message context is writtenon the message (5); then the channel serializes andtransmits the message (6 and 7).

Colombo support for WS-AddressingMany of the difculties that arose during develop-ment of the Colombo runtime centered on issuesregarding the WS-Addressing specication.

9Here

we describe how Colombo supports WS-Addressingand the impact of this specication upon messagerouting. WS-Addressing denes a set of messageinformation headers (SOAP headers) that providemessage routing and correlation information.Figure 8 shows a sample request message with WS-Addressing headers in a SOAP envelope (with anempty SOAP body).

For each request, Colombo requires the WS-Ad-dressing To and Action headers to be present. Aswas mentioned earlier, Colombo uses WS-Address-ing headers to identify the target of an incomingmessage. The To header is used to route the messageto the appropriate service and hence to the correctservicelet. The Action header, in turn, identies theoperation being invoked on that service, and thusidenties the message exchange pattern (i.e., itindicates whether the message is one-way or part of a request/response exchange.) In addition, a subset

of the SOAP headers present in the inbound messagemight correspond to WS-Addressing referenceproperties and is used to direct the message to aparticular servicelet instance (or servicelet contextinstance).

Reference properties are specic SOAP headers thathave been previously communicated to the servicerequestor with the endpoint reference of the targetservice instance (possibly sent in the ReplyTo eld

of an outbound message), and that the requestormust place on new messages directed to theservicelet instance. Colombo uses a single, well-dened, reference property (the Colombo instanceID ) to identify instances, but its value is otherwiseopaque to requestors. The values of the headers of

the To and reference properties are sufcient toidentify the servicelet conversation and retrieve thecorresponding conguration parameters (such asnegotiated policy settings) or conversation state(recall that each servicelet instance can maintainonly one simultaneous conversation with eachservice partner.)

Request/response operations, as indicated in theWSDL document for the service, also require thatthe ReplyTo header be present. The ReplyTo headerindicates where the response message should be

directed. A specic

anonymous

URI dened bythe WS-Addressing specication is used to indicatethat the delivery mechanism for the reply messagewas provided out-of-band. In particular, this coversthe case of synchronous request/response interac-tions in which the response is delivered through theopen connection as part of the HTTP response.Observe that the semantics of the ReplyTo header inWS-Addressing requires the runtime to dynamicallydetermine, based on the inspection of the ReplyToheader, whether a response needs to be returnedsynchronously over the open HTTP channel or

whether a new connection needs to be created todeliver that response to a different address. Throughmanipulation of the headers, WS-Addressing allowsthe service requestor to force an asynchronousmessage exchange over an otherwise synchronouscommunications transport.

When a request for a request/response operation isreceived by the Colombo message processor with an anonymous ReplyTo , the HTTP channel is keptopen until the operation returns and the responsemessage is sent back as part of the HTTP synchro-nous response. If, however, any other URI is presentin the ReplyTo eld, the HTTP connection is closedand a 200 OK returned. Next, a new HTTPconnection to the address specied in the ReplyTo isopened and used to deliver the response messagereturned by the servicelet, resulting in the asyn-chronous delivery of the response.

The use of ReplyTo in WS-Addressing is not strictlylimited to request/response MEPs. When received as



14/22

part of an invocation response or a request (exceptin the case of the anonymous URI), the Colombomessage engine uses the ReplyTo eld to bind, forthe duration of an extended message exchange, theendpoint address of a service partner. This is

particularly relevant in the case of the interactionbetween a BPEL process instance and a servicepartner. The scope of the ReplyTo header isinterpreted in this case more broadly and, in effect,provides an in-band mechanism to support con-versation migration (because a new value of theReplyTo address may be communicated with anyincoming message). All future invocations to thatpartner will then be delivered using the new URI.

Colombo supports all WS-Addressing headers asdened in the WS-Addressing specication ( FaultToto direct faults, MessageId for message correlation,etc.), but we will not describe their operation here.Refer to the WS-Addressing specication for detailson the semantics of these additional headers.

9

Note that Colombo currently assumes that all of theURIs specied by means of WS-Addressing mecha-nisms are network routable (e.g., when performingan invocation, the To header contains enoughinformation for the connection to be opened),

although it would not be difcult to add a layer of indirection for URI resolution. However this maymake interoperability with other systems moredifcult.

The servicelet managerA servicelet manager provides the connective layerbetween servicelet implementations and the rest of the systems infrastructure. Different implementa-tion runtimes have different requirements andformats. Therefore, having different serviceletmanagers for each kind of servicelet enables thereuse of most of the common SOA infrastructurewhile still allowing specialization for differentruntimes. Examples of servicelet types requiringdifferent servicelet managers include Java service-lets and BPEL servicelets. In order to add support for

additional servicelet types to the platform, a newservicelet manager that hooks the new serviceletsand their runtimes into the rest of the Colombomachinery can be added. At the very least, aservicelet manager interfaces with the SOAP pro-cessing machinery and the policy handlers, serial-izes and deserializes message payloads into and outof the correct format, and manages instances(creation, destruction, and routing).

Figure 8Sample request message


15/22

In cases such as Java, where the language itself doesnot have mechanisms to represent conversations,the developer needs programmatical access topartner representations and a language-specicinterface that complies with the WSDL portTypebeing implemented. To provide this capability and

shield the developers code from dependencies onthe servicelet manager, stubs, skeletons, and adapt-ers are generated. The stubs and skeletons providethe layer of abstraction for the developer code. Thestubs and adapters also provide the glue-code thatinterfaces with the servicelet manager. These arethen used by the servicelet manager to handleserialization and deserialization of data types.

The invocation sequence in the case of Javaservicelets is as follows: the manager passes theservicelet context and the parser to the generated

adapter, which uses a

read

method dened in thegenerated target Java class to parse the remainder of the message. The appropriate method is theninvoked on the skeleton, which contains the busi-ness logic for the operation. Note that the adapter isstateless and does not maintain a reference to theskeleton. There is one adapter instance per adapterclass, and each skeleton reference is passed to theadapter, along with the context and parser, at thetime of invocation. After the skeleton methodinvocation is completed, the return value is writtenout by using the typed XML serializer.

BPEL, on the other hand, is natively conversational.It provides a representation for conversations basedon WSDL portTypes (partnerLinks), as well asactivities to interact with partners along theseconversations. Therefore, there are no stubs andskeletons to expose to the BPEL servicelet devel-oper. His or her interaction will always be strictlywith standardized XML formats (BPEL, WSDL,XPath, XML Schema), especially BPEL activities.The BPEL servicelet manager therefore has thechoice of whether to use static stubs and adaptersinternally to aid in reading or writing messagepayloads or to do the serialization and deserializa-tion dynamically itself. The latter option is currentlychosen in Colombo.

Handling service invocationsAs noted earlier, the mechanism by which aservicelet invokes one of its required servicesdepends on its implementation language, that is,either a call to a stubs operation in Java or through

the activation of an invocation activity in BPEL, orthrough whatever other mechanism a newly sup-ported implementation language would provide.Whichever way it occurs, a request for an invoca-tion eventually reaches the relevant serviceletmanager. The servicelet manager then creates a

Colombo message. A new Colombo outgoing mes-sage is always assigned a unique identier known asa MessageID. The MessageID is serialized into amessage header. If a response is expected, theservicelet manager registers the message in anoutstanding-request registry, using the MessageID asa key. Finally, the servicelet manager hands theColombo message to the message-processing ma-chinery so that it can be sent to the partner.

In the Java case, the servicelet makes a request to itscontext to retrieve a stub. When a method is

invoked on the stub, a sequence of events occurs,which are essentially the inverse of the adapterinvocation described earlier. Typed XML serializersare used to write the argument types required by theoperation being invoked.

The response to the invocation arrives separately asan incoming message to be dispatched to a waitingservicelet instance. When a message arrives at aservicelet manager, the latter has to nd outwhether it is a new request or the response to aprevious invocation. The servicelet manager checks

the RelatesTo eld in the header. Following WS-Addressing, the value of this should be theMessageID from the invocation request message.Therefore, the servicelet manager can use this valueto look up in its registry of outstanding invocationsthe invocation to which the MessageID belongs.Once found, the servicelet manager can dispatch theresponse appropriately.

Handling service requestsUpon deployment, each servicelet is registered withthe relevant servicelet manager (Java, BPEL, etc.).Once a message comes into the system, the relevantservicelet manager is identied and handed themessage. The servicelet manager, upon receiving anincoming request, has to nd a servicelet instance toconsume it or create one if none is found. Thesystem will ask the servicelet manager for theinstance of the conversation corresponding to themessage. The system will also do any policy-relatedrequired work based on that information andeventually return to the servicelet manager with the



16/22

message so that it can be handed to and processedby the instance. Colombo uses a single, well-dened, reference property (the Colombo instanceID ) to identify instances, but the value of thereference property is otherwise opaque for request-ors.

The default mechanism for looking up a conversa-tion instance is to use the WS-Addressing headers.The uniform resource locator (URL) informs theservicelet manager which servicelet should consumethe message. The servicelet manager then uses anyavailable reference property headers to nd out if there is an already existing instance to which thismessage should be routed. If there are no referenceproperties and the servicelet manager does not haveany alternative routing schemes (such as BPELcorrelation sets using the application data in the

message), then the servicelet manager returns a newconversation instance for the appropriate servicelet.For optimization, the creation of the serviceletinstance itself can be delayed until the messageneeds to be processed.

Once the system returns to the servicelet managerfor the actual dispatching of the message to theinstance, the servicelet manager simply passes it on.At this point it may create a new instance if it needsto. If a new instance is created, it is assigned aunique identier ( Colombo instance ID ) with

which it is registered. The message is deserializedand handed to the implementation in the dataformat it expects either dynamically by the serviceletmanager itself or by using an adapter if one ispresent. Currently we use the former in the BPELservicelet manager and the latter in the Javaservicelet manager.

In the case of a request/response operation, theresponse again goes through the servicelet manager.The servicelet manager creates a response messageby using the destination endpoint reference that itobtains from the conversation context, the actualmessage content, and relevant information from theoriginal request such as a RelatesTo headercontaining the requests message ID. A ReplyToheader is added containing the URL of the serviceletalong with the unique identier of the instance as areference property. This is then handed to theoutbound dispatcher along with information on anypolicies that need to be applied to the message on itsway out.

Updating endpoint referencesOnce an instance is created by a servicelet manager,the endpoint references of its provided services(already containing a URL) are updated with areference property consisting of the instance identi-er. It is also registered with the servicelet manager

by using the instance identier.

The services that a servicelet invokes may alsochange their endpoint references at runtime. Thesechanges occur when a request message arrives withan endpoint reference in the ReplyTo header that isdifferent from the one saved in the serviceletinstance information. In the section Colombosupport for WS-Addressing, we explained how thisis done when there is a ReplyTo header in themessage: the endpoint reference in the ReplyToheader overwrites the one saved in the conversation

instance, provided that the former is not anony-mous. A servicelet implementation may also askthat the endpoint reference of an active instance beupdated. In this case, it needs to inform its serviceletmanager so that the required endpoint referenceupdates take place. For example, in BPEL, one of thecapabilities of the assign activity is to copy anendpoint reference passed by an application mes-sage into the endpoint reference to be used insubsequent interactions along one of its partner-Links (conversations).

Instance deactivationThe servicelet manager deregisters servicelet in-stances once they are deactivated and are no longerable to consume messages. The cause of deactiva-tion will depend on the type of servicelet (and itscorresponding servicelet manager). For example,once all the activities in a BPEL process instancehave been completed, that instance must be dereg-istered because it can no longer process messages.Another example is in the case of a Java servicelet,where a deactivate operation can be called at anytime programmatically from within the implemen-

tation.Policy framework As described earlier, a key feature of SOAs is theexplicit declaration of functional as well as QoScapabilities and requirements in agreed-upon, ma-chine-readable formats. In the Web Services frame-work, policies are used to refer to meta-data for QoSattributes of services. The WS-Policy language

6

denes a base language and operators for policy



17/22

assertions; this is designed to be extended bydomain-specic languages (such as languages fordening security or transactional policy assertions)to provide a rich framework for dening policies.

Policies are general statements about QoS and are

attached to Web Services. A single service denitionmay have multiple policies attached to it simulta-neously, at various levels of granularity (forexample, to the service as a whole, a particularendpoint, an interface, an operation, or even aparticular message type). In Reference 19, trans-action policies are attached to BPEL processes.These policy attachments may be part of the servicedenition or may be externally specied. The WS-Policy Attachment specication

20denes how pol-

icies are attached to Web services.

Colombos policy subsystem is responsible forcollecting, interpreting, and enforcing policies.Policies are enforced at the level of a conversation;that is, for each message entering or leavingColombo, the policy subsystem needs to ensure thatthe message complies with the expected policy.Because policies are attached at different levels of granularity, interpreted policies need to be mergedto compute the effective policy for each suchmessage exchange.

Computing effective policy The policies that the Colombo runtime applies to theinteraction with a deployed service originate fromthree sources:

1. Service policy The policy documents associatedwith a service that is made available usingColombo. These are attached to the servicedenition or a part of the service denition.Partner services that wish to use the functionalityoffered by such a service need to comply with theassociated policies. As an example, a transactionpolicy may be associated with a service interfacefor an Internet banking service, because thesemantics of the function offered through thatinterface require transactional behavior.

2. Partner policy The policy documents associatedwith a partner service that is used by a Colomboservice. These policies represent requirements forpartners. For example, our example of an Internetbanking service might offer a loan facility. Thisoperation might make use of an external credit-check service. The banking service might require

that the credit-check service follow the sametransactional protocol so that transactions can bepropagated and credit checks can occur withinthe same transactional context as a loan requesttransaction.

3. Framework policy A policy document associated

with a particular deployment of Colombo. It isused to enumerate the capabilities of the partic-ular Colombo installation.

On deployment of a servicelet, the service policiesand partner policies for each service supported bythe servicelet are checked against the frameworkpolicy to ensure that each of the services does nothave requirements that go beyond the platformcapabilities. If any service requires a policy notsupported by the platform, deployment of theservicelet fails. Note that partner policies represent

requirements for partners; therefore, before partnersare assigned endpoints (i.e., before the abstractpartner interface becomes fully specied), theservice policy of one partner must be determined tobe compatible with the partner policy that is desiredby the other partner. In Colombo, the abstractpartner interface is fully specied at deployment.Thus, discovery of the offered policy of one partnerand the checking of it against the desired partnerpolicy of the other is assumed to have taken placebefore deployment. Doing this dynamically is aplanned future area of research (Reference 21 offers

one approach to arriving at negotiated policy).Based on this assumption, the semantics of thepartner policies are that they represent the agreed-upon, negotiated policies for the interaction betweenthe service and its partner, obtained by priormatching of the QoS requirements with partnerofferings.

Next, effective policies need to be computed foreach potential message destined to or originatingfrom the services. This may be done at deploymentor dynamically, when a message leaves or arrives ata service. In either case, the process is identical. Thepolicies attached to each input and output messageof a service endpoint are examined along with allhigher scopes in the same hierarchy, such aspolicies attached to the service endpoint, interfacedenition, or I/O-message denition. These policiesare merged to arrive at the effective policy for aparticular input or output message, as shown inFigure 9. For example, the effective policy for inputmessage of operation o1 in endpoint s1 is obtained



18/22

by merging policies P1 (attached to message type),P2 (attached to port type), P3 (attached toendpoint), and P4 (set of permissible congurationssupported by platform).

The method for comparing and merging policydenitions is implied by the WS-Policy denitionand described in some detail in References 22 and23. Simply put, policies can be represented asBoolean expressions where policy operators aremapped to Boolean ones, and policy assertions formthe terms being combined. Prior to merging orcomparing policies, they are put into a normal form(analogous to disjunctive normal form (DNF) forBoolean expressions). In this representation, each of the terms in the DNF can be thought of as apermissible combination of QoS features. A merge of two policies can be obtained by dening a con-junction of the normalized policy expressions thateach of the individual policies represents. The termsof normalized policy expressions can be compared.There are two caveats to these methods. The rstone deals with policies that have different vocab-ularies. Consider two policies where one has anassertion relating to a security protocol (for exam-ple, a requirement that messages are signed usingthe RSA (Rivet Shamir Adlerman) algorithm, whilethe second policy has no assertions dealing with thisparticular security protocol. One solution would beto disallow such comparisons, but in practice theywould likely occur often. We chose the solution of completing the policy where the term in questionwas missing, by adding its positive and negativeform to each of the terms in the DNF form of thepolicy (thus doubling the number of terms). In other

words, the policy would be extended to explicitlystate that the security protocol was supported aswell as not supported in each of the permissiblecongurations allowed by the policy (see policy-merge example later). Although this solution worksfor many practical cases, it does have inadequacies

that we have described further in Reference 22. Thesecond caveat involves dealing with effectivepolicies that allow multiple congurations (i.e., theDNF of the merged policy has more than one term).Consider the situation where the incoming messagefor a particular operation offered by a particularendpoint of the service has a DNF with more thanone term. For policy enforcement to take placecorrectly, when the message in question arrives, ithas to be veried as following the policy correctly.This is possible only if there is prior agreementbetween the service and its partner as to which of

the permissible congurations will be used. Someprotocol is needed for making this determination.This is another area of work we plan to undertake inthe future; currently, Colombo requires that alleffective policies consist only of one term. Thisrequirement is not a hindrance if QoS policies aredened narrowly.

Policy P1: RSA_Signature (Subjects must followRSA algorithm to sign messages)

Policy P2: AT_Mandatory (Subjects must

participate in atomic transactions)

Normalized forms:P1n: (RSA_Signature

^

!AT_Mandatory) v

(RSA_Signature ^

AT_Mandatory)

P2n: (AT_Mandatory ^

RSA_Signature) v

(AT_Mandatory ^

!RSA_Signature)

Final merged policy: ATMandatory ^ RSA_Signature

Policy enforcement After effective policies are computed, the enforce-ment mechanism for each effective policy can be putinto place. As in the case of computation of effectivepolicies, this can be done either at deployment ordynamically, when a relevant message is beingprocessed by Colombo.

Information relevant for policy enforcement (suchas transaction IDs or message digests) is carriedalong with messages as header information. Thisinformation is serialized or deserialized by code that

Figure 9Calculating effective policy for operation o1

Colombo Server

PolicyP1

PolicyP2

PolicyP3

Service Definition

Message m1Message m2Message m3Port type P1 Operation o1

Input m1 Output m2 Operation o2 Input m3Binding b1Service s1Service s2

Policy P4

ServiceDefinition



19/22

is specically designed to deal with data followingthe requirements of a particular message channel(for example, according to SOAP rules). Forincoming messages, deserialized header informationcan then be consumed by policy handlers to performthe function required by a particular policy, such as

recording message arrival or departure in the case of a reliable messaging policy. For outgoing messages,the policy handler performs the function mandatedby the protocol and adds any relevant headerinformation (such as a message ID in the case of areliable messaging protocol) to the message. Thisinformation is later serialized by the relevant headerprocessor before the messages departure from thesystem.

The mechanism for policy enforcement is thus alinear chain of policy handlers, customized for a

particular policy. For example, if a message has anassociated policy requiring message reliability andparticipation in a 2PC (two phase commit) trans-action protocol, Colombo has to ensure that relevantmessages are routed to the transaction policyhandler and reliable-messaging policy handler. Thisapproach of using the interceptor pattern to handleQoS is well known.

21,24,25

When is a handler chain computed? The procedurefor doing this involves parsing the effective policyfor a message to congure a handler chain appro-

priately. It can be performed when services aredeployed in Colombo (this is the default), or atruntime. After a handler chain is computed, theconguration can be stored for use with futuremessages with the same effective policy. If thisfeature is disabled, handler chains are dynamicallycomputed when the need to process a particularkind of message is identied, and then the chainsare discarded. This offers the most exibility as thesystem can adapt even to changes in the effectivepolicy.

Policy handlers need access to services offered bythe Colombo framework (such as access to adatabase), the ability to invoke external services(such as a transaction coordinator service) andfeatures that affect the routing of messages withinColombo (such as the ability to interrupt or resumemessage delivery to a service endpoint). Many of these requirements are identical to the requirementsof services hosted within Colombo. Policy handlersare thus designed as services hosted within a

specialized container (the policy handler container),which offers access to the internal elements of theframework that are not available through othercontainers. Other than this important distinction andsome specialized logic for routing messages to thepolicy handler container, policy handlers can con-

ceptually be deployed and managed as regularservices and can use a programming model identicalto that used by servicelets. Currently though,Colombo comes packaged with a set of predeployedhandlers supporting reliable messaging and trans-action and security policies and does not allowadditional handlers to be deployed.

A difcult problem in policy enforcement relates tothe order in which messages are processed byhandlers within a handler chain. Our designimplicitly assumes that each policy handler works

independently, and the order of message delivery isnot relevant. This is usually not the case. Consider apolicy that requires encryption along with reliablemessage delivery. When a message is encrypted, itsheaders, including any headers used by the reliable-messaging protocol (such as a Message ID), are alsoencrypted. Thus, decryption of the message has totake place before the message is handed to theprocessor or handler of the reliable messagingheader. This is a dependency that comes out of thesemantics of the policy of that message. We plan toexplore solutions to this general problem of handler

dependencies within the chain, but currently wetreat security (in particular, encryption) as a specialcase within the policy subsystem and take care of that before message delivery to other policy han-dlers.

FUTURE WORK Work in the Colombo project continues in threeareas: completing the implementation of the runtimeplatform, extending support to developers, andtesting and measuring Colombo as a competeplatform.

Two major areas of the Web Services stack are stillnot supported by Colombo. One is discoverycapabilities, either a registry-based discovery (UDDI)or dynamic meta-data exchange (WS-MetadataEx-change). Colombo is already designed to takeadvantage of dynamic service discovery (e.g.,through dynamic policy reconguration), but cur-rently Colombo does not support service partnerdiscovery other than static binding. The second area



20/22

is the use of the business activity protocol (WS-BusinessActivity

26) to support loosely coupled

business interactions, as opposed to the tightlycoupled scenario where an atomic transactionprotocol might be used.

Support for developers will be extended by sup-porting bottom up development strategies for Javaand incorporating scripting languages (Javascript**,Perl) into the set of servicelet-supported languages.We are considering adding the capability to updatean already deployed servicelet without stopping andrestarting the Colombo server (hot update), tocomplement the existing hot deploy capability.

Finally, the ultimate goal of the Colombo project is todeepen our understanding of what kinds of middle-ware architectures are most appropriate to support

SOC environments. We are planning to test Colom-bos assumptions about the performance and sim-plicity yielded by a platform that natively supportsthe SOC paradigm through a set of performancebenchmark tests and a eld study focused on thedevelopers ease of use experiences.

SUMMARY This paper has presented an overview of theColombo platform, an experimental IBM Researchproject aimed at providing a deeper understandingof how middleware can address the requirements of the SOC paradigm. Colombos approach is to build anative Web services runtime and programmingmodel focused exclusively on the execution anddevelopment of service-oriented applications. Co-lombo thus does not address the problem of integrating legacy middleware and applications,except by assuming that they can be enabled forWeb services by using the tools and adaptersalready available in the market.

The Colombo programming and deployment modelsachieve substantial simplication by extending theservice paradigm to both application and systemservices and by concentrating on the compositionproblems. Colombo programming can be imple-mented in multiple languages; Java and BPELrealizations of this programming model are alreadyavailable. The Colombo runtime is built on anasynchronous SOAP processing engine in which apolicy-processing framework provides customizableQoS capabilities.

Colombo is an ongoing Research project. Workcontinues to provide support for service discoverystandards, management interfaces, and extensionsto the set of programming tools. The evaluation of the platform in the areas of performance, manage-ment, and developers usability is now taking place,

and is likely to yield important insight into theproblem of designing and optimizing middleware tosupport service-oriented environments.

ACKNOWLEDGEMENTSThe Colombo project is a cross-departmental proj-ect. In addition to the authors of this paper, TomMikalsen, Stefan Tai, and Ignacio Silva-Lepe fromthe IBM Thomas J. Watson Research Center andMichiaki Tatsubori from the IBM Tokyo ResearchCenter have been key contributors to the design andimplementation of the Colombo platform.

** Trademark, service mark, or registered trademark of SunMicrosystems, Inc. or Microsoft Corporation.

CITED REFERENCES1. F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi,

and S. Weerawarana, Unraveling the Web ServicesWeb: An Introduction to SOAP, WSDL, and UDDI, IEEE Internet Computing, 6, No. 2, 8693 (2002).

2. F. Curbera, R. Khalaf, N. Mukhi, S. Tai, and S.Weerawarana, The Next Step in Web Services,

Communications of the ACM , 46 , No. 10, 2934 (2003).

3. E. Christensen, F. Curbera, G. Meredith, and S. Weer-awarana, Web Services Description Language (WSDL

1.1),

W3C Note, http://www.w3.org/TR/wsdl, March2001.

4. C. Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley Professional ,Boston, MA, 1999.

5. D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N.Mendelsohn, H. F. Nielsen, S. Thatte, and D. Winer, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/SOAP, May 2000.

6. D. Box, F. Curbera, D. Langworty, A. Nadalin, N.Nagaratnam, M. Nottingham, C. von Riegen, and J.Shewchuk, Web Services Policy Framework (WS-PolicyFramework), 2002, http://www-128.ibm.com/developerworks/library/specication/ws-polfram/.

7. UDDI V3.0.1 specication, http://uddi.org/pubs/

uddi-v3.0.1-20031014.htm.8. F. Curbera and J. Schlimmer (Eds.) Web Services

Metadata Exchange (WS-MetadataExchange) (Septem-ber 2004), ftp://www6.software.ibm.com/software/developer/library/WS-MetadataExchange.pdf.

9. D. Box, E. Christensen, F. Curbera, D. Ferguson, J. Frey,M. Hadley, C. Kaler, D. Langworthy, F. Leymann, B.Lovering, S. Lucco, S. Millet, N. Mukhi, M. Nottingham,D. Orchard, J. Shewchuk, E. Sindambiwe, T. Storey, S.Weerawarana, and S. Winkler, Web Services Addressing(WS-Addressing), W3C Member Submission, August 10,2004, http://www.w3.org/Submission/ws-addressing/.



21/22


22/22

architecture, development and programming models, andsupporting infrastructure. His most recent efforts have beenfocused in the area of Web services.

Nirmal Mukhi IBM Research Division, Thomas J. Watson Research Center,19 Skyline Drive, Hawthorne, New York 10532([email protected]). Mr. Mukhi is a software engineer in

the Component Systems Group at the Watson ResearchCenter. He received an M.S. degree in computer science fromIndiana University in 1999 and is currently working on a Ph.D.degree. He has been studying programming models for Webservices, service composition, orchestration, and relatedproblems. His current area of work is in developing policy-driven, recongurable middleware for Web services.

Sanjiva Weerawarana([email protected]) Dr. Weerawarana received a Ph.D.degree in computer science from Purdue University in 1994.After a few years at Purdue as visiting faculty, he joined IBMResearch in 1997, where he worked as a research staff member in the Component Systems Group. While at IBM, hewas elected a member of the IBM Academy of Technology. Hisresearch interests are in component-oriented programming,specically component-oriented distributed computing

architectures. He has been an active contributor to IBMstechnical strategy for Web services and is an author of manyWeb Services specications including WSDL, WS-Addressing,WS-MetadataExchange, BPEL4WS, and WS-ResourceFramework. Dr. Weerawarana has implemented many of those specications and has contributed to multiple IBM Webservices products and offerings. He left IBM in April 2005. Heis a very active member of the open source community, as amember of the Apache Software Foundation and as co-founder of the Lanka Software Foundation, an open sourcefoundation in Sri Lanka. In his leisure time, he teaches at theUniversity of Moratuwa, Sri Lanka, where he lives. &

colombo: lightweight middleware for so computing

Documents