SOCA (2011) 5:245–264DOI 10.1007/s11761-011-0088-5

ORIGINAL RESEARCH PAPER

Modeling service representatives in enterprise systemsusing generic agents

Mehran Najafi · Kamran Sartipi

Received: 31 December 2009 / Revised: 11 April 2011 / Accepted: 25 August 2011 / Published online: 16 September 2011© Springer-Verlag London Limited 2011

Abstract As a common practice in business enterprisesystems, a service provider delegates a human agent to aclient site to serve the client. On the other hand, in a comput-erized business application, enterprise organizations adoptService-Oriented Architecture (SOA), where an enterpriseagent is modeled as a software agent that cannot be transmit-ted efficiently by service messages. In the proposed approach,we extend the traditional architecture of SOA implementa-tions to support generic and lightweight agents that reside atthe client site. These agents, that we call “Service representa-tives”, can be customized and trained based on the providergenerated role description and knowledge to perform theirassigned tasks. In addition to providing innovative applica-tions, such a technique allows for more sophisticated featuressuch as maintaining client privacy and separating the func-tionality of the service and its delegated agent. To indicatethe variety of roles that can be done by the service represen-tative, we provide three case studies to show how a local andgeneric agent can be customized by different providers topersonalize financial advice, apply medical guidelines, andverify credit card transactions.

Keywords SOA · Resident agents · Generic agents ·Autonomous agents · Knowledge management ·Context-aware services

M. NajafiDepartment of Computing and Software, McMaster University,Hamilton, ON, Canadae-mail: najafm@mcmaster.ca

K. Sartipi (B)Faculty of Engineering and Applied Science,University of Ontario Institute of Technology (UOIT),Oshawa, ON, Canadae-mail: kamran.sartipi@uoit.ca

1 Introduction

Enterprise systems [1] are strategic communication assets forlarge organizations such as banking, healthcare, and insur-ance companies. An enterprise system is tightly coupled withthe internal structure, processes, and business model of anorganization. Architectures for enterprise systems must befeatured by major non-functional qualities such as simplicity,flexibility, maintainability, reusability, and decoupling tech-nology from functionality.

Service-Oriented Architecture (SOA) [2] is a high-leveland technology-independent concept that provides architec-tural blueprints for enterprise systems. SOA-based architec-tures focus on dividing the enterprise application layer intoservices where each service has a direct relationship with abusiness functionality of the enterprise. In SOA, enterpriserelated tasks are addressed by interactions between serviceclients and providers through services. A service providerregisters its services in a service registry. A service clientinquires the service registry to receive the description of anappropriate service from a provider to satisfy its needs [3].Further on, the requester and the selected provider(s) maynegotiate about the service usage terms [4]. After agree-ment between client and provider, the client invokes theservice. Also, different services can be either composedto serve a client [5], or customized based on a client’scontext [6].

In the real-world business domain, an enterprise organiza-tion usually sends an agent or other personnel (e.g., a repre-sentative, installer, maintainer, or trainer) to the client site todeliver services locally. Accordingly, several organizationalunits in enterprises (e.g., customer service, dealership, train-ing unit, and delivery unit) require to send or employ agentsto serve the clients. Therefore, to provide a comprehensivemodel of enterprises, SOA needs to model enterprise agents

123

246 SOCA (2011) 5:245–264

efficiently. Lack of this model may result in limiting the appli-cations and functionality of SOA-based systems.

XML-based web services are the dominant platformsfor implementing SOA. A web service is defined by themessages it exchanges. That is, a service client sends arequest message to a (web) service provider. Then, theweb service processes the request message and replies bya response message. An enterprise agent can be modeled asan autonomic agent [7] that is a computer program that can-not be transmitted by communication messages efficiently.

In this paper, we extend the traditional architecture ofSOA implementations to enable enterprise systems to employgeneric agents as their service representatives. Instead ofsending different agents to the service client, we maintaina lightweight and generic agent at the client site that can becustomized to act different roles and be trained to performdifferent tasks on behalf of the service provider. The custom-ization and training are performed based on the role descrip-tion and knowledge that are generated by the service providerand can be efficiently transmitted by the messages. The pro-posed approach significantly enhances the capabilities of thecurrent SOA services. Since the proposed agent is local tothe service client, it can customize service responses basedon the client’s context; this mechanism reduces the securityand privacy concerns by eliminating the need to send client’sprivate information to the provider. Finally, the proposedagent represents a service provider at the client site, therefore,we call this agent Service Representative (SR).

The organization of this paper is as follows. Related workis discussed in Sect. 2. Service Representative is introducedin Sect. 3. The proposed architecture and its details are dis-cussed in Sect. 4. Section 5 introduces the developed proto-type system. Three case studies in business, health care, andinsurance domains are explained in Sect. 6. The applicationsand challenges of the proposed approach are discussed inSect. 7. Finally, conclusions and future work are discussedin Sect. 8.

2 Related work

Web services have had quick growing success and broadacceptance by the enterprise systems. However, there are stilla number of impediments that limit the wide applications ofweb services in industry for which, agent-based techniquesseem to be proper solution for enabling dynamic collabora-tion among e-Business systems. Therefore, there are growingdemands for using agents to evolve the current architectureof SOA in several aspects as follows:

1. Agents as services The Intelligence Service System(ISS) [8] is introduced as a framework for integratingexpert systems into service-oriented landscapes. In this

framework, a computerized expert system (intelligentagent) acts as a service, which receives requests (includ-ing query and training data) from business applications.By using the training data, the expert system is trainedand returns its response to the query. Since agent plat-forms [9] and web service platforms have similar compo-nents (registry, descriptor, communication protocol, andsemantic language), AgWebs architecture [10] is pro-posed to provide interoperability and interaction betweenthem.

2. Services as agents In ASMF [11], a network of webservices is modeled by a number of autonomic agents(each service is wrapped into an agent). Furthermore,these agents interact with each other to form service rela-tionships. In addition to service agents, service brokersare designed as autonomic elements. In [12], a role-basedarchitecture is adapted to facilitate the service definitionand relationship among SOA components.

3. SOA related tasks by employing agents Agents havebeen used to facilitate SOA related tasks such as ser-vice composition and service negotiation. In [13], duringa service composition process, software agents engagein conversations with their peers to agree on the webservices that participate in this process. Moreover, agentshave been proposed as coordinators for web services. Forexample, [14] introduces a service processing agent thatsearches, selects and invokes service components for aservice composition, dynamically and according to theuser’s context.

4. Agent-based enterprise modeling Integration of agentsand web services has been proposed to model thebusiness aspects of enterprise systems. In [15], each roleor major function of an enterprise system is consideredas an agent (e.g., supplier agent, producer agent, coop-erative agent, information service agent, and customerservice agent). Then each agent is wrapped into a webservice. The agents, when combined with web services,can easily communicate with each other. As anotherexample, a distributed market place is modeled by agents[16]. In this approach, service providers and clients areconsidered as sellers and buyers, where an agent mod-els each buyer or seller. These agents can negotiate witheach other until they reach an agreement.

In the proposed model, we address a new application ofcollaboration between agents and services. The proposedgeneric agents are in charge of delivering the functionality ofservice providers, but, these agents are located at the clientsite.

