Adaptive application-specific middleware

Adaptive Application-Specific Middleware

Alan Colman, Linh Duy Pham, Jun Han, Jean-Guy SchneiderFaculty of Information and Communication Technologies

Swinburne University of TechnologyHawthorn, Australia

{acolman,lpham,jhan,jschneider}@ict.swin.edu.au

ABSTRACTThe open/dynamic environment of Service-Oriented Com-puting requires middleware that can cope with services thatare heterogeneous, and possibly unknown, unreliable or un-trusted. Service-oriented middleware also needs to supportboth, ad-hoc and long-lived relationships between such ser-vices, and provide mechanisms for service coordination andcooperation. This needs to be achieved in a rapidly changingtechnical context with standards that are continually chang-ing and evolving. This paper introduces adaptive appli-cation-specific middleware composites which are built us-ing the ROAD framework. These composites are adaptiveruntime role structures that allow services to be composedand autonomously reconfigured. In these composites, dy-namic contracts control interactions between services, setnon-functional requirements for those interactions, and mea-sure the QoS of services against those requirements. Thesemiddleware composites can themselves be encapsulated asservices that can be recursively composed and distributed.These composites can cope with changing requirements andperformance of the services they compose. Composite rolesand contracts also map naturally to business entities.

Categories and Subject DescriptorsD.2.11 [Software Engineering]: Software Architectures—Domain Specific Architectures; D.2.12 [Software Engineer-ing]: Interoperability—Distributed Objects.

KeywordsAdaptive Middleware, Service-Oriented Computing, ROAD

1. INTRODUCTIONMiddleware standards and technologies are, in general,

generic. By using a common middleware, heterogeneous ap-plications are able to communicate and collaborate. Mid-dleware technologies also hide complexity and add value to

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MW4SOC ’06, November 27-December 1, 2006 Melbourne, AustraliaCopyright 2006 ACM 1-59593-425-1/06/11 ...$5.00.

these interactions. Taking a high-level, Enterprise Appli-cation Integration (EAI) view, Figure 1 illustrates a simpleschema of two heterogeneous applications that communicatevia a conventional middleware layer that handles variousproperties related to their interaction (reliable messaging,logging, persistence etc.).

App 1 App 2

Middleware Services Directory, Messaging, Transactions, Security, ...

Figure 1: Conventional Middleware.

In more open environments typical of service-oriented com-puting, a number of shortcomings of the conventional view ofmiddleware become apparent, particularly when the middle-ware concept is applied in cross-organisational Web servicesrather than conventional middleware integration within asingle organisation. Cross-organisational composition of ser-vices involves issues such as lack of trust and asynchronous,long-lived transactions, as well as deployment issues suchthe location of the middleware in a distributed system [1].

The other major shortcoming of the conventional middle-ware concept is the necessity for all participants of an inter-action to agree on, and use, interoperable standards. In thefast-changing world of Web services, the basic technologyfor handling interactions is well established and accepted,but standards for handling more complex interactions suchas WS-Coordination, WS-Agreement, and OWL-S are stillevolving and are sometimes overlapping depending on thedomain and the originating standards body (e.g., W3C, OA-SIS, Global Grid Forum, etc.). In order to build adaptableapplications in this changing and uncertain technical con-text, it would be desirable for applications to be able tomake use of heterogeneous standards, while not being boundto any one standard. Although we cannot do without stan-dards, the challenge remains to create integrated applica-tions that can make use of the heterogeneous middlewaretechnologies, but that are not dependent on any particulartechnology. To use an analogy: programming languages likeJava can run on heterogeneous operating systems by provid-ing an independent layer (Bytecode running on the JVM)between the application code and the operating system. Inorder to preserve this Write Once, Run Anywhere approachto software development, we need to avoid tightly coupling

6

applications to their execution environment, whether thatenvironment be an operating system or middleware.

In this paper, we introduce the concept of application-specific middleware. As in conventional middleware, all mes-sages between the component services pass through a middle-ware layer. In addition, application-specific middleware pro-vides adaptive structures for the composition, control of ser-vice interactions, and the measurement of the Quality of Ser-vice (QoS) of those interactions. Application-specific mid-dleware performs no domain-specific function by itself, in-stead it provides abstract functional roles that can be playedby other entities. These roles are formed into adaptive struc-tures, tailored to the particular application, for the compo-sition and control of service interactions.

