Information Processing Letters 108 (2008) 192–203

Contents lists available at ScienceDirect

Information Processing Letters

www.elsevier.com/locate/ipl

A conceptual model for negotiating in service-oriented environments

Jyhjong Lin

Ming Chuan University, Department of Information Management, Kweishan, Taoyuan Country, Taiwan

a r t i c l e i n f o a b s t r a c t

Article history:Received 19 October 2007Received in revised form 5 May 2008Available online 24 May 2008Communicated by J.L. Fiadeiro

Keywords:Service-oriented environmentNegotiationObject-orientationConceptual modelSoftware engineering

In recent years, Web services have been developed as a fundamental technique for the newgeneration of B2B or EAI applications. As they have matured and a new vision of service-oriented computing has emerged, the software industry has shifted its attention fromdeveloping required software to delivering desired services. In order to benefit from such aservice-oriented model of software, several critical issues must be addressed in a service-oriented environment such as differentiation of services by various attributes, dynamicselection and provision of services in a supply chain style, and commitment of serviceswith prescribed rules. From the managerial perspective, these issues are concerned with aprocess of negotiating desired services in a service-oriented environment. In this paper, wepropose an object-oriented model that specifies such a negotiation process by architecturalconstructs where these critical issues are adequately addressed. The model contains ause case diagram that depicts requirements for the negotiation process, an architecturediagram that describes collaborative components for satisfying these requirements, anda class/sequence diagram that specifies class objects in these components to perform allbehaviors occurring within the negotiation process. For illustration, the model is applied toan exemplified negotiation process for book publishing.

© 2008 Elsevier B.V. All rights reserved.

1. Introduction

Following the rapid advances of Internet technologies inrecent years, Web services have been developed as a fun-damental technique for the new generation of business-to-business (B2B) or enterprise application integration (EAI)applications. Since their underlying infrastructures suchas XML [1,2], SOAP [3], UDDI [4], WSDL [5], WSCL [6],BPEL [7], and BPML [8] have gradually matured, more Webservices are discussed in the literature with a new visionof service-oriented computing [9]. In order to benefit fromsuch a service-oriented vision [10,11], the software indus-try has shifted its attention from developing required soft-ware to delivering desired services in a service-orientedenvironment [12]. From the viewpoint of service provision,this means that software services are selected and deliv-ered in a dynamic manner tailored to the needs of thechangeable business environment nowadays.

E-mail address: jlin@mcu.edu.tw.

0020-0190/$ – see front matter © 2008 Elsevier B.V. All rights reserved.doi:10.1016/j.ipl.2008.05.006

For achieving the dynamic provision of services, con-siderable sophisticated behaviors need be imposed to ad-dress several critical issues in a service-oriented environ-ment, including (1) differentiation of services by variousattributes such as price, quality, and trust value; (2) dy-namic selection and provision of services in supply chainstyle where a composite service comprises a set of con-stituent ones; (3) criticality of time for dynamic selectionof services for desired service requests; (4) volatility of ser-vice provision where services might not be available allthe time; and (5) commitment of service provision withprescribed rules such as contract enactment and trust for-mulation. From the managerial perspective, these criticalissues are concerned with a process of negotiating desiredservices in a service-oriented environment [10,11]. There-fore, it becomes a major focus of all service participants(e.g., service requesters and providers) to impose sophisti-cated behaviors to support the realization of such a nego-tiation process where these critical issues are adequatelyaddressed.

J. Lin / Information Processing Letters 108 (2008) 192–203 193

Fig. 1. The architecture for negotiating in a service-oriented environment.

Conceptual modeling is an important technique for rep-resenting a (part of a) complex situation in an abstractmanner with concise notations. It has been commonlyused, for example, in analyzing and specifying user re-quirements of a computer-based application, as well ascollecting and representing information required for deal-ing with complex technical and/or managerial issues to beresolved. Thus, in our knowledge, whenever the develop-ment of a service-oriented environment is necessary fordynamic service provision, it would be a good choice touse a conceptual model to specify the negotiation processwhere in particular behavioral mechanisms are employedfor supporting sophisticated behaviors to deal with thoseaforementioned critical issues. In the literature, many tech-nical discussions about service-oriented computing and itscorresponding negotiation process and issues for consider-ation have already been presented [9–15]. For instance, thediscussion in [11] presents a sound description of the ne-gotiation process on top of a service-oriented architecture:negotiating in a service-oriented environment can be seenas a three-phase process: pre-negotiation, negotiation, andservice delivery. Besides, service-oriented computing alsoaddresses many key issues that summarize the domaincharacteristics of a service-oriented environment. In gen-eral, although these existing discussions figure out the re-quirements well for service-oriented computing, thoroughconceptual models for specifying these requirements arestill few nowadays. Such models are indeed needed in thattheir specifications for these requirements are important inrealizing a service-oriented environment; failure to specifythese requirements usually results in poor quality and highmaintenance costs in the environment.

