Durham Research Online

Deposited in DRO: 08 October 2008 Version of attached le: Published Version Peer-review status of attached le: Peer-reviewed Citation for published item: Turner, M. and Budgen, D. and Brereton, P. (2003) 'Turning software into a service.', Computer., 36 (10). pp. 38-44. Further information on publisher's website: http://dx.doi.org/10.1109/MC.2003.1236470

Publisher's copyright statement:

c 2003 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Additional information:

Use policy

The full-text may be used and/or reproduced, and given to third parties in any format or medium, without prior permission or charge, for personal research or study, educational, or not-for-prot purposes provided that: • a full bibliographic reference is made to the original source • a link is made to the metadata record in DRO • the full-text is not changed in any way The full-text must not be sold in any format or medium without the formal permission of the copyright holders.

Please consult the full DRO policy for further details.

Durham University Library, Stockton Road, Durham DH1 3LY, United Kingdom Tel : +44 (0)191 334 3042 | Fax : +44 (0)191 334 2971 https://dro.dur.ac.uk COVER FEATURE

Turning Software into a Service

The software as a service model composes services dynamically, as needed, by binding several lower-level services—thus overcoming many limitations that constrain traditional software use, deployment, and evolution.

Mark Turner n 1999, the Pennine Group—a consortium of new services that use existing ones. The “Sample David software engineering researchers from the Uni- SaaS Scenario” sidebar shows inherent SaaS ideas Budgen versity of Durham, Keele University, and the in the context of a company helping with an over- University of Manchester Institute of Science seas property purchase. Pearl I and Technology—asserted that continued This approach lets the set of services a business Brereton development of new architectural styles based on uses evolve without any user intervention as that Keele University, constructional forms such as objects or compo- business and its context change. Also, the key know- Staffordshire nents would not advance the software field. Rather, how involved is not who provides services, neces- they foresaw a future in which developers take a sary though that knowledge is, but what service a radically different view of how software delivers transaction requires at any particular point, along its functionality to users.1 with negotiating suitable terms for its use. Selecting We have explored the software as a service (SaaS) and binding the means of providing an appropriate concept through several small-scale experiments.2 service can therefore be performed dynamically, on This concept envisages a demand-led software mar- demand, through ultra-late binding. ket in which businesses assemble and provide services when needed to address a particular SAAS AND OTHER SERVICE FORMS requirement. The SaaS vision is a vital contribution Despite advances in programming language and to current thinking about software development development environment technologies, the basic and delivery that has arisen in part from initiatives paradigm for constructing and maintaining soft- in the Web services and electronic-business-com- ware has altered little since the 1960s. Developers munication communities. still construct software largely by employing some SaaS focuses on separating the possession and variant of the edit-compile-link cycle to generate an ownership of software from its use. Delivering soft- executable binary image from a source described ware’s functionality as a set of distributed services using a procedural programming language. that can be configured and bound at delivery time Although the Web may have widened our interpre- can overcome many current limitations constrain- tation of what software is, the practices used to ing software use, deployment, and evolution. Such develop and implement a Web site differ little from a model would open up new markets, both for rel- those traditionally employed for constructing soft- atively small-scale specialist-services providers and ware and are just as error prone. for larger organizations that provide more general To achieve our vision, we have focused on devel- services. In addition, service provision could include oping a radically different paradigm. We believe the dynamic creation and development of entirely that software should deliver a service. Further,

38 Computer Published by the IEEE Computer Society 0018-9162/03/$17.00 © 2003 IEEE

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. Sample SaaS Scenario