Service 1 Service 2

MW2

Service 3

Service Composite Role Structure

Adaptable domain specific structure Contracts maintaining

Long-lived transactions, QoS

MW1 MW3

Application-Specific

Middleware

Conventional middleware

ROAD framework

Figure 2: Schema service composite as application-specific middleware.

As shown in Figure 2 above, application-specific middle-ware can be viewed as an extra layer that provides a level ofindirection and management between services. This middle-ware consists of a composite(s) of dynamically contractedroles which are played by the various services in the com-position. This composite role-structure is autonomouslymanaged by a composite organiser. The roles, contractsand organisers that constitute the application-specific mid-dleware are built from a generic library called the ROAD(Role-Oriented Adaptive Design) framework [3, 5]. The ser-vices that play roles can use whatever middleware standardsthey are built to, provided the service composite has adap-tors that support those standards. Therefore, the compositefunctions as an interoperability bridge [7].

Application-specific middleware in the form of role-struc-tures provides a number of advantages for service-orientedcomputing in open and dynamic environments, including theability to:

• dynamically compose heterogeneous services by cre-ating role instances, associating those roles with con-tracts, and binding concrete services to those roles,

• create contract instances that specify permitted inter-action patterns (e.g., business protocols) and controlactual interaction between specific instances of roles(as distinct from policies that apply to all instances ofa type),

• specify non-functional requirements (e.g., QoS) on con-tracted interactions between roles, and to measure theperformance of interactions with respect to those re-quirements,

• dynamically alter those requirements and add new re-quirements,

• autonomously reconfigure the relationships between ser-vices in response to changing requirements or chang-ing environments (e.g., dynamic selection of servicesto optimise some QoS criteria), and

• create both ad-hoc and long-lived relationships be-tween services, and to store the state of those rela-tionships; that is, to implement a virtual organisation.

The rest of this paper is organized as follows: in Section 2,we will introduce, as a motivating example, an application-specific middleware that assists institutional clients (i.e. li-braries) to purchase books from Web-Service suppliers. Sec-tion 3 briefly discusses the function and structure of compos-ite role structures as defined in the ROAD framework, andhow these composites can be recursively composed and dis-tributed. We then show how a middleware composite adaptsitself in response to changing requirements and the changingperformance of the services attached to the composite. Inparticular, we examine how QoS and other non-functionalproperties can be handled. Section 4 discusses some issuesthat arise from this approach and Section 5 discusses relatedwork. Section 6 concludes with a summary of the main ob-servations and future work.

2. A MOTIVATING EXAMPLEIn this section, we will illustrate the concept of application-

specific middleware by describing a middleware role struc-ture that mediates between purchasers and suppliers of books.This structure allows services of various types (clients, sup-pliers, brokers) to be dynamically attached and regulated sothat clients can purchase books from suppliers on the bestterms.

Large institutional libraries purchase many books frommany suppliers. The same book can often be sourced frommultiple suppliers. Because libraries are such large pur-chasers of books, suppliers have an interest in providinga high level of service to such clients (competitive prices,quick turn-around etc). Likewise, libraries have an interestin maintaining good working relationships with key suppli-ers. As distinct from an individual purchase transaction, theterms of a library-supplier relationship are more long-lived,but the properties of the relationship often vary. The corre-sponding variables (we will call them terms-of-trade) couldinclude discount, if any; time from order to delivery; termsof payment (prepay, on invoice, days to pay); past reliabilityof supplier; value of trade with supplier; reputation of sup-plier (particularly if purchases are prepaid); and durationof relationship. A library will have desired values for thisset of variables: low price, payment 30 days on statement,delivery not more than 2 weeks, etc.

Application-specific middleware will provide a structurethat allows libraries, book suppliers and broking services toplay role(s) in that structure. A library service submits re-quests for quotes and book orders over its service interface.Book suppliers provide automated Web service interfaces for

7