For this need, we propose, in this paper, a conceptualmodel that specifies the negotiation process in a service-oriented environment where those aforementioned criti-cal issues are specifically addressed. Traditionally, concep-tual modeling can be achieved by using function- [16–18],data- [19,20], or object-oriented [21–24] means, wherethe development of object-oriented ones is particularlymotivated by the drawbacks and problems in the othertwo kinds: The significant features and benefits of object-oriented approaches would make resultant models morenatural and abstract, and hence easier to be understood,maintained, and reused. As a result, our model is object-oriented with UML [25–28] utilized as its modeling toolThe model contains a use case diagram that depicts re-quirements for the negotiation process, and then an archi-tecture diagram that describes collaborative components

for satisfying these requirements. Finally, for specifyingbehaviors, it uses a class/sequence diagram that specifiesclass objects in these components to perform all behaviorsoccurring within the negotiation process.

This paper is organized as follows. Section 2 presentsthe use case and architecture diagrams used in our model.The class and sequence diagrams are then introduced inSections 3 and 4 respectively. In Section 5, the model isillustrated by an exemplified negotiation process for bookpublishing, while its evaluation is discussed after the illus-tration. Finally, Section 6 contains the conclusions and ourfuture work.

2. The architectural components

In a service-oriented environment, services are dynami-cally requested and delivered within a negotiation process.In this context, the term ‘negotiation’ represents negoti-ating among prospective participants for selecting desiredservices to be delivered by targeted providers. The discus-sion in [11] for negotiating in a service-oriented environ-ment presents a sound description about the negotiationprocess on top of a service-oriented architecture. Basedon this idea, our model first has an architecture diagramthat supports the negotiation process by imposing collab-orative components for achieving the considerable numberof activities within the negotiation process. Fig. 1 showsthe most abstract view of our architecture diagram. In thisdiagram, three components are imposed where each playsa designated role for participating in the negotiation pro-cess.

(1) The service requester

The service requester is responsible for issuing servicerequests to a selected service provider that delivers desiredservices after negotiation with other negotiators (i.e., theservice discovery agency and the selected service provider)has been completed. More specifically, for achieving its re-sponsibilities, the requester takes the following issues intoconsideration.

(a) For negotiating with the service discovery agency todetermine a suitable service provider for satisfyingservice requests, and also for negotiating with theselected service provider to deliver desired services,a protocol with associated rules to be complied withamong all negotiators is needed; therefore, the ser-

194 J. Lin / Information Processing Letters 108 (2008) 192–203

Fig. 2. Use cases for the service requester.

vice requester must maintain an interaction protocolfor proceeding negotiations.

(b) Since a negotiation encompasses a number of interac-tions among negotiators and hence is time consuming,it is valuable for the service requester to adopt cer-tain approaches that reduce the number of invokednegotiations or expedite the completion of the nego-tiating; as a common recognition, these approachesmay include (1) keeping a list of preferred providersand their providing services, and whenever a requestis desirable, a service provider can be determined di-rectly and then agreement on a contract can be ne-gotiated immediately; or (2) predicting future desiresbased on the pattern of existing service requests, andhence suitable service providers can be determinedand agreement on a contract can be negotiated beforenew requests are issued.

(c) Since it is often required to determine a suitable pre-ferred provider from a list for each request, the re-quester would best adopt certain approaches that ex-pedite the completion of the determination; a com-mon approach is to structure the list in a sophisticatedway (e.g., in a classified or indexed directory), andhence the determination can be expedited by explor-ing the list via a convenient access (e.g., traversing theclassified or indexed directory).