Mobile agents can physically travel across a network andperform tasks on different nodes. Agent mobility requiresfacilities that convert an agent into a form suitable fornetwork transmission (e.g., messages) and, on the receiving

123

SOCA (2011) 5:245–264 247

end, allow the remote system to reconstruct the agent. Java’sobject serialization accomplishes this conversion and recon-struction. Concordia [17], Odyssey [18], and Voyager [19]are examples of mobile agent frameworks based on java.Also, mobile agents are suitable to be formally representedusing pi-calculus [20]. There are several security and privacyissues to be considered in mobile agent-based computing.Viruses and malicious attacks are other possible vulner-abilities of mobile agent systems. Mobile agent architec-tures also suffer from low efficiency as they need to sendthe entire computer program or process. Moreover, flexi-bility and interoperability concerns must be considered inthese approaches. These issues motivated us to customizegeneric resident agents as opposed to transmitting mobileagents.

3 Service representatives

We propose to extend the major components of SOA (ser-vice provider, service requester, and service registry) with theservice representative, as it is shown in Fig. 1. In this sec-tion, first we address the limitations of the existing SOA-based technologies to model enterprise services. Then, weintroduce the notion of service representative that can beimplemented using resident generic agents to facilitate deal-ing with these limitations.

3.1 Existing technology issues

As mentioned earlier, enterprise services are modeled basedon message exchanges. A service is typically defined usingWSDL technology that represents the request message thatthe service provider receives and the response message that itgenerates. This message-based structure imposes limitationson enterprises that aim to use SOA to provide their services.Some of these limitations are listed below.

Fig. 1 Proposed extended SOA model. The shaded area representsthe non-essential component (service registry) in the SOA model. Thismodel also supports the traditional service invocation where the serviceprovider returns the service response directly to the service client

Functionality limitation There are several types ofservices that cannot be modeled efficiently by messageexchanges, such as

– Supervisory service which is called to control clientresources. A set of provider generated messages cannotperform this task since it needs an executable platform atthe client site that has access to the local resources.

– Event-triggered service which is called by a client, andthe service will wait until a predefined event occurs at theclient site. Implementing these services by the messageexchange technology requires a permanent connectionbetween the provider and the client.

– Advertising service which introduces other services inthe enterprise while performing its task. A message-based service sends a response message to the clientbased on the query in the request message, without anyopportunity to advertise other services. Even if the pro-vider embeds advertisement messages in the responsemessage, the client cannot extract them since it lacksthe required mechanism to predict that advertisementmessages will be received.

Privacy and security issues Since web services pro-cess client requests at the provider site, the client mayneed to include personal information in the request mes-sages. This may cause significant privacy and securitybreaches.

Needs for expertise As providers pack their responses inthe form of messages, the interpretation of these messagesis the client’s task. So, it is likely that a client lacks enoughexpertise and knowledge to understand and use the serviceresponses. This situation gets worse as a client has to dealwith different providers in different domains.

Service competition Message-based web service provid-ers are usually passive in dealing with enterprise issues.They register the descriptions of their services into aservice registry, then it will be the responsibility of serviceclients or coordinators to discover and compose those ser-vices. Active providers are expected to address the enter-prise issues more efficiently. For example, in the case ofservice discovery, instead of analyzing the service descrip-tions to find the best service for the client’s needs, the candi-date services can compete and the client simply chooses thewinner.

Stateful services According to the SOA’s requirement,web services should be designed to work in a statelessfashion. However, in some situations, message exchangetechnologies force developers to implement stateful services.For example, efficient service negotiation techniques ask theproviders to keep track of a negotiation process initiated bya client.

123

248 SOCA (2011) 5:245–264

Fig. 2 Relationship among data, information, knowledge, and theservice representative in the proposed model

3.2 Generic agent as service representative

Sending agents as service responses (mobile agents) couldfacilitate dealing with the above limitations; however, themessage-based structure of web services does not allow pro-viders to dispatch their agents efficiently. We propose anextension to the existing SOA architecture that utilizes theconcept of “generic agents” that are resident at the client siteand are customizable and trainable for different roles. Theproposed architecture requires that the service provider onlytransfers essential messages to customize and train a genericagent, as opposed to sending the entire agent. Since the agentexecutes at the client site and has access to the local resourcesof the client, it can potentially violate the client security andprivacy. To prevent this, we limit the power of the agent byrestricting the resources that it can access.

The proposed architecture organizes the contents of thecommunication messages into three segments “data”, “infor-mation”, and “knowledge” [21], where: (1) data is defined asraw fact; (2) information is the result of applying knowl-edge on data; and (3) knowledge is an understanding of howto process data to produce information, based on evidences,experience and insight that can be represented as guideline,decision-flow or patterns of data.

In this context, the service client asks to receive informa-tion from the service provider by sending a request message.The service client may receive the resulting information in aresponse message directly from the service provider or indi-rectly through the service representative. Therefore, the pro-posed service representative can be viewed as an agent thatworks in a knowledge management environment illustratedin Fig. 2. The service representative, which is modeled by aresident generic agent, provides the following facilities forthe SOA architecture.

More sophisticated functionality By introducing an exe-cutable platform at the client site, service providers canoffer innovative services. For example, a service represen-tative can be customized and trained to advertise other

Fig. 3 Structure of an autonomous software agent, called MAPE-K(monitor-analyze-plan-execute over a knowledge base), proposed byIBM [22]

provider’s services, control local resources or be activatedwhen an event occurs.

More privacy and security As the service represen-tative has access to local resources at the client site, theclient does not need to send its personal data to the pro-vider in order to receive customized services. Moreover, weimpose two constraints to preserve the client privacy andsecurity. First, the client determines local resources that theservice representative can access to them. Second, the com-munication between the provider and its agent is one way(from providers to service representatives), which impliesthat the agent cannot return any of the client’s resources to theprovider(s).

Local and trainable experts A service provider can traina generic agent to interpret its response messages in the formsthat a client can understand. Also, the agent can guide aservice client on how to use the service responses.

Active providers When a generic service representative iscustomized and trained, it can represent its provider regard-ing its assigned role in performing the enterprise relatedtasks. Popular and high-demand tasks can be pre-defined asstandard tasks to be dispatched to the generic agents. Forexample, in the case of service discovery, after customizinggeneric agents by different providers, they can compete onbehalf of their providers to find the best service for a client.

Stateless services By employing the service representa-tives, enterprise related tasks can be modeled for statelessservices efficiently. In other words, by assigning an agentto each client, providers do not need to keep the state ofeach request. For example, in a service negotiation scenario,a provider sends essential negotiation skills to the servicerepresentative to negotiate with the client about the terms ofusing the service.

An enterprise agent can be modeled as an autonomicagent, shown in Fig. 3, and hence can be defined using atuple of its components, as below:

– Sensors act as the agent input devices and obtain datafrom the system.

123

SOCA (2011) 5:245–264 249

– Monitor scans the sensed data that is generated by thesensors, to extract the relevant data.

– Analyzer analyzes or modifies the monitored data in away that the agent can use them.

– Knowledge Base contains knowledge sentences that otheragent components can use to perform their tasks.

– Executor processes the input data and generates the outputas information.

– Planner acts as the brain or controller of the agent thatspecifies how the executor generates outputs or how andwhen the knowledge base can be used.