book search, quoting, ordering, and payment. The protocolsfor these transactions and the terms of trade vary betweeneach supplier, and the broker needs to be able to work withall of them. The responsibility of the broker is to purchasethe books needed by the library, with optimal terms of tradefor the library, while maintaining strong relationships withsuppliers. Therefore, the broker has to assess the value ofeach transaction to the library (not just the price). It alsohas to ensure that the library and supplier have matchingorder, payment and delivery protocols. In practice, thereare many different protocols that client, broker and suppliercan follow, for example, payment before delivery, paymentafter delivery, payment on invoice, and client either payssupplier via broker or directly, etc. The application-specificmiddleware has to be flexible enough in order to accommo-date these variations and enforce them at runtime.

In assessing the library’s optimal terms of trade, the bro-ker has to abide by the purchasing policies and preferencesset by the library. These preferences often have to be traded-off. For example, the broker can source books either locallyor from overseas. While overseas books are often cheaper,delivery times are typically longer. Methods of paymentalso vary between local and overseas suppliers. Most (notall) local suppliers are happy to supply books on invoice asthe library is a reliable payer. Overseas suppliers invariablywant payment up front. The library therefore sets a pur-chasing policy (general terms-of-trade) that provides rulesto the broker so that it can trade-off these variables. Forexample, it instructs the broker that it prefers to pay oninvoice, but that it is prepared to pay upfront if the totalcost saving is greater than 15%, provided the supplier has agood reputation. As well as these general terms-of-trade, alibrary will have specific relationships that have been nego-tiated with each of its suppliers. The specific terms-of-tradewill define the rules for transactions between those parties(protocol for payment, discounts, etc.). The advantage fora library using a broker is that the broker hides many ofthe details of relationships with suppliers, and automatesthe supplier selection process. A library, broker and thesuppliers can be thought of as forming a virtual enterprisethat creates and maintains dynamic business relationshipsof varying duration between its entities.

3. MANAGED ROLE STRUCTURESIn this section, we will show how the above scenario can

be represented by managed role composites built using theROAD framework, and discuss the characteristics of thosecomposites. Figure 3 shows a role structure that representsthe organisational relationships within a Broking compositebetween clients, brokers and vendors. Client role instancesare created for each library. Each book seller service is repre-sented by a different role, rather than having a single vendorrole attached to different seller services at different times.

Multiple vendor and broker roles are required becauseeach broker instance represents a particular library client,and the relationship between a broker and vendor containsthe specific terms-of-trade and the history of actual ‘perfor-mance’ of each parties with respect to the relationship. Thisis because the agreed specific terms-of-trade and history oftransactions needs to be persistent for each broker-vendorrelationship. Note that it is possible for a concrete service(e.g. the Broking Agent Service) to play multiple roles (i.e.Broker1 and Broker2) in an application-specific middleware

Library B

Broking Composite

b1: Broker

c1: Client

General terms-of-trade BOrganiser

... Amazon Barnes & Noble

Broking Agent

v4: Vendor v3:

Vendor v2: Vendor v1:

Vendor

Specific terms-of-trade

Middleware Role Structure

Concrete Services

b2: Broker

c2: Client

Library A

plays

Service instance

Functional role instance

Composite organiser

Composite

Contract instance

Figure 3: Broking Composite with multiple clients.

composite.As discussed in Section 1, an application-specific middle-

ware composite does not perform any domain function byitself, rather it defines and maintains specific relationshipsbetween concrete services via their roles. In our example,the client, broker and vendor roles are placeholders that de-scribe a ‘position description’ within an organisational struc-ture. Likewise, the terms of contracts can be defined declar-atively. Both contract and role descriptions can be passedto a middleware composite factory that dynamically createsthe runtime organisational structure. In the following, wewill discuss the properties of roles, contracts, organisers andcomposites that make up this middleware layer.

Application-specific middleware can be created using theROAD (Role-Oriented Adaptive Design) framework [3, 5].The ROAD framework is a set of abstract Java classes usedto define adaptable software “organisations.” These ab-stract classes are extended by application developers to cre-ate a software system that can autonomously adapt both tochanges in the non-functional requirements, and to changesin the performance of the functional services or other func-tional software entities that are bound to the organisationalstructure.

