Business Object Component Workshop VI: Enterprise Application Integration

Software Agents for Enterprise Application Integration

^¶Computer Science Department and ^¶Research Center in Geomatics

Laval University, Ste-Foy, QC G1K 7P4, Canada

Abstract

In this paper, an enterprise-application integration environment is presented. In order to collaborate efficiently and effectively within this environment, a software agent-based approach is adopted. Integration aims at allowing separate enterprises to share their information resources. However, integration could be impeded by different constraints, such as application distribution and heterogeneity. To overcome these constraints, software agents gathered into multiagent systems could carry out integration operations on behalf of users. Moreover, certain of these agents could be enhanced with mobility mechanisms. Agents provide a natural abstraction to analyse and design integration environments.

Keywords: software agents, enterprise integration, distribution, and heterogeneity.

1. Introduction

With the recent progress in information technologies, such as the World Wide Web, enterprises are much more complex and dynamic. For example, new alliances, leading to merging these enterprises’ processes, are set up. Usually, enterprises manage several software applications that are distributed across networks and heterogeneous at different levels (hardware, software, and particularly terminology). Integrating these applications is a great challenge for designers and managers. In fact, integration is not usually a technical matter but most of the time, related to difference in semantics and business rules between applications that were never intended to collaborate. Integration aims at allowing an enterprise to share transparently its information resources with its own divisions, i.e. internal sharing, as well as with other enterprises, i.e. external sharing[1]. In order to assist enterprises in achieving their information sharing, an infrastructure that supports application integration should be developed. This infrastructure should be able to consider the relevant aspects that characterize integration, such as distribution – where do this integration’s operations take place, role – who is responsible for carrying out these operations, and resource – what do these operations require. In order to deal with these several aspects, a promising approach consists of developing a set of intelligent components, called Software Agents (SAs) [1] that could run on top of the integration infrastructure. Enhanced with appropriate mechanisms, each SA would be able to act on behalf of an enterprise in this infrastructure.

Setting up an infrastructure for enterprise application integration requires working at three different levels. The first level, called interconnectivity, allows simple data transfer with no semantic. The second level, called integration, involves the various applications and enables these application to exchange information and invoke mutually their services, even if different persons designed these applications at different times with different techniques. Working at the application level is not enough, particularly if the enterprises have to merge as well as to expand their business processes. Therefore, collaboration at the management level is required. In what follows, the three levels are summarised[2] (cf. Figure 1):

-         Interconnectivity at the physical level: to guarantee basic communication, computing resources are first interconnected to exchange messages.

-         Integration at the application level: its main purpose is to carry out operations among different applications. Generally, these applications are distributed and heterogeneous. The support infrastructure, that we intend to develop, should be associated with the integration level.

-         Collaboration at the management level: it goes beyond application integration, by expanding processes to other enterprises. To this end, a collection of software agents could be used in carrying out these processes. These agents should run on top of the support infrastructure.

Figure 1 From interconnectivity to collaboration, through integration

Traditionally approaches for distributed and heterogeneous application integration achieve this integration via a global schema or a common manipulation language [2,3]. Unfortunately, most of these approaches have little or no concern to adaptability, flexibility, and scalability requirements. In this paper, we illustrate how SA technology allows meeting these requirements. Agents, viewed collectively as a society, work together to achieve their own goals, as well as the goals of the whole society. The society and its agents correspond respectively to the integration environment and the enterprise applications.

The remainder of the paper is organized as follows. Section 2 presents an overview of the relevant concepts that are used in the development of our integration environment. Section 3 details this environment at structural and functional levels. Section 4 describes an implementation of this environment. Finally, Section 5 concludes this paper.

2. Basic Concepts

Several advanced concepts could be used in the design and development of an integration environment. In this section, we briefly describe those that are used in our work, namely SA, Workflow (WF) [5], code mobility [6], and virtual process.