The following scenario, set within the context of a much A more complex example, involving composition, would be larger example, demonstrates the ideas inherent in the software- for Alice to add a new service to help negotiate mortgages. as-a-service concept. Relating this example to the key service-oriented functions of Alice has set up a company that offers services to people who our service integration layer can be instructive. want to purchase property abroad. She currently offers two First, in terms of service description, Alice must be able to services: One provides information about available properties, describe her general requirement to have a document trans- while a second handles actual negotiation and purchase. lated, its more specific details—including that it is a legal doc- Alice’s purchasing service uses other services to handle tasks ument—and the languages involved. Service description also such as translation, legal and financial negotiations, financing, encompasses the way a service provider such as Scribe or ES- and currency transfer. Offering these services involves specify- trans describes the services it can supply—either directly or ing the terms, conditions, and form of service provision, using other providers—and the parameters within which they together with the rules describing how other services will be will negotiate a service contract. employed. This is the know-how element of her service. This example contains two instances of service discovery. Drawn from the complete scenario, one small task concern- The first occurs when Alice seeks the translation service, the ing a legal document might play out as follows. Alice’s pur- second when the Scribe broker seeks a service that can deliver chasing service urgently needs to have the document translated the translation in the required time. from Spanish to English, which involves the following steps: Likewise, the example shows two stages of negotiation. First, Alice’s service will negotiate with Scribe. Because she frequently • The purchasing service seeks a translation service and, needs translation services in general, however, the service also after negotiating the terms and conditions, selects Scribe, may conduct this negotiation periodically, resulting in a longer- the cheapest from the four available. term contract between Alice’s service and Scribe, in which case • Scribe, a broker that evaluates services but doesn’t actually the immediate negotiation will be concerned purely with ser- provide them, seeks a Spanish translation service geared to vice parameters. Second, Scribe can then negotiate a much handling legal documents. From the three providers offer- shorter-term, per-document agreement with ES-trans and other ing this service, based upon previous use history and sat- possible providers. isfactory delivery, Scribe selects ES-trans, which offers an Service delivery in this example occurs when ES-trans immediate service. receives the original document and returns the translation. • ES-trans provides the translation that Alice’s purchasing However, if ES-trans does not do this within the specified service requires. time—determined by the form in which Alice’s service may have defined “urgently” in this case—either Alice’s service or Within SaaS, the services involved in a system can change Scribe can opt to invoke the suspension step and renegotiate with the associated business, and SaaS can perform this change with another provider. Finally, a form of service composition dynamically. For example, in Alice’s scenario, such a change occurs when Scribe employs its know-how about translation might occur if Scribe becomes aware of new translation services. services to seek a suitable service and negotiate with it.

shifting the focus from providing software to Figure 1. Service describing and delivering a service moves the focus Service layer models. (a) The away from the constraints that traditional soft- Supplier’s software (applications created application service on demand from current supply-led smaller services) ware construction, use, and ownership models service model impose. Hence, our service-based model config- Service integration layer provides only a ures, executes, and disengages one or more services Service transport layer predetermined range 3 (using forms such as to meet a specific set of requirements —a vision of .NET or J2EE) Service transport layer of services from a instant service consistent with the widely accepted remote server. (b) (a) (b) definition: “an act or performance offered by one The proposed party to another. Although the process may be tied demand-led service to a physical product, the performance is essen- model has a service tially intangible and does not normally result in could be if developers insert a further service inte- integration layer 4 ownership of any of the factors of production.” gration layer above the transport layer. inserted above the Figure 1a shows an abstract interpretation of The model in Figure 1a is supply-led because it transport layer. what the current literature widely refers to as a ser- supports applications that can provide only a pre- vice model: A fixed set of applications sit on top of determined range of services from a remote server. a service transport layer that uses technologies such The model in Figure 1b is demand-led because as Microsoft’s .NET or Sun’s J2EE platform, along applications can be constructed from smaller com- with XML-based enveloping and message formats ponent services and bound dynamically as needed. such as the simple object access protocol (SOAP). Providing this capability will require support from Figure 1b shows our vision of what a service model high-bandwidth information networking, which