– Effectors act as the agent’s output devices.

The generic service representative is defined based onits generic components (generic sensors, generic monitor,generic analyzer, generic execute, generic effectors, andgeneric knowledge base). The agent planner (the only con-crete component) is in charge of concertizing the genericcomponents based on the provided role (or role description)and knowledge (or role knowledge) to perform the assignedtask. The role description is a list of the tasks, functions, orresponsibilities, and role knowledge is the required exper-tise that the service representative needs to complete thedescribed tasks and responsibilities. The planner transformsa generic service representative into a specific service repre-sentative in two phases (customization and training) and thenexecutes the assigned task in the execution phase, as follows.

1. Customization In this phase, the planner sets up the agentconfiguration (including SR sensors, effectors, and exe-cuter) and creates an abstract process in the SR executerbased on the role description.

2. Training In this phase, the planner uses the role knowl-edge to train the customized agent for the assigned role.The role knowledge can be received from the provideror/and extracted from the local knowledge base. Con-sequently, the abstract process will be completed toperform the specified tasks.

3. Execution In this phase, the customized and trained ser-vice representative receives the client’s local data (viathe sensors and monitors), adapt them (via the analyzer),executes the created process to generate the requestedinformation (by executer), and delivers the information(via the effectors) to the client.

4 Extended SOA architecture

In this section, we extend the typical architecture of SOAimplementation to enable service providers to employ thegeneric service representative at the client site. The proposedarchitecture is illustrated in Fig. 4 and consists of three maincomponents: service provider, service client, and service

representative. The message transmissions among these com-ponents are as follows. A service client sends a request mes-sage (data) to receive a service response (information) from aservice provider. In a simple model of communication (with-out using the service representative), the provider’s informa-tion layer receives and processes the request message thatcontains client data and returns the resulting informationback to the client application. This model represents tradi-tional web services. In an agent model of communication(with using the service representative), the client request isprocessed at both provider and client-side as follows.

1. At the provider site, the customization and traininglayers send a role description and required knowledgeto the service representative to process the client datalocally to generate the requested information.

2. At the client site, the generic service representativereceives the role description and knowledge segmentsand evolves into a customized service representative.Then, it performs the assigned tasks on the clientlocal data that are available through the communicationchannel.

The specification for each component of this architectureis given in the following subsections.

4.1 Service provider model

In contrast to the existing SOA models whose serviceresponse messages have only one segment (information), theproposed model introduces service response messages withthree segments (role, knowledge, and information). Accord-ingly, the service provider consists of three layers that aredesigned to work independently, and each layer is respon-sible to provide one segment of the response message, asfollows.

Customization layer This layer specifies a role forthe generic service representative to customize and per-form assigned tasks on behalf of the provider. First, a role(e.g., negotiator, customizer, or adaptor) is assigned to thegeneric agent. The role can be determined explicitly, i.e.,the client specifies it in the request message, or implicitly,i.e., the customization engine predicts it based on the pre-vious similar situations. Then, this layer specifies the agentconfiguration for the assigned role including the type andspecification of the required sensors, effectors, analyzer, andexecutor. Moreover, the role specification includes a processmodel describing the order in which a series of steps (calledtasks) needs to be executed.

The required knowledge for each step of the role pro-cess can be provided either locally by the SR knowledgebase or remotely by the provider’s training layer. Since theservice provider can employ the service representative for

123

250 SOCA (2011) 5:245–264

Fig. 4 Proposed architecture. Based on the client’s request, the service provider generates a 3-segment response message to customize and train aclient-side generic agent as its representative to serve the client

different roles, the roles configuration and description arekept in the role database. Conceptually, this layer can beviewed as a technical support unit in an enterprise organi-zation that informs a technician their responsibilities abouta customer or a product. The layering structure of the pro-posed model implies that the customization layer should beindependent from the knowledge layer. It is based on thefact that technicians are assumed to be knowledgeable whenthey are assigned some tasks. They only receive the over-all task description while their knowledge are provided fromother sources, such as education, training, past experiences,or following strict guidelines.

Training layer This layer generates the knowledgesegment of the response message, based on the knowledgemodel specified in the customization layer. The knowledgeis provided using knowledge representation techniques andis stored in the knowledge base.

Information layer This layer essentially represents theservice provider in the traditional model of SOA, where theservice provider receives a request message from a client,processes its data, and returns the result of the operation ondata (as information) back to the client via the informationsegment of the response message. This layer provides thecompatibility of the proposed SOA model with the existingmodel.

4.2 Service client model

A service client consists of a client application and a com-munication channel, as follows.

Fig. 5 Example of a communication channel

Client application This is a traditional client applicationthat generates and sends request messages to service pro-viders. The client application will receive the informationsegment of the response message. This information can beeither consumed directly or passed to the service representa-tive via the communication channel to be modified by theservice representative. The service provider publishes therequired communication channel schema for each client-sideweb service in the service registry using WSDL documents.In order to call a client-side web service, the client applica-tion needs to put the client data in the communication channelbased on this schema.

Communication channel This channel consists of anumber of ports that are connection links to the internalresources of the client application, as well as the means forthe client application to receive the result of the requestedtask through the service representative. A client grantspermission to the service representative to read/write a num-ber of its resources through this channel. The ports can beinput, output, or input/output (from the client point’s of view).Input ports can be read by the SR sensors and output portscan be written by the SR effectors. One instance of a com-munication channel is shown in Fig. 5.

123

SOCA (2011) 5:245–264 251

4.3 Service representative model

As mentioned earlier, a generic service representative istransformed into a specific service representative aftercustomization and training phases. The agent then modifiesthe client’s internal resources through the communicationchannel. A service representative is modeled by an autono-mous structure as follows.

– The sensors and effectors are connected to ports in thecommunication channel.

– The knowledge base contains the internal role knowl-edge that is pre-loaded by the client or received fromexternal resources. The received knowledge from webservices can be stored to relieve web services from send-ing them each time. Moreover, by storing basic knowl-edge of a specific domain in the SR knowledge base,we can develop domain-specific service representativeswhere they can perform the domain relevant tasks effi-ciently.

– The planner has functions to configure the agent and aprocess engine to follow different steps of the assignedrole.

– The monitor and analyzer receive and convert the sensedinput data to a format that is understandable for the agent.

– The executor contains one or more knowledge modelinstances that are specified in the customization phaseand trained in the training phase.

In the execution phase, the service representative performsits assigned role as follows: (1) the sensors read client datafrom the communication channel; (2) the relevant data areextracted by the monitor, and the analyzer converts theminto a proper format for the service representative; (3) theseinput data are fed to the knowledge models in the executor;(4) the trained knowledge models will be applied to the datato generate the output results; and (5) the results are writtenback to the communication channel by the effectors.

4.4 Types of supported services

The proposed architecture is an extension to SOA, henceit must cover the typical SOA services where there is noneed for the proposed service representatives. Moreover, theservice representative can work in two separate modes, there-fore, the proposed architecture can model three types of ser-vices, which are described below.

– Type 1 The service response only contains “informa-tion segment” that is received by the client application,while the role and knowledge segments are empty. Type 1includes typical web services provided by traditional ser-vice providers that do not need to employ agents in orderto serve the clients.