-         What is a software agent? It is an autonomous entity having the abilities to assist users in performing their operations, to collaborate with other SAs to jointly solve different problems, and to answer users' needs.

-         What is a Workflow? It is "the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules" (Workflow Management Coalition) [7].

-         What is code mobility? It is a program that can migrate from machine to machine in a heterogeneous network. The execution of this program can be suspended at an arbitrary point and resumed to another machine.

-         What is a virtual process? It is a process whose execution goes beyond an enterprise’s boundaries. This process combines the services provided by different enterprises.

3. An Infrastructure for Enterprise Application Integration

In order to remain competitive, enterprises tend to follow and monitor the progress of their business processes. To this end, multiple enabling technologies, such as WFs, could be used. In fact, these enterprises aim at being able to react efficiently and quickly to name a few, to the events that could impede their processes from being completed successfully. However, when these processes span different divisions of separate enterprises, i.e. a virtual process, monitoring their progress is a much more complex operation for users. In what follows, we present the infrastructure that could support these users.

3.1 Infrastructure Architecture

In [8], a number of issues that should be addressed when developing an integration architecture have been identified:

-         Heterogeneity: most enterprises are heterogeneous with respect to hardware platforms, operating systems, and programming languages.

-         Semantic unification: when different applications share information, they must be referring to the same thing.

-         Security: since an integration architecture includes several applications from different origins, security must be present in several forms, for instance users must be authenticated and data must be encrypted.

-         Adaptability: an integration architecture is constantly growing to include new enterprise applications. Therefore, this architecture must be flexibly enough to adapt to this.

-         Standards compliance: by complying with existing standards, it makes it easy to design an adaptable integration architecture.

Additional issues should be dealt with, such as: how to provide a mechanism whereby enterprises can advertise their capabilities, in term of services to offer? How to execute processes spanning several enterprises? And, how to keep track of such processes for monitoring purposes?

Figure 2 illustrates the infrastructure architecture we suggested for enterprise application integration. This architecture can be viewed from two different sides: enterprise side and user side. Moreover, this architecture integrates two types of SAs, namely user-agent and interface-agent. Among these SAs, certain are enhanced with mobility mechanisms. User-agents belong to the user side and interface-agents belong to the enterprise side. In the infrastructure architecture, each enterprise is encapsulated into a Multi-Agent System[3] (MAS) that maintains its autonomy. Each MAS integrates several interface-agents that are respectively associated with the enterprise applications. Two services exist in the infrastructure architecture: application-services offered by interface-agents and integration-services offered by user-agents.

Figure 2 Infrastructure architecture for enterprise application integration

In Figure 2, we assume that the applications of an enterprise are connected through Local Area Networks (LANs). In addition, we assume that the enterprises that aim at constituting an integration environment are connected through Wide Area Networks (WANs). The enterprise and user sides interact through a communication infrastructure. This infrastructure offers the appropriate functionalities to support remote interactions as well as mobility. Remote interaction means that a user-agent sends its queries to interface-agents. Next, these interface-agents process these queries and send back the results they obtained to this user-agent. However, mobility means that a user-agent migrates to a MAS, interacts locally with its interface-agents to process its queries, and goes back with the results it obtained to its original site.

Services types

In the infrastructure architecture of Figure 2, two types of services exist: application and integration.

-         An application-service identifies a capability that an enterprise application achieves, such as updating a database. In fact, an application-service is a means to advertise an application’s capabilities to the external environment.

-          An integration-service is offered to users who aim at integrating multiple applications in order to satisfy their needs. Therefore, the completion of an integration-service involves multiple application-services. An example of an integration-service could be tracking the progress of a process that needs to be run on two separate applications. In our work, each integration-service is associated with a WF (cf. Table 1). We recall that a WF is a set of processes, which themselves are a set of tasks.

Agent types

In the infrastructure architecture of Figure 2, two types of agents exist: interface-agent and user-agent.

-         An interface-agent maintains the autonomy of an enterprise application and hence, knows the protocols through which this application accepts requests and provides back results. In fact, an interface-agent is the proxy of the application.

