Decentralized multi-agent service
composition
Petros Papadopoulos, Huaglory Tianfield∗, David Moffat and Peter Barrie
School of Engineering and Built Environment, Glasgow Caledonian University, Glasgow, UK
Abstract.Current approaches to service composition are mostly based on centralized control model, and suffer from scalabil-ity, performance, and robustness issues. In this paper we propose a decentralized multi-agent model for service composition, drawing inspiration from natural systems. The idea is that the composition will “emerge” from local service interaction, using holonic organizational theory for adaptation. In a holonic multi-agent system, a holon is a concept of coalition that is formed through commitments amongst agents and induces an emergent structure amongst agents. A prototype is developed based on JADE platform and web services integration gateway to implement the proposed decentralized multi-agent service compo-sition model. Furthermore, a case study is presented on service compocompo-sition problem for a distributed generation electricity supply chain. Simulation experiments with different scenarios of the volatile electricity supply chain in distributed generation are conducted to validate our proposed decentralized multi-agent approach. When compared with centralized control approach, which is clearly limited when dealing with large-scale systems, our proposed approach performs favorably in tackling increased systems complexity and scale, though decentralized multi-agent approach does generate a larger message overhead and longer service discovery times.
Keywords: Decentralized system, emergence, holonic multi-agent system, self-organization, service composition, service-oriented architecture, distributed generation, electricity supply chain, demand-side driven generation
1. Introduction
The integration of inter-organizational systems is a key area to address for an enterprise participating in an open market. Service-Oriented Architecture (SOA) is deemed as an appropriate paradigm for this type of systems integration, more precisely, by offering the required abstraction to make component reuse a simpler task. Research efforts are now concentrating on how to automate to a maximum degree possible the process of systems integration, i.e., a system of systems, which is one of the main motivations to our work. Systems integration is important, especially if the enterprise Information Technology (IT) system is comprised from several legacy systems and/or there are different technology stacks in an enterprise, a common phenomenon in organizations today, as a result of acquisitions and/or mergers [34].
Service composition addresses a much broader domain of what traditionally was an Enterprise Ap-plication Integration (EAI) field [24]. Automatic service composition usually uses Artificial Intelligence (AI) planning technique where knowledge about available actions and the outcomes of those is used to determine a sequence of actions, which, when applied in a given state, attain a desired goal [74].
Current efforts typically use centralized control approaches to tackle the problem of service composi-tion, but it is clear that these approaches will not suffice as the complexity increases [41].
It is evident in the literature that when it comes to service composition and the automation of the process, planning approaches are widely used, including the perception of service composition as a planning problem, and adoption of AI planning approaches to solve it. Therefore, by using a service interface, the higher level business functionality (business goal) is mapped to the precondition and effect of the problem and a search space of all available services. The composition process must produce a sequence of services that satisfies the given precondition and effect. Using AI planning techniques to solve the problem, the searching algorithm will have to discover all the available services and determine which are required to solve the problem. Issues arise when the number of services is too large, resulting in a problem that can be solved but at a great cost of time and computational resources.
Also IT systems today become more geographically dispersed. Therefore, the composition will have to be performed over a wide area network or even the internet. The centralized control algorithms or rule based repositories, no matter how capable they are, will not be deemed suitable to deal with this environment and will fail to offer acceptable solutions performance.
Service composition is not per se a problem, but the requirement for self-adaptability is introducing a higher level of complexity that service composition must deal with.
Self-organizing mechanisms are usually found in complex systems, in which constituent parts have the capability of communication and interaction, and the complexity is derived from the large number of the constituent parts and their interaction [18]. There are efforts to address the service composition prob-lem by intelligence, but the intelligence becomes pointless if the system managed is too complex, i.e., it becomes unattainable to solve a composition problem. The way in which most natural self-organizing systems deal with complex problems is by having very simple rules that allow entities to solve com-plex problems through their local cooperation. Therefore, the service composition model fundamentally affects the degree of intelligence necessary to solve a composition problem.
This paper is addressing this issue by empowering services with autonomy, using proxy service agents, adding the capability to proactively or reactively cooperate to solve a composition problem. In contrast to a centralized control approach, which depends on a central “intelligent” composer which possesses all the necessary knowledge to solve the problem, the resulting system is decentralized with services participating in coalitions without any knowledge of what is happening at the macro-level.
This paper investigates self-organization models and algorithms inspired by natural systems, etc., to determine a mechanism for service composition in a SOA. We put forward an architecture capable of self-configuring services via Multi-Agent System (MAS) to form a “strong” self-organizing model for service composition, aiming at functional oriented composition rather than QoS oriented composition.
The remainder of this paper is organized as follows. Section 2 presents a literature survey on service composition, including combining SOA with MAS. Section 3 presents a multi-agent based framework of self-organizing service composition, specifically the decentralized multi-agent service composition model based on holonic organizational theory. Section 4 develops a prototype implementing the pro-posed multi-agent architecture of self-configuring services based on JADE platform and WSIG add-on, i.e., Web Services Integration Gateway. Section 5 presents a case study on service composition problem for a distributed generation electricity supply chain. Section 6 presents comparative simulation exper-iments in various scenarios of the case study with centralized control and decentralized multi-agent approaches. Finally, Section 7 evaluates the proposed approach and draws conclusions.
Fig. 1. Service composition taxonomy. BPMN: Business Process Modeling Notation. CSDL: Conceptual Schema Definition Language. BPEL4WS: Business Process Execution Language for Web Services. HTN: Hierarchical Task Network. MAS: Multi-Agent System. OWL-S: Web Ontology Language for Services. PDDL: Planning Domain Definition Language. SHOP2: Simple Hierarchical Ordered Planner 2. SOAP: Simple Object Access Protocol. SWORD: A Developer Toolkit for Web Service Composition, involving standards such as WSDL, SOAP, RDF (Resource Description Framework) and DAML (DARPA Agent Markup Language). UDDI: Universal Description and Discovery Interface. UML: Unified Modeling Language. WSCDL: Web Services Choreography Description Language. WSDL: Web Service Description Language. XML: eXtensible Markup Lan-guage. (Colours are visible in the online version of the article; http://dx.doi.org/10.3233/ MGS-130201)
2. Literature survey
The taxonomy in Fig. 1 is not exhaustive but the most notable approaches are included. Note that an attempt to provide with further clarification of the taxonomy is given (color coded), but it is not restrictive, as different models often use the same methods to solve the composition problem.
2.1. Service composition approaches
In [1] a set of considerations that affect service composition models are proposed, according to input and user involvement:
– Are the composition and execution phase separate?
Service Composition
Defines tasks & data dependency by abstract process model given ; Selects and binds services automatically
Creates process model and selects services automatically; Specifies constraints and preferences
Dynamic Static
Fig. 2. Dynamic versus static service composition.
– How does the composition happen, i.e., search based (planning) or template based (templates)?
– What information is used for composition, i.e., service types, service instances published, services deployed, templates/policies?
– How are external events handled at run-time, i.e., on the fly (instant) or gradual (time lapse)? The available information and the user involvement dictate what approach can be used for service composition. For example, if a set of constraints and preferences are given then the approach most likely to be followed will fall in the AI planning field. If you are given a defined process model, but a program is required to find the atomic services then it is obvious that you are searching a set of workflows to find a possible solution [60]. In [1], it proposes a taxonomy of composition methods with regard to necessary input for them to function, but concentrates mainly on the manual approach and does not cover automatic service composition.
2.1.1. Classification of service composition
Service composition can be classified according to various criteria such as manual versus automatic, static versus dynamic, solution techniques, i.e., AI or formal methods [38].
Design-time versus run-time service composition. There are three different times at which services can be composed: design-time, run-time, and interleaved composition where you cannot practically sep-arate design-time and run-time [1]. The service composition is designed to complete various functional requirements translated from the needs and goals of the business users. There is also the non-functional aspect which is expressed in Service Level Agreements (SLA) and QoS, agreed between business users and service providers. The automation of run-time service composition and the different phases of the process are presented in [42,60].
Static versus dynamic service composition. Static workflow generation means that an abstracted model must be provided by the requestor before the composition planning starts. On the other hand, dynamic workflow generation creates the process model and selects the atomic services automatically [60]. Static service composition is performed during design-time, when architectural decisions of the software sys-tems take place, as illustrated in Fig. 2. The components identified are linked, compiled and deployed. This is a good approach if there is not frequent change on the service environment [22]. When business partners provide new services or old services are replaced by newer ones, then the service environment is prone to change. This inevitably entails change in the software architecture, which makes it necessary to re-bind to other services or change the process definition and redesign the system entirely. In this case, service environment will benefit from a dynamic service composition strategy, allowing components to adapt automatically in unforeseen, unpredictable changes [22].
In terms of solution techniques, there are three main approaches to service composition [42]:
– Workflow based service composition,
– AI planning based service composition.
In the first step of workflow based composition, the user/developer will create an abstract specification of a high level plan. Then, the user/developer advances to the second step which is to create an abstract composite workflow by the decomposition of the specification. This is usually performed with some service workflow modeling language, e.g., BPEL [42].
In a template based approach the composition solutions are stored, then with the requirement for a new composition, the stored solutions are searched to find a suitable template and accordingly it is adjusted to satisfy the user requirements. This method is widely used to solve the service composition problem. In [69] the agents are used to control and coordinate conventional services without integrating any of their functionalities. They use case-based reasoning and case-based planning to modify existing templates and provide a solution for a new requirement. This approach often involves users that will have to validate a suitable template and provide with customization in stages in the life cycle [42].
AI planning investigates the problem how to synthesize complex behaviors given an initial state, an explicit goal representation and a set of possible state transitions [30,67]. It is evident that the service composition problem can benefit greatly by using AI planning methods, since there is commonality be-tween the two. In order for AI planning to provide a correct composition it assumes that the information that is gathered does not change until the execution of the plan [59]. In [57], it uses planning as model checking to deal with the non-deterministic aspect of the domain. The domain is represented using a finite state machine, with requirements expressed in EaGLe goal language.
As far as standards are concerned, there are two ways services can be composed to achieve some meaningful result [1,67].
One is primarily concerned with the provision of standard notations to allow inter-operability, i.e., composing business services using WSDL, BPEL, SOAP, etc.
The most common approach is to use BPEL, a workflow language that will define a specific order of steps to perform business functions provided by the aggregation of services of the system into meaning-ful compositions. BPEL provides programming language like constructs, e.g., sequence, switch while, pick as well as graph-based links that represent additional ordering constraints on the constructs [67].
The other is a semantic rich approach, which provides the capability to add meaning to the information. By semantic rich approach, services are composed based on the semantic web services using ontology, goal directed reasoning, etc.
As described in [25], there are different levels of interoperability in the services area: signature level, protocol level, semantic level, quality level, and context level. These levels are used to define the com-munication model for the service environment. For example, the protocol level is covered by WSDL which offers a unified way of describing all services, or the environment can consist of just “services” accessed using a variety of invocation mechanisms. The signature level deals with syntax consistency of service description, registration, and invocation. The protocol level determines the relative sequence a service expects its operations to be called, or it calls other services. Semantic level is the interoperability problem of the different understanding of the service semantics between service providers and service requestors. Quality level is concerned with the quality of service, when a service requestor place some quality constraints. The context level is service interoperability typically found at ubiquitous computing environments [25].
2.1.2. Service description
The way a service is described dictates the information that is available, and thus directly affects the type of methods and algorithms that can be used accordingly.
Fig. 3. Service description, composition and verification methods.
Service composition is a problem that is closely related to and heavily dependent upon the service description problem as well as the service discovery problem [21]. They are so closely related that a technology selection in one of those areas will have a profound effect on the others. The service description problem is associated to the degree of semantic information enrichment of a service interface. The degree of semantic inclusion dictates the model and method that can be deployed to perform service composition, e.g., inference logic or intelligence. The discovery problem relates to the practical task of advertising a service; well-known problems with a centralized repository approach result in scalability issues, which will certainly become a problem as the IT landscape moves towards SOA.
Syntactical description based service composition deals with roles and functionality that enable for composition of a service from multiple others and use the resulting service in to further more complex services. The cumulative service providers also have the role of publishing the service description as well as impose policies on aggregate services [56].
The main concept of Semantic Web Service Composition is to integrate a Semantic Web Service (SWS) to produce a group of services that satisfy a user requirement. Semantics use ontology to provide with meaning that a machine can understand about the relations of components in a system; they usually use formal methods to express service composition [51]. They use concepts and the relationship between them with a fixed and accepted meaning within a specific environment of partners [45]. Ontologies are becoming popular, since they can offer a common understanding of a domain that is suitable for communication between people and application systems [39].
Formal methods are used for their capability to compare whether two services are equivalent, and can determine if a service satisfies required properties [71]. Unfortunately, it is difficult to describe services in a formal and expressive language, which will assist automatic service composition. The majority of proposals that describe, compose, and verify services fall into two main categories, as illustrated in Fig. 3, based on state-action models, e.g., timed automata, Petri nets, or based on process models, e.g., π-calculus [71].
2.2. Service composition protocols
Protocols come from two distinct schools, the business school and the academic school. The business school has based its efforts on XML based standards to formalize the specification of services, their flow composition and execution. The academic school congregates the semantic web community, dealing with web resources reasoning by explicitly declaring their preconditions and effects with terms pre-cisely defined in ontologies. Service composition is typically carried out using goal-directed reasoning, inspired from AI planning [67,68]. Syntactic descriptions like WSDL define the order and types of ser-vice parameters and return values. Semantic interface description language like OWL-S annotates these parameters with meaning. Rule-based service composition examines both the syntactic and semantic properties of web services. Syntactic rules dictate the operation and binding protocols of services [60].
OWL-S is the resulting artefact of the semantic web vision. OWL-S is an ontology built on top of OWL by the DAML project [23]. OWL-S is a service ontology, comprising a service profile, a service model and a service grounding, that enables automatic service discovery, invocation, composition, in-teroperation and execution monitoring. The main advantage is the composition process can be executed without human involvement [27,50].
The service model consists of a sub-class called process model that defines a service with regard to inputs, outputs, pre-conditions, and post-conditions [71]. There are examples of OWL-S used in con-junction with HTN (Hierarchical Task Network) that produce a promising solution to the composition problem [65].
In [60], it divides semantic compatibility rules to four levels:
– Message compatibility determines if the output of one service is compatible with the input of an-other.
– Operation semantic composition ensures compatibility at the domain level and the category and intent of the services.
– Qualitative composability adheres to the consumer’s preferences relating to the quality of the com-posite operation.
– Composition soundness determines the correctness of a service composition.
WSDL is an XML language that is used to describe services over a network. The language describes the service in two fundamental parts. The first part is the abstract, which describes a web service with regard to the messages it sends and receives; messages are described without being specific to a technol-ogy, e.g., XML schema. An operation is also part of the abstract section of the description; it associates a message exchange pattern with messages. A message exchange pattern determines the sequence and cardinality of messages sent and received in addition to who they are sent to and received from. Finally, the interface groups together operations without any commitment to transport and wire format. The sec-ond part is the concrete, which specifies a binding that ties one or more interfaces in to a transport and wire format. An endpoint associates a network address with a binding. Finally, a service groups together endpoints that implement a common interface [16].
BPEL4WS is the result of IBM’s WSFL (Web Services Flow Language) and Microsoft’s XLANG (Web Services for Business Process Design) merger; it integrates features of a block structured process language, i.e., XLANG taken from pi-calculus and of graph based process language, i.e., WSFL taken from Petri Net [5,50]. BPEL4WS provides a construct to define complex business processes that interact synchronously or asynchronously with their collaborators. A BPEL process starts with the process ele-ment and is composed of the children: partnerLinks, variables, activities and the optional children: fault-Handlers, eventfault-Handlers, correlationSets. All these children are concurrent [13,50]. In BPEL a WSDL description of partners is connected to variable with a message. A web service that takes part in a BPEL process is modeled as a portType, i.e., service operations (op) provided by a service. The operations are executed by the use of a partnerlink (pl) [13]. The basic activities in BPEL are: receive, reply, invoke, assign, wait, empty, exit, and throw. A partial machine is used to describe each activity.
UDDI is a platform agnostic XML based registry, used by service providers and consumers to register and locate web services [17].
SOAP is a protocol targeting the exchange of structured information in a distributed environment. It contains a message construct, based on XML technologies, which can be exchanged over a plenty of underlying protocols [31].
2.3. Multi-agent system (MAS) and service composition
SOA and MAS can be viewed in the same way, and at the same time, the two different concepts are strongly complementary to each other.
Some aspects of MAS’s characteristics are ideally aligned with the SOA environment [64]:
– Each agent has only partial knowledge for solving a problem,
– There is no system global control,
– Service interface information is decentralized,
– Computations are asynchronous.
Combining these two concepts/technologies is an effort to get the best out of both worlds, i.e., service reusability and self-organization. The agent concept is characterized by autonomous software entities that can simulate any systems and cooperatively solve problems. The service paradigm, on the other hand, is enriched with an additional complementary management layer, which provides the means for domain dynamics (i.e., changes) and service composition mechanisms to materialize. The fusion of the concepts is driven by agents, due to the inability of services, within the SOA context, to deal with ontologies, hierarchical structures, and proactiveness.
In [28,61], it is observed that SOA and MAS have similarities, i.e., both construct an interacting dis-tributed loosely coupled flexible systems, but also have technology dissimilarities, i.e., services have interface standards and exchange protocols as opposed to agent communication languages and proto-cols. This leaves a barrier for direct integration to produce a landscape of a flexible, interoperable, and functional system. This is because services provide a well-defined infrastructure and interoperability, whereas agents’ main concerns are dealing with intelligence and social capabilities.
In [28], it identifies fundamental requirements that will need to be addressed in order to produce a consistent multi-agent SOA system, from a software engineering perspective, taking in to account existing frameworks and techniques from both paradigms.
In [46], it studies the integration of MAS and SOA technologies based on service descriptions, regis-tration, communication, semantic language, and interaction. This is accomplished by the conceptual and practical merge of the two technologies. It advocates encompassing the MAS characteristics in to SOA. Similarly in [58], it advocates that MAS and SOA technologies and concepts are ideal to combine and complement each other. It summarizes the capabilities and tasks to be performed by agents, e.g., to include reasoning capabilities, to behave in a dynamic way based on business rules, to build workflows, to compose external web services and monitor their execution.
The model represented in [43,44] illustrates the advantage of MAS and SOA with regard to self-organization paradigms. Entities enter complex negotiations and finally reach an agreement using the FIPA contract net protocol. New functionality is introduced by injecting an entity in the system that has a higher level functionality according to the corresponding decomposition of the ontology, and the higher functionality is then broken down to smaller tasks that are eventually satisfied by services from the SOA environment.
In [44], a promising approach to semantic web service composition is presented. The process of intro-ducing a new agent in a system with an ontological description of the tasks required to satisfy user needs is analyzed. The agent carrying this ontology is then decomposed into individual tasks, which enables a search to map each task to a specific service and to satisfy the user’s requirement. An option of using a mediator agent specialized to a sub-domain area is also presented to handle the process of deciphering the ontology to tasks and finding suitable services for each task.
In [47], it looks at the integration of JADE with JXTA (a peer-to-peer XML network independent protocol). It involves implementation of a decentralized algorithm in which every agent is looking for its successor, i.e., a service whose input matches its predecessor’s output. When a request with input and expected output is posted, the process stops when a solution is found or there is not a solution or the agents detect a loop when delivering requests. Similar work is in [53].
In [15], it proposes a framework for the full life cycle of service oriented architecture, i.e., planning, binding, enactment, using the same technology as in [46] but having extended the functionality to cover all the different phases of SOA. While this framework shows how the management of SOA can be accomplished using agent technology, functional composition is not addressed in this study. It only covers the local global QoS service composition, prone to service failures and SLA violations.
In [10,11], it presents a multi-agent service composition approach that is more concerned with the service environment rather than the algorithm to control the planning process. The importance of an environment where interactions occur comes from applying Conway’s law to service composition and from the realization that complex systems cannot be controlled, but rather managed by an algorithm, i.e., processes are designed to capture the interactions amongst the services. Although it has a greater tardiness, it is a promising approach that does deliver a decentralized service environment.
There are several other efforts investigating MAS and SOA fusion at both concept and technical levels, e.g., [8,69]. In some cases it is addressing the organizational part of services [9]. In [12], it debates the suitability of SOA for building adaptive systems and argues the fusion with MAS is the way to overcome the limitation.
In [75], it discusses three nature inspired approaches to service composition. It firstly highlights the importance of combining syntactic and semantic approaches for interfaces not only to define the port of input and output but also to define the type of the input, e.g., input integer, output float. The first algorithm is a straightforward uninformed algorithm that uses information from goal predicates. It is fast enough for small service repositories and optimal if the problem is satisfied only by exhaustive search. The second is an informed greedy algorithm that uses heuristics to find the best node but to select the next best. The third is a genetic algorithm that represents service sequences using a variable string of service identifiers. All the algorithms work by exploiting a central service registry and manipulating the way to search this registry fast to come to a correct solution. A central repository can prove problematic, due to both scalability and the fact that it is a single point of failure for the whole system.
In [20], it takes a different approach to service composition and management based on inspiration from a biological system, namely the neuroendocrine-immune (NEI) system. It uses Linear Logic to provide with the service composition in a system that is developed using the NEI mechanism.
In [49], it proposes a model of software agents for service composition. The model should be capable of implementing most of the major approaches to service composition, i.e., workflow based, and AI planning based. There is a description of service composition using extra-logical axioms in Linear Logic, translated from WSDL or OWL-S. The requirements of the composite service are in the form of Linear Logic sequent to be proven. To conclude that the composite service can be satisfied by existing atomic services, MILL (Multiplicative Intuitionistic Linear Logic) theorem prover is used.
In [35,36], it proposes to combine QoS and functional compositions. Most service composition re-search addresses one or the other. It proposes a reinforcement learning algorithm which is later extended to a hierarchical reinforcement learning algorithm to provide with an evolutionary, dynamic service composition.
In [14], it investigates the use of agent coordination protocols for a service environment. It studies ser-vice composition and agent coordination, and proposes a novel protocol for agent serser-vice composition. It includes requirement specification directly from a user in plain English.
Fig. 4. Factors of automatic service composition. 2.4. Comments
Although there are several standards developed to allow for easier service composition, automatic service composition is still problematic and quite difficult to perform. It is attributed to the inability of machines to understand the purpose of a service, i.e., semantics, and the complex task of defining workflows to create compositions of services that fulfill a requirement [77].
Since service composition is heavily dependent upon service description, the main challenge is the capability to recognize the type of service model encountered and the prompt guidance to an appropriate solution, suitable for a particular situation. Although service description standards provide technology compatibility, it is imperative for semantic compatibility as well, which becomes a more apparent prob-lem in inter-organization systems integration.
In most cases service composition is viewed as a planning problem, and thus models, methods, and tools from AI planning are adopted. In AI planning approaches, services can be specified by precon-ditions and effects in the planning terminology. Since a service takes data as input and produces data as output, the preconditions become the input data and the effects the output data [60]. A key effect characteristic of service execution is that the state of the world will be altered in some capacity.
In automatic service composition, main problems are how to identify appropriate services, how to compose them and how to verify how accurately they match a request [70]. A specification of goal must be provided, using either a description language or some mathematical notation, then an “intelligent” composition engine selects suitable services and provides the composition to the user [70]. This means that a production of a service composition plan is always handled by a central composition manager, a contrast to “strong” self-organizing approaches.
It is imperative to reduce to a maximum degree possible the intelligence of the entities, i.e., drastically reduce the complexity of the composition algorithms in the system and “shift” this intelligence to the structure of the system, i.e., the interactions among simple entities [48]. Unfortunately, AI planning based approaches require for more intelligent algorithms and will result in non-scalable systems.
The description of services, the model of the system, and the composition algorithm are interlinked (see Fig. 4). A selection in one of them affects the performance and feasibility with the selection of the other two.
The establishment of the service composition environment, in which a SOA implementation is real-ized, ultimately constrains the service description and consequently the information that each service can provide to perform service composition. The available information from the services determines what type of solution, i.e., models/algorithms, is appropriate to perform service composition, as illustrated in Fig. 4. It is often the case that the more simplistic the service description and model, the more complex the algorithm usually is, i.e., the syntactical service description approach requires algorithms with more intelligence than the semantic description.
Many researchers opt for the syntactic representation of service composition, others champion that without semantics it is not feasible to create workflows that fully satisfy user goals in an automatic way [42]. Although the limiting factor in the semantic approach is the lack of dynamism, semantic
composition is devised to work under a centralized control; usually planning compositions as workflows and then enacting the corresponding services. This approach is restrictive when the environment is open, dynamic, and distributed [73].
However, it would be unrealistic to exclude semantics from the service description, since discrepancies are unavoidable.
Composition scalability and performance are difficult to be achieved with existing methods, e.g., with BPEL, the larger the composition, the larger the XML file becomes. The lack of standard graphical notation intensifies the problem, though some approaches provide UML-like notations for descriptions. The OWL-S approach suffers from similar problem as the syntactical approach [71].
In respect of the representation of the user in the system, it is typically exogenous to the system. With the user and participating stakeholders barred from the system, the driving forces of the system are outside the system boundaries. This makes some aspects of automation untenable, as they are dependent on user behavior.
Current approaches still are not capable of representing the adaptive model of a domain and imple-menting “strong” self-organization to satisfy the IT needs of that domain. Rather than building complex and labor-intensive semantic models capable of logically reasoning about the knowledge that will dictate how a system can be integrated, the system should be built on much simpler descriptions of resources that can be matched by decentralized multi-agent approaches.
Our novel framework for service composition will store laconic descriptions that may not be as capable of producing a solution for a given composition problem, but it will have entities that can cooperate and produce a solution as in the semantically enriched method. The nature and other decentralized systems demonstrate appropriate models, and provide elegant solutions to problems that share characteristics to SOAs. The more information is embedded in the framework, the less complex the algorithm will need to be to solve problems, i.e., the way a problem is represented is directly affecting the method to be employed to solve it.
3. Multi-agent based framework of self-organizing service composition
The SOA paradigm has the prospect to adopt self-organization models, which can manage service composition according to the business workflow level [19]. The SOA paradigm can be further expanded using MASs to design and implement large-scale distributed systems that can self-organize at the busi-ness process level in run-time to satisfy user or system requirements, specified as workflows and executed with services [32].
Our aim is to provide a “strong” self-organizing system for service composition, i.e., no centralized control.
The purpose of using a self-organizing model in service composition is to address the complexity of systems integration problems, which provides a scalable and robust approach that performs acceptably in the service composition process.
This paper will exploit and extend SOA capabilities by combining with MAS, which can capture user and system needs in real-time and build the capability of system self-organization on the fly.
3.1. Elements of self-organization in service composition
As discussed earlier, most approaches to service composition are based on centralized control model. This means that there is one component of the system responsible for undertaking the calculations to
produce a valid service composition. An alternative to centralized control approach will be to embed this capability at local level and allow the system components to perform the calculations as a collective rather than relying on a central point of control.
Models that demonstrate highly self-organizing properties are typically comprised of small au-tonomous entities that do not have a high degree of intelligence but can communicate with each other. The entities cooperate with each other. Although individually they have only a partial knowledge of the system, cooperating they can solve complex problems.
A key outcome of service composition and indeed the paradigm of SOA is the way services are de-scribed. Platform agnostic description is the essence of SOA. The atomic services, which cannot be further divided, are used as the basis for interacting services with the aim to produce desired composi-tions, as a derivative of the interactions. As stated earlier, the two main de facto standards of describing services are semantically enriched and syntactically represented by OWL-S and WSDL, respectively.
Regardless of the service description approach, one element is undoubtedly always present, i.e., the input and output of the service. Rather than using a service description language, this paper uses this important information for service description. Input and output are part of a service interface, usually designed in a top-down breakdown of business requirements. In order to take advantage of this top-down paradigm and build a framework that will be capable of producing an emergent phenomenon desired to satisfy some business requirement, input and output matching seems to be the most logical approach to service composition.
3.1.1. Distributed agents for decomposition of business processes
A business process is the logical reflection of a coordinated, composite task, which purposely satisfies a desirable goal. The composite task is formed from the behavior of entities, each encapsulating the required knowledge and programmed into a software agent, and the communication amongst agents according to their behavior will still produce some desirable result.
A MAS is an ideal candidate, since it offers a powerful tool to represent any type of world and its dy-namics, usually achieving emergent phenomena as the result of the multi-agent interaction. Furthermore, a MAS provides the means to implement decentralized control mechanism using distributed autonomous entities, i.e., agents, an imperative to “strong” self-organization, whereas a centralized control approach will suffer from complexity issues and failure with the increase in the numbers of services available and scenarios possible [73].
As illustrated in Fig. 5, a holonic MAS integrates with the lower SOA run-time environment and satis-fies business workflows from higher business management layer. The service composition is performed from local agent interaction based on interface matching calculations, using holonic organizational the-ory to produce a new service composition by an agent injection, i.e., head agent.
In order to identify services for a new composition, there must be a mechanism that triggers a require-ment. The requirements are usually user or system generated in order to perform some action, part of the activities associated with a domain. Our proposed framework models the behavior of the user in the MAS, and hence allows requirements to be expressed in an automatic manner. Thus, requirements will arise from some action performed by an agent, according to its own behavior and domain rules, which will result in a requirement. This requirement can be realized by a combination of services, which, once executed, will complete the action started by the user. The completion of this whole process will result in a change of the state of the world.
Fig. 5. MAS enabled SOA self-organization framework. 3.1.2. Emergence in self-organizing service composition
Vital elements to produce a self-organizing system are interaction, service description, and service autonomy. From service description the input and output are used as a reflection of the capability of a service. A service description like WSDL 2.0 includes information relating to the concrete and abstract part of the service. The concrete part is responsible to bind the abstract parts of the service to an endpoint using a URI (Uniform Resource Identifier) (see top part of Fig. 6). The abstract part describes what a service can do; using the operation’s input and output (see middle part of Fig. 6). This paper uses the input and output to describe a service capability and extends it so it can carry out service input and output matching with adjacent services.
In order to introduce emergence to the self-organizing system, it is necessary to introduce another component into the system. The emergence is triggered by the injection of a high level component that has precondition and effect determined by user or a system requirement, after which the system should self-organize and produce a valid service composition. Emergence in a self-organizing system is based on a set of rules that the elements of the system have to follow. Another method of adaptation is through the environment with which the elements interact to provide the stimuli for the system to shift and in doing so to adjust to the new conditions.
This paper is primarily concerned with self-organization by the interactions amongst the system ele-ments rather than the interactions between the environment and system eleele-ments. Essentially this paper
Fig. 6. WSDL 2.0 schematic representation.
provides a framework for service composition in a way that simple interactions will be able to self-organize the composition.
To sum up, we will employ the following definitions and assumptions:
– Service is an artefact that has its interface available, has unique name and input/output parameters, is stateless and platform agnostic, and can be proactive, reactive or both.
– A service can use a semantically enriched form of expressing the capabilities as long as it meets minimum requirements that are essential to invoke.
– The precondition is input on which some function will be performed either to calculate something or change the state of the world.
– The users are represented in the system by agents.
– The service environment is providing with facilities to host and allow communication of services.
– The state of the world is represented in the system by the associated state of the agent, and can only be changed by a transition that is associated with that state.
– Transitions are a set of steps, with each step corresponding to a service.
– Service composition is considered time persistent.
3.1.3. Centralized control based service composition (CCBSC) algorithm
Service composition is a search process that selects candidate solutions, i.e., different service compo-sitions. When a composition is found, the evaluation of the composition is performed to determine its correctness.
Fig. 7. Centralized control based service composition (CCBSC).
Figure 7 depicts is a Centralized Control Based Service Composition (CCBSC) model or sometimes called “weak” self-organization. Weak self-organization means the composition process is controlled by a central entity (see Fig. 7(a)), though strictly speaking, it is arguable if it can be labeled as a self-organizing system at all.
The composer algorithm is executed when a user agent requires a transition from one state to another. Taking electricity supply chain management as an example, a user agent must be connected to a supplier in the electricity grid after an agreement is reached. If the agent for some reason becomes disconnected, that will trigger a sequence that will result in finding a new supplier. To complete this transition, once a consumer identifies a suitable supplier, there are some standard tasks that must be completed so that the customer is able to receive bills and customer care. The consumer agent reflects what would have actually happened if a human customer was to search manually for a supplier.
The service composition algorithm, i.e., what is executed by the service composer, for the aforemen-tioned system is presented in Algorithm 1.
Algorithm 1. Centralized control based service composition (CCBSC) algorithm
Get initial Input Get end Output
current input becomes equal to initial Input While (current input not equal to end Output) Search available services
Get servicen Get serviceninput Get servicenoutput
If (current input is equal to serviceninput) current input becomes equal to servicenoutput
If (servicenoutput equals end Output)
Service Composition Found becomes equal to true End inner if
End outer if loop
Service composition, handled by Algorithm 1, is completed when the composer finds a sequence that can satisfy the customer’s precondition and effect, i.e., if customer information is given to a supplier, an account is created in the supplier database, and as a result, this causes a change in the state of the customer agent from disconnected to connected and completes the transition.
Algorithm 1 can perform service composition, given a precondition and effect (initial Input, end Out-put) and a set of services that can satisfy the conditions in a CCBSC model. The algorithm takes the required precondition and effect and then requests for their interface from all available services. The information is stored in an array that consists of the name of the service, input, and output, and the algo-rithm then starts to match the precondition in to available service until there is a match. When a match is found, the output of that service is used as the next search criterion, and this process is repeated until the effect that is required is reached.
The composition model used here, as illustrated in Fig. 7, is inspired by the planning based models and algorithms. The implementation is more focused on the model and the implications of using such an approach to service composition, rather than the actual algorithm of the composition.
3.2. Decentralized multi-agent service composition (DMASC) algorithm
The user, which is also part of the system, is represented by an agent capable of behaviors that lead to some change in the state of the environment associated with the agent. Hence, states are transitory from one to another by a series of tasks, as illustrated in Fig. 8. This series of tasks is the decomposition and devolution of the user goal, and each task can be satisfied by a service. The services can be grouped together according to functionality relating to different business sub-domains. Service composition does not produce a flat structure, but a highly complex hierarchical structure in which services are grouped together in accordance to some requirement. They further support higher parts of hierarchically structural representation of an organization, which, when combined, offer a holistic aspect of that organization’s day-to-day operation. Holonic organizational theory embodies the idea of a part being part of a larger system, cooperating to form mutually beneficial formations.
A MAS is able to address modularity, scalability and flexibility required of service composition. The fundamental issue is to detach behavior and data from services, in agents and stateless services, respectively, which will provide a system capable of self-organizing according to user requirements.
Fig. 8. Decentralized multi-agent service composition (DMASC).
The user requirements are embedded in the behavior of agents, and are satisfied by the consumption of services. By this way, it’s always maintaining accordance to SOA concepts, as integration typically occurs using a business process language that produces composite applications using services.
Our aim is to fundamentally challenge the current approach towards distributed systems in order to build a simpler composition algorithm, focusing on the way the system works, i.e., the system structure and how service composition is performed. Figure 8 illustrates a framework of Decentralized Multi-agent Service Composition (DMASC) that can involve a business domain user and a service environment. The business domain associates consumer agents with states that drive this system, i.e., from a disconnected customer to a connected one (see Fig. 8(a)). Taking electricity supply chain management as an example, the process is completed and the state changed when the customer registers with a supplier and that can happen only by the consumption of services (see Fig. 8(b)). The registration process is initiated by the injection of a head service in the service environment with specific precondition and effect and it is the responsibility of the head service to find a service path that satisfies the registration process.
The inevitably large number of services will result in the practical problem of creating a message overhead during service discovery with a reduced intelligence algorithm. An option to more efficient
service discovery would be to narrow down the service search space by categorization of services with common functionality that are likely to form compositions, thus reducing the search space and efficiently finding a plan within an acceptable time-frame. The time persistence of a composition remains, until one of the services in the composition leaves the service environment.
This self-organizing model is based on local interaction of entities with a service composition algo-rithm, inspired from holonic self-organization [72]. This algorithm is executed locally by every service participating in a composition. The algorithm configures services to proactively seek and find compati-ble services, i.e., service interface matching (see Fig. 8(b)). The interface matching operation performs input and output matching as in the centralized control approach, but it is done locally and the outcome is not a composition. According to holonic organizational theory, the service can be part, multi-part or stand-alone service, the compatibility of which can be calculated by a function if a service should participate in a coalition [32,62].
A service contains functionality capable of cooperatively producing a composition, as illustrated in Fig. 8. The composition is produced from stimulus from the user or system, and it is in the form of a new head service, configured with the desired precondition and effect and in accordance with holonic organizational theory to enable the composition to emerge. In DMASC, a head service represents a goal that needs to be satisfied, e.g., make payment, produce bill. In order for DMASC to work, services must contain functionality not present in the centralized control approach: request for interface descriptions from other services, determine if the services are compatible to participate in a coalition that satisfies a workflow, as illustrated in Fig. 8. DMASC is presented in Algorithm 2.
Algorithm 2. Decentralized multi-agent service composition (DMASC)
Service input Service output Get interface Sinput Get interface Soutput
While not found successor and predecessor If input equals Soutput
Found predecessor becomes equal to true Else if output equals Sinput
Found successor becomes equal to true End if
If search all services and no successor and predecessor is found Solution does not exist
exit loop
The head service is started by the user and performs a slightly different matching from the algorithm illustrated in Algorithm 2. It is the head service that reflects the user requirement for such a service composition and implements an algorithm to match precondition and effect given from the user, i.e., input to input and output to output matching. Thus, the head service is searching for the start and end of a sequence of services that completes the composition process, rather than searching for predecessor and successor.
The service participation in a composition and consequently the agent participation in a coalition (treated as synonymous in this paper) is determined by a special type of service, namely a head service. The head service is instantiated by a user agent when some functionality must be satisfied, in order to
complete a business function or sub-function. In DMASC, head service takes some high level input and output required from the user agent, and executes the matching algorithm until all participating services in the composition have found their matches (each service will have two).
4. Prototyping
4.1. Implementation considerations of service composition
The concept of automatic service composition should not be confined to a specific platform, from a service technology implementation point-of-view.
A service registry in SOA is usually a centralized mechanism, e.g., UDDI, where service producers register and service consumers can search when querying for a specific service description. The central repository is perceived as problematic with scalability and efficiency in open systems.
In this paper we use a repository only to satisfy the prototype’s addressing purpose. Perhaps a more sensible approach would have been to use a service broker architecture, which can be used to keep track of services that are geographically or logically grouped together and can result in performance enhancements, as in [2]. In [2], it also uses positive and negative feedback method to determine which services are more probable to provide with a good level of service and which are not, and then entries at different levels are kept in a list that is stored by each service.
In addition, the users, or more exactly their behavior, must be represented by an agent that is part of the system. The parameters of that system can be of course adjusted according to the user needs, but the user is within the system boundary. MASs are ideal to represent users or any other type of socio-ecological system due to their ability to encapsulate and re-enact user or system behaviors. The users interact with the environment by taking in a specific state and following the transition between different types of states by the consumption of an array of services that alter the state of a user, as illustrated in Fig. 8.
Let’s look at the change of states by taking Scenario #1 of our case study as an example. Assume that there is a user in a small community looking to buy electricity from suppliers, until a supplier is found the user is disconnected from the grid; and when a supplier is found, some necessary account management procedures must be completed. The procedures are satisfied by a combination of services that are available for the process to complete and change state to a connected user, as illustrated in Fig. 8. The state in this work is associated with a goal that a user must reach and is the trigger for agent interaction. This event driven system in which every user must reach a desirable state is producing a persistent composition that is maintained until any of the participant services becomes unavailable.
Service composition in a distributed, open system involves some key aspects, i.e., communication model, service environment, and service description. The communication model in our prototype as-sumes that the service environment is able to exchange XML messages, thus ensuring homogeneity at that level. The service environment is mainly concerned with the manner in which services become avail-able. Since our aim is to tackle service composition in a decentralized system, a central repository would not be appropriate, or at the very least is a selection that may cause future issues, e.g., scalability and robustness. This issue is illustrated in [41], and extends to other BPEL/UDDI/WSDL approaches [26]. It has become the norm to most current implementations of SOA to use WSDL, SOAP, and UDDI, known as the WSU technology stack of de facto standards, for the sake of acronym. Service description can be satisfied using a syntactic language like WSDL, sufficient for the service description requirements of our work. More precisely, this paper uses the abstract part of a WSDL description, represented by a tuple
Fig. 9. SOA service composition environment.
consisting of the input and output of the service. Although the use of XML at the communication level offers protocol homogeneity, unavoidable errors often occur at the semantic level. This can be the result of subtly different message types, despite the fact that they represent the same or similar semantics [37]. A message transformation service would provide the capability to overcome this type of message type difference using semantics; it would be triggered when incompatibilities are found, but it is outside the scope of this paper.
We use an agent platform to simulate certain aspects of a domain that later drives the composition of services in a self-organizing manner, triggered from user day-to-day activities. Services represent the necessary aspects of the supporting IT infrastructure, which are built in accordance to the SOA paradigm. Due to the inability of the SOA paradigm to encapsulate domain and stakeholder behaviors, an agent platform is more appropriate to realize advanced service composition models. The services represented in the MAS will not affect any aspect of the composition process. Hence, our prototype is developed using an agent platform that will allow the formation of hierarchical structures of service composition for DMASC model and still maintain services as a “flat” structure independent of any other knowledge, i.e., semantic rich service description. Here, flat structure means that the services hold no knowledge of the services they are compatible with. This approach of SOA and MAS is selected in order to maximize both reuse and service composition automation potential of the SOA paradigm.
4.2. Service composition environment
We define a conceptual service environment, encapsulated in a comprehensive framework and ana-lyzed over the different requirements throughout the development life cycle, as illustrated in Fig. 9. This environment is compatible with the main paradigms involved, i.e., SOA and MAS, the service environ-ment represents services in a way that can integrate with WSU stack services. Furthermore, the proposed service environment exposes the SOA service capability to a MAS and takes advantage of agent ability to drive and control those capabilities. The service environment justifies the fusion of various service de-scription and discovery technologies and the corresponding service composition models and algorithms.
Fig. 10. MAS design and MAS enabled SOA systems architecture. 4.2.1. Systems architecture of the prototype
For the implementation of our proposed framework, the agent paradigm is used in order to replicate a system’s behavior and use the functionality of the services to satisfy business scenarios accordingly.
The JADE platform is used to implement the behavior of users from a distributed generation electricity supply chain case study and the service composition layer, using a service proxy agent to represent each WSU stack service in the agent platform. The first logical part is responsible for the representation of the structure of the domain, its stakeholders, their behavior, and the dynamics of it, that will result in a desirable interaction pattern. The second part is responsible for embodying the technology that supports, enables, and serves the operation of the domain, expressed in accordance to the SOA paradigm.
The systems architecture we employ to address the requirements of our prototype is illustrated in Fig. 10.
The software platform is divided in to two parts, the electricity supply chain market and the underlying service-oriented environment. The former has the responsibility to capture the electricity supply chain dynamics and the later has the role of providing support for the parallel billing system to be developed. Both parts are implemented using the JADE platform.
The utilization of MAS has key benefits that extend from the representation of the dynamic domain, to the capability to control and configure the underlying environment using the same platform.
4.2.2. JADE platform and web services integration gateway
The prototype is taking advantage of the flexibility of the JADE platform in order to express the self-organizing models to service composition, ensuring at the same time compatibility with the technology and guidelines of the SOA paradigm. JADE is widely used platform, experimenting high levels of inte-gration efforts between MAS and SOA. Most notable of the efforts are the WSDL2JADE tool and WSIG add-on, i.e., Web Services Integration Gateway. The integration of SOA and MAS provides the prospect of agents controlling the dynamic composition of services, on behalf of users or organizations [29].
WSIG offers an integration of the two platforms relying upon the JADE platform’s capabilities to represent WSDL descriptions of services using proxy agents [6]. Proxy agents have the capability to synchronize the UDDI and DF (Directory Facilitator), used to describe services and agents, respectively. The benefit of WSIG is providing a bi-directional transformation from MAS to SOA and vice-versa without any additional need for altering or interfering with the standards and specifications of either organization. Furthermore, that allows for the deployment of the technology instantly without any further development effort. There are semantic differences in the way these representations are made, but the benefit of the immediate integration seems to outweigh this drawback.
The Web Services Description Language (WSDL) 2.0 consists of two parts, the abstract part, i.e., types, interface, and operation and the concrete part, i.e., binding, service, and endpoint.
4.3. Prototype system
4.3.1. Introduction to the case study
In order for implementation artifacts to be explained and justified more easily, a short description of our case study is presented here. Our case study is based on the electricity supply chain of a small com-munity with some small-scale electricity production capability. An electricity consumer is searching for an electricity supplier. There are 5 electricity suppliers selling renewable generated electricity at different prices. The consumer has to select according to some preferences, i.e., price, type of electricity gener-ation, etc. The consumer must communicate these preferences to the suppliers and the suppliers must respond with the type of the generation and the price for their product. When the customer receives all responses, a decision must be made according to preference, and a contract agreement must be reached with the selected supplier. When the agreement is reached, the stakeholder interaction is completed and the consumer triggers the start of the requirement for registration with the supplier’s system in order to allow for account management capabilities imperative for customer care and billing functions to be carried out.
The service composition to satisfy the consumer requirement is performed with a CCBSC model and a DMASC model, respectively. The whole process is completed when the transition of the consumer changes from being not connected to the electricity to being connected.
The software structure of our prototype system for distributed generation electricity supply chain is depicted in Fig. 11.
The prototype’s structure is divided into four packages:
(i) The Service package covers all the requirements for the software to accommodate for the different models, algorithms and services that are necessary for the scenarios;
(ii) The Run Simulation package manages all the configuration requirements of the different scenarios; (iii) The Electricity Generator package consists of electricity producers that represent an electricity
supply stakeholder and his relevant behavior; and
(iv) The Electricity Consumer package represents the consumer stakeholder and the behavior necessary to enact the scenarios.
As to the implementation of CCBSC model, the Abstract Service class represents an abstract service that can be started at run-time and configured with a desirable interface. The purpose of this service is to start a new service when the service composer finds a solution. The service class represents reactive only services that can only reply to interface requests. The Service Composer is started by the consumer with some preconditions and effects in order to produce a composition that satisfies them.
As to the implementation of DMASC model, the Decentralized Head service is started by the con-sumer and takes some high level preconditions and effects that the concon-sumer wants fulfilled. The com-position stops when all services required have found their matching services. The Decentralized Service is participating in compositions, using a matching algorithm, but cannot represent one.
The Dummy Service class is used in both models to provide for the service numbers required for different experiments with randomly generated interface.
The Run Simulation package fulfils the JADE requirements for platform run-time configuration. Each run class captures the running instance of JADE and agents or services can be started each with specific attributes and parameters. The experiment is set up in the Run Simulation class. The configuration class starts agents according to the selected scenario and services accordingly; and service names and their interfaces are imported to the platform from a text file.
Both the Electricity Generator and Electricity Consumer packages implement the stakeholders of the electricity supply domain and their behaviors according to scenarios.
4.3.2. Agents
The system is comprised of agents engaged in an electricity market in which they interact with each other. The environment can consist of a user agent (usually interacting with a graphical interface), the physical world, other agents, and in some cases the internet. MAS is used when a centralized control based model is either impractical or simply not possible, due to the limitations associated with it.
The agents demonstrate search and agreement negotiation capabilities that allow the enactment of a domain’s day-to-day operation. Figure 12 depicts the capabilities of supplier agent behavior, in order to participate in an open market and compete with other suppliers. The consumer agent is more complex in providing capabilities that extend the process of searching and reaching an agreement with suppliers. The service composition is also handled by the agent, as illustrated in Fig. 13.
The agent must specify the preconditions and effects of a service composition. The service composi-tion can be handled differently. Either a service composer is assigned the task of finding a composicomposi-tion with CCBSC model, as illustrated in Fig. 14, or the consumer directly introduces a head service that handles service composition in DMASC.
The direct introduction of a head service in to the environment is explained below.
4.3.3. Services
A Service is represented using a service proxy agent, which is declared as a service proxy in the DF pages. This is strictly for platform addressing purpose only, i.e., to distinguish between the agent and
Fig. 12. Supplier agent. Fig. 13. Consumer agent.
Fig. 14. Service composer agent. Fig. 15. Proxy service.
the services that are also part of the prototype. The services can self-describe their capabilities (they can respond to interface description requests to agents) and can be proactive or reactive (this can only happen because of the agent capabilities). Thus, the integration of services to the agent platform and the agent capabilities allow for advanced models to be realized. Services are mapped into the agent platform using a service proxy (an agent representing a service) on a one-to-one relationship, as illustrated in Fig. 15. The proxy service is an agent implementation that only offers the service interface of the service and the means to invoke the service, but the imperative part that defines service composition is the service interface.
Note that the WSIG add-on can easily extend this platform to support WSU implementations of ser-vices (it has been tested with Apache CXF and Axis 2).
The service depicted in Fig. 16 has also the added capability of performing input/output matching in order to find compatible services. The input and output matching will not suffice in order to produce a desirable composition. The head service is introduced by the user with the desired precondition and effect, which are satisfied by performing its own interface matching.
4.3.4. Service description, discovery and composition on the platform
Service composition in the prototype is possible by both centralized control and decentralized multi-agent approaches; service description is currently confined to a syntactical representation. This syntacti-cal representation, i.e., input and output of a service, is extracted from WSDL 2.0 W3C recommendation.
Fig. 16. Self-configuring service.
Other parts of the recommendation are not necessary for service composition in the prototype, and thus not included in the service environment.
We utilize the JADE DF to distinguish and search for services in order to communicate with them and extract the service interface. The DF is capable of representing the description of services, using ontolo-gies, which are supported by the JADE platform. The capability of semantic DF service description is not used here, as the approach is very similar to UDDI that poses a scalability issue. The eradication of a central repository will provide for a suitable, decentralized architecture.
There are two composition models in our prototype, i.e., CCBSC and DMASC. In the first model, the service composer is an agent that implements a CCBSC model in the JADE platform. It operates by taking some high level input and output and satisfying those parameters in the search space, i.e., the interfaces of all existing services and a sequence of services that can satisfy the given input and output. The composer is triggered according to specific market dynamics embedded in the agent platform that emerges from the behaviors and goals of each agent and their interaction. After the composition process has been successfully completed, that will in some aspect alter the state of the agent in to the desirable state. In the second approach, composition is using a DMASC model. The composition is triggered by a head service introduced by an agent in order to satisfy some requirement. All participating agents perform local input/output matching in order to determine compatible services and collectively find a solution.
5. Case study
Our case study is inspired by the project undertaken in the Washington state in USA using an event driven SOA approach [3]. Unfortunately, the actual implementation architecture is not publicly available, hence a similar project that has the information available is used to form a basis of services required to build such a system. The second project, called open automated demand response (OpenADR), has been carried out by the Lawrence Berkeley National Laboratory [4]. In order to evaluate the self-organization in a SOA environment, a case study based on micro-generation electricity supply chain is implemented.