– Type 2 The service response contains “role” and “knowl-edge” segments that are received by the service repre-sentative, while the information segment is empty. Basedon the role description, the service representative appliesthe received knowledge to the local client data and pro-vides resulting information as the service response for theclient.

– Type 3 The service response contains “role”, “knowl-edge”, and “information” segments. In this case, two sce-narios are possible: (a) the service client uses the receivedinformation and the service representative performs itsassigned task to provide additional information for theclient and (b) the service client redirects the informationto the service representative in order to be modified orused during the service representative task execution.

Finally, because web services of Type 2 and Type 3 areexecuted at the client-side, we call them client-side webservices as opposed to web services of Type 1 that are exe-cuted at the server-side.

5 Prototype system

To evaluate the effectiveness and feasibility of the proposedextend SOA model, we developed a prototype system ofthe proposed architecture including the service representa-tive as well as the extended service client and provider. Thisprototype, namely SR version 1.0, is developed based onJ2EE 1.5 technologies and Apache Tomcat 6.0 applicationserver, which can be used by the service developers andclients to develop and invoke the client-side web services,respectively.

The developed service representative has a built-in Drools[23] process engine (located in the SR planner component) toexecute the process included in the role segment of each ser-vice response. The SR v1.0 uses the Drools rule flow as theprocess model for the client-side web services. Moreover,SR v1.0 can receive and understand knowledge sentencesthat are compatible with PMML (Predictive Model MarkupLanguage) V3 [24], as follows.

– Rule-based model: It consists of rule-based knowledgesentences in the form of if-then-else statements such asthe following pattern.

If Condition (clientData)Then serviceResponse = Modify (initialResponse)

The above knowledge sentence states that if the definedcondition on the client data (clientData) is true, thefinal service response (serviceResponse) is obtained byapplying the modification function to the received service

123

252 SOCA (2011) 5:245–264

response (initialResponse). Relevant rule-based state-ments can be grouped into the same category to be evalu-ated at the same time. Moreover, different rule categoriescan be ordered to be executed sequentially. SR executeruses the Drools rule-engine to apply the rules to the clientdata using the forward chaining strategy. In this strategy,a rule engine matches data against the rules to infer con-clusions, which result in actions.

– Mining model: It represents the result of applying a datamining algorithm to training data and the resulting modelcan be used to analyze new data. A mining model isspecified by two elements: model signature and modelcontent. A model signature is in the form of a 3-tuple< t ype, inputs, outputs > that represents the struc-ture of the model. Each mining model has a number ofparameters whose values (assigned in the training phase)specialize the model for a specific task. The model param-eter values identify the content of each mining model. SRVersion 1.0 supports two types of mining models: neuralnetwork [25] and decision tree [26].

– Neural network: It includes a network of simple pro-cessing elements (called neurons) that can exhibitcomplex global behavior, determined by the neuronsinterconnections and their assigned weights. Learn-ing in neural network involves adjustments to theneurons and interconnection weights. There are twodifferent styles of training that are both supported bySR Version 1.0. In incremental training, the weightsand biases of the network are updated each time aninput is presented to the network, while in batch train-ing, the weights and biases are only updated after allthe inputs are presented. To support neural networks,SR executer has the following components: (1) a neu-ral network builder to build the structure of the modelbased on the received model signature; (2) a neu-ral network trainer to train the model based on themodel content; and (3) a neural network executor toapply the model to the client data and returns theresult.

– Decision tree classifier: It is a predictive model that ispresented in the form of a tree. Decision tree learninginvolves constructing a tree by recursively partitioningthe training data. In each step, a node is added to thetree to represent a new partitioning. The nodes andtheir edges represent the content of a decision tree.Similar to the neural network model, the SR executercontains: (1) a decision tree builder and (2) a decisiontree executor to work with decision trees.

Finally, SR version 1.0 is provided as two Java packages:ServiceDeveloper and ServiceRep, which can be importedinto any service provider and client applications as follows.

– ServiceDeveloper package: a service developer uses thispackage to develop a client-side web service graphicallyusing the Drools APIs and widgets. Figure 6 (top) repre-sents a snapshot of the Client-side Web Service Developerapplication, developed based on this package.

– ServiceRep package: a client application developer usesthis package to generate one instance of the servicerepresentative and communication channel. Using theprovided APIs, the client application can supply the cli-ent data to the communication channel, according to thechannel schema that is obtained from the service regis-try. The communication channel schema is also passedto the service representative instance to configure itself.After configuration, the client invokes the client-side webservice from the provider and blocks itself to receivethe service response from the service representative andthrough the communication channel. Figure 6 (bottom)shows a snapshot of the Service Representative Manager,which uses this package to monitor different phases of aclient-side web service invocation.

6 Case studies

In order to present and evaluate diverse applications of theproposed service representative, we designed and developedthree case studies in different domains: banking, health care,and insurance. Since web services of Type 1 in the proposedSOA model refer to typical web services, we only focus onweb services of Type 2 and Type 3, discussed in Sect. 4.4.To reduce the redundancy and cover different aspects of theproposed model, similar parts are eliminated in the followingcase studies.

6.1 Case study 1: highly secure financial adviser

In order to call a context-aware service, a service client shallreveal her contextual information to the service provideror a context manager, while this may violate her informa-tion privacy and security. For example, to provide person-alized advice, traditional financial advisers ask for personalinformation from their clients (e.g., client’s portfolio or cashinformation). In the first case study, we present a secure finan-cial adviser in the context of stock market where a serviceuses the service representative to personalize financial advicewithout asking the client to send her personal information.To call this web service, the client sends a request to the ser-vice provider to receive financial advice and then providesher financial information (client data) to the service represen-tative through the communication channel. After processingthe client request, the service provider responds a messagewith the following components.

123

SOCA (2011) 5:245–264 253

Fig. 6 (Top): snapshot of the“Client-side Web ServiceDeveloper”, used by a servicedeveloper to develop aclient-side web service.(Bottom): snapshot of the“Service RepresentativeManager”, used by a serviceclient to monitor a client-sideweb service invocation(e.g., a decision support servicein this case)

– Role segment: financial advice customizer.– Knowledge segment: guidelines to personalize general

advise based on the client’s portfolio.– Information segment: general financial advice.

Case study specification The process of generating finan-cial advice could be very complicated and is out of scopeof our discussion. In this case study, we are interestedonly in the personalization procedure, as follows. Thisservice receives client’s general preferences such as categoryof investment (stock, option, or mutual fund); term duration(short term or long term); and risk level (low, medium, orhigh). However, the client keeps her sensitive informationlocal and private, such as client’s financial information (port-folio and cash). Then, the service provider generates a set ofgeneral financial advice (stock buy and sell advice) accordingto the client preferences.

Fig. 7 Communication channel schema in the financial adviser casestudy

Each general financial advice is in the form of eitherBuy Advice = < Share Symbol, Min Percentage, SharePrice> or Sell Advice = <Share Symbol, Max Percentage,Share Price>. A stock buy (or sell) advice recommends theclient to have minimum (or maximum) percentage of a spe-cific share in their portfolio. The service provider assignsthe role of advice customizer to the service representativeto personalize the general advice based on the local cli-ent’s financial information and by performing the followingoperations.

123

254 SOCA (2011) 5:245–264