-         A user-agent acts on behalf a user. Hence, it assists this user in satisfying his needs. Each user-agent has the ability to create a delegate-agent and ship this delegate-agent to appropriate MASs. This means that delegate-agents are mobiles.

3.2 Infrastructure Functioning

Once a user initiates an integration-service, its user-agent uses the appropriate WF of this service. Next, the user-agent performs remotely this WF’s processes in collaboration with diverse interface-agents. Such a situation corresponds to the case where the WF that is used requires remote interactions between the user side and the enterprise side (cf. Figure 3). More interesting are the situations requiring agents’ mobility between user and enterprise sides as well as between MASs. In fact, a delegate-agent moves to distant MASs and interacts locally with their interface-agents. An example of such a situation is given below.

Figure 3 Infrastructure functioning for enterprise application integration

Figure 3 illustrates an example of a WF that involves three enterprise applications (Application₁₁, Application₁₂, and Application₂₁) and two MASs (MAS₁ and MAS₂). Application₁₁ and Application₁₂ belong to MAS₁ of Enterprise₁ and Application₂₁ belongs to MAS₂ of Enterprise₂. Numbers in Figure 3 correspond to the chronology order of operations. Once the user invokes an integration-service, the user-agent creates a delegate-agent. Next, the user-agent assigns to this delegate-agent the WF of this integration-service. This WF mentions that the delegate-agent has to move[4] to MAS₁. When this delegate-agent arrives at MAS₁ (1), it interacts with interface-agent₁₁ (2) in order to perform the WF’s processes on Application₁₁ (3). This means that the application-services of interface-agent₁₁ are invoked. In addition, the WF in progress mentions that other processes need to be performed on Application₁₂. Hence, the delegate-agent interacts remotely, through the LAN, (4) with interface-agent₁₂ (5). Moreover, the WF mentions that Application₂₁ is also required before the WF can be totally completed. Therefore, the delegate-agent migrates to MAS₂ (6) and meets with interface-agent₂₁ (7,8). Then, the user is notified with the final results of the requested service (9). At the end, the delegate-agent is deleted.

WFs specification

In Table 1, we describe the language we proposed to the specification[5] of a WF of an integration-service. In the following paragraph, numbers between parenthesis refer to numbers in Table 1.

A WF (1) is decomposed into two parts: the head and the body. The head part identifies the WF that is associated with the integration-service (2). The user-agent that is related to this integration-service is also, part of the WF’s head-part. The body part is a set of several processes that are ordered sequentially (3). In order to be completed, a process requires an application-service from an interface-agent (4). This process can be executed either locally or remotely (5).

Table 1 Integration-service specification as a WF

3.3 Agents Definition

In order to meet the requirements of an integration environment, namely flexibility, adaptability, and scalability, we suggested to define an agent according to three characteristics: intrinsic, organisational, and social (cf. Figure 4). These characteristics could be applied to an interface-agent as well as to a user-agent.

1.      Intrinsic characteristics are directly related to the agent and consist of the following properties:

-         Identifier.

-         Role.

-         Services to offer /* each service represents a capability of the agent */.

2.      Organisational characteristics are related to the management of the agent according to the environment in which it evolves. These characteristics consist of the following properties:

-         Supervisor: (yes/no) → identifier.

-         Subordinates: (yes/no) → *{identifier}*.

-         Group of subordinates: (yes/no) → {responsible,identifier}.

-         Areas of operations /* in an integration environment and for security purposes, it is important to be aware of the areas in which an agent performs its services. An agent’s area of operations could contain both cooperative and concurrent agents */.

3.      Social characteristics are related to the behavior of the agent towards other agents. These characteristics consist of the following property:

-         Message → interaction pattern /* an interaction pattern is associated with each message an agent receives. Patterns specify how agents should behave */.

Figure 4 Agent representation in an integration environment