October 2003 39

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. we expect emerging grid technologies to pro- bounds of provision, or when the bounds are In its most vide and enhance. reached, the suspension step establishes the point at direct form, which the client no longer needs the provider to SERVICE INTEGRATION LAYER supply the service. know-how— The key to the quite radical difference expressed in between the two models represented in Service composition terms of rules— Figure 1 lies in the functionality that results In its most direct form, know-how—expressed drives service from combining the facilities that the service in terms of rules—drives service composition composition. integration layer provides with those from so that a service provider can compose its service the component services that make up an from lower-level services. However, such knowl- application. This layer employs software edge is sufficient only for constructing those ser- technology to support a set of concepts vices for which rules already exist. In the longer closely related to business and supply models. The term, we seek to devise a suitable mechanism for service integration layer incorporates four key ser- creating new forms of service on demand. Nothing vice-oriented functions. in our model prevents this, but creating the means of automatically providing entirely new services Service description will clearly only be practical once the other ele- This function matches client needs to appropri- ments of the service integration layer have been ate and available services. Essentially, the service fully developed. description provides the means of mapping between the provider’s description of its offerings CURRENT SERVICE-RELATED PROTOCOLS and the client’s description of its needs. The form The current research literature frequently uses the used should accommodate descriptions of func- service-model concept to describe Web service tech- tionality, interfaces, and nonfunctional character- nologies such as Microsoft’s .NET platform. Al- istics and constraints such as quality of service and though the Web services paradigm is fairly consistent cost. It should also describe the parameters within with our vision of SaaS, creating a true service- which both the service provider and client will oriented marketplace requires further developments. negotiate. Since the introduction of Web services, three XML-based protocols have become de facto stan- Service discovery dards. These three protocols have become so wide- Clients use service discovery to locate appropri- spread that the term Web services has become ate services, according to their requirements and synonymous with them: selection criteria. Using this process, a client identi- fies those potential service providers whose offerings • SOAP provides a message format for commu- meet its functional needs and who are prepared to nicating with and invoking Web services; negotiate within some acceptable bounds. Discovery • the Web Services Description Language (WSDL) can involve the recursive use of other services, includ- describes how to access Web services; and ing brokers, and will result in a list of candidate ser- • universal description, discovery and integra- vices and providers. Service negotiation involves the tion (UDDI) provides a registry that clients can interaction between a client and one or more of the use to discover available services. service providers identified through the discovery process or already known to the client. This negoti- These three protocols are adequate for simple Web ation aims to achieve agreement on the terms and services requiring a remote-procedure-call style of conditions for supplying a service. communication. For more complex Web services that consist of several services, other XML-based Service delivery specifications provide functions at higher or inter- This function consists of three steps. Invocation mediate layers in a stack of protocols. is the calling-for step, during which the client When developing complex Web services, the lack requests the provider to supply the specified service of a universally accepted protocol that provides all according to the agreed terms and conditions. Next, the functionality required at each layer can cause to validate the invocation, in the provision step the problems. Adding to this confusion is the lack of service provider must supply the agreed-upon ser- an overall definition for the actual layers such a vice within the period agreed to in the supply con- stack requires. The many standards organizations tract. Finally, where the contract has unspecified and companies involved all have different visions of

40 Computer

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. UDDI ebXML Discovery registries

ebXML Contracts CPA

Business process/ BPEL4WS DAML-S service model BPML workflow BPML

Transactions WS-Transaction BTP BTP

Choreography WS-Coordination DAML-S service model ebXML WSCI BPSS Conversations CS-WS WSCL DAML-S service profile Nonfunctional WSEL description DAML-S service grounding ebXML Service description WSDL CPP RDF

ebXML messaging XML-based messaging SOAP

HTTP, FTP, SMTP, and others Network

WSDL-based Semantic-based ebXML-based

Figure 2. Proposed the layers and protocols that make up the Web ser- • Network. This is the underlying transport Web services stack vices architecture. protocol layer. framework. IBM produced one of the stack’s original defini- • XML-based messaging. XML is the message Separated into three tions in its Web Services Conceptual Architecture format for communicating documents and vertical sections, document.5 It included the three de facto standards procedure calls. This layer can, for example, the protocols use at the XML-based messaging, service implementa- use SOAP with any underlying transport pro- or extend WSDL, tion, and description and discovery layers, along tocols in the network layer. This layer decou- have roots in the with a service flow layer that incorporated IBM’s ples messaging from the physical transport semantic Web’s Web Services Flow Language.6 However, the latter protocol so that messages can concentrate resource description has now been combined with Microsoft’s XLANG on describing the service semantics. The framework, and protocol (www.gotdotnet.com/team/xml_wsspecs/ Electronic Business XML solution, ebXML the DARPA Agent xlang-c/default.htm) to produce a new set of pro- Messaging Specification (ebMS), builds on Markup Language tocols: the Business Process Execution Language SOAP by using its header specification exten- for Services for Web Services (BPEL4WS; www-106.ibm.com/ sibility to include authentication and contex- (DAML-S), and developerworks/webservices/library/ws-bpel/). The tual information. include ebXML W3C Web Services Architecture group also is • Service description. This layer provides the specifications. working on its own stack version to standardize functional description of a Web service in the required layers,7 again emphasizing the three terms of its interface and implementation. The basic protocols. majority of description languages at this layer Few of the available stacks include any detail utilize the XML Schema language for express- on the semantic Web protocols or the more busi- ing data-type information. ness-oriented Electronic Business using Extensible • Nonfunctional description. Protocols at this Markup Language (ebXML). As a result, which layer describe a service in terms of its less tech- technologies to use at each level—and even which nical features, such as quality of service, cost, of the available technologies are compatible— geographic location, number of retries, and remains unclear. To this end, we propose an legal factors. updated Web services stack framework that • Conversations. In this context, a conversation places the currently available initiatives in con- refers to the external view of the messages a text. Web service is receiving and sending. This layer The stack framework shown in Figure 2 consists therefore describes the correct data types and of several open-systems-interconnection-type lay- sequence of messages or documents a Web ser- ers, with each level using the services of the levels vice is exchanging. below it. • Choreography. Whereas all the previous lay-