– For each sell advice: if the share symbol is not avail-able in the client’s portfolio, ignore the advice. Oth-erwise, compute the number of this share that theclient should sell based on the client’s portfolio and theadvice max percentage field.

– For each buy advice: if the client does not have enoughcash to buy the corresponding share, ignore the advice.Otherwise, compute the number of this share that the cli-ent should buy based on the client’s cash and the advicemin percentage field.

Service client The client application sends a request mes-sage to receive financial advice. The request message doesnot contain sensitive financial information of the client.Moreover, the client application supplies its portfolio andcash information into the communication channel (Fig. 7),based on the communication channel schema published onthe service registry. Finally, the service client receives thefinal customized advice from the service representative andthrough the communication channel.

Service provider The three layers of the service providerare specified as follows.

1. Customization layer specifies the role of financial advicecustomizer for the service representative (shown inFig. 8). For this purpose, it first assigns a process ofapplying two categories of rule-based knowledge mod-els to the general advice. Moreover, client’s portfolio,holding, and cash information are assigned to the SRsensors, and an effector is considered to return the cus-tomized advice to the client.

2. Training layer encodes the advice personalization knowl-edge sentences (represented in Fig. 9) into the knowledgesegment of the response message.

3. Information layer is fed by either an automated systemor a financial expert who generates financial advice in

the specified format in Case Study Specification section,such as the following advice.

Buy Advice: <MSFT, 12%, 25.12$>

Sell Advice: <AAPL, 5%, 344.00$>

This advice is assembled into the information segmentof the response message.

Service representative The SR planner uses the role seg-ment of the service response to customize the generic servicerepresentative to be a financial adviser by performing the fol-lowing tasks.

1. Generates an abstract process with two sub-processesbased on their descriptions in the role segment. This pro-cess is placed in the SR executer.

2. Assigns a rule-based knowledge model to each of thegenerated sub-processes.

3. Connects the SR sensors to the Read ports of the commu-nication channel to provide client personal data as inputsfor the knowledge models.

4. Connects the SR effectors to the Write port of the com-munication channel to return the customized advice.

In the training phase, the planner loads each rule-basedmodel by the received customization knowledge from theservice provider. Finally, in the execution phase, the SR exe-cuter runs the generated process where in each step of thisprocess, it applies the corresponding rules to customize thegeneral advice.

This web service can be more sophisticated if the SR ana-lyzer is involved to convert the client data into a proper formatfor the knowledge models. For example, if the client uses adifferent currency than the general advice, the agent ana-

Fig. 8 Role description of the service representative in the financial adviser case study

123

SOCA (2011) 5:245–264 255

Fig. 9 Advice personalization knowledge

lyzer can exchange their currency before applying the mod-els. Finally, the service representative stores the customiza-tion knowledge into its internal knowledge base to relieve theservice provider from sending them each time.

The message exchanges between the service provider andthe service client is shown in Fig. 10. The XML schema ofthe request and response messages are displayed in Figs. 11and 12. By using these schemas, we developed WSDLdescription of this web service and then we used a top-downapproach to implement the body of this web service.

6.2 Case study 2: agent-based clinical decisionsupport system

In this section, we present a case of a Clinical DecisionSupport System (CDSS) in the context of vascular diseases.A CDSS provides recommendations for both patients andphysicians by applying its medical guidelines to the per-sonal health information, known as Personal Health Record(PHR) or Electronic Medical Record (EMR). A typical CDSSrequires that the patients send their information that may vio-late their privacy and security. Moreover, as a medical centercalls the same CDSS for different patients, transferring PHRsover the network increases the network traffic significantly.Based on the proposed model, a CDSS can employ the ser-vice representative to apply its medical guidelines to the localPHRs to improve the security and efficiently.

We modified a CDSS that is called Vascular Tracker (VT)[27] to work based on the proposed model, as follows. A phy-sician (service client) supplies the patient’s PHR information(client data) into the communication channel and sends a

Fig. 10 Message exchanges between the secure financial adviser webservice and the service client

Fig. 11 Financial adviser request message schema (FinancialAdviser-Request.xsd)

request message to receive medical advice. The CDSS (ser-vice provider) response message contains three segments asfollows:

– Role: clinical decision support agent.– Knowledge: medical guidelines.– Information: none.

123

256 SOCA (2011) 5:245–264

Fig. 12 Financial adviser response message schema (FinancialAdviserResponse.xsd)

This service is categorized as Type 2 of the proposed ser-vices and uses mining models as its knowledge models. Dif-ferent parts of this system are described below.

Case study specification COMPETE III VascularTracker (C3VT) [27] is a decision support system that assistsphysicians to observe and ideally control patient’s different

123

SOCA (2011) 5:245–264 257

Fig. 13 Communication channel schema in the agent-based CDSS

risk factors within the domains of cardiovascular, diabetes,hypertension, and dyslipidemia diseases. C3VT’s databasecontains a large body of medical guidelines collected using amethodology known as evidence-based practice. The clinicalalgorithms are so fine-tuned that cover different cases of mostindividual patients and is confidently used by a large group ofphysicians. The VT guidelines are categorized into diabetes,hypertension, dyslipidemia, coronary artery disease, cere-brovascular disease, peripheral vascular disease, and healthy.Each category has a number of corresponding guidelines thatcan be applied to a patient’s PHR in a specific order. Asa result, each medical guideline generates recommendationmessages for both physicians and patients. Moreover, VTdefines a schema for the request messages including vascu-lar-related PHR information such as blood pressure, HBA1Cresults, eye exam, weight, and diet that must be provided bya caller to use this CDSS. In this case study, we use the ser-vice representative to apply the medical guidelines (receivedthem from VT) to a local PHR at the client site.

Service client The client application sends a request mes-sage to receive medical advice and recommendations. Therequest message does not contain the patient’s informationand only identifies the category of VT supported diseases thatapply for the patient. The client supplies the patient’s infor-mation into the communication channel (Fig. 13), based onthe VT schema published on the service registry. There arealso two ports of the communication channel that allow thepatient and physician to receive the medical recommenda-tions and alert from the service representative.

Service provider The developed service provider is amodified version of the VT CDSS where its three-layer archi-tecture enables VT to offer high privacy for their clients.Since this service is of Type 2, the data are provided to theSR by the client application and therefore the informationlayer is not required. The customization and training layersof the service provider are specified as follows.

1. Customization layer specifies the role of CDSS agentfor the service representative based on the received VTdiseases category from the client. A SR role descrip-tion to provide recommendations in the case of diabeticpatients is displayed in Fig. 15. The corresponding pro-cess defines a sequence of medical guidelines that shouldbe applied to the relevant patient’s PHR. Moreover, thislayer defines the SR configuration to perform this roleas follows. It assigns a sensor for the relevant patient’sPHR and two effectors for the patient and physician rec-ommendations. Finally, this layer specifies the required

knowledge model in each step of the process that includesthe type of the model (decision tree), model inputs (rele-vant PHR information), and model outputs (patient andphysician recommendations). In other words, it specifieseach knowledge model by defining its signature.