In ROAD, functional roles are first-class runtime entitiesthat hold abstract service definitions. Because the servicesthat play instances of roles can be transitory (for exam-ple, there may be no service currently available to play arole), roles store incoming message in queues. Roles alsoperform the function of message routers as the services thatare bound to a role in an organisational structure do notdirectly reference each other. Roles may be contracted toa number of other roles (e.g., a broker role instance in Fig-ure 3) and, therefore, need to forward messages from theirservice-player to the appropriate associated role. While rolesare implemented in Java, they may need to communicatewith a heterogeneous range of services using different con-ventional middleware technologies, and adaptors are bound

8

to roles as needed. From the role’s viewpoint these adap-tors are proxy services that hide the heterogeneity betweendifferent services. They convert messages from the middle-ware’s native Java to the appropriate format (e.g. SOAPif the remote service is a Web service) and provide otherproperties needed for interoperability (e.g. WSDL serviceendpoint references) [4].

Contracts perform three functions in a ROAD organisa-tional role structure: composition, interaction control, andperformance monitoring. A ROAD contract consists of oneor more terms that define a dynamic, rich association be-tween two roles. Contracts are implemented using associa-tion aspects [5, 14], an extension to the AspectJ compiler.Such association aspects allow contract instances to be cre-ated that associate groups of objects (in this case associa-tions of role instances). By creating and/or revoking con-tract instances, the topology of the composition of roles canbe altered. As all roles (as opposed to services) are inter-nal to the organisation, ROAD contracts are also internal tothe organisation. All runtime communication between func-tional services bound to the organisation is via such con-tracted roles. ROAD contracts (being association aspects)have the ability to intercept the communications betweenthese roles using pointcut pattern matching on method sig-natures. This interception is used to prevent communicationnot authorised by the contract, and to invoke aspect advicebefore and after a transaction, to measure the performanceof the transaction relative to a term in the contract. In thisway contracts perform a similar function to interceptors inconventional middleware. Contract terms define the mu-tual obligations of the participant roles in an organisationalcontext. They define the interactions that are permissible orrequired by the participant roles, and can be used to enforcesequences of interactions. Contracts can also be used to setarbitrary non-functional requirements in the form of utilityobjects on their roles’ interactions (like SLA papameters in[10], these are separable from the contract terms). Contractsmonitor those interactions for compliance to their respectiverequirements.

Organisers create and destroy roles, make and break thebindings between organisational roles and services (serviceselection), and create and revoke the contracts between theroles. They can thereby create various configurations of rolesand services. Organisers set the performance requirementsfor the contracts they control, and receive performance in-formation from those contracts. Organisers have reconfig-uration strategies they can employ if they detect under-performance in the composite they control. In short, organ-isers provide the adaptivity to the composite application bymanaging the composition and instantiation. Organisers,along with the contracts and roles that they control, can beviewed as a middleware management layer that composesand controls the interaction of the functional services.

Each organiser is responsible for the configuration of a setof roles and contracts: a self-managed composite. In terms ofa management analogy, a self-managed composite in a busi-ness organisation would be a department. An instantiatedmiddleware composite can itself be a service as the roles in-ternal to the composite have services attached. Messages tothe composite are delegated to its internal role-players. Mid-dleware in the form of these self-managed composites cantherefore be distributed (as any service can be distributed).As a composite can itself be a service that plays a role in

another composite, it follows that composites can also berecursively composed and/or decomposed.

The ability to compose/decompose middleware role com-posites enables complex systems to be modeled. For ex-ample, a library could itself be made up of a number ofservices that are organised by a role composite. In Fig-ure 4, the broking composite instance is associated withtwo types of library services. The first type of library ser-vice (LibraryA) is itself a role composite (not all its internalroles or associated services are shown in the diagram). Li-braryA plays the Client1 role in the broking composite. Con-versely, the broking composite plays the Supplier role in theLibraryA composite. The implication of this bi-directionalrole-playing is that all functional messages between the com-posites pass through these respective roles. Such a structurewould suit composites in different organisational domains(e.g., with different owners), because each composite has aninternal role that is a proxy for the other composite. There-fore, functional coupling is kept to a single interface.

c1: Client

Library B

c2: Client

b2: Broker b3:

Broker

Library A Composite Service

Supplier

