Effective e-commerce relies on an efficient and precise information interchange between participating stakeholders (typically customer and provider), using the existing communication infrastructure. Internet and intranet communication facilities are making the amount of available information quite large, and it continues to increase progressively (at the same time, information requested by users is gradually rising too). It is imperative to find some mechanism that allows clients and servers to interchange information in a fluent and precise manner, minimizing the time normally spent in finding really useful information, which tends to be quite expensive. Experiences using a multiagent system (MAS)-based intermediation service for e-commerce, implemented with Java and CORBA are described here, with emphasis on communication and management system activities.
Brokerage service (provided by an information broker) is a very helpful tool to promote symmetry in the context of e-commerce, allowing customers and providers to communicate in a simpler manner. The main problem it has to address is information acquisition and subsequent information delivery specifically required by users. Generally, this brokerage service enables navigation through an information index, so that users can begin a search procedure in order to find what is demanded.
There are more flexible and transparent approaches, however, based on personal recommendations (user profiles) with the intention that users are not forced to become involved in the navigation process, which often becomes somewhat complicated [5, 9]. We will distinguish between two of these systems:
- Natural-language approach: users can make requests and select the desired information more comfortably. They can also increasingly improve their profiles and the searching mechanism, evaluating the received results.
- Collaborative entities: the main idea is to create common knowledge, so that users can get information from each other and mutually take advantage of this learning mechanism while looking for useful information. Agent technology will be very relevant here [5].
A brokerage service of the kind we have introduced would be considered a constitutive part of what is usually known as a mediation platform [1]. This platform includes the set of duties that are supposed to rule every transaction associated with e-commerce: brokerage, security, delivery, accounting, billing, and connectivity. All these tasks are oriented toward decreasing the distance between users and providers from a commercial viewpoint.
ABROSE Prototype
Following all these ideas, an implementation of an electronic brokerage service based on agent technology, Java (JDK1.1.7+Swing), and CORBA (OrbixWeb3.1), with a fully functional management system, has been developed in the context of the ABROSE1 project (Agent Based Brokerage Services in Electronic Commerce), belonging to the European Commission ACTS program. ABROSE, formally specified using UML (with Rational Rose98), explicitly emphasizes the brokerage task (enforced by agent technology), including the two navigation and collaboration approaches we mentioned. The main proposed objectives in ABROSE include:
- Dynamic knowledge capture.
- Usage of a multiagent system to represent the knowledge base.
- Navigation and information retrieval through a graphical interface (also supported by agent technologies). It will also help (together with agents) providers in their labor of registering and propagating their offers.
- Utilization of Java and CORBA as implementation technologies.
- Usage of collaborative agents to optimize intermediation.
- Evaluate agent technology implications in information brokerage and commercial applications.
- Java, CORBA, and SNMP usage to implement the management architecture.
From a functional standpoint, the ABROSE system is an Internet-accessible brokerage service that addresses the diverse technological objectives listed here. The user accesses the system from a Web browser (with the subsequent access phase), and once inside the service, a graphical interface appears and the user is able to ask the broker to collect some information or navigate through its knowledge base (see Figure 1).
Contrasting with an implementation where the broker would consult the different providers, return the answers, and directly represent them in the browser [8], in ABROSE we have the broker exhaustively searching for providers related to the request and users’ having to access the providers by themselves. Agent technology allows the broker to learn users preferences transparently, increasing its accuracy when building the related providers list.
In ABROSE we have the broker exhaustively searching for providers related to the request and users having to access the providers by themselves.
The system architecture is based on two well-differentiated domains: the broker domain, which has the dual mission of brokerage and system management; and the user domain, which assumes all the functionality of displaying information to the end user (navigations, requests, answers, and so forth).
Figure 2 shows the system architecture with the different blocks and relations between them. Some management and communications-related blocks have been omitted and will be further developed later in this article. The remainder of this section covers the different modules, classifying them in the described domains—this description will allow a much more precise understanding of the functioning of the system. The user domain includes:
- Connection Assistant (CA): helps users to connect and join the system.
- Agent Management Assistant (AMA): coordinates intradomain and interdomain communications.
- Navigation Assistant (NA): allows users (providers or customers) to navigate through the broker knowledge base and to select relevant domains and criteria in order to improve their queries.
- Spy: gets information from user requests to enhance user’s preferences from the broker viewpoint (user profile), so that precise information acquisition will be easier.
- Front End (FE): access point to provider information. The user will get a reference to connect FE as the answer to his requests.
The broker domain includes:
- User Access Manager (UAM): manages user profiles and verifies the access to ABROSE. The user profile has, for example, information to perform the access phase (login and password). It is created at system initialization and managed while the service is working.
- Broker Manager (BM): monitors interactions between various modules of the system. It is also responsible for system initialization. Management architecture will be explained later.
- Operator Terminal (OT): helps the system operator to perform management and administration of the service provided by ABROSE. It shows modules status, making access to management parameters easier.
- Multiagent System (MAS): in the broker domain, agents represent both clients and providers. Every agent is associated with a TA (Transaction Agent) module and all the TAs are grouped by knowledge areas and ruled by the MA (Mediation Agent) module. The system knowledge is based on a belief network (BN), formed by the particular knowledge of all these internal agents. Each time a request is made, based on the specific knowledge of the MA or/and the TA, the corresponding provider agents are located. The inverse case is also possible, when a provider makes an offer and the corresponding user agents are found.
Multiagent System
Multiagent systems are computational systems composed of several agents capable of mutual and environmental interactions. Agents can communicate, cooperate, coordinate, and negotiate with one another to reach both individual goals and the good of the overall system in which they are located.
In ABROSE, the MAS is concerned with the brokerage functionality for e-commerce activity. Buyers and sellers are represented by proactive, autonomous, and cooperative agents. The originality of this broker is in the usage of a collective memory to find a relevant agent and in the learning process that updates the knowledge of the collective memory at several levels. Furthermore, each agent has its own viewpoint of itself and of other agents in the system.
The MAS utilizes a three-layer architecture, as described in the following paragraphs, in which every layer is made of communicating agents. At any level, an agent is composed of cooperative agents from a lower level (see Figure 3).
The Mediation Agent (MA), at the upper level controls transaction agents (TAs), encapsulating all their acquired knowledge, and will progressively learn from system transactions. The MA is also responsible for dispatching relevant messages to other MAs (or to a TA that it holds, supposing the MA believes that it can manage the message). The MA can be added or deleted from the system, depending on the needs of having a global knowledge (global BN).
The Transaction Agent (TA) is located at the medium level. Each customer or provider is associated with a TA, storing knowledge about themselves and obtaining information from other TAs hosted by its own MA. The TA is responsible for autonomously exchanging requests or answers with other TAs. At TA level, the right organization comes up when each TA is able to solve requests or to answer an offer received in messages, and always knows partners able to help it. It uses its own beliefs in order to find these partners.
The Belief Agent (BA) is located at the lower level. Both MA and TAs, contain information about themselves and about other agents located in their own level. These beliefs describing the organization of the agent society, are called Belief Networks (BN) and are composed of BAs. The knowledge of an agent on other agents is continuously updated on the basis of the transaction flow. Thus, each layer improves its internal organization in order to give efficiently and constantly relevant information.
Communications in ABROSE
ABROSE communications design and implementation are explained here, introducing the two new blocks UCOMMS and BCOMMS comprising the heart of this architecture, because they both are responsible for client and server being in touch (see Figure 4). Here, we present user domain, broker domain, and interdomain communications architectures.
In general terms, the user domain consists of a Web browser with a Java VM executing the different classes (modules CA, AMA,…), that are downloaded from the Web server through HTTP. The first program to be called is an applet (acquired from the ABROSE Web access page). Afterward, the rest of the modules are loaded in their corresponding graphical interface (CA or AMA) or in independent threads if no graphics are needed (UCOMMS).
In order to communicate between them, these modules use their Java object references, so the main point to allow communications is to provide a method to exchange these references. When the reference of the destination module is known, communication is as easy as executing the desired method in the elected module. UCOMMS, responsible for communicating the user and broker domains, communicates with the rest of the modules of the domain using these Java references as well.
In the broker domain, communications are performed in the same terms as previously discussed. Every module is implemented as an independent thread (BM, BCOMMS, …), although no graphical interface is used now. The BM is the first-launched component and is responsible for initializing the rest of the modules and dispatching references between them. As mentioned, communications are done using these references to execute the corresponding methods.
BCOMMS is the symmetric module of UCOMMS in the broker domain. It is responsible for joining the user domain and the broker domain. Communications with the rest of the modules are done again, using Java references (including agent communications).
In the client/server communications (inter-domain) realm, communications between each domain have been implemented using CORBA and a centralized approach, with two modules (one for each domain) responsible for sending and receiving data from the other domain. That way, UCOMMS and BCOMMS are the only modules that need to speak CORBA. As soon as users need to send any request to the broker, they invoke a method in UCOMMS. This module contacts BCOMMS, which delivers the query to the corresponding module inside the broker domain.
Another possibility would be to make every module responsible for its own communications [1]. Every module in the broker domain would be a CORBA object and communications between them would be through CORBA instead of invocations through Java references, so the system could take advantage of CORBA object distribution possibilities, enabling every module to run on a different machine. Every module in the client side would communicate at its own risk with the corresponding broker module. CORBA utilization, however, implies a speed execution decrease compared to that in the ABROSE scheme, where every broker module is executed in the same JVM and method invocations are immediately performed.
With this distributed possibility, every CORBA module would have to define its programming interfaces using IDL and from the beginning of the implementation stage it would be stated which methods and parameters are accessible from other modules. This may imply a stronger effort in the design stage, but it makes system integration easier because it can be assured that at least module interconnections are homogeneously performed.
With the ABROSE scheme, the only components that must use CORBA are UCOMMS and BCOMMS, and so communications can be managed easier because the rest of the modules stay absolutely unaware of communications complexity (connections, sending and receiving data, error controls, and so forth). It must also be noted that ABROSE does not require a high degree of distribution, so centralized advantages are preferred to distributed ones.
When the user gets into the system, a new UCOMMS instance is created. This module contacts BCOMMS passing its CORBA reference (and getting the equivalent reference from the broker) and from then on, both domains remain connected. From this interchange, it can be deduced that there will only be one BCOMMS instance executing at a time in the broker, while there will be one UCOMMS instance for every connected user. This considerably increases BCOMMS complexity, making it more than a bridge module devoted to receiving calls from UCOMMS and resending them to the proper module or receiving invocations from the broker in order to send them back to the client. Since there can be several users simultaneously connected, BCOMMS must remain permanently unblocked and ready to receive requests from users or answers from the broker.
The applied solution (another view will be presented later) goes through the creation of an independent Java thread every time BCOMMS receives a client call (see Figure 4)—the complete process would be:
- UCOMMS receives a request and transmits it to BCOMMS.
- Instead of making the request to the broker by itself (CORBA invocations can be made non-blocking, but Java invocations as these are, block the calling module until the end of the executed method), it creates a thread that is responsible for making the real request.
- This thread is blocked, and BCOMMS is free again to keep on receiving more requests.
To send the answer back to the user it is not necessary to pass through BCOMMS again (so it will not suffer from additional overflow). The auxiliary thread will receive the answer (it will usually be the attribute returned by the invoked Java method) and will directly give it back to UCOMMS.
In a CORBA synchronous scheme, the answer to a request is usually the returned attribute of an invoked method (the client receives the answer as soon as the server method ends its execution). Occasionally however, it is very interesting to have this answer asynchronously and call-backs are the way to do it. If it is foreseeing that the request will take a long time before it can be processed, the client should not be kept waiting until the end of a specific method. It is much more efficient, from the user viewpoint, to get free once the request is made and make the server send the answer back by itself.
The problem in our case is that every Java call is, by definition, a blocking call. This means that the calling module cannot continue its execution until the module that incorporates the called method finishes its execution. In CORBA there is the possibility of defining a method as one-way that must obviously return nothing and doesn’t block the caller (these are the methods normally used to implement call-backs).
Had we used CORBA to communicate with every module (following the distributed approach presented earlier), no additional mechanism would have been needed (such as threads created by BCOMMS, in order not to get blocked).
Management
Existing problems in agent-based application management like ABROSE are explained here. Some approaches to solutions are provided by comparing several proposals that integrate network management with agent-based application management deployed over these networks.
From a management viewpoint, the deployment of agent-based environments supposes the challenge of obtaining a behavior global view of the applications, through the management information maintained in its components. Therefore, it is necessary to standardize the access to that information, allowing the management service implementations to be reused for future agent-based applications. This also implies the need to instrument the applications to provide the requested management information. Conversely, a large amount of existing management platforms require applications management to be integrated with traditional network management technologies. Another important requirement is to minimize the impact over applications so that management functionality affects their development as little as possible.
The first approach developed in ABROSE (see Figure 5) used a gateway that accessed the different components of the application through a single CORBA interface (the management dispatcher contained in the BM), forwarding the received requests to the application and to network and system agents.
In this case, there was a matching between component names and the defined management information so that the dispatcher could redirect requests using this straight relationship to the different components, threads in the same process address space. These application components might have a well-known management interface, so that access and modification to previously defined variables was possible. The instrumentation has been performed with the inheritance of objects that implement the management interfaces and maintain the managed variables [8].
For a highly distributed scenario, Joint Inter-Domain Management (JIDM) [7] works should be considered: JIDM concepts define how to achieve the interoperability between CORBA, SNMP, and CMIP, describing the translation of the specifications and the interactions between these domains. Applying JIDM concepts, the previous approach would work as follows. When the gateway receives a request, the JIDM algorithms defined for the interaction translation are used to access the manageable resources, translating SNMP primitives to CORBA invocations to objects, and obtaining their references through the services created for this purpose. The components of these resources would implement the IDL interfaces generated, translating the specifications from the management information previously defined in a SMI MIB.
With this approach, CORBA interceptors can also be used to account for the operations exchanged between different components. There exists the possibility of managing different instances of the same component, very useful in a multiagent system. However, the rise of interactions between different system components will cause a loss in the obtained performance [2].
Another approach, which has been applied for the management of the final ABROSE prototype [10], is based on component technology. This facilitates software development, using previously developed objects with modifiable attributes accessing interfaces that fulfill certain design patterns. In the particular case of Java, management JavaBeans have been defined in JMX (Java Management Extensions) for that purpose.
With this approach, it is possible to manage a multiagent and multithreaded application, transparently to managers and programmers, creating components based on the defined management information and finally, adding them to the different threads that compose the application. These components also have the ability of attending requests from traditional network management protocols such as SNMP. The existence of other components that forward requests to other applications allows the usage of external agents to obtain standard management information without requiring any gateway.
In relation to CORBA, communications were monitored using interceptors. A thread was responsible for monitoring users’ connections, accessing users’ CORBA interfaces, so the manager could know at any time who was connected, from where and how long; useful data for a charging functionality. Another thread was responsible for monitoring the state of each agent. This thread would send a notification to the manager if the monitored status was different from that contained in a table, so that he/she could know every time if a certain agent was running, sleeping, or stopped.
Conclusion
The main conclusions we can extract from our communication experiences concern the selection of a centralized communication scheme between domains and the utilization of Java inside of them. The centralized scheme allows concentrating all the complexity that every system demanding connectivity has into two modules, so that all the others can remain unaware of the communication architecture. As it usually happens in a centralized system, a little flexibility is lost and a little additional delay is introduced, because whenever communication is to be established, these intermediate modules must be traversed.
Using Java as the communication medium between modules inside each domain allows higher speed than using CORBA but requires replacing call-back versatility with a more complex implementation code. At the same time, the application environment does not tend to be extremely distributed or heterogeneous, so that CORBA utilization in intradomain communications could be justified.
In respect to agent-based applications management, it has been shown that monitoring and controlling them results in an improvement in the quality of service. The existing technology allows performing this management by means of multiple approaches, each of them more adequate for certain situations. We have also explained several approaches to manage agent-based distributed applications, through the utilization of management platforms and existing network management tools, using solutions based on gateways with different generalization levels and component technology. The management implementation of them has been performed using concepts like inheritance and CORBA interceptors.
Both the presented communication and management architecture have been conveniently validated and verified in the different prototypes implemented for ABROSE. The agent platform has also been implemented, tested, and validated in ABROSE and results have partly been evaluated and reported to FIPA (Foundation for Intelligent Physical Agents) [6].
Join the Discussion (0)
Become a Member or Sign In to Post a Comment