Seamless Incorporation of Agents in an E-Commerce
Intermediation Platform
Irene Sygkouna1, Maria Strimpakou1, Francisco Valera 2, Anastasia Kaltabani1, Luis Bellido3, Enrique Vazquez3, Miltiades Anagnostou1
1
National Technical University of Athens, 9, Heroon Polytechneiou Str., 15773, Zografou, Athens, Greece
{isygk, mstrim, akalt, miltos}@telecom.ntua.gr 2
Universidad Carlos III de Madrid (UC3M) Avda. de la Universidad 30, 28911 Leganés, Madrid, Spain
Universidad Politécnica de Madrid (UPM). Spain. {lbt, evazquez}@dit.upm.es
Abstract. This paper describes the realization of a business-to-business inter-mediation e-commerce platform. The main concern derives from the usage of two emerging technologies, namely the Java 2 Enterprise Edition (J2EE) and the Mobile Agent Technology (MAT). The key issues that are addressed in this paper are the following. First, the scenario of the proposed system. Second, the definition of the required functionality and its design by means of appropriate service components based on J2EE principles. Third, the exploitation of agents in terms of their detailed design and implementation activities. Finally, the evaluation of the two interoperable technologies.
1
Introduction
Over the past few years, electronic commerce has become an increasingly central part of the economy. In e-commerce literature, the overall electronic intermediation theme, as well as its relevance and relationship with particular business to business issues, have attracted considerable attention and generated quite comprehensive analyses. Equally important experimentation and commercial exploitation of respective soft-ware systems [1,2] have been, in parallel, achieved.
One of the most important things in actual electronic commerce is to achieve an accurate information interchange between participating entities (typically customer and provider), using any available communication infrastructure. The current net-working environments with all the Internet and Intranets communication services make possible the access to a great amount of information. Nowadays, it is essential to find a mechanism that allows customers and providers to find each others and per-form e-commerce transactions in a fluent and precise manner, minimizing the time normally spent in finding useful information, which tends to be quite high. This kind of mechanism is provided by the so called mediation platform that typically includes the set of duties which are supposed to rule every transaction associated with
e-commerce and are oriented to decrease the distance between customers and providers, from a commercial point of view.
In this paper, we present a particular brokerage platform, compliant to business to business models and respective systems implementation requirements, that is consid-ered applicable across a number of diverse business domains. It introduces some ex-periences from the architecture, that are mostly related to the J2EE and MAT. The whole procedure has been performed in the context of the IST Smart-EC project.
The J3EETM [3], is a middleware platform that facilitates the development, de-ployment and execution of distributed multi-tier Internet applications. On the other hand, MAT is an advanced software technology, well suited for e-commerce, which supports the possibility of the direct and efficient interaction with procurement soft-ware through the agents’ ability to move among network nodes.
This article is structured as follows: Section 2 describes the scenario of the pro-posed platform as well as its architecture in terms of the J2EE terminology. Section 3 focuses on the usage of the agent technology according to a detailed design and im-plementation issues, and the incorporation of the two technologies. Section 4 evalu-ates the usage of the two aforementioned software technologies. Finally, some co m-parisons and conclusions are presented.
2
Modeling an intermediation e-commerce platform
2.1 Smart-EC Scenario
In the proposed complex services transactions model we consider three basic domains that is the User Domain, the Service Provider Domain and the Broker Domain, which actually represents the specific brokerage platform domain. The main phases of the complex e-commerce service transactions lifecycle of the proposed system are the following: first, the request formulation and solutions pre-processing, second, the so-lutions identification and bilateral negotiation, third, the soso-lutions evaluation and fi-nally, the transaction execution. The proposed system [4] is able to handle complex services composed by a set of simple services. A simple service is defined to be pro-vided as a whole by a provider. In the sequel, the functionality of the complex serv-ices transaction e-commerce system is described.
After a customer has successfully accessed the system, he may construct requests by browsing a hierarchical menu of provided services. The knowledge required by the user to dynamically formulate a complex service request is provided by means of the Ontology technology [5] capabilities supported by the platform. Upon the user request validation and confirmation, the system invokes its internal brokering functionality in order to find an acceptable solution. A solution is defined as a set of offers (made by service providers) that is able to satisfy the user request. Specifically, for each simple service composing the request, the system identifies corresponding offers (i.e., zero, one, or more) meeting the requirements that account to the attribute values selected in the request form.
When the solution identification phase is completed, the system presents a solution to the customer. The solution may be presented in several ways depending on the customer preferences. The platform is designed so as to support the co-operation with
and servicing to a class of providers by allowing an extensive and online access to the brokered resources (affiliate service providers). The customer of the described bro-kerage platform, hereafter denoted as user, may redefine the attribute values of simple services for which no satisfactory offers have been found. In this case, the system will validate the updated request and perform a new solution identification process, until a satisfactory solution is found.
Once the proposed solution has been accepted the system proceeds with the subs e-quent phase that is the transaction execution phase. In this last phase, the platform performs the corresponding service reservation and the necessary interactions with the service provider domains in order to actually proceed with e-commerce services pro-vision and delivery.
2.2 Smart-EC Architecture based on J2EE principles
In the middle of the J2EE architecture are Enterprise JavaBeansTM (EJBTM), which are responsible for solving the business logic and data access of the enterprise applic a-tion. They are reusable components where developers can code almost any necessary object functionality (through session or entity beans) and that can be accessed by cli-ent programs and run on a J2EE server.
Following this movement, in Smart-EC a three-level-tier architecture (client, server and information services) based on J2EE is being used (see Fig.1). In this way, clients just have to handle the user interface and they do not have to query databases, execute complex business rules, or connect to legacy applications, because the middle-tier server is doing these jobs for them transparently.
SYSTEM CONTROLLER SYSTEM CONTROLLER A D M I N I S T . M A N A G E R L O G I N L O G I N U S E R H A N D L E R U S E R H A N D L E R P R O V I D E R H A N D L E R P R O V I D E R H A N D L E R S O L U T I O N B U I L D E R S O L U T I O N B U I L D E R H A N D L E R T R A N S A C T I O N H A N D L E R T R A N S A C T I O N H A N D L E R O N T O L O G Y H A N D L E R D A T A C O N T R O L L E R O N T O L O G Y O N T O L O G Y D BD B G E N E R I C S E R V L E T G E N E R I C S E R V L E T
J 2 E E
J 2 E E
H A N D L E R C U S T O M E R H A N D L E R C U S T O M E R C O M P L E X S E R V I C E H A N D L E R C O M P L E X S E R V I C E H A N D L E R R E M O T E P R O V I D E R H A N D L E R R E M O T E P R O V I D E R H A N D L E R M O D E L S U T I L S PROVIDER WAP I N T E R F A C E W E B INTERFACEFig. 1. Smart-EC core system architecture based on J2EE
Smart-EC supports a diversity of heterogeneous clients, such as Web browsers and hand held devices. These clients are built with plain HTML and WML pages (no Java applets or scripting languages are used) and server access is done through HTML and WML forms that are processed by a servlet in the middle tier.
This servlet acts as an information entry point to the middle tier from the client and several EJBs are responsible for providing the business logic of the project (see Fig. 1). One of them, the System Controller Bean, is responsible for analysing the XML stream received from the servlet and dispatching the corresponding action to other related beans (UserHandler, ProviderHandler, LoginBean). These XML information exchanges, together with XSL (eXtensible Stylesheet Language) documents make the system independent from the accessing device.
Whenever it is necessary to retrieve external data, two special beans are used to contact the third tier of the architecture: the Ontology Handler is able to interact with the stored ontological knowledge and the Data Controller is centralising specific data-base accesses (user and provider profiles and catalogue queries or updates), so that the rest of the modules do not have to cope with database issues. Finally, there are three more beans that complete the system: the Complex Service Handler that is able to build atomic requests breaking the global request from the user into simpler requests so that they can be solved by different providers although they are finally offered as a whole to the user, the Solution Builder bean classifies the retrieved catalogue so as to select the offers that best fit with the user requests and the Transaction Handler bean in order to complete the trading cycle.
The remaining bean, the Remote Provider Handler (RPH), is responsible for the connection of the system with the external affiliate provider system. In specific, RPH is commissioned with the responsibility to create and delegate the Mobile Provider Agent (MPA) in order to carry out the interaction between the Smart-EC side and each affiliate provider. In each Affiliate Provider Domain, the two agents that are identified are called Static Affiliate Provider Agent (SAPA) and Mobile Affiliate Pro-vider Agent (MAPA), respectively.
3
Use of Agents in Smart-EC
In the context of the system communication with the external providers, a two-way interaction is ensured, namely each external provider has the possibility to contact the broker domain while on the other way around the Smart-EC system takes the initia-tive to contact the remote providers.
3.1 Agent-based functionality
The functionality that is mainly provided by the agents in the Smart-EC platform is spanned over the processes that are analytically described in the sequel.
The proposed system architecture enables each affiliate provider to contact the Smart-EC platform in order to keep up-to-date the system database. In this respect, he has the possibility to add, update or delete one or more of his offers to/from the sys-tem database. In the first case, namely the addition or update of offers, SAPA creates MAPA and supplies him with a collection of offers retrieved from provider’s database apart from the credentials that are necessary for gaining access to the Smart-EC data-base. Then, MAPA migrates to the broker domain and proceeds with the permissible insertion of the offers in the database. In the case of the deletion, MAPA is provided
with the code names of the offers that have to be deleted as well as with the corre-sponding credentials. The following figure shows the sequence of the events.
S m a r t - E C D a t a b a s e S t a t i c A f f i l i a t e P r o v i d e r A g e n t M o b i l e A f f i l i a t e P r o v i d e r A g e n t c r e a t e a d d U p d a t e O f f e r s d e l e t e O f f e r s a u t h e n t i c a t e
Fig. 2. Affiliate provider initiative for the information update in Smart-EC
In Smart-EC domain, the administrator, in terms of his global monitoring responsi-bility, is able to request specific offers or the whole catalogue of offers that are a pro-vider’s own. More specifically, he is privileged to request the update of offers when-ever he detects that some offers stored in the Smart-EC database are stale. In this sense, the AdminManager invokes the RPH who in turn creates and initiates the MPA. The RPH supplies the MPA with the appropriate credentials so as to be authenticated in the affiliate provider side and the requested offers code names. In the sequel, the MPA migrates to the affiliate provider domain where he interacts with the SAPA in order to be authenticated and to obtain the relevant information from the lo-cal database. Then, it migrates back to the system where the captured information is stored in the Smart-EC database. The aforementioned process is analyzed in terms of time ordered messages, in the following sequence diagram (Fig.3):
Smart-EC Database AdminManager RemoteProvider Handler Mobile ProviderAgent StaticAffiliate ProviderAgent A f f i l i a t e D a t a b a s e requestOffers create getOffersRemote getOffers updateOffers getUser getOffersbyCodes
During the process of finding suitable offers that meet the user request, the Solu-tion Builder (SB) sometimes tracks that some offers stored in the database are incom-plete, i.e., some attributes have no value. In this case, he requests these offers to be completed by contacting the owner of the offers and afterwards proceeds with the evaluation of their potential correspondence to the user request.
The relevant process falls into the following operations: The SB invokes the RPH who then creates the MPA. Following, the MPA migrates to the affiliate provider do-main carrying the code names of the incomplete offers. With the fulfillment of the compulsory authentication procedure he retrieves the completed offers through the SAPA agent. Finally, he returns back and delivers the acquired information to the SB. In the context of the solution building, if the customer has selected the online checking of the offers’ availability, a remote communication takes place between the system and the appropriate affiliate provider. In this sense, the system avoids propos-ing to the user a pointless solution due to potential unavailability.
In terms of system modules, as it is shown in the next diagram (Fig.4), the SB trig-gers the RPH who then communicates remotely with the SAPA residing at the pro-vider side. At the end, SAPA returns the proper answer after inquiring the local data-base. The following sequence diagram enlightens the aforementioned processes:
S o l u t i o n B u i l d e r S m a r t - E C D a t a b a s e R e m o t e P r o v i d e r H a n d l e r M o b i l e P r o v i d e r A g e n t S t a t i c A f f i l i a t e P r o v i d e r A g e n t A f f i l i a t e D a t a b a s e g e t O f f e r s c o m p l e t e O f f e r s c r e a t e g e t O f f e r s R e m o t e g e t O f f e r s c h e c k A v a i l a b i l i t y c h e c k A v a i l R e m o t e u p d a t e O f f e r s g e t U s e r g e t O f f e r s b y C o d e s g e t A v a i l
Fig. 4. Solution building procedure with the affiliate provider participation
Once the customer determines the most preferable solution according to his request among a list of proposed solutions, the system engages to start the transaction proce-dure. For the offers that correspond to affiliate providers, an online connection to these providers is required. More specifically, the transaction phase consists of the following tasks:
1. Reserve all the atomic offers that compose the solution and correspond to different affiliate providers.
2. Confirm every atomic offer if each one has been successfully reserved.
3. Cancel the overall reservation in the case that at least one of the atomic offers ei-ther is not reserved or is not confirmed by the corresponding affiliate provider. As the following diagram depicts (Fig.5), the Transaction Handler (TH) that is triggered with the customer initiative to proceed with the transaction details, invokes the RPH that in turn communicates remotely with the SAPA in order to perform the specified task. C u s t o m e r H a n d l e r T r a n s a c t i o n H a n d l e r R e m o t e P r o v i d e r H a n d l e r S t a t i c A f f i l i a t e P r o v i d e r A g e n t A f f i l i a t e D a t a b a s e s t a r t G l o b a l T r a n s a c t i o n r e s e r v e S e r v i c e c a n c e l S e r v i c e r e s e r v e S e r v R e m o t e c a n c e l S e r v R e m o t e g e t R e s c o n f i r m S e r v i c e c o n f i r m S e r v R e m o t e g e t C o n f g e t C a n c e l
Fig. 5. Involvement of affiliate provider in transaction procedure
3.2 Implementation of the Agent-based Components
In order to create and execute software agents, the developer can use a ready-made development environment. In the context of Smart-EC, the selection of the mobile agent platform, should enhance the system performance with the higher acceptability regarding the implementation of the core Smart-EC system, while at the same time, overcome any interoperability problems with the J2EE technology. Following the framework of the seamless integration of MAT to the existent architecture of SmarEC, the use of Grasshopper [6] was decided, keeping in mind that one of these pla t-form considerable advantages is that it effectively supports J2EE compliance.
Mobile agents require a specific and secure runtime environment that provides the mechanisms and the functionality necessary on all potential destination hosts, in dis-tributed environments. Among others, this environment has to fulfill the tasks of sup-porting the agents’ creation, execution, localization, migration, communication and security control. In specific, Grasshopper is a middleware mobile agent platform that is built on top of a distributed processing environment, manifesting the evolution of distributed software objects towards mobile agents. In principal, it provides all the
aforementioned services while at the same time it ensures the interoperability between agent platforms of different manufactures, compliant with the Mobile Agent System Interoperability Facilities (MASIF) standard.
As it is known, mobile agents are able to move from one physical network location to another. In this respect, MAT is regarded as a replacement of the client/server paradigm. However, the combination of both approaches, i.e., not only migration and local interactions but also remote procedure calls enables the development of applica-tions that exploit the advantages of both mechanisms in an optimal way, something that Grasshopper supports.
Although Grasshopper platform offers many advantages in the context of Smart-EC system and therefore, the incorporation of mobile agent technology in an e-commerce application is realized without confuting problems, the interoperability between Grasshopper and J2EE technology has a black point.
Specifically, Grasshopper employs the Communication Service, one of the system core services, for all the remote actions that take place between its distributed comp o-nents, such as location-transparent inter-agent communication, agent transport and agents’ localization. In addition, this service enables external application objects, such as Enterprise Java Beans (EJBs) to interact with Grasshopper components. An appli-cation object may act as a client, something that is realized in Smart-EC without any complication, for example EJBs simply invite the agents’ methods. On the other hand, if an application acts as a server, namely receive requests, it must follow some spe-cific rules dictated from the Communication Service. The application component should implement a server interface and start a communication receiver that listens to communication clients on a specific address and port. The dispute arises when a Grasshopper component, in this case one of the designed agents, propagates a request to an EJB.
In this sense, neither a Grasshopper agent is able to create a new instance of an EJB nor an EJB is able to register itself as a server object to the communication re-ceiver. Thus, given this restriction, one of the issues that should be solved is the ac-cess to the Smart-EC database by an agent. Undoubtedly, a Grasshopper agent can contain SQL code and elaborate a usual API, like JDBC, for accessing a database. The main drawback in this approach comes from the fact that in systems like Smart-EC is much more efficient to retain a centralized control of the database to a unique component and not let other components interfere with it. Moreover, the code for dis-seminating data in the database is already in the Data Controller component and it would be inefficient to repeat existing functionality. In this respect, an alternative is found and the desired communication is achieved with the usage of J2EE Application Clients.
A J2EE Application Client is a Java application that differs from a stand-alone Java application Client simply because it is a J2EE component. Firstly, it is portable, running on any J2EE-compliant server and secondly, it may access J2EE services. In a few words, it is a stand-alone program launched from the command line or desktop, and typically accesses EJB executed on the J2EE application server. A brief insight in the way the J2EE application client acts as a middleware between Grasshopper agents and EJBs is illustrated in the Fig. 6.
Enterprise Bean Home Interface Remote Interface Container Database J2EE Server J2EE Server Main Module Application Client Server Object Module Main Module Grasshopper Core System Agent Modules
Grasshopper Communication Receiver
Fig. 6. The J2EE Application Client as a middleware in Smart-EC
As it is depicted, the Application Client comprises two modules. Firstly, a server object module that actually implements the server interface and provides the access to the EJBs methods. Secondly, a main module that starts the communication receiver and registers the aforementioned server object to it. Thus, if an agent is commissioned to access an EJB method it merely uses the standard communication mechanism that Grasshopper prescribes for accessing any external application.
5
Evaluation of the J2EE and Mobile Agent Technologies
After the implementation of the final prototype of Smart-EC (May 2002), we can conclude that these are the main advantages we have obtained from J2EE in order to design, build and run our e-commerce mediation platform:
• Easy design and integration process: The structured modular approach imposed by the EJB architecture serves the good functionality division and reusability of code. Moreover, due to this modularity, the integration phase is not so hard as in con-ventional software developments.
• Distribution facilities: communications between different EJBs are mainly based on RMI. This means that application distribution has been managed in a co m-pletely transparent manner in our system.
• Supporting services: some commerce necessary tasks such as transaction and s e-curity are easily managed by the system.
• Database interoperability: it is almost immediate to install different databases and make them run within the system. In Smart-EC prototype, both Cloudscape and Oracle databases have been used and both are accessed locally or remotely. Despite of these advantages, J2EE has also shown notorious inconvenience during several phases of the project:
• The development and execution platform is quite a resource intensive one. It is mandatory to have never less than a Pentium III with 128 MB RAM.
• During the designing phase, remote communications, scalability and database de-sign and fine-tuning, must be seriously considered. Otherwise, the running appli-cation will be suffering from serious performance lacks.
• Integration and deployment processes have turned out to be very specialised tasks that have nothing to do with other kind of software development cycles.
Apart from the J2EE, an evaluation process of the mobile agent technology is also regarded. Taking into consideration that Smart-EC system is not a pure mobile agent application but one that elaborates agents as an add-hoc technology for serving the real-time access to remote resources, the main observations are the following:
• For complex or data-intensive interactions, where the amount of the transferring data is considered respectable, e.g. in the request offers procedure, or the given task involves multiple interactions in order to be accomplished, the shifting of the computation to the data rather than the opposite, with the elaboration of agents, is a very appealing proposition to reduce the network load.
• On the other hand, the design procedure has shown that in some use cases, the sum of the exchanged communication messages restricts to limited, short server request and responses, e.g., in the transaction procedure. In this context, the use of a mo-bile agent would consume extravagant bandwidth, in expense to performance, comparing to the utilization of remote location-transparent procedure calls. In this sense, the proposed application takes advantage of both communication mecha-nisms that the mobile agent platform supports.
• Concluding, it is worth mentioning that the interoperability between J2EE and Grasshopper agent platform is quite feasible despite the fact that some additional system configurations are needed in order to achieve their successful merging. In this respect, a more global exploitation of the J2EE facilities is accomplished due to the fact that the use of J2EE Application Clients is motivated.
6
Conclusions
In this paper, an intermediation platform for e-commerce is described emphasizing on the several experiences derived from the usage of the new middleware J2EE platform and the mobile agent possibilities within the same environment that are considered as a value added in its architecture. Useful and interesting remarks from the combined exploitation of both technologies are also deduced.
References
1. Martin Bichler, Arie Segev, “A Brokerage Framework for Internet Commerce”,
Distrib-uted and Parallel Databases, Vol.7, Number 2, pp.133-148, April 1999
2. M. Lambrou, G.Karetsos, E.Protonotarios, “A Service Analysis and Service Design
Framework for the Implementation of a generic Brokerage Service”, Advances in Info r-mation Technologies: The Business Challenge, pp. 226-233, IOS press, 1998
3. Sun Microsystems , Inc. JavaTM 2 Platform, Enterprise Edition Specification v 1.3.
Febru-ary 2001. [Last visited: August 2001] http://java.sun.com/j2ee/
4. Smart-EC: Support for Mediation And bRokering for Electronic Commerce,
IST-1999-10130, RTD Project, Deliverable 3.1, “Service Specifications”
5. M. Fernandez Lopez, “Overview of methodologies for building ontologies”, Proceedings
of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5)