October 2003 41

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. ers are largely concerned with describing a sin- ments added to SOAP to provide secure messaging Current gle Web service, the choreography layer coor- capabilities such as those that WS-Security defines. dinates several Web services into a pattern to However, because it concentrates instead on other methods lack provide an overall outcome. For example, pro- areas, our current model does not include security. descriptions of tocols in this layer would specify the order in service delivery’s which the methods—or operations in WSDL REALIZING THE SERVICE INTEGRATION LAYER negotiable terminology—of each Web service must be Figure 2 reveals several significant gaps in the invoked. current Web services stack. aspects. • Transactions. The protocols in this layer facil- itate monitoring transactions between Web Service description services. When services themselves consist of Current description methods suffer from a severe other services, numerous points of failure limitation: Although they provide the technical become possible. The transactions layer information a client requires to invoke a service, describes how to achieve this composition in they cannot describe the function the service pro- an atomic way, so that, for example, the entire vides semantically. They also lack descriptions of process either completes successfully or rolls service delivery’s negotiable aspects. For example, back. although it is the de facto standard Web services • Business process and workflow. The protocols language, WSDL describes a service in terms only in this layer describe how to actually compose of its acceptable data types, methods, message for- a higher-level service from several other Web mat, transport protocol, and end-point uniform services, through descriptions of the control resource identifier (URI). and data flows involved in the process. It dif- In the ebXML section of our stack framework, fers from the choreography layer by providing the Collaboration Protocol Profile specification internal details of the composition to supply deals with service description. Although it includes an executable business process. more details about the service provider and error- • Contracts. This layer outlines the format of the handling scenarios than WSDL, the CPP focuses machine-readable contracts necessary to auto- largely on the transaction’s technical aspects. In the mate service-based electronic business. The WSDL-based section of our framework, IBM’s Web contract outlines the transaction’s terms and Services Endpoint Language6 is the only protocol conditions and finalizes any negotiable para- explicitly designed to describe the nonfunctional, meters, such as cost and acceptable time to negotiable elements of Web services. WSEL, how- delivery. ever, remains a work in progress. • Discovery. Providers use this layer to publish DAML-S is the only available description details of their Web services so that clients can method designed specifically for describing the then search and discover any that meet their functional and nonfunctional aspects of services, needs. including details of what they actually do. A client can use the specification’s service profile to describe We also separate our stack into three vertical sec- its requirements, and the service provider can use tions. The first section includes protocols that use the service profile to describe its capabilities, includ- or extend WSDL. The second includes protocols ing nonfunctional parameters, in a semantically that have roots in the semantic Web: the resource rich, ontology-based format. However, while clos- description framework (RDF) and the DARPA est to our requirements, DAML-S has not yet Agent Markup Language for Services (DAML-S).8 reached a final release. Thus, the exact details of As Figure 2 shows, WSDL crosses the boundary what the service profile will include have yet to be into the semantic-based section in our stack. This finalized, and it also currently lacks an extensive is not because WSDL is semantic-based, but selection of usable, standardized ontologies. because DAML-S builds upon WSDL for its Service Support for the language within current tools is also Grounding specification. The ebXML specifications fairly limited. comprise the third vertical layer in our stack. Although it is independent of Web services, ebXML Service discovery offers much the same functionality as the other UDDI is the de facto standard for discovery in the sections. Web services environment. For our purposes, Also, several protocols relate to security within UDDI’s key limitation lies in its inability to allow the Web services paradigm, including enhance- semantic descriptions. This limits searching to key-