2. Training layer provides the specified medical guide-lines in the customization layer where each guideline isencoded as a decision tree. A corresponding decision treeto a set of VT medical guidelines is displayed in Fig. 14.This guideline gives recommendations to both patientand physician about the result of a blood test (Hb1Ac)with considering three patient PHR fields. The decisiontree parameters including the decision and split nodesinformation (i.e., model content) are serialized into theknowledge segment of the response message.

Service representative The planner customizes thegeneric SR by connecting the sensors and effectors to the cor-responding ports of the communication channel and instan-tiating a process with the corresponding sub-processes inthe SR executer. To complete the customization phase, theplanner assigns one decision tree builder object to each sub-process. Also, the received knowledge is stored in the SRknowledge base that can be reused in the next service calls. Inthe training phase, each decision tree is reconstructed basedon the received knowledge to represent an executable med-ical guideline at the client site. Finally, the executer applieseach decision tree to the patient’s PHR and the outcome (rec-ommendations) is written to the communication channel.

6.3 Case study: customizable credit card fraud detector

In this section, we present a case of fraud detection in the con-text of credit card transaction systems. The legal or fraud pat-terns in the credit card transactions can be identified by eithersymbolic or numerical models. A symbolic approach usesknown fraud patterns while a numerical model uses a neuralnetwork to classify the transactions. In general, a sophisti-cated fraud detector system requires a large number of train-ing instances from different locations of the covered regionwhich may have different patterns of fraud. In such cases, afraud detector that is customized based on local data seemsto be more proper and accurate for small and medium sizeorganizations such as a bank or an insurance company. In thiscase study, we are interested in a fraud detector web servicethat takes local data into account to verify credit card transac-tions. Based on the proposed model, a service provider canuse the service representative to build a customized frauddetection model at the client site, as follows:

A service client gives permission to the service repre-sentative to read the local transaction information via thecommunication channel and sends a request message toreceive a fraud detector service. The fraud detector service

123

258 SOCA (2011) 5:245–264

Fig. 14 Decision tree representing a VT medical guideline that corresponds to one step of the process described in Fig. 15

Fig. 15 Role description for the service representative to perform as a CDSS agent

responds with a message containing three segments as fol-lows:

– Role: credit card fraud detector.– Knowledge: symbolic fraud detection model and guide-

lines to build a local numerical fraud detection model.– Information: none.

In this case study, we use both the rule-based and miningmodel knowledge to train the service representative. Differ-ent parts of this system are described below.

Case study specification Each transaction is representedas a tuple x of features (x =< x1, . . . , xn >). Fea-tures can be symbolic (e.g., type, address) or numerical(e.g., time, money). Consequently, the symbolic and numer-ical fraud detectors operate on symbolic and numerical

123

SOCA (2011) 5:245–264 259

features, respectively. Two metrics are usually used to eval-uate a fraud detector system as follows: precision indicatingthe number of found fraud transactions relative to the totaltested transactions; and confidence indicating the accuracy ofthe method. While, the symbolic model offers high precision,the numerical model yields higher confidence. A sequentialcombination of these models is reported in [28] to provideboth high precision and confidence. Instead of applying ageneral fraud detector model to a target transaction at theprovider site, the proposed approach uses the service repre-sentative agent to customize and apply a fraud model to thelocal transactions at the client site.

Service client The client application connects a read portof the communication channel to its database containing thelog of the collected local transactions (training data). Thetarget transactions to be checked for fraud (testing data) arealso supplied into a read port of the communication channel.There is also a port that the service representative writes theresults of the local transactions verification for the client. Thestructure of the communication channel is shown in Fig. 18.Therefore, the client application only sends a request mes-sage to the service provider, which does not include localtransaction information.

Service provider The service provider is a modified ver-sion of the sequential fraud detector presented in [28]. Similarto the second case study, this web service is categorized asType 2 and its required data is supplied solely by the client.The customization and training layers of this service providerare specified as follows.

1. Customization layer defines a role for the service rep-resentative to customize a numerical model using clientdata and then apply this model. Moreover, the SR is askedto reconstruct a symbolic model from the received modelparameters from the service provider and then apply thismodel to the local transactions. The final verification willbe obtained by a selection model. Figure 16 illustratesthe role description where the assigned process includesone mining and two rule-based knowledge models asfollows.

– Model I is an incremental Radial Basis Function(RBF) model to represent a numerical fraud detec-tor. This model is generated and customized at theprovider and client site, respectively.

– Model II is a rule-based model to represent a symbolicfraud detection model.

– Model III is a rule-based model that acts as an arbi-trator between the other two models.

2. Training layer generates or extracts the model contentfor each specified model in the customization layer, asfollows.

– Model I: It is initiated based on the provider trainingtransactions. In this case study, each training instanceis a tuple of (x1, x2, . . . , x8, y) where xi representsthe amount of money that a credit card holder spentin the i th week and y represents the legal or fraudresult for this instance. After training the RBF, itsparameters are encoded by PMML and are put in theknowledge segment of the response message.

– Model II: It is a number of if-then-else rules that rep-resent the relations between the symbolic features andfraud. These rules can be obtained based on the gen-eralization techniques described in [28] and is shownin Fig. 19. In this technique, fraud transactions arecompared with each other to find the similar pairs.Each pair is then merged into a generalized rule byreplacing a non-identical feature by a don’t-care sym-bol “*”.

– Model III: It describes a sequential combination ofModels I and II that improves the performance met-rics of the fraud detector. These rules are listed in(Fig. 17), where the decisions for fraud by the sym-bolic model are checked additionally by the numer-ical model to increase confidence and decrease thenumber of false alarms.

Service representative After setting the SR configurationin the customization phase, the SR planner trains the threespecified knowledge model as follows. The numerical model(Model I) is initially built from the received model parame-ters and then it is completed by the client training transactionsreceived from the SR sensors. Moreover, the symbolic model(Model II) and the selection model (Model III) are loadedwith the received rules. In the execution phase, the servicerepresentative applies the customized numerical model andthe symbolic model to the local transactions, and finally, theadjusted result that is obtained by applying the third modelis written back into the communication channel to be usedby the client.

6.4 Evaluation

To compare the proposed client-side web services with thetraditional server-side web services, we developed an equiv-alent traditional web service for each of the described casestudies, as follows.

1. A financial adviser web service that takes client’s portfo-lio and cash information and returns personalized adviceto the client.

2. A clinical decision support service that takes patient’sPHR information; applies the vascular tracker guide-lines; and returns recommendations for both the patientand the physician.

123

260 SOCA (2011) 5:245–264

Fig. 16 Role description for the service representative in the customizable fraud detector case study

Fig. 17 Required knowledge for Model III, in the customizable fraud detector, to combine the verification results obtained by a symbolic and anumerical approach

3. A customizable credit card fraud detector service thattakes transaction records stored in the client database aswell as the target transaction and returns the verificationresult to the client.

As our evaluation metrics, we used the QoS parameters tocompare proposed client-side and traditional server-side webservices. The QoS parameters for web services refer to thequality aspect of a web service. These parameters are used asconstraints when a service client searches for the best service.Service Level Agreements (SLA) are also defined based onthe QoS parameters. These may include performance, avail-ability, scalability, accuracy, accessibility, security, privacy,throughput, and network-related QoS requirements.