Dynamic NFRs for Client c1

... ...

Fixed NFRs for Client c2

Lib Org

...

Management interfaces Functional

interfaces

v1: Vendor

Contract measures actual performance of an obligated party (v1 played by Service1) by monitoring interactions

Service1 Player

Organiser translates ss composite requirements

into required performance for

contracts

Broking Agent

Broking Composite

Service

Players may have claimed performance

BOrganiser

dTUte: DeliveryTime

Utility

Required performance defined in utility objects attached to the

terms of the contracts that obligate the role players

Figure 4: Composition of role composites, and thesetting and measurement of NFRs.

Each self-management composite has exactly one organ-iser role (e.g. BOrganiser in the Broking Composite). Aself-managed composite has a management interface whichis the external interface of its organiser role, as shown inFigure 4. This interface performs a similar function to an“out-of-band” manageability interface in MoWS [13] in thatrequired and actual performance-measures pass backwardsand forwards over it.

The second type of library (LibraryB) in Figure 4 is nota role composite, but a basic service. It has a function-ally compatible service interface through which it interactswith the broking composite, but it has no management in-terface or organiser. While both LibraryA and LibraryB canplay roles in the broking composite (i.e. order books fromthe broker), basic services like LibraryB cannot dynamicallycommunicate non-functional requirements (NFRs) to com-

9

posites such as the Broker. LibraryB’s NFRs would need tobe set statically in advance (or through some form of super-visory control via BOrganiser).

Application-specific middleware composites can adapt tochanges in two ways: regulation and reconfiguration. Reg-ulation involves the setting of non-functional requirementsin the contracts it controls. Reconfiguration involves chang-ing the role structure by creating/destroying roles and con-tracts, or swapping services that are bound to its roles.

A composite receives NFRs via its management interface.The organiser of the composite needs to convert these NFRsinto contract terms (a process similar to intra-service com-position in [15]). In Figure 4, as both the LibraryA and theBroking composite are self-managed composites, they bothpresent a management interface over which changing NFRsflow between their respective organisers. In this case, the or-ganiser within the libraries’ acquisition departments sendsthe Broking Service NFRs relating to their general terms-of-trade. The organiser of the broking composite service (BOr-ganiser) stores these NFRs in the respective Client-Brokercontracts, and then interprets them into specific terms-of-trade stored in the Broker-Vendor contracts. As shown inFigure 4, these NFRs are in the form of utility functionobjects. The expected value of the parameters can be setin these objects (e.g., for a DeliveryTimeUtility these valuesmight given for TargetMean, BreachThreshold, etc.). As wellas storing the required performance, a utility object storesthe actual performance based on the history of interactionsbetween the contracted roles. Each utility class implementsa method calculateUtility that returns a value associated withcontract performance (e.g., InBreach, UnderPerforming, Per-forming).

Reconfiguration, the second type of adaptation, is neededwhen new services (Libraries or Book Sellers) are added to,or removed from, the composite. This can involve merelyswapping the service an existing role is playing with an-other service, or adding/removing roles and creating thecorresponding contracts. Reconfiguration can occur in re-sponse to new services being discovered, or in response toan existing service not meeting its contractual obligationsas defined by the terms of its role’s contract(s).

These changes to NFRs can only be triggered via the man-agement interface, that is, either from another composite orby a supervisory control program that can access the man-agement interface. The ability to trigger a change in require-ments or structure within a middleware composite raises theissue of which services have the authority to make changesin the composite. In our example, we would not want a bookseller arbitrarily changing the terms-of-trade with a brokeror client, it follows that some scheme of ownership rightsand security need to be established in middleware compos-ites that operate in open environments.

In the case where adaptivity is required across an organ-isational boundary, one architectural solution would be foreach organisation to deploy and maintain its own compositemiddleware. This would be the case if the LibraryA and theBroking Service had different owners (c.f. Figure 4). Thesemiddleware composites communicate via their managementinterfaces and the functional roles they play in each other(the Library composite playing the Client role in the BrokingComposite, and the Broking Composite playing the Supplierrole in the Library composite). As discussed before, there isno restriction on the distribution of composites. As these