42 Computer

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. words, such as the name of the service provider or actions and terminate the process if this con- the service itself, the service’s location, or the business tract is broken. However, in relation to our The SaaS model classification. Although the ebXML registry specifi- model, this document does not detail any legal cation offers richer searching capabilities in the form or nonfunctional parameters such as cost or requires that of SQL and XML filter queries, it does not allow quality of service. the client and semantic searching. Therefore, a client cannot use Several other protocols in the stack, particu- provider negotiate either of the available registry specifications to search larly the Web Services Choreography Interface the service’s for a service based on its functionality, which limits and WSEL, also include elements that touch delivery terms and the current model’s dynamic discovery capabilities. upon service monitoring and suspension. WSCI Clients can use the DAML-S service profile to lets the developer specify how a service will conditions make requests for services, and providers can use it react in exceptional circumstances, while both automatically. to describe their services semantically by the func- WSCI and WSEL can detail time-out periods. tionality they provide. Because the language is Thus, developers could use these elements to ontology-based, its inferential capabilities should monitor the transaction at a basic level. allow matching requests to service descriptions. Also, true dynamic binding and invocation relies However, this requires a registry capable of per- heavily on the richness of the service description. forming true semantic matching, which UDDI cur- This description must be machine readable and rently does not do. To this end, researchers have semantically rich to enable the requesting service been using an algorithm from previous research to automatically decipher all the requirements of that matches requests to advertisements according use. This capability is not yet fully in place. to their semantics9 to determine how to extend UDDI with DAML-S. Service composition The automatic composition of Web services Service negotiation requires suitable protocols at the conversations, The SaaS model requires that, upon discovering choreography, workflow, and transactions layers. a suitable service, the client and provider must As Figure 2 shows, several protocol combinations negotiate the service’s delivery terms and conditions are available at each of these layers within the automatically. Although several protocols through- WSDL-based section: out the stack framework include descriptions of negotiable parameters—including ebXML’s CPP, • HP’s Web Services Conversation Language DAML-S, and WSEL—none allow for fully auto- (WSCL) and IBM’s recent Conversation- mated negotiation. The model also needs electronic Support for Web Services specification (CS- contracts to seal any negotiations that take place. WS) both cover the conversation layer,11 Figure 2 shows that, among the current ap- • the WS-Coordination protocol and WSCI proaches, only ebXML includes such contracts. both cover the choreography that links each The Collaboration Protocol Agreement primar- of the collaborating Web services together, and ily defines the common protocols and capabilities • the Business Transaction Protocol (BTP) and of only two parties. Formed from the intersection WS-Transaction both cover monitoring and of the two parties’ CPP documents, the CPA uses handling long-running business transactions. XML to define properties such as the contract’s duration and the transactions’ agreed security fea- Developers can use either the Business Process tures. Formulating a CPA is intended to be a man- Modeling Language or the Business Process Exe- ual process.10 cution Language for Web Services to model the actual control and data flows within the composi- Service delivery tion. BPEL4WS, which is likely to become more Our model identifies three steps of primary widely adopted, can be distinguished from other importance to service delivery. Current technolo- protocols in the layer because it includes both an gies cover a Web service’s basic invocation and pro- abstract XML description and an executable lan- vision, but they do not support either monitoring guage. The actual BPEL4WS specification also whether the service is supplied within the agreed encompasses the WS-Coordination and WS- terms and conditions or suspending the provision, Transaction protocols, thus ensuring compatibil- if necessary. Doing so would require an electronic ity among the three layers. contract, which only ebXML includes. Services can The Business Process Specification Schema (BPSS) use ebXML’s CPA document to monitor the trans- provides an ebXML alternative. When combined