(d) Service requests may be dependent among themselvesdue to their resulting from a composite (e.g., a com-posite request for achieving a more complex objec-tive); in such a case, the service requester needs tomaintain any relationships among these constituentrequests for negotiating and issuing them in an ad-equate sequence and to deal also with the conse-quences from negotiating or issuing these requests(e.g., success to discover and select service providersfor these requests or failure to deliver services fromthese service providers).

(e) Once negotiating for a request has been completed anda service provider is discovered and selected, the ser-vice requester must sign a contract with the selectedservice provider; therefore, the service requester mustmaintain a contract template for completing the sign-ing and enacting of the contract.

(f) Once desired services are delivered under the promisesdenoted in corresponding contracts, the service re-quester should evaluate the effects of using theseservices (i.e., how these services are delivered in accor-dance with those promises) such that the trust valuesfor the service provider can be updated to help de-termine the selection of the same (preferred) serviceprovider upon future requests.

The service requester needs to address these issues asits requirements to be satisfied; corresponding use casesfor specifying them can therefore be identified and de-scribed by a use case diagram in UML as shown in Fig. 2:

1. maintain service request—decomposing composite ones(issue d), evaluating and composing delivered services(issue f), and updating the list of preferred providers(issue f)

2. maintain the structured list of preferred providers (is-sues b and c)

3. maintain discovery protocol and negotiate with servicediscovery agency (issue a)

4. maintain contract protocol and negotiate with serviceprovider (issue a)

5. maintain contract template and sign contract with ser-vice provider (issue e)

where ‘uses’ or ‘extends’ relationships may exist betweenvarious use cases that describe the sequences of concernamong these issues.

Based on these use cases, it is now possible to iden-tify behavioral components that collaboratively support the

J. Lin / Information Processing Letters 108 (2008) 192–203 195

Fig. 3. Architectural components for the service requester.

achievement of these use cases. In UML, this is modeled bya component diagram that is designated to depict an archi-tectural partitioning of physical components to support theachievement of required use cases. Fig. 3 shows the resul-tant components and their interactions for collaborativelyachieving those use cases in Fig. 2.

(2) The service discovery agency

The service discovery agency is responsible for deter-mining a service provider that provides services to sat-isfy desired service requests from the service requester.As a common recognition, the determination is based onreferring desired service requests to a set of service de-scriptions published by various service providers. Once thereferring of desired service requests to suitable service de-scriptions is reachable, the service discovery agency re-turns these published service descriptions and their ser-vice providers to the service requester. Similar to the ser-vice requester, for achieving its responsibilities, the dis-covery agency takes the following issues into considera-tion.

(a) For negotiating with the service requester to receiveits service requests and determine a suitable serviceprovider, and also for negotiating with the serviceprovider to accept its published service descriptionsand refer to service requests, a protocol with asso-ciated rules to be complied with among all negotia-tors is needed; therefore, the service discovery agencymust maintain an interaction protocol for proceedingnegotiations.

(b) Since for each service request it is often required todetermine a suitable service provider from a list of ca-pable ones, the agency is better off to adopt certainapproaches that expedite the completion of the deter-mination work; a common approach is to structure thelist of capable service providers that publish intendedservices in a sophisticated way (e.g., in a classified orindexed directory), and hence the determination can

Fig. 4. Use cases for the service discovery agency.

be expedited by exploring the list via a convenientaccess (e.g., traversing the classified or indexed direc-tory).

The service discovery agency needs to address theseissues as its requirements to be satisfied; correspondinguse cases for specifying them can therefore be identifiedand described by a use case diagram in UML as shownin Fig. 4:

1. maintain discovery protocol and negotiate with servicerequester (issue a)

2. maintain publishing protocol and negotiate with ser-vice provider (issue a)

3. maintain a structured list of capable providers (is-sue b)

where ‘uses’ relationships may exist between various usecases that describe the sequences of concern among theseissues.

Based on these use cases, behavioral components canthen be identified that collaboratively support the achieve-ment of these use cases. Fig. 5 shows the resultant com-ponents and their interactions for collaboratively achievingthose use cases in Fig. 4.

196 J. Lin / Information Processing Letters 108 (2008) 192–203

Fig. 5. Architectural components for the service discovery agency.

Fig. 6. Use cases for the service provider.

(3) The service provider

The service provider is responsible for delivering ser-vices to the desired service requester after negotiating forthese services with other negotiators (i.e., the service dis-covery agency for publishing these services and the ser-vice requester for seeking these services) has been com-pleted. More specifically, for achieving its responsibilities,the provider takes the following issues into considera-tion.