roles can only communicate according to the rules in theircontracts, each composite can prevent the other party invok-ing unauthorised interactions. The transmission of NFRsbetween composites via their management interfaces wouldneed to be negotiated. The issue of contract negotiation ishowever beyond the scope of this paper.

4. DISCUSSIONBy its very nature, application-specific middleware re-

quires customisation. The ROAD framework assists thisprocess by providing a library of abstract classes (roles, con-tracts and composites) that can be extended to suit theneeds of the domain/application. These framework classesprovide composition, monitoring, and adaptive mechanisms.An application developer can extend the classes with domain-specific roles, contracts and composites which can largely bedefined declaratively. The library also provides a set of ab-stract contracts that define prototypical interaction patternsbetween roles (e.g. Buyer-Seller, Supervisor-Subordinate,Peer-Peer). The lack of space does not permit a descriptionof the ROAD framework in further detail; interested readersare referred to [3, 4]. A ‘proof of concept’ framework anda number of test applications have been developed. Boththe variable performance of services and the changing ofnon-functional requirements have been simulated in orderto demonstrate the adaptability of the system. A simplemitigation strategy has been implemented in an organiserplayer which is provided with a predefined list of potentialservices (service discovery has not yet been implemented).Currently, our prototype only provides Web service (WSDL-SOAP) adaptors.

Controlling and monitoring interactions using an appli-cation-specific middleware composite has advantages anddisadvantages. As described in Section 1, the compositecan act as an interoperability bridge to which middlewareadaptors can be added on an ad-hoc basis. However, if thetwo remote services that communicate via the middlewareshare the same standards (e.g., WSDL-SOAP) or are inter-operable, then a relative performance overhead is incurredin converting messages to the composites’ language (Java)and then marshaling them back to the original format. Asthis overhead can be quite substantial, the application of ourapproach is probably limited to domains that do not involvehigh loads or require rapid response times. Commercialtransactions in virtual enterprises where long-lived transac-tions predominate would be an appropriate field of applica-tion. On the other hand, based on testing of the prototypeframework, the overhead imposed by the ROAD frameworkin message interception, contract enforcement and updat-ing the performance measurement is relatively insignificantcompared to format conversion, accounting for less than 2%of the total overhead in a Web service context.

Application-specific middleware only deals with “inter-nal” contracts between roles within the organisational bound-ary, although those roles are proxies that represent externalservices. This approach does not preclude the use of exter-nal contracts [9, 10, 15] or external coordination mechanisms[2]. The internal contract that binds the proxy role to therest of the system can serve as an agreement template fordefining external service-level agreements according to theWS-Agreement standard (or a coordination context in thecase of WS-Coordination). The concept of a contract alsomaps naturally to Service Level Agreements at the business

10

level, in part because roles map better to business entitiesthan, for example, BPEL activities.

5. RELATED WORKAdaptive middleware has been an active area of research

in recent years. However, much of this work focuses onthe management of variable computational and network re-sources [6, 11] rather than focusing on adapting to changes inservice-level requirements as described in this paper. Adap-tive architectural frameworks such as Rainbow [8] have muchin common with the approach described here in that man-agment is exogenous to the services. However, Rainbow in-frastructures have global adaptation strategies (rather thanbeing modularised in a composite’s organiser) and they can-not be recursively decomposed or distributed as can ROADcomposites.

Application-specific middleware is capable of expressingservice compositions. Like BPEL, our framework is a meansof creating executable compositions, but with roles as itsfundamental unit rather than activities. Another advantageof a role-oriented approach is that it allows for the separa-tion of management code from functional code that mightotherwise be tangled. The use of contracts in our frameworkalso allows a more natural mapping to inter-organisationalbusiness contracts than do process-based approaches.

As mentioned above, ROAD complements work done onSLAs in Web services, [10, 15, 16]. In terms of frameworks,Ludwig et al. [12] have proposed the Cremona frameworkthat addresses many of the same issues as the ROAD frame-work. Cremona differs from ROAD in that it is based onWS-Agreement, and it focuses on external contracts ratherthan contracts between roles within the middleware.

6. CONCLUSIONSThis paper introduces adaptive application-specific middle-