As presented above, an agent performs its services according to the areas of operations that are assigned to this agent (cf. Table 2). However, in order to perform these services, this agent requires authorisations from whether its supervisor, the supervisor of the area, or both.

Table 2 provides examples of a service specification. We assume that agent₁ offers service₁ and service₂. In order to perform service₁ in area₁, for example financial department, agent₁ requires an authorisation from agent₂. Agent₂ is agent₁’s supervisor (link: Agent-Supervisor). However, agent₁ does not require an authorisation for service₁ if this service is executed in area₂, for example stock department. Regarding service₂, agent₁ requires authorisations for both area₁ and area₂. These authorisations are provided by both agent₂ that supervises agent₁ (link: Agent-Supervisor) and agent₄ that supervises area₁ (link: Area-Supervisor).

Table 2 Examples of a service specification

Example

Figure 5 provided a representation of the agent’s three characteristics. In what follows, we focus our description on agent_i. We assume that agent_i is an interface-agent and is responsible for production management in enterprise₁.

1.      Intrinsic characteristics

-         Identifier: agent_i.

-         Role: production manager.

-         Services to offer: DB_product_update; DB_product_edition (these services correspond to different application-services).

2.      Organisational characteristics

-         Supervisor:  yes → identifier: agent_j.

-         Subordinates: yes → identifiers: agent_1,2,3.

-         Group of subordinates: yes → responsible: agent₁ – identifiers: agent_1,2.

-         Areas of operations:

-         Enterprise₁: (Area₁₁ - agent_a,b) (Area₁₂ - no agents).

Area₁₁ and area₁₂ could respectively be the financial department and the stock department. In area₁₁, agent_a could be the accounting manager.

-         Enterprise₂: (Area₂₁ - agent_c).

Area₂₁ could be the customer department.

3.      Social characteristics

-         Message “request details on product_p”

Figure 5 Example of an interaction pattern

4. Implementation

Figure 6 presents a snapshot of the prototype that is used in simulating the integration environment of Section 3.1. In this prototype, the agents are implemented as Java classes, through JDK 1.2.2 for Windows. Moreover, the mobility of certain agents is achieved through the middleware Bee-gent from Toshiba [9]. In Bee-gent, two types of agents exist, namely wrapper (static) and mediator (mobile).

In our work, we have developed five agents, namely supervisor, agent₁, agent₂, agt-enterprise₁, and agt-enterprise₂. Supervisor, agent₁, and agent₂ inherit from the wrapper class while agt-enterprise₁ and agt-enterprise₂ inherit from the mediation class. The supervisor supervises both agent₁ and agent₂ and asks them to get information from agt-enterprise₁ and agt-enterprise₂. In what follows, we focus our description on agent₁. The same description applies to agent₂. First of all, the supervisor creates agent₁ (message 1.1: I have created agent₁) and sends it to enterprise₁. As soon as agent₁ arrives to enterprise₁, it interacts with agt-enterprise₁ that acts on behalf of this enterprise (message 1.4: I am talking with agent₁). Finally, agent₁ returns back to the host of its supervisor with appropriate information (message 1.5: agent₁ has returned back to its supervisor; message 1.6: agent₁ is back and brings this information from enterprise₁: enterprise₁ is at 132.203.114.20). The purpose of the current prototype is to demonstrate the feasibility of our approach for enterprise application integration. More work needs to be done, for instance by enhancing agents with WF systems.

5. Conclusion

In this paper, we presented the major structural and functional characteristics of an environment for enterprise application integration. This environment relies on software agents to carry out the operations that satisfy users’ needs. Two types of agents exist, namely interface-agents and user-agents. An additional type of agents, called delegate-agent, is created when needed. A delegate-agent is mobile.

Satisfying users’ needs require from interface-agents, user-agents, and delegate-agents to interact and perform different operations. How these agents behave is mainly defined using WFs. Each WF is a set of processes that are performed either locally or remotely.

Figure 6 Snapshot of the integration environment prototype

References