(a) For negotiating with the service requester to receiveservice requests and deliver desired services, and alsofor negotiating with the service discovery agency topublish service descriptions, a protocol with associ-ated rules to be complied with among all negotia-tors is needed; therefore, the service provider mustmaintain an interaction protocol for proceeding nego-tiations.

(b) Since delivering services to the service requester re-quires proper compensation, the trust values for theservice requester should be evaluated before deliv-ery to ensure its qualified collaborative role; there-fore, the service provider must maintain a list of col-laborative service requesters with their trust valuesto help determine service delivery upon future re-quests.

(c) Once negotiating for service requests has been com-pleted, the service provider must sign a contract with

the service requester for delivering desired services;therefore, the service provider must maintain a con-tract template so that the service requester may com-plete the signing and enacting of the contract.

(d) Once desired services are delivered under the promisesdenoted in corresponding contracts, the service pro-vider should evaluate compensations from the ser-vice requester (i.e., how these services are compen-sated in accordance with those promises) such thatthe trust values for the service requester can be up-dated to help determine the delivery of its futurerequests.

The service provider needs to address these issues as itsrequirements to be satisfied; corresponding use cases forspecifying them can therefore be identified and describedby a use case diagram in UML as shown in Fig. 6:

1. maintain publishing protocol and negotiate with ser-vice discovery agency (issue a)

2. maintain contract protocol and negotiate with servicerequester (issue a)

3. maintain a structured list of collaborative requesters(issue b)

4. maintain contract template and sign contract with ser-vice requester (issue c)

5. maintain service provision—evaluating compensationand updating the list of collaborative requesters (is-sue d)

J. Lin / Information Processing Letters 108 (2008) 192–203 197

Fig. 7. Architectural components for the service provider.

Fig. 8. Object class diagram for the service requester.

where ‘uses’ or ‘extends’ relationships may exist betweenvarious use cases that describe the sequences of concernamong these issues.

Based on these use cases, behavioral components canbe identified that collaboratively support the achievementof these use cases. Fig. 7 shows the resultant componentsand their interactions for collaboratively achieving thoseuse cases in Fig. 6.

3. The object class diagram

After identifying architectural components, an objectclass diagram is then developed to describe requiredclasses for defining objects to be allocated in these archi-tectural components; these objects collaborate to performthe behaviors in use cases. In UML, the ingredients ina class diagram can have three kinds of stereotype: bound-ary, entity, and control classes where a boundary classrepresents an interface used to interact with the applica-tion with an actor as a bridge, an entity class models theinformation and associated behaviors in the real world,and a control class controls the access between interfaceand entity classes for accomplishing a desired behavior.Fig. 8 shows our class diagram for the service requester

based on the architectural diagram in Fig. 3. It is noted thatin this diagram, various relationships may occur betweenclasses such as association and inheritance. As a com-mon recognition for the object-oriented paradigm, theserelationships (together with other features like informa-tion hiding in individual classes) are particularly usefulfor making the application easier to understand, maintain,and reuse. Figs. 9 and 10 present other two class diagramsfor the service discovery agency and the service providerbased on the architectural diagrams in Figs. 5 and 7 re-spectively.

4. The object sequence diagram

After identifying classes for defining objects in architec-tural components that collaborate to perform the behaviorsoccurring within the negotiation process, it is now timeto create an object sequence diagram that specifies howthese class objects perform these behaviors. Fig. 11 is oursequence diagram for the service requester based on theclass diagram in Fig. 8, while Figs. 12 and 13 present othertwo sequence diagrams for the service discovery agencyand the service provider based on the class diagrams inFigs. 9 and 10 respectively.

198 J. Lin / Information Processing Letters 108 (2008) 192–203

Fig. 9. Object class diagram for the service discovery agency.

Fig. 10. Object class diagram for the service provider.