ware composites which are built using the ROAD frame-work. These composites are adaptive runtime role structuresthat allow services to be composed and autonomously re-configured, support both ad-hoc and long-lived service rela-tionships, and provide mechanisms for service coordinationand cooperation. These composites can potentially act asinteroperability bridges between services running on hetero-geneous conventional middleware platforms. Dynamic con-tracts in these composites control interactions between ser-vices, set non-functional requirements for those interactions,and measure the QoS of services against those requirementsat runtime. These composites can reconfigure themselvesin response to changing requirements and measured perfor-mance of the services they compose. Such middleware com-posites can themselves be encapsulated as services that canbe recursively composed and distributed. Composite ser-vices communicate changing NFRs and performance dataover their management interfaces. Composite roles can beused to model business entities, and contracts also map nat-urally to cross-organisational service-level agreements.

Further work needs to be done in integrating application-specific middleware composites with standards for servicediscovery, coordination and the negotiation of service-levelagreements. Research challenges also remain in how to dy-namically generate adaptors to overcome the heterogeneityof service middleware technologies; how to represent proto-cols of services (required order of exchanged messages); how

to address different non-functional requirements such as se-curity; and how to incorporate mechanisms for negotiationbetween composites belonging to different organisations.

7. REFERENCES[1] G. Alonso, F. Casati, H. Kuno, and V. Machiraju.

Web services concepts, architectures and applications.Data-centric systems and applications. Springer,Berlin, London, 2004.

[2] BEA Systems, IBM, and Microsoft. Web servicescoordination (ws-coordination), 2004.

[3] A. Colman and J. Han. Coordination Systems inRole-based Adaptive Software. In Proc. of the 7th Int.Conf. on Coordination Models and Languages, LNCS3454, pages 63–78. Springer, 2005.

[4] A. Colman and J. Han. Adaptive service-orientedsystems: an organisational approach. Int. Journal ofComp. Systems Science and Engineering,21(4):235–246, 2006.

[5] A. Colman and J. Han. Using Associations Aspects toImplement Organisational Contracts. Electronic Notesin Theoretical Comp. Science, 150(3):37–53, May 2006.

[6] H. A. Duran-Limon, G. S. Blair, and G. Coulson.Adaptive Resource Management in Middleware: ASurvey. IEEE Distributed Systems Online, 5(7), 2005.

[7] W. Emmerich. Engineering Distributed Objects. JohnWiley & Sons, 2000.

[8] D. Garlan, S.-W. Cheng, A.-C. Huang, B. Schmerl,and P. Steenkiste. Rainbow: Architecture-BasedSelf-Adaptation with Reusable Infrastructure. IEEEComp., 37(10):46–54, Oct. 2004.

[9] Global Grid Forum. Web services agreementspecification (ws-agreement), version 1.1, May 2004.

[10] IBM. Web services level agreement (wsla) languagespecification. Technical Report v1.0, wsla-2003/01/28,IBM, 2004.

[11] M. Leclercq, V. Quema, and J.-B. Stefani. DREAM:A Component Framework for ConstructingResource-Aware, Configurable Middleware. IEEEDistributed Systems Online, 6(9), Sept. 2005.

[12] H. Ludwig, A. Dan, and R. Kearney. Cremona: anarchitecture and library for creation and monitoring ofWS-agreements. In Proc. of the 2nd Int. Conf. onService Oriented Computing (ICSOC ’04), pages65–74, New York, NY, Nov. 2004.

[13] OASIS. Web Services Distributed Management –Management of Web Services, Version 1.0, Mar. 2005.

[14] K. Sakurai, H. Masuhara, N. Ubayashi, S. Matuura,and S. Komiya. Design and Implementation of anAspect Instantiation Mechanism. Trans. onAspect-Oriented Software Dev., 3880:259–292, 2006.

[15] J. Skene, D. D. Lamanna, and W. Emmerich. PreciseService Level Agreements. In 26th Int. Conf. onSoftware Engineering (ICSE ’04), pages 179–188,Edinburgh, UK, May 2004.

[16] V. Tosic and B. Pagurek. On comprehensivecontractual descriptions of web services. In Proc. ofIEEE Int. Conf. on e-Technology, e-Commerce ande-Service. EEE ’05., pages 444 – 449. IEEE, 2005.

11