October 2003 43

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply. with the compatible BPML and BTP specifications, 2001), IEEE CS Press, 2001, pp. 292-300. it can also describe the internal details of workflows 3. O.P. Brereton et al., “The Future of Software,” and long-running transactions. However, the BPSS Comm. ACM, Dec. 1999, pp. 78-84. is designed to model only a transaction between two 4. C. Lovelock, S. Vandermerwe, and B. Lewis, Services parties, not a complex Web services composition. Marketing, Prentice-Hall, 1996. DAML-S covers many of the compositional layers 5. H. Kreger, “Web Services Conceptual Architecture with the service profile and service model specifica- (WSCA 1.0),” 2001; www-3.ibm.com/software/ tions. However, the current release lacks support for solutions/webservices/pdf/WSCA.pdf. long-running transactions. We expect that a future 6. F. Leymann, “Web Services Flow Language (WSFL) specification will include such support, along with 1.0,” 2001; www-3.ibm.com/software/solutions/ a control model that describes a process in terms of webservices/pdf/WSFL.pdf. its state, allowing automated monitoring. 7. D. Booth et al., “Web Services Architecture: W3C Working Draft,” 14 May 2003; www.w3.org/TR/ ws-arch/. lthough many available technologies support 8. A. Ankolekar et al., “DAML-S: Web Services service composition, they require that the Description for the Semantic Web,” Proc. 1st Int’l A developer knows, at design time, the details Semantic Web Conf. (ISWC 2002), Springer-Verlag, of the services to be used. In the SaaS model, ser- 2002, pp. 348-363. vices will be dynamically composable when needed, 9. M. Paolucci et al., “Importing the Semantic Web in through binding of several other, lower-level ser- UDDI,” Proc. Web Services, E-Business, and Seman- vices. Indeed, a true service-oriented model will tic Web Workshop (CAiSE 2002), Springer-Verlag, automatically compose a new higher-level service 2002, pp. 225-236. from a client’s description of the sequence of tasks 10. ebXML Trading-Partners Team, “Collaboration-Pro- to be performed. The service could achieve this by tocol Profile and Agreement Specification,” v. 1.0, searching for and dynamically binding to lower- 2001; www.ebxml.org/specs/ebCCP.pdf. level services that perform each task. 11. J.E. Hanson, P. Nandi, and S. Kumaran, “Conversa- Although many of the protocols necessary to tion Support for Business Process Integration,” Proc. achieve true service provision are either available 6th IEEE Int’l Enterprise Distributed Object Com- or under development, significant gaps remain. puting Conf. (EDOC 2002), IEEE CS Press, 2002, Perhaps not surprisingly, these protocols address pp. 65-75. the less technical aspects of service delivery and thus represent research challenges that have strong inter- Mark Turner is a research assistant and PhD stu- disciplinary elements. dent in the Department of Computer Science at Keele University, UK. His research interests focus on service-based software engineering, in particu- Acknowledgments lar access control, description languages, and Web We thank the members of the Pennine Group services substitution. Turner received an MSc in (www.service-oriented.com) for their continuing information technology from Keele University. research into software as a service and for con- Contact him at [email protected]. tributing to the ideas in this article. We also thank the members of the Integration Broker for David Budgen is a professor of software engineer- Heterogeneous Information Sources project ing at Keele University. His research interests (www.co.umist.ac.uk/ibhis) for their useful discus- include design, measurement, and empirical eval- sions concerning Web services and for the ongoing uation practices for software-based systems. Bud- development of a service-oriented prototype. gen received a PhD in theoretical physics from the University of Durham. Contact him at d.budgen@ cs.keele.ac.uk. References 1. O.P. Brereton and D. Budgen, “Component-Based Pearl Brereton is a professor in the Department of Systems: A Classification of Issues,” Computer, Nov. Computer Science at Keele University. Her research 2000, pp. 54-62. focuses on component-based and service-based 2. K.H. Bennett et al., “An Architectural Model for Ser- software engineering. Brereton received a PhD in vice-Based Software with Ultra-Rapid Evolution,” numerical analysis from Keele University. Contact Proc. Int’l Conf. Software Maintenance (ICSM her at [email protected].

44 Computer

Authorized licensed use limited to: University of Durham. Downloaded on October 8, 2008 at 10:08 from IEEE Xplore. Restrictions apply.