For illustration, as shown in Fig. 11, the sequence ofbehaviors performed by objects in the service requesterare: after a ‘requester’ enters a (possibly composite) re-quest via a ‘request interface’, the ‘request composer’ figuresout a ‘request composition’ from the request in terms ofa sequence of desired service requests to various serviceproviders. This sequence of service requests are then re-trieved by the ‘request manager’ that activates in turn the‘discovery manager’ for determining service providers thatprovide services satisfying these requests. For each request,the ‘discovery manager’ queries then the ‘preferred providerlist’ to ensure directly if a ‘preferred provider’ can be foundthat provides a service (published via a ‘service descrip-tion’) satisfying the request. In the case that none of thepreferred providers publishes a service satisfying the re-quest, the ‘discovery manager’ negotiates with the ‘servicediscovery agency’ (under prescribed ‘protocol rules’) for de-termining a suitable service provider. After recognizing asuitable service provider by the aid of the ‘service discov-ery agency’, the ‘discovery manager’ activates the ‘contractmanager’ that negotiates with the ‘service provider’ (under

prescribed ‘protocol rules’) for the ‘signing’ of a ‘contract’(under designated ‘contract template’) to deliver the desiredservice under the commitment of the ‘contract’. After re-ceiving the desired service, the ‘contract manager’ evaluatesthe effects of using the service and then returns the re-ceived service, together with the evaluated trust values forthe ‘service provider’, to the ‘request manager’ that in turnupdates the ‘preferred provider list’ to help determine theselection of the same (preferred) service provider uponfuture requests. Finally, the ‘request manager’ returns thereceived service to the ‘service composer’ that figures out a‘service composition’ to be displayed to the ‘requester’ via a‘result interface’.

5. Illustration and evaluation

To illustrate our model, in this section we demonstratean application of our model on negotiating for servicesabout book publishing to be offered by selected book pub-lishers. Following the illustration, an evaluation of ourmodel will be discussed.

J. Lin / Information Processing Letters 108 (2008) 192–203 199

Fig. 11. Object sequence diagram for the service requester.

Fig. 12. Object sequence diagram for the service discovery agency.

5.1. The illustration

(1) The requirements for book publishing

Providing customers with book services is very impor-tant for book publishers. Many existing publishers offersuch services to customers as searching, viewing, and or-dering books via their own web sites or some intermedi-ary agents (e.g., Amazon). However, these services are nottruly useful for (part of) their customers who desire moresophisticated services like publishing books. To meet this

need, book publishers may consider to offer the followingservices for their customers (e.g., teachers):

1. author a book: a teacher authors chapters of and pre-pares art work for a book.

2. organize a book: a teacher organizes the structure of abook.

To offer these services in a service-oriented environ-ment, the negotiation process among prospective partici-pants could be conducted as follows:

200 J. Lin / Information Processing Letters 108 (2008) 192–203

Fig. 13. Object sequence diagram for the service provider.

1. The teacher desires services about book publishingfrom a book publisher.

2. The teacher acts on a service requester to try to issuebook writing and organizing requests.

3. The service requester negotiates with an agency in thebook publishing marketplace to get a recommenda-tion of suitable book publishers for satisfying theserequests.

4. Through negotiating, the agency identifies and recom-mends suitable book publishers.

5. Based on the recommendation, the service requesterselects a book publisher from which to receive desiredservices.

6. The service requester negotiates with the book pub-lisher to sign a contract for delivering book publishingservices.

7. Under the contract, the service requester issues bookwriting and organizing requests to the book publisher.

8. After receiving requests, the book publisher deliversbook writing and organizing services to the service re-quester and then, based on returned compensations,updates the trust value about the teacher on whichthe service requester is acted.

9. Once receiving book writing and organizing services,the service requester returns compensations to thebook publisher and also evaluates the effects of theseservices to update the trust values about the bookpublisher.

(2) The architectural component and class diagrams for bookpublishing

In the above negotiation process for book publishing,a teacher acts on a service requester to issue book pub-lishing requests to a selected book publisher after recom-mendations are made by an agency in the book publishingmarketplace. The services are delivered under the com-

mitment of a signed contract and hence compensationsof these services are returned based on the evaluation oftheir effects. Finally, both the service requester and thebook publisher update the trust values about their col-laborators to help determine future collaborations. Sincethe illustrative negotiation process proceeds along with ourdiscussions in Section 2, it is therefore straightforwardlyspecified by employing those architectural components inFigs. 3, 5, and 7 for the requester, the agency, and theprovider, respectively. Then, the classes required to defineobjects allocated in these components can also be identi-fied and specified by employing those classes in Figs. 8–10for the requester, the agency, and the provider, respec-tively.

(3) The behavioral object sequence diagrams for bookpublishing