The traditional web services (Type 1) are differentiatedfrom the proposed services (Type 2 and Type 3) by the plat-form where the client data are processed. While the formerintegrates all the processing at the server platform, the latterdistributes the processing between the server and client plat-forms. This directly affects the performance parameters (e.g.,response time), network-related QoS metrics (e.g., message

Fig. 18 Communication channel schema in the customizable creditcard fraud detector case study

size), and the client privacy. There are also QoS parametersthat depend on the performance and network parameters suchas throughput, scalability, and capacity. However, other QoSmetrics are independent of client-side or server-side process-ing of client data such as accessibility, security, accuracy, andavailability. Then, we considered three service parameters asour evaluation criteria: service message size, service responsetime, and client privacy, because they are representative forQoS comparison of client-side and server-side web services.

Client privacy is defined as the client ability to keep hersensitive and confidential data local and private. The pro-posed web services process confidential client data locallyusing the service representatives, while the traditional webservices process confidential client data at the provider site.The comparison results are illustrated in Table 1.

123

SOCA (2011) 5:245–264 261

Fig. 19 Credit card fraud patterns reported in [28]. Each column represents one symbolic transaction feature

Table 1 Client privacy comparison results

Privacy Proposed Traditional web serviceweb service

Case study 1√ ×

(Revealing financial information)

Case study 2√ ×

(Revealing PHR information)

Case study 3√ ×

(Revealing credit card information)

Table 2 Message size comparison results

Message size Proposed Traditional web service (kB)web service (kB)

Case study 1 8 11

Case study 2 12 7

Case study 3 6 835

Message size (MS) is the total size of service request andresponse messages that is defined for a web service as fol-lows.

MS(s) = SizeRequest(s) + SizeResponse(s) (1)

The traditional approaches require transferring completeclient data from service clients to service providers. On theother hand, the proposed web services process client datalocally that implies the MS is independent of the size of theclient data. Table 2 illustrates the MS comparison of the tra-ditional and proposed web services for the described casestudies.

Based on Table 2, the traditional and proposed web ser-vices represent compatible Message Size for the first andsecond case studies. However, the proposed approach outper-forms the traditional approach in the third case study wherethe client has to send her entire local database to the serviceprovider in order to receive customized verification results.

The proposed approach improves the Total Message Size(TMS) significantly, which represents the total size of servicemessages where the same service is called multiple times bya service client. In the traditional web services, the TMS is

equal to multiplication of Message Size by the number of ser-vice calls. While in the proposed web services, the receivedknowledge is stored in the SR knowledge base that results inreducing the size of the response messages. Figure 20 (top)compares the Total Message Size of the proposed and tradi-tional web services for each case study.

Response Time (RT) is divided into two factors: Networktime (N) and Process time (P) and is defined for a web serviceas follows.

RT(s) = N (s) + P(s)

Network time is the amount of time required to transferrequest and response messages that depends on both networkbandwidth and message size. Process time is the amount oftime it takes a web service to perform its designated task.Since service providers use more powerful CPUs, traditionalapproaches have less process time. On the other hand, theproposed web services require smaller messages results inless network time.

For this case study, we obtained the process time, P(s), forthe three case studies using a 2.4 GHZ dual-core CPU. More-over, we assumed the service provider has a CPU that is twicefaster than the service client. Finally, there is a 128 KByte/Seclink connects the service client to the service provider.

Table 3 shows the Response Time comparison between theproposed and the traditional web services. These results showthe proposed approach overcomes the traditional approacheswhen the client data grows.

Similar to the Total Message Size metric, we comparedthe Total Response Time (TRT) of the proposed and tradi-tional web services in the context of these case studies. Thiscomparison, which is illustrated in Fig. 20 (bottom), confirmsthat client-side processing of client data improves the TRT.

7 Discussion

The proposed client-side web services are differentiated fromthe traditional server-side web services as they can processclient data locally using local and generic agents. In this sec-tion, we list a few important issues such as the applicationsand challenges of the proposed web services.

123

262 SOCA (2011) 5:245–264

Fig. 20 (Top) Total message size and (bottom) Total response time comparisons of the traditional and the proposed web services where theyimplement the described case studies

7.1 Applications

The proposed web services do not intend to replace the tradi-tional web services. However, web services can be developedefficiently and securely using service representatives in thefollowing cases.

1. Context-aware services, where the services operateaccording to the available contextual information fromthe environment. If a context-aware web service can bemodeled with a pair of (general service response, cus-tomization knowledge), it is eligible to be delivered bythe service representative. Therefore, the privacy andsecurity aspects of these services will be improved (CaseStudy 1).

2. Sensitive and confidential client data, where these datashould be processed locally (Case Study 2).

3. Large volume client data, where sending these data to aservice provider requires large messages (Case Study 3).

4. Dynamic environments, where the client’s context ischanging over time. If the context (e.g., location) ischanging frequently, a traditional service must be calledfor each change, which increases the network traffic aswell as the service cost. In contrast, the SR utilizes the

role knowledge to generate dynamic service response foreach change of the context.

5. Dynamic services, where the provider’s knowledge ischanging over time. The SR enables providers to separatethe required knowledge from the service implementationand facilitates change management.

The proposed web services are described by WSDL doc-uments, which can be stored in XML repositories. A WSDLdescription for a traditional web service includes what theweb service does, how it is accessed, where it is located,and name and type of the service parameters. The traditionalWSDL documents are sufficient enough to describe the pro-posed services where the service parameters are divided intotwo parts: local that are used by the service representative andremote that are sent to the service provider to be processedremotely. As a result, the web services that employ servicerepresentatives to process client data can be discovered bothstatically (at design time) or dynamically (at run time) usingexisting WSDL-based approaches.

Finally, the proposed client-side web services can alsobe composed with the traditional server-side web servicesusing BPEL models. To invoke a client-side web service, aBPEL process first calls the web service and sends its remoteparameters. When it receives the service response message

123

SOCA (2011) 5:245–264 263

Table 3 Response time comparison results

Response time Proposed Traditionalweb service (ms) web service (ms)

Case study 1 131 112

Case study 2 125 75

Case study 3 207 6,612

that includes the role description and the required knowl-edge and information, it will forward it to the client-side tobe executed by the service representative.

7.2 Challenges

Although the distributed service processing offered by theservice representative improves the SOA performance in sev-eral cases, it imposes a number of challenges for both serviceclient and service developer which should be addressed.

– Service provider privacy: Required knowledge forthe service representative can be enterprise assets andresources that revealing them may violate the enterpriseprivacy. To prevent this security vulnerability, a serviceprovider can use one of the following techniques.

1. Enterprise knowledge can be divided to be appliedlocally (at the provider side) by the service or exter-nally (at the client-side) by the service representa-tives. Therefore, the critical knowledge (e.g, marketanalysis in Case Study 1) remains at the service pro-vider, while the non-critical knowledge (e.g., advicecustomization guidelines in Case Study 1) will besent to the service representative.

2. The service client only receives the service responsefrom the service representative. Therefore, the cli-ent does not have access to the transferred knowl-edge between the service provider and representative.Consequently, encryption techniques can be used fordata transmissions between a service provider andrepresentative to improve the enterprise privacy.