After identifying classes, an object sequence diagram isthen created that specifies how these class objects collabo-rate to achieve the teacher’s needs. Figs. 14(a)–14(c) showthe sequence diagrams for those objects in the requester,the agency, and the provider respectively that interact toperform the teacher’s negotiation process for book publish-ing.

5.2. The evaluation

Based on the above illustration, we discuss below howour model facilitates the realization of the negotiation pro-cess in a service-oriented environment.

(1) The model provides a thorough work for specify-ing the negotiation process where considerable issuesare specifically concerned. It uses object-oriented di-agrams to specify step-by-step use cases, architec-tural components, objects in these components, and

J. Lin / Information Processing Letters 108 (2008) 192–203 201

(a)

(b) (c)

Fig. 14. (a) Object sequence diagram for the request and receiving of book publishing services by the service requester. (b) Object sequence diagram forfinding a suitable book publisher by the book publishing agency. (c) Object sequence diagram for delivering book publishing services by the book publisher.

how these objects collaborate to achieve the behav-iors occurring in the negotiation process. We believethese diagrams are quite helpful for understandingand describing the requirements for requesting desiredservices and how to achieve them by negotiating ina service-oriented environment.

(2) The model fits the request and delivery pattern forbook publishing services well. Although illustrated by

a specific case, the model can be easily adjusted forother cases with similar needs. This is because it isbased on the module concept such that each archi-tectural component provides designated behaviors in-dependent of other ones, the addition or modifica-tion of its components can be easily accomplishedby applying some well-known object-oriented main-tenance methods [29]. Generally speaking, the model

202 J. Lin / Information Processing Letters 108 (2008) 192–203

supports the scalability for a service-oriented environ-ment.

(3) The model supports a specification process testable byemploying a use case analysis. The identified use casesare used in determining architectural components tobe constructed; they can also be used as the desig-nated test cases for testing after these componentshave been constructed. In addition, the model sup-ports a traceable specification process, from abstractuse cases to concrete class objects. The outputs ofone diagram are used as the inputs for the followingone while keeping the transition between diagramssmooth.

(4) As stated above, the model supports a traceable andtestable specification process, so it is quite beneficialto assure the correctness of the specification. Hence,our model supports the correctness for a service-oriented environment. It adopts UML notations suchthat each diagram is easy to comprehend. The object-oriented features of these diagrams also make themeasy to be maintained for dealing with the changingneeds that are often introduced in a service-orientedenvironment.

6. Conclusions

Conceptual modeling is an important technique forrepresenting complex situations in an abstract mannerwith concise notations. Motivated by the drawbacks inother methods, object-oriented modeling approaches aredeveloped in order to result in a more natural, under-standable, and maintainable representation. Therefore, ourmodel adopts UML as its object-oriented modeling toolto support the specifications for a negotiation processin a service-oriented environment. In order to deal withthe complexity of negotiating for desired services, com-ponents/constituents in each negotiator are identified andspecified in a top-down fashion. As a result, a higher-level use case diagram is first created that depicts re-quirements for the negotiation process. An architecture di-agram is then used to describe collaborative componentsfor satisfying these requirements where each componentplays a designated role in the negotiation process. Finally,a class/sequence diagram is derived that specifies class ob-jects in these components to perform required behaviorsoccurring within the negotiation process. Since these di-agrams are specified along with an abstraction-realizationpath, they provide a good way for understanding and spec-ifying the negotiation process gradually and easily. Finally,due to the formal semantics of the object sequence di-agram, verification of required behaviors by class objectscan be conducted via formal analysis of the diagram.

The work for negotiating desired services in a service-oriented environment has become a popular discussion.Although some technical research about it has been done,no studies yet provide a thorough conceptual model forspecifying the negotiation process where a considerablenumber of issues are specifically concerned. In our knowl-edge, this may result in poor quality and high mainte-nance costs when developing a service-oriented environ-ment. Our model provides one means of meeting this need

by using object-oriented diagrams, in particular employinga use case analysis that makes it testable, and presentingit along with an abstraction-realization path that makes ittraceable. In general, such a traceable and testable specifi-cation process makes it easy for our model to ensure thecorrectness of a service-oriented environment.

As the technical issues for Web services have gradu-ally matured in recent years, more Web services will beavailable in the near future and hence a comprehensivemechanism for extensive supports of the development ofa service-oriented computing environment will certainlybecome much more desirable. In our view, using object-oriented techniques together with sound modeling con-structs is a promising approach for such a mechanism.In our future work, we will explore further some otherkey issues that our model has not addressed yet, includ-ing, for instance, how an enterprise recognizes its busi-ness objectives and how these objectives are specifiedand achieved by desired Web services under a committedservice-oriented environment. As stated in [30], these is-sues should also be specifically addressed for keeping anenterprise competitive in a dynamic and changeable busi-ness environment. Therefore, how to specify them by ex-tending our modeling constructs will be carefully explored.Meanwhile, we will construct a tool to facilitate practicalapplication of our model. These include a design environ-ment for building the high-level use case and architecturediagrams and then deriving the detailed class and objectsequence diagrams.

References

[1] Extensible Markup Language (XML), http://www.w3.org/TR/xml11.[2] C. Goldfarb, P. Prescod, The XML Handbook, Prentice-Hall, 1998.[3] Simple Object Access Protocol (SOAP), http://www.w3.org/2002/ws.[4] Universal Discovery, Description, and Integration (UDDI), http://

www.ibm.com/services/uddi/standard.html.[5] Web Services Description Language (WSDL), http://www.w3.org/TR/

wsdl.[6] A. Banerji, et al., Web Services Conversion Language (WSCL) 1.0, W3C

note, March 2002.[7] T. Andrews, et al., Business Process Execution Language for Web Ser-

vices (BPEL) 1.1, May 2003.[8] Business Process Modeling Language (BPML), http://www.bpmi.org.[9] M. Champion, et al., Web service architecture, W3C Working Draft,

2003. http://www.w3c.org/TR/2002/WD-ws-arch-20021114.[10] A. Elfatatry, Service-oriented software: A negotiation process, Ph.D.

dissertation, University of Manchester, Institute of Science and Tech-nology, Manchester, UK, 2002.

[11] A. Elfatatry, P. Layzell, Negotiating in service-oriented environments,CACM 47 (8) (2004) 103–108.

[12] K. Bennett, et al., The future for flexible software, in: Proc. of theAsia-Pacific Software Engineering Conference, IEEE CS Press, Dec.2000, pp. 214–222.

[13] P. Faratin, et al., Using similarity criteria to make negotiation trade-offs, in: Proc. of the 4th International Conference on Multi-AgentSystems, 2000.

[14] K. Gottschalk, et al., Introduction to web services architecture, IBMJournal 41 (2) (2002).

[15] N. Jennings, On agent-based software engineering, Artificial Intelli-gence 117 (2000) 277–296.

[16] J. Cameron, An overview of JSD, IEEE Trans. on Software Engineer-ing 12 (2) (1986) 222–240.

[17] M. Jackson, System Development, Prentice-Hall, 1983.[18] E. Yourdon, Modern Structured Analysis, Prentice-Hall, 1989.[19] R. Hull, R. King, Semantic data modeling: Survey, applications, and

research issues, ACM Computing Surveys 19 (3) (1987) 201–260.

J. Lin / Information Processing Letters 108 (2008) 192–203 203

[20] J. Peckham, F. Maryanski, Semantic data models, ACM ComputingSurveys 20 (3) (1988) 153–190.

[21] F. Hayes, D. Coleman, Coherent models for object-oriented analysis,in: ACM OOPSLA Conference, 1991, pp. 171–183.

[22] J. Rumbaugh, et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991.

[23] S. Shlaer, S. Mellor, Object-Oriented Systems Analysis, Yourdon Press,1988.

[24] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Develop-ment Process, Addison Wesley, 1999.

[25] G. Booch, et al., The Unified Modeling Language User Guide, seconded., Addison Wesley, 2005.

[26] M. Fowler, K. Scott, UML Distilled: Applying the Standard ObjectModeling Language, second ed., Addison Wesley, 2000.

[27] J. Rumbaugh, et al., The Unified Modeling Language Reference Man-ual, second ed., Addison Wesley, 2004.

[28] T. Quatrani, Visual Modeling with Rational Rose 2002 and UML, Ad-dison Wesley, 2002.

[29] J. Chen, S. Chang, An object-oriented method for software mainte-nance, in: JOOP, Jan. 1994, pp. 46–51.

[30] F. Casati, et al., Business-oriented management of web services,CACM 46 (2003) 55–60.