– Service client adaptation To call the proposed web ser-vices, the service client is required to install a genericservice representative with the corresponding communi-cation channel, which increases the client-side complex-ity. However, the current version of the service repre-sentative (SR version 1.0) needs a few megabytes (about3 MB) hard disk space and offers reasonable computingspeed (discussed in Evaluation section). Moreover, afterthe generic service representative installed, the serviceclient can invoke different client-side web services.

– Testing: The service representative executes a processon behalf of the service provider at the client site. There-fore, testing and error handling procedures are more chal-

lenging for service developers since they do not havedirect access to the client’s resources and execution plat-form. An effective evaluation technique is required thatincludes test cases for different client’s platform and con-text. Moreover, the interaction between the client appli-cation and the service representative should be evaluatedusing proper test cases. Finally, evaluation techniquesfor the Rich Internet Applications (e.g., Java Applets orMicrosoft Silverlight) [29] can be useful for testing theclient-side web services.

– Interoperability: Interoperability of service client andprovider is another challenge in using the client-side webservices. Traditional web services force service clients tosend service parameters that are understandable for theservice provider. However, in the proposed approach, theservice representative uses its analyzer component to con-vert the client data into an understandable data format forthe service representative which may increase the interop-erability issues. To support different types of client data,the service provider is required to send the correspond-ing conversion functions (as the knowledge) to the servicerepresentative to be applied by the SR analyzer.

8 Conclusions and future work

In this paper, we presented a novel model for SOA-based sys-tems that enables enterprise organizations to delegate theiragents to operate on the client platform. According to theproposed model, a generic and client-side service represen-tative applies the knowledge that is received from the serviceprovider to the client data and delivers the requested infor-mation to the client. To support this model, we also proposedan architecture that introduces an executable platform at theclient site for service providers which enhances the privacyand security aspects of web services. In addition to existingweb services, the proposed approach models two novel typesof services.

Different types of web services are complementary and abusiness service can be implemented based on one or moreof these types. As a future work, we will define cost functionsfor each of the involved factors (e.g., testing, response time,interoperability, and complexity) to guide service developersabout the proper type for each business service. Moreover,we intend to assign the service representative more SOA rel-evant roles such as negotiator to develop new approachesfor SOA related tasks. The proposed service representativecan be employed by collaborating service providers to per-form a composite role at the client-side. This motivates us toextend our model to introduce the concept of client-side ser-vice composition. Finally, we are also working on a web ser-vice extension that supports service representatives directly.

123

264 SOCA (2011) 5:245–264

Acknowledgments The authors would like to thank COMPETEgroup for the use of their Vascular Tracker (VT) materials for our exper-iments.

References

1. Soja P, Paliwoda-Pekosz G (2009) What are real problems in enter-prise system. Ind Manag Data Syst 109(5):610–627

2. Krafzig D, Banke K, Slama D (2005) Enterprise SOA: service ori-ented architecture best practices. Prentice-Hall, USA

3. Le D, Eck SA, Cao T (2007) A survey of web service discoverysystems. Int J Inf Technol Web Eng 2(2):65–80

4. Hung PCK, Li H, Jeng J (2004) WS-Negotiation: an overview ofresearch issues. In: The 17th annual Hawaii international confer-ence on system sciences, Hawaii, pp 10–18

5. Dustdar S, Schreiner W (2005) A survay on web service composi-tion. Int J Web Grid Serv 1(1):1–30

6. Baldauf M, Dustdar S, Rosenberg F (2007) A survey on context-aware systems. Int J Ad Hoc Ubiquitous Comput 2(4):263–277

7. Huebscher MC, McCann JA (2008) A survey of autonomic com-puting—degrees, models, and applications. ACM Comput Surv40(3):1–28

8. Alessandrini M, Lippe W, Nuesser W (2008) Intelligent servicesystem: an agent-based approach for integrating artifical intelli-gence components in SOA landscapes. In: International confer-ence on web intelligence and intelligent agent technology, Sydney,pp 496–499

9. Sycara K, Paolucci M, Soundry J, Srinivasan N (2004) Dynamicdiscovery and coordination of agent-based semantic web service.IEEE Internet Comput 8(3):66–73

10. Lee S, Choi K, Shin H, Shin D (2007) Ag Webs: web servicesbased on intelligent agent platform. In: The 9th international con-ference on advanced communication technology, Phonex, Korea,pp 353–356

11. Cheng Y, Leon-Garcia A, Foster I (2008) Toward an autonomicservice management framework: a holistic vision of SOA, AON,and autonomic computing. IEEE Commun Mag 46(5):138–146

12. Xu B, Yang X, Shen Y, Shanping L, Ma A (2008) A role-basedSOA architecture for community support systems. In: Internationalsymposium on collaborative technologies and systems, Irvine,pp 408–415

13. Maamar Z, Mostefaoui S, Yahyaoui H (2005) Toward an agent-based and context-oriented approach for web services composition.IEEE Trans Knowl Data Eng 17(5):686–697

14. Yamato Y, Ohnishi H, Sunaga H (2008) Study of service process-ing agent for context-aware service coordination. In: IEEE inter-national conference on service Computing, Hawaii, pp 275–282

15. Xiang L (2007) A multi-agent-based service-oriented architecturefor inter-enterprise cooperation system. In: Second internationalconference on digital telecommunications, Silicon Vally, pp 22–32

16. Khalili A, Badrabadi A, Khoshalhan F (2008) A framework fordistributed market place based on intelligent software agents andsemantic web services. In: IEEE international congress on servicespart II, Hawaii, pp 141–148

17. Wong D, Paciorek N, Walsh T, DiCelie J, Young M, Peet B (1997)Concordia: an infrastructure for collaborating mobile agents. In:MA ’97: proceedings of the first international workshop on mobileagents, Springer London, pp 86–97

18. Wong D, Paciorek N, Moore D (1999) Java-based mobile agents.Commun ACM 42(3):92–102

19. Pham V, Karmouch A (1998) Mobile software agents: an over-view. IEEE Commun Mag 36:26–37

20. Sangiorgi D, Walker D (2001) PI-Calculus: a theory of mobile pro-cesses. Cambridge University Press, New York

21. Zins C (2007) Knowledge map of information science. J Am SocInf Sci Technol 58(4):526–535

22. IBM Corporation (2004) An architectural blueprint for autonomiccomputing, 4th edn. Technical report

23. Proctor M, Neale M, Lin P, Frandsen M (2008) Drools documen-tation. Technical report. JBoss.org

24. Raspl S (2004) PMML version 3.0—overview and status. In: pro-ceedings of the ACM workshop on data mining standards, servicesand platforms, Philadelphia, pp 18–22

25. Haykin S (2008) Neural networks and learning machines. PrenticeHall, New York

26. Han J, Kamber M (2000) Data mining: concepts and techniques.Morgan Kaufmann Publishers, San Francisco

27. Compete III Vascular Tracker website. http://www.competestudy.com/

28. Brause R, Langsdorf T, Hepp M (1999) Neural data mining forcredit card fraud detection. In: ICTAI ’99: proceedings of the 11thIEEE international conference on tools with artificial intelligence,IEEE Computer Society, Washington, p 103

29. Raffelt H, Margaria T, Steffen B, Merten M (2008) Hybrid test ofweb applications with webtest. In: Proceedings of the 2008 work-shop on testing, analysis, and verification of web services and appli-cations, ACM, New York, pp 1–7

123