Integrating Mobile Agent Technology into an e-marketplace Solution

Transcription

1 Integrating Mobile Agent Technology into an e-marketplace Solution - The InterMarket Marketplace - Friedrich-Schiller-University Jena Computer Science Department Ingo Müller, Peter Braun, Wilhelm Rossak Friedrich-Schiller-University Jena Computer Science Department Ernst-Abbe-Platz 1-4 D Jena, Germany Tel. +49 (0)3641 / Fax. +49 (0)3641 / Ingo.Mueller@informatik.uni-jena.de

2

3 Abstract E-marketplaces are trading platforms that offer e-commerce online trade between several buying and selling companies. They enable good trading possibilities by supporting different business models such as multi-supplier catalog-based e-sales and e-procurement, pinboard or exchange system as well as several types of auctions. E-marketplaces give their participants the ability on the one side to acquire new trading partners or even new markets and on the other side to simplify their procurement and sales processes for reducing costs. This sector of e-commerce is growing rapidly and is predicted to reach 37 percent of overall e-commerce, generating total revenues up to 6 trillion US dollars worldwide by the end of 2004 [22, 26]. The main goal of e-marketplaces in their formation phase from the end of 1995 to 1998 was to bring different trading partners together. However, the requirements on e-marketplaces already increased within this phase. Companies demand additional features for lowering costs and for automation and optimization of their business processes. According to this, the ostensible task for e-marketplaces in the second phase from 1998 to 2001 was to offer more value adding services through intensively support the value chain such as with offering services for initiation, fulfillment, and completion of trading transactions including shipment, payment and logistic services. Nevertheless, today s e-marketplaces lack of fully automated business processes and still require a significant manual effort by human users. The mobile agent technology might take e-commerce trading to the next phase. Mobile agents are intelligent, independent, and pro active electronic representatives of businesses such as buyers, suppliers, customers, or even whole companies which can relieve marketplace participants from lots of routine works. The mobile agent technology can be a suitable approach for resolving the given problems. On the one hand intelligent stationary agents add automated trading capabilities and intelligent negotiation models for example for auctions, request for quotes, and request for proposals and on the other hand mobile agents can easily offer connections to mobile devices such as personal digital assistants or mobile phones. Besides, mobile agents add even more business opportunities because they can represent a company on different marketplaces everywhere in the world at the same time without human involvement. This can lead to a new quality of saving costs while expanding business activities. The following document describes the requirements for a new approach of an e-marketplace called InterMarket, which integrates the mobile agent technology. A feasibility study, made for two existing software applications, the mobile-agent system Tracy and the e-commerce platform Enfinity, investigates the ability to combine both solutions to form the new agent-based e-marketplace. In conclusion, recommendations are made for not yet fulfilled features to reach the identified requirements. Finally, a general architecture should be the foundation for further refinement and for a possible research project. 3

4 4

5 Contents 1. Introduction Structure of the Document Requirements for Reading this Document InterMarket Foundations E-Marketplaces Definition of E-Marketplaces Transaction Functionality Fulfillment Functionality Integration Capabilities of E-Marketplaces Information Providing Additional Services Consulting Function Overall E-Marketplace Architecture Mobile Agent Technology Definition of Mobile Agents Mobile Agent Environment Migration of Mobile Agents Advantages of Mobile Agents Problems with Mobile Agents InterMarket Objectives Motivation for a New Marketplace Solution Main Objectives of InterMarket Overall Concepts Why using Mobile Agents? InterMarket Requirements Agent-based Functional Requirements Actors The Main Usecase Model The Configure Agent Usecase The Migrate Usecase The Perform Tasks Usecase The Return Results Usecase Non-Functional Requirements Integration of Application Server and Agent Server

6 Contents Portability of the Agent Server Performance Scalability Availability Reliability Security Extensibility and Flexibility Personalization and Internationalization Standard Functional Requirements Introduction of the underlying Applications Enfinity Platform Enfinity in General Enfinity Architecture and Components Enfinity s Pipeline Concept Communication inside Enfinity Storefront Request Workflow in Enfinity Extending Enfinity using the ecapi Connecting to Enfinity using the erxi API Procurement Component in General Procurement Component Technical Architecture Tracy Introduction Infrastructure of a Tracy System The Tracy Agent Model Application Integration via System and Gateway Agents Communication between Agents Agent Migration The Architecture of a Tracy System The Software Architecture of a Tracy Agent Server InterMarket Feasibility Study Agent-based Functionality The Configure Agent Usecase The Migration Usecase The Perform Tasks Usecase The Return Results Usecase Non-functional Behavior Integration of Agent Server and Application Server Portability of the Agent Server Performance Scalability Availability Reliability Security Extensibility and Flexibility Personalization and Internationalization

7 Contents 7. Conclusion and Future Work Conclusion Future Work Bibliography 114 List of Figures 116 A. References for Basic Knowledge 117 7

8 Contents 8

9 1. Introduction The following paper deals with the evaluation of two existing software applications in order to form a new kind of e-marketplace system. This e-marketplace shall provide new advanced automated business processes, support of automated intelligent trading and negotiation techniques, and the mobile access to (multiple) e-marketplace installations. The objectives of the composed solution should be reached through the usage of mobile and stationary software agents, which are electronic representatives of human traders on e-marketplaces. The agents can act autonomously on behalf of their users after a suitable configuration and can fulfill different tasks along the supply chain such as finding proper products or trading partners, bidding in auctions, or negotiating goods directly with other marketplace participants without involvement of human users. Accordingly, the software agents represent companies on e-marketplaces and can initiate, fulfill, and complete trading transactions and place contracts without the presence of humans, which leads to time effort and cost reduction while increasing trading opportunities. Referring to the introduced main objectives, the first point to mention is a mechanism for aggregating different business steps to build automated workflows. For example, it could be possible to combine tasks for finding a suitable offer on several e-marketplaces. This procedure would include all necessary tasks such as visiting several e-marketplaces or comparing the received data and retrieving the best offer. Composing all these steps takes routine work from users and helps, therefore, to save time and costs. This scenario could be even extended with regard to mobile agent technology. By spreading mobile agents over several e-marketplaces for representing their users, they can enter these marketplaces for managing business activities or observing important information sources. This feature offers wider trading opportunities for companies, because they are represented at one time at different locations, being able to react on market changes. The second objective is to support more advanced purchasing techniques by implementing intelligent and automated trading mechanisms, for example for negotiations and auctions. Stationary agents can implement intelligent strategies for performing multi-attribute negotiations, which are not restricted only to the price as the only parameter. Thus, software agents can participate in such advanced price finding processes representing a company and leading to time and cost savings as well as offering more trading opportunities to their users. In addition, software agents can use these advanced techniques in combination with the above-mentioned workflows to increase automation. The last objective is to provide mobile access to e-marketplaces using a consistent medium, which is able to connect to many different portable devices such as PDAs, mobile phones, or other wireless connected mediums. Mobile devices emphasize a key feature of mobile agents: the mobility. After an initial configuration, a mobile agent leaves the device and migrates independently through the Internet. Therefore, the mobile device, mostly restricted by transmission quality and time, must hold no open connection while the agent is working. Thus, the mo- 9

10 1. Introduction bile agent technique introduces a suitable technology for connecting small portable devices to e-marketplaces. For implementing the agent-based functionality in a realistic industrial scenario a professional e-commerce platform is needed as reliable basis, found in the Enfinity Solution from Intershop. This application, extended with a set of add-on components from Intershop, introduces all the standard functionality required for e-commerce activities. In combination with the mobile agent system Tracy, from Friedrich Schiller University Jena, it should be validated in the following document, whether both applications combined are able to provide an e-marketplace offering advanced agent-based features. The new constructed solution is called InterMarket in the further Structure of the Document After the introduction, we start with presenting the foundations of InterMarket by defining the e-marketplace term and giving an overview over the mobile agent technology in Chapter 2. The main concepts and goals of the InterMarket approach will be described in the following Chapter 3 in detail. One part of this chapter is a discussion why mobile agents are chosen for Inter- Market. In Chapter 4, the requirements for the advanced e-marketplace solution are introduced, emphasizing the new agent-based requirements. Because of reusing existing software the two candidates, Tracy and Enfinity, are introduced in Chapter 5. These insights are mainly focused on the functions and features, which affect the InterMarket solution. After forming the basis, the feasibility study is presented in Chapter 6. Detailed information are given for all requirements, which were acquired in Chapter 4, if both applications can fulfill them. The usability is emphasized for every requirement and if necessary, recommendations for further work or adaptations are made. If several opportunities remain for solving an important feature of InterMarket all suitable approaches were discussed in detail. The last chapter finishes the document by giving a final conclusion and explaining future work Requirements for Reading this Document This document contains a multitude of information basing on several fundamentals of software engineering and standard techniques of software development. Therefore, the reader is expected to have basic knowledge about: Object-oriented analysis and design and UML, Component-based software development and software architectures, Java 2 and Java 2 Enterprise Edition (J2EE) including some of its higher features such as Enterprise Java Beans (EJB) or Servlets, Communication protocols such as HTTP, RMI, and CORBA, Fundamentals of XML. For readers not complying with these requirements it is referred at this position to the appendix. There, the reader can obtain references of suitable literature for all listed topics. 10

11 2. InterMarket Foundations Chapter two gives an overview of the basics, which underlie the InterMarket approach and serves in the further as foundation for all following chapters. The chapter starts with an introduction in the topic of e-marketplaces. After a general definition, e-marketplace functions and features are in the focus followed by a short survey of current architectures and technologies used with e-marketplace systems. Of course, this part is not complete at all. Please refer to [66] for more details. The mobile agent technology is introduced within the second part of the chapter. Again, a general definition leads into the topic. The section explains after presenting information about the infrastructure of the agent technology the key feature of mobile agents: the migration. Finally, advantages and problems of the mobile agent technique are discussed to give a complete overview E-Marketplaces Definition of E-Marketplaces The opinions about the definition of e-marketplaces diverge. They range from emphasizing only the Internet-based character of e-marketplaces [59] up to describing more the functionality to show the value-added features of e-marketplaces [58]. Thus, the definition heavily depends on the role a person or company plays in e-commerce: buyer, supplier, seller, or distributor. However, all definitions share the statement in common that e-marketplaces are Web-based applications, which offer abilities for e-commerce online trade between several buying and selling companies. E-marketplaces play a big role in e-business. Following a study from Forrester Research [22] 251 billion US dollar were accounted in sales using e-marketplaces across 13 industries, including construction, aerospace and defense in the USA in Forrester Research and the Gartner Group [26] predict that 37 percent of B2B e-commerce transactions will be done by e-marketplaces in 2004 [44], which are a big part of forecasted 6 trillion US dollar overall B2B revenues in that year. E-marketplaces offer different business models such as multi-vendor catalogs for e-sales or e-procurement as well as several types of auctions or exchange systems for enabling companies dynamic trading opportunities. In addition, e-marketplaces can provide even more value-added functions such as payment, transaction completion, and fulfillment services as well as content management or integration capabilities for existing legacy systems of the companies. E-marketplaces offer their participants the ability to meet new trading partners, to automate their procurement or sales strategies, and to use more advanced and automated techniques for finding best offers and prices to lower costs and cycle times. The offered services vary between different e-marketplaces depending on the type of industry they try to cover [66, p.10], [21]. 11

12 2. InterMarket Foundations As indicated above, e-marketplaces are more than simple e-commerce sites for selling or buying products or services. E-marketplaces provide functionality along the supply chain, which offer multiple services for each stage. Figure 2.1 maps e-marketplace functionality and services to supply chain stages. The functionality presented in the figure will be described with the following subsections. Figure 2.1.: E-marketplaces enable services along the supply chain [66, p.19] Transaction Functionality The transaction functionality envelops the core mechanisms of e-marketplaces. It enables companies to meet, to exchange information, and to trade products and services. Foregrounding, this functionality contains services for matching suppliers and buyers and mostly provides a catalog and order management. The matching describes the opportunity to group marketplace participants according to industry types and offers search and browse mechanisms to them for finding trading partners on the e-marketplaces. The catalog and order management cover functionality to maintain multi-vendor catalogs in a hierarchical structure and manage incoming orders. Orders will be persistently stored, split regarding to different involved suppliers, and automatically distributed to these suppliers. For both, buy and sell side, the order status can be tracked for informing about their current transactions. In addition, most e-marketplaces implement dynamic pricing and negotiation models such as auctions or exchange systems for offering their participants various mechanisms for finding best offers and prices. E-marketplaces must implement suitable transaction models according to the goods, which are traded on them. Currently there exist mainly four different transaction models: multi-vendor catalog, pinboard, exchange system, and auction. When to use which type of model regarding to the kind of goods and the regularity of purchases is depicted in Figure 2.2. Goods are distinguished between production goods and MRO goods. Production inputs are more complex goods having passed through a preprocessing and will receive further processing in the buying company. Sheet metal components for the car industry are a possible example. MRO stands for maintenance, repair and operations and includes products such as energy, cooling medium, lubricant, or pens and paper, which are important to keep on going the production. Purchasing regularity is distinguished between regular and irregular traded goods. For example it makes no sense to offer irregular purchased products in a catalog system, because the price is mostly vari- 12

13 2.1. E-Marketplaces able and is new negotiated for every single transaction. In this case it seems to be more useful to support an auction or exchange system. The particular models of the transaction functionality are described in the follow. Figure 2.2.: Proper use of transaction models [66, p.23]. Multi-vendor Catalog is a data structure containing aggregated product catalogs of different suppliers centralized. The catalog structure is a kind of hierarchy divided by suppliers and categories. Suppliers have the ability for uploading, importing and manipulating supplier catalog data using standard classification schemes such as ecl@ss [18] or UN/SPSC [19] and standard catalog exchange formats such as BizTalk [54] or ebxml [47]. Buyers can browse the catalog maybe regarding to a specific view and can choose required product items for getting information or putting them into a shopping cart. E-marketplaces offer shopping carts, which are containers for chosen products within a single user session. The contents of the shopping carts can be ordered. Most of the marketplaces offer an additional mechanism, sometimes called shopping history or shopping lists, for reusing shopping cart contents within multiple sessions. Of course, if orders contain product items of different vendors, order splitting and routing is supported for spreading orders to all involved suppliers, including only the items they provide. Both trading partners, buyers and suppliers, can observe the status of orders in all marketplace solutions. Multi-vendor catalogs additionally support options for discount specifications for special buyers or products, for buying communities (a group of smaller companies that want to advance from amount discounts) or even for specific quantities. Pinboard is a platform for advertisings and petitions mostly realized as a directory with a simple search and find mechanism for requested order or offer entries, such as requests for quotes (RFQ) and requests for proposal (RFP). An entry in the directory is not only a link to a Web site of a company, but provides information about products or services and maybe additional descriptions. A pinboard is used for products with badly indexable data and owns no clear definition of the actor s roles: everybody can be supplier and buyer at the same time. E-marketplaces enable 13

14 2. InterMarket Foundations their businesses to meet and also can add completion and fulfillment services for a transaction initialized at the pinboard. However, the trading transaction is independently processed by the trading partners. If a trader accepts an offer, the trading partner is informed via or SMS. Then both traders complete the transaction without involving the e-marketplace. The pinboard model enables two special forms of advertising mediation: RFQ RFP Request for quotes is used by buyers to trade goods according to the buyers conditions. The request is placed at a directory service, such as pinboard or can even be sent to a supplier directly. Every registered supplier can read the entry on the directory and can make a specific offer. The buyer chooses the most attractive offer and initiates a transaction with the supplier following the arranged terms. Request for proposal is a special offer of a supplier to trade goods with the suggested conditions. The offer is published using a directory service such as pinboard or is sent directly to a buyer. If a buyer accepts trading conditions a trading transaction can be initialized. Exchange System is an extension of the pinboard transaction model. It also provides services to bring businesses together, but additionally offers services for transaction completion and price negotiations. The exchange system delegates the best offers to a seller. Double auctions are an example of an exchange system. Although the name is something confusing, double auctions realize price finding similar to trading stocks at a stock exchange through opposing supply and demand. Auction is similar to the exchange system, but less flexible. The characteristics of the product to be auctioned have to be clearly describable and the price must be the only trading criteria. Most auctions are non-durable and live only for a certain time period. Several auction models exist and can be mixed up. The e-marketplace providers manage the proper auction type regarding to the kind of the market and the behavior of the participants. There mainly exist the following auction types: English Auction Dutch Auction Public Auction Private Auction This auction starts with a low price set by the supplier for the product to be auctioned. The price increases with every bidding by a certain value unless no buyer places a bid. Finally the highest voting wins. Here the auction starts at a high price. The price lowers in time intervals during the auction by a certain amount. The buyer who accepts first the actual price wins the auction. is also called open auction. All participants in a public auction know the identities and bidding amounts of all other auction participant. is also called closed auction. An auction participant doesn t know anything about the other participants of the auction. 14

15 2.1. E-Marketplaces Selling Auction Reverse Auction A supplier offers a product or service and different buyers bid to buy the good. A buyer specifies the product/service he wants to buy. Different suppliers can then place their offers to bid. Normally, the offer with the lowest price wins Fulfillment Functionality The fulfillment functionality offers support for the value chain stages completion and long-term supplier relations. The supported services ease the transaction processing by offering add-ons for initiation, fulfillment and completion of trading transactions. E-marketplaces offer tools for checking credit-worthiness of potential contract partners for an initiation phase of a transaction. In addition, e-marketplaces can provide techniques for checking product quality, for example by supporting a voting mechanisms for buyers to determine the qualities of specific offers and suppliers. By integrating shipping and logistic services with e-marketplaces it is possible to execute orders immediately. Thus, a supplier is assigned with the delivery of the order. Of course, e-marketplaces offer the ability for integrating with companies ERP systems (see Section 2.1.4) for the fulfillment phase for supporting automated transaction workflow. In addition, e-marketplaces can offer even additional features such as insurance services for insuring order items and deliveries or a trustee functionality for guaranteeing complete delivery in time and payment guaranty. E-marketplaces can provide a payment service for automating and simplifying currency transfer and clearing services, which help to check order and delivery correctness as well as invoicing for the final stage of a business transaction, the completion. Berlecon predicts, that e-marketplace solutions must implement these value-added services to increase companies acceptance and to acquire new participants and bind them for longer time. In addition, taking these tasks from the businesses lowers costs and cycle times and leads to transparent and easy transaction processes, businesses would prefer most.[66, Ch , pp. 45] Integration Capabilities of E-Marketplaces The integration functionality supports the same supply chain stages like the fulfillment functionality, because a main task for the integration functionality is to enable e-marketplace solutions for offering advanced fulfillment services. Providing a large variety of interfaces for integration with nearly any external software solution would give marketplaces the opportunity for flexible adaptation and extension of themselves regarding to the market needs. Therefore, such kind of e-marketplaces can offer their participants many useful fulfillment and other services. The integration with companies ERP/CRM applications and other standard inventory software is the most important integration type, because this opens the ability for high automation of business processes and a high integration of e-marketplaces into the supply chains of their participants. E-marketplaces are able to offer additional value-added functionality such as for payment, logistics, and insurance through the integration of third-party software systems. Thus, it is possible to create high value-added for the participants. On the other side integration describes also the opportunity for connecting to several other systems such as DBMSs or directory servers, which is important for the overall functionality of marketplace systems. 15

16 2. InterMarket Foundations Finally, Berlecon points out that the most cost saving factor of e-marketplaces is to automatically adapt different data formats [66, box on p.35]. Thus, e-marketplaces should be able to integrate other solutions using standard data formats. In addition, Berlecon emphasizes the importance of supporting lots of interfaces for the integration of additional features and services to acquire participants and hold them for high frequently long term trading relations [66, pp. 33] Information Providing Information providing is better known as content management and also a very important feature. Berlecon finds out that offering additional information, for example to find trading partners and products (e.g. implemented with yellow pages or a business directory) as well as market news and industry-related articles (e.g. offered with newsletters and white papers), is a good approach for acquiring participants and create opportunities for them to increase their value-added through e-marketplaces [66, Ch. 3.5, pp. 35]. The information offer could be even improved by installing a discussion forum on the marketplace for helping businesses by solving problems through offering easy access to information or knowledge from other marketplace participants. Thus, participants can interact and exchange knowledge directly with their trading partners. Of course, the information spread with e-marketplaces can include graphics and multimedia contents Additional Services Additional services are supported for all stages along the supply chain. They should support e-marketplace participants by using the new media and as second they should enable users to observe their business activities within e-markets. Market reports are the most important feature. The participants should be given the capability to create transaction-based market reports of their business activities for analyzing sales and turnovers as well as product or order-related information. E-marketplaces should provide tools for creating and outputting graphical reports on business metrics even via multiple data formats to give the users a wide range of information opportunities. Another possible way for giving support is to offer a customer hotline or user support for fast and uncomplicated help or by supporting a messaging system for simplifying contacting with other marketplace participants or for exchanging information with them. A further important service is to offer multiple currencies and languages if the e-marketplaces are focused on global trade. Additional services can also stand for application server providing (ASP) or sale-site hosting for an easing market entry of potential participants. Renting these resources is much cheaper for the businesses than buying, if they want to test e-marketplace capabilities for their company Consulting Function This functionality marks a new trend in e-commerce, which is also known as collaborative commerce (c-commerce). It adds concrete support for business processes to help e-marketplace participants to optimize their business processes by offering services for planning, transacting and improving processes. C-commerce provides virtual offices for temporary collaborations of several businesses. The cooperation partners can on the one side easily synchronize their data 16

17 2.1. E-Marketplaces and product exchange or even their corporate business workflow. On the other side they can hold meetings via the Internet (e-meetings). E-marketplace solutions providing these features, which increase value for their participants [66, ch , pp.37]. In fact, there is a trend of e-marketplaces specializing only on this area of e-commerce by providing mainly c-commerce features for their users Overall E-Marketplace Architecture E-marketplaces are built as Internet-based Client/Server software systems offering access for a large number of users maybe spread over the whole world. Berlecon finds out that in 2001 the top German e-marketplace installations had over participants [66, p.11]. And that is not the highest number, when thinking of the increasing overall e-commerce. Thus, it is necessary to provide mechanisms that satisfy such a large number of users by ensuring accurate and fast access to the e-marketplace s functionality. Figure 2.3.: Standard e-commerce three-tier architecture. To suffice these circumstances, e-marketplaces are implemented, like most of all e-commerce solutions, using a three-tired architecture consisting of a client tier, a middle tier and a back-end tier (presented by Figure 2.3). Of course, e-marketplace architectures are designed for supporting a wide number of requirements such as availability, reliability, security, and load balancing. A three-tier architecture separates presentation logic, business logic, and the database layer and forms the foundation for developing large scalable applications with good maintainability and extensibility [77]. Thus, e-marketplaces can be extended to extreme large systems installed on multiple machines, following the separation of the logical layers. E-marketplace solutions support several standards such as J2EE, XML, or CORBA and implement a distributed component model such as EJB for offering even more support for the denoted requirements. Finally, an e-marketplace should be developed using standard techniques on the one side, such as HTTP, XML, and CORBA for the communication across different subsystems and on the other side for system architecture to ensure a platform-independent, language-independent, and application-independent solution, for example using Java J2EE. 17

18 2. InterMarket Foundations The Client Tier covers the parts of the application as well as the communication protocols used by client users for interacting with the e-marketplace functionality. The client access is very diverse for e- marketplaces regarding to the hardware, software, and network capabilities of the users. E- marketplace solutions use thin clients based on Web browsers, because of the restrictions of knowledge about users of e-markets and the facts that most participants own PC/ workstation computers and e-marketplaces are Internet-based. This brings advantages introducing easy and fast access to the market, independence for the users from maintainability works of the business logic, and consistent processing. Thin clients do not own business logic, because they are only responsible for presentation. The relations to the Internet also induce the usage of communication protocols. Using browsers, it is implicit to use HTTP or HTTP/S over TCP/IP for connecting to e-marketplace systems. Additionally, XML can be employed on top of the HTTP. Using this simple communication strategy implies that the more sophisticated logic resides on the server side. Some more advanced techniques such as applets or ActiveX controls are used for thin clients (for example when implementing a real-time auction mechanism) only in a few cases. However, there exists another kind of user, which introduce more control over their capabilities. The marketplace s administrative users such as the marketplace organizers connect to the marketplaces mostly over an Intranet, which offers more network speed and bandwidth. They use thick clients, which implement a connection using for example Java RMI, CORBA/ IIOP, or DCOM to access marketplace s administrative and control functionality directly on the server. Therefore, the server offers a naming service (e.g. JNDI) or an Object Request Broker (ORB) in combination with a distributed object model such as EJB or DCOM. Fat clients adopt some business logic. Despite of the mentioned disadvantages such as lower performance or problems after maintaining works the use of thick clients for administrative tasks is, nevertheless, possible, because these clients do not work in a large number concurrently in the system. The Middle Tier supports several important components, which the Web server should be the first component to be mentioned. It connects with the clients using HTTP for sending HTML pages covering text, graphics, and multimedia contents or maybe also applets. Client requests cause the Web server to send static pages. A Web server is used with special techniques, such as page caching or storing multimedia data on extra directory servers, for enabling fast access to optimize the response times to the clients. The Servlet Engine is the second component to be mentioned. A client request can initiate the generation of dynamic HTML pages using special techniques such as ASP or JSP/Servlet, and the invocation of distributed objects (e.g. EJBs) from the application server. With other words the Servlet Engine allows for dynamic interaction with the user. However, the application server is the most important part of the middle tier, because it is responsible for processing the business logic of a marketplace solution. The application server is defined in [52] as a component-based server-centric product that allows organizations to build, deploy, and manage new applications for Internet users. It is a middle tier solution that augments the traditional Web server. The application server provides middleware services for applications such as security and the maintenance of state and persistence for transactions, which leads to accessing and managing data in a consistent way. The application server offers a framework for e-business combining the former isolated stages building, deploying, and managing in one 18

19 2.1. E-Marketplaces solution [52, 79]. Therefore, it offers visual deployment tools for the building step, a distributed component model for the deployment step, and administration and management tools for the management of the system [52, pp. 130]. The application server offers through the distributed component model possibilities to integrate with other systems (e.g. RDBMS, ERP software) via defined data exchange and connection standards on the one side and on the other side allows for business process integration. This means that it is possible to combine different business steps into a workflow. Therefore, the application server mostly implements an additional logical layer above the distributed business objects and even additional graphical tools for giving marketplace providers capabilities for flexibly defining more sophisticated business workflow. For a discussion of possible models for implementing business process integration see [79, ch.2 and 6] or [65, ch.7]. Application servers are build for three-tiered applications providing more performance, scalability, availability, security, and extensibility introducing re-usability and easy distribution over several servers through the insert of distributed component models such as EJB or MS DCOM, and CORBA ORB. Figure 2.4 shows the architecture of a J2EE-based application server. For more information on application servers, please see [52] and the references of leading application server systems: [4, 30, 31, 62, 67]. Figure 2.4.: Architecture of a J2EE standard application server [52, p.145]. Finally, as the last component of the middle tier, the Administration and Control Servers provide services for the management of application server business logic, the distributed components, and the e-commerce site contents on the one side and on the other side offer services for managing the application server cluster. In practice, the mentioned components of the middle tier never stand alone, but they are combined to logical units providing even more scalability by being placed in server clusters [52, p. 141]. Because of this additional partition of the middle tier through these two or three groups of servers it is often spoken from the n-tier architecture when meaning three tier architecture. For example Web server and Servlet Engine are composed for serving many of the routine requests, for example for the home page and static pages and are responsible for load balancing [52, pp. 19

20 2. InterMarket Foundations 189] and availability. The second server group covers the application server and Administration and Control Server functionality. Most application servers own administrative capabilities. Application server receive dynamic request from the Web server, for example, for placing items in the shopping cart or for placing orders or filling product information in catalog pages. Most application servers implement Web server functionality to receive requests from the Web server. The Back-end Tier covers relational database management systems (RDBMS), inventory and ERP/ CRM applications as well as other systems that can be accessed from the middle tier using several techniques such as HTTP, RMI, CORBA/ IIOP, or DCOM. The main task of this tier is to provide information and data persistence for the Middle tier business logic. It is possible to use XML for data exchange on top of the named protocols. E-marketplaces mainly implement a database with this tier for storing data of catalogs, users, orders, transactions, sessions, and etc Mobile Agent Technology Definition of Mobile Agents The agent term was already introduced into the computer science in the late 1970s within the artificial intelligence (AI) research (see Nwanda [60]). Agent stands for autonomous intelligent behavior including the ability for communication, which is subsumed in a general introduction of the agent term in the AI research by Wooldridge and Jennings [76]. Accordingly, an agent is thought of as a software entity or component in the modern software engineering owning the following properties, described in a general overview by Bradshaw [7] and Nwanda [60]: autonomy, an agent can act following self-constructed plans ability for communication, an agent can interact with other agents reactivity, an agent can react on environment changes pro-activity, regarding to the previous feature, an agent can react on specific events by performing special standard or optional processes depending on the event adaptation, an agent can be configured to match special user experiences or to solve problems in a specific way intelligence, an agent own on the one side decision-making abilities and on the other side learning algorithms for learning about its user s behavior Since the early 1990s software agents are brought into context with the development of distributed systems. Related to this, not only the above-mentioned properties playing a role, but additionally a special feature called mobility. Mobility describes the ability of a mobile agent to move through a heterogeneous electronic network and deciding autonomously when and where to go [60], [10, p. 8]. This proceeding is presented with the following Figure 2.5. In the figure, a mobile agent migrates for example from a platform A to another platform B to access services of applications or to retrieve data from a database, which are only offered at the target platform of its migration. However, the graphic should emphasize another feature of the mobile agent 20

21 2.2. Mobile Agent Technology approach. These agents can only live in a special software environment (see Section 2.2.2). The environment offers two important communication capabilities. External applications are able to interact with mobile agents via the local mobile agent environment and vice versa. Today, mobile agents are mostly realized with an object of an object-oriented programming language. An example for an object-oriented approach is given in Chapter five with the introduction of the mobile agent system Tracy. Braun [10, p. 8] concludes, that many authors see mobile agents as a new paradigm for the development of large distributed systems [56, 71] or for the communication within [5], because mobile agents introduce a completely new approach by sending the code to the data and not vice versa. Finally, some special features of mobile agents should be mentioned differentiating the agent approach from other distributed techniques such as RPC, RMI, and CORBA, as listed by Braun [10, p. 9]: Mobile agents work in large and heterogeneous networks, where no assumptions about reliability and security of the involved platforms can be made. The migration is controlled by the programmer, which means that the program itself and not the operating system decides when and where to go. The execution of the program is not location-transparent, but the program moves to a specific server for using services, which are only provided at this platform. Please refer to Cockayne [14] for more information about the mobile agent topic or for getting an idea of the capabilities, which arise with mobile agents for business applications. Figure 2.5.: Mobile agents migrate through heterogeneous networks Mobile Agent Environment Mobile agents need a special software system as a living environment on each platform, which should participate in a mobile agent network. Thus, every platform in the network covers a network-connected host with a special application for receiving, sending, starting, and executing agents [10]. This application, often called agent server (e.g. Tracy [9]) or agency (e.g. Grasshopper [32]), provides as a type of container services and management functionality for 21

22 2. InterMarket Foundations mobile agents as well as defining a place on a host where mobile agents can be secured executed. Figure 2.6 shows the most important services of an agent environment such as security (for data and code of mobile agents as well as for the system services for protection against misuse and destruction by mobile agents), communication (for enabling agent interaction), management (for controlling agents, their resources and communication), migration (see Section 2.2.3), persistence (for persistently storing agents and their data) and directory services (for storing specific content). Figure 2.6 also depicts the ability of other applications for enabling access to mobile agents for configuring and starting agents and for exchanging data with them. Figure 2.6.: Mobile agent environment Migration of Mobile Agents Migration describes the process of a mobile agent moving from one host to another. Although migration is only one out of many features of mobile agents, lets focus on it, because it is most significant. Mobile agent systems mostly use for the network transmission the TCP/ IP protocol. A mobile agent only has to inform the agent environment about the IP address of its target host and the name of the agent environment there before the transmission will be started [10]. Right for the question how the agent will be transferred there exist two approaches. First, the strong migration should be introduced with its representative mobile agent systems such as Telescript from General Magic [73] and NOMAD [68]. After the agent has signalized its wish for migration with a special go -command the agent environment freezes the agent execution and starts packing agent s code, data, and current state (enveloping the contents of the local variables of the current method as well as the Call Stack, Operand Stack, and the Instruction Pointer) for migration. After the transmission, the agent will be restarted on the platform with the transferred code, data, and state. The agent execution starts then with the first command after the go instruction. Although this approach is very comfortable for the programmer, because migration is almost transparent, strong migration is hard to implement. Please see Braun [10, pp. 17] for details. The weak migration is the second opportunity for transferring mobile agents. Here, the programmer is responsible for the migration, meaning the storing of agent state in data structures, because the weak migration only covers the transport of code and data. This migration type 22

23 2.2. Mobile Agent Technology induces no restart of the mobile agent after transmission with the first statement following the go -command. Moreover, the programmer has to indicate a method before the migration, which the mobile agent executes instead on the new host. In fact, weak migration is easier to implement. However, this advantage is paid off with more programming effort and the need for higher programmer skills at all. Finally, some example agent systems implementing weak migration shall be named: Aglets [50], Grasshopper [32], or Tracy [9]. However, there exist even more techniques and optimization strategies for the migration process, being not subject here. For more information about this topic, see [10, 11, 20] Advantages of Mobile Agents To understand the decision for using mobile agents with InterMarket it is necessary to know the advantages of the mobile agent technique. The following list, collected by Braun [10, pp. 10], is not completely replicated. However, it should form the idea where mobile agents can help improve current architectures. Asynchronous Computations could be outsourced to other powerful systems if the local resources are completely overused. The agent could visit a host, which is able to process the given tasks and the agent could even pay for the service. Thus, during execution no network connection is required, it is very applicable for mobile devices with less computing power and memory. Reaction on remote events in real time A mobile agent can react as representative for a human on events on a remote system, which saves the costs for the network latency in contrast to contacting a centric decision-making instance. Robustness and failure tolerance A mobile agent is able to move to another system if the current host fails even in case of a routine shut down for maintaining works. State sensitive communication A mobile agent carries its own state and so even the intermediate data within a communication process. Thus, agents reduce network traffic in contrast to RPC. Scalability Mobile agents reduce long network transactions for example in case of performing many calculation steps or processing a large data amount to a minimum because they transform remote processing in local execution. Semantic Routing Detailed knowledge is not required about server names, offered services and their parameters in contrast to Client/Server. Agents are able to autonomously find information about servers and services by exchanging key words with servers. 23

24 2. InterMarket Foundations Personalized services Agents enable user-specific task processing. Security Sensitive data can be encrypted and safely carried inside agents through the Internet using their own keys. Mobile computing Mobile users can take advantage using agents in three points [29, p. 7]. A mobile user can save network connection time, because of the short connection period, required for sending and receiving single agents. The agent fulfills the tasks while the user is offline and a user has to be connected again after starting a mobile agent only for a short period to receive the results. Most mobile devices own slow network connections. Therefore mobile agents can help to increase efficiency through an agent-mediated pre-selection, reducing the amount of transferred data. Mobile users have smaller computing power and memory capacities. The shifting of computations to servers via mobile agents can help to save resources on mobile devices. Only the results are sent back to the users devices Problems with Mobile Agents This subsection summarizes in an overview some main problems with mobile agents. It is not a complete nomination, but important points in the areas security, management, and interoperability are mentioned. Security is today s most important feature to increase mobile agent acceptance in the IT world. However, this topic introduces some problems that are not solved with a consistent and universal solution. Nevertheless, it is possible to implement many security features by making some presumptions. But this should not be discussed in detail now. For further information please refer to Vigna [70]. Some of the main problems regarding to security should be mentioned below to give a short insight. The agent server is normally protected through a sandbox, which limits the capabilities for mobile agents to access functions, which they are not allowed to do. However, some problems remain. How could be ensured, that mobile agents do not attack the agent server? They can try to pretend bad identities or maybe try to overload the server, to crash it. This pretending problem can be solved maybe using some kind of encryption features with private and public shared keys similar to normal Client/Server approaches. However, an agent server cannot decide whether a mobile agent performs only its tasks or it tries to crash the agent server through performing useless tasks [12] only for lowering server performance. The security problem is also active in the vice versa direction. How could be a mobile agent saved from malicious agent servers? Because the agent executes in a container of the agent server, it could be possible for the server to get access to private data and maybe algorithms of the agents. The agent server can try to change the execution of a mobile agent, can read or change the private data, or can even prevent the agent from execution. Additionally, it is possible that malicious agent servers try to infiltrate unauthorized mobile agents to other agent servers. 24

25 2.2. Mobile Agent Technology Therefore, it is very important to save the mobile agent from interception by malicious agent servers and so prevent it from bad access to its private data. Finally, it can happen that agents could attack other agents. Bad agents can try to access private data or even to change it. On the other side it could be possible, that agents try to prevent other agents from execution or they crash the agent by sending thousands of bad messages to the victim agent. Management Problems arise, when a mobile agent system is used to form a dynamic local or global network. Questions form, such as how could be managed dynamically changing networks? A possible agent-based approach is introduced with [8]. Other problems such as tracking mobile agents in the network, determining if an agent is crashed, or if it needs only many time for a task [2, 64], or determining if an agent has completed its tasks [1] are less easy problems, which lead to a high management effort. This can be extended by the problems of finding orphans, which are mobile agents without human users anymore. Interoperability is the last big problem area. Here you may find problems such as how communicate mobile agents in a multi-agent approach [3] regarding to the possibility of agents descending from different agent systems. How looks a general approach for forming cooperation between different agent systems? Today it does not exist a generally accepted standard for exchanging agents between different agent systems. Standards such as MASIF [57] and FIPA [24] do not really hit. 25

26 2. InterMarket Foundations 26

27 3. InterMarket Objectives This chapter presents the main objectives of InterMarket. The chapter starts with a short motivation, which justifies the InterMarket approach. The following parts introduce the main objectives by describing the advanced features of the agent-based marketplace solution. After giving some thoughts on the overall concept of InterMarket, a final discussion should clarify the question, why mobile agents should be used with the InterMarket approach Motivation for a New Marketplace Solution E-marketplaces define a sector of overall B2B e-commerce realizing high rates of growth. Thus, the Gartner Group [26] estimates, that the worldwide B2B e-commerce transaction volume will surpass 1,9 trillion US Dollar in 2002 and will reach about 6 trillion US Dollar in Together with Forrester Research [22] the Gartner Group forecasts, that thereof a fraction of 37 percent will fall to B2B marketplaces in the same year. These numbers point out the dynamic and rapid growth of the e-marketplace segment. However, the B2B market is not a straightforward automatism. A hard competition for market shares has already raised in 2001, forcing e-marketplace providers to improve their offers according to market changes and competition [16, 17]. According to a study from Berlecon Research [66] from the year 2001, today s German e- marketplaces try to offer more than only transaction functionality, but additionally fulfillment and other additional services. At the moment they do not cover the whole value chain for their participants. Berlecon subsumed, that e-marketplaces have to offer through integration and business process support value-added services along the supply chain to reach three main goals [66, pp. 45]: 1. Acquiring new participants 2. Bind participants for long term transaction relations 3. Introduce new taxing models for gaining profits This statement is intensified and verified by a study of Deloitte Research [17]. Founding on these problems, InterMarket should introduce new features, which base on the mobile agent technology and will be presented in the following subsection Main Objectives of InterMarket Business Processes Integration In a poll with buying departments of German companies, the research center Explido [21] posed 27

28 3. InterMarket Objectives the question, for what the employees use the Internet. The most mentioned points were searching for suppliers (98 percent), searching for detailed information (87 percent) and placing requests for quotations (60 percent). Only 44 percent of the interviewees indicated to use e-marketplaces for their daily work [75, Ch. 1]. These facts tell mainly two things. On the one side employees perform many jobs by hand and on the other side e-marketplaces do not seem to offer a wide variety of sufficient services, from which users can take a real advantage. Thus, it remains a great potential for automation of daily work of the denoted employees, which can lead to time and costs savings. That s why InterMarket should offer capabilities to relieve employees by assigning routine work to software agents. Software agents can be configured for a single task or even for a whole workflow of tasks according to their users needs. Thereby, the sequence of tasks should be exactly configurable by human users or should be even completely left to the agents. These agents cannot only cover tasks of the first steps of the value chain such as searching for and comparing of trading partners and their offers or performing product ordering, but also tasks of further steps, for example bidding in auctions, negotiating, or also payment or logistic functions. The insert of the agent technology can lead to an improvement of the value chain processing, which is demanded by 75 percent of all B2B market participants worldwide [17]. Figure 3.1.: Agent-based automated business workflows including intelligent negotiation techniques. Lets think about a little example, which is illustrated with Figure 3.1. Imagine, a department manager of a company wants to order new hardware equipment for his employees. He authorizes a software agent with the search and pre-selection of suitable products on an Inter- Market marketplace. Thereby, he specifies all parameters, which characterize the demands on the products, such as processor speed, guarantee and maintenance constraints, or the total price. After configuration, the agent interacts with other agents and also accesses the database on the e-marketplace for retrieving offers. Thereby, the agent performs many different tasks following an autonomously created workflow. The executed tasks range from more simple tasks such as catalog search and comparison up to advanced activities such as search for special offers on a pinboard or negotiating directly with other marketplace participants. The agent informs the manager automatically after finishing its work. In addition, the agent can collect not only offers, 28

29 3.2. Main Objectives of InterMarket but also detailed information about products and techniques to increase the manager s knowledge base. Finally, the manager only has to explore the agent s results and has to make an order decision in this scenario. If the manager decides on a trade he induces the agent to start another workflow on the e- marketplace for initiating and fulfilling orders. The agent observes order status during the whole transaction and reports to the manager, for example by sending order confirmations or messages with track information. However, the agent can perform even additional tasks such as informing a logistic provider for delivering the goods, or interacting with a payment service to manage the currency transfer on behalf of the manager. Finally, the manager only receives the delivery of the ordered hardware. Please see [46, 80] for information on business process and workflow management with software agents and see [27, 45, 72] for an overall introduction of workflow management. Providing Intelligent Trading and Negotiation Techniques Agents, that automatize value chain stages, must be able to simulate human behavior in some particular situations of several business processes. For example, agents can take part in auctions and negotiations on the InterMarket marketplace. Therefore, agents have to implement special advanced functions, which realize artificial intelligence for the software agents. The indicated functions need a set of parameters to adapt to a specific user behavior. Because agents act on behalf of their users, they receive rules and conditions during the configuration by their human users before starting activities. How mentioned in the example above, the manager can authorize an agent on the e-marketplace to perform even more advanced tasks, such as negotiating with other marketplace participants, or bidding in auctions. For example, it could be possible, that the agent has not found a suitable offer in the marketplace catalogs and on the pinboard. Thus, the agent can try to directly negotiate offers with several marketplace suppliers according to the product features, which it was configured by the manager. On the other side it could be possible, that the agent detects an auction, which offers the proper products. So the agent starts bidding until the auction does no longer hit the demands of the manager wishes. The intelligent techniques of software agents are illustrated in the workflow cycle at the right top of Figure 3.1. A main objective of InterMarket should be not only providing prize negotiation strategies for agents, but also more advanced negotiation models such as multi-attribute negotiations, which depend not only on the price. This leads to an additional improvement of some business processes along the value chain. And in fact, nearly two-thirds of participants from a current poll made by Deloitte Research see the most important improvements for realizing value-added features on e-marketplaces through modification of business processes [17, box, p. 15]. Please refer to [49, 51, 55, 81] for an overview over current research and state of the art applications on the area of intelligent agent-mediated e-commerce. Interconnection of multiple E-Marketplaces Deloitte Research predicts, that e-marketplaces will form strategic alliances, because they are forced through the business crisis in 2001 and the increasing competition [17, pp. 5, p. 14]. Deloitte Research describes the input of middleware or translation hubs [17, box, p. 9], which build the foundation for linking multiple marketplaces that form new networks and other models [17, box, p. 9]. These incidents will increas value for both, marketplace operators and participants. InterMarket should offer an independent approach for connecting different e-marketplaces 29

30 3. InterMarket Objectives through mobile agent technology, which is a possible form of a middleware. InterMarket-based marketplaces facilitate agent servers to where mobile agents can migrate to through the Internet. Thus, mobile agents can use functionality of several different electronic marketplace solutions. However, mobile agents do not get direct access to the marketplace functionality, they have to contact stationary agents for security and scalability reasons. A consistent approach is defined through this multi-agent technique, offering in addition management services to locate agentbased e-marketplaces in the World Wide Web. Regarding to Figure 3.2, the manager is not further limited to use only one e-marketplace or to visit several e-marketplaces by hand. Mobile agents are able to migrate and connect to different e-marketplaces, which using agent technology. Thus, the manager can extend his capabilities to reach selling companies, to transparently search, request, and order products such as the workstation equipment from the former example, across the world. The agent technique can even adapt and handle problems evolving in world wide trading actions across borders such as for example languages, continents, and currencies by providing for example multi-language or multi-currency support as well as automated tax calculation, for instance. Figure 3.2.: Mobile agents provide marketplace access and interconnection via mobile devices. Connecting mobile devices InterMarket offers the capability of directly connecting even new devices such as PDA, mobile phones, or other wireless-connected or portable devices to an e-marketplace. The mobile agent technology enables management of mobile and distributed networks. This approach fits very well to today s increasing dynamic and heterogeneous IT landscape. The portability of the mobile agent technology forms the foundation for the InterMarket approach. Advantages of mobile agent technique can be the lower network traffic, the smaller demands on network quality and bandwidth (because mobile agents do need only for a short period of time, the migration, an open network connection) compared with other middleware approaches. Please see a benchmark for the mobile agent system Tracy, which underlines the latter statement [10, 11]. Following the former example, imagine the manager is on a workshop and he learns there something about the latest hardware equipment. He is so enthusiastic that he wants to update his department. Thus, the manager just uses his laptop or PDA and starts an ordering process with a 30

31 3.3. Overall Concepts mobile agent from this mobile devices from somewhere in the world, how depicted in Figure 3.2. Mobile agents can run from mobile devices owning an agent server by using a transient network connection Overall Concepts The main difference between InterMarket and current e-marketplace solutions is that InterMarket offers access not only for humans, but additionally for mobile software agents. Furthermore, the agent-based processing of tasks on the marketplace marks a new approach. InterMarket realizes not only classic human-to-human, but also human-to-agent trading capabilities. The trading transactions are absolutely transparent to the users or agents. Figure 3.3.: Agent-based features of an InterMarket e-marketplace. Following this approach, InterMarket offers a wide range of users access (see in the left of Figure 3.3). First of all for standard users using a web Browser on a PC/workstation. Through the insert of mobile agents are additionally mobile users able to enter the marketplace from their mobile devices. Therefore, InterMarket offers a portable agent server, which is the foundation for mobile access. Of course, it is possible even to use mobile agents from stationary hosts, only by installing a proper agent server. Finally remains to mention that even machines can use agent functionality of the InterMarket marketplace for machine-to-machine commerce, indeed over a standard HTTP connection. User can choose the best way for them using an e-marketplace. 31

32 3. InterMarket Objectives On the marketplace itself, there will be offered beside conventional e-marketplace functionality agent-based services from three categories, which can be used by mobile agents as well as by standard users (via HTTP) (see Figure 3.3). InterMarket implements catalog-based trading capabilities for agents. Thus, agents are able to query marketplace s catalogs for searching, comparing, and also placing product orders in the marketplace s database. Second, InterMarket supports auctions or double auctions. Agents can participate in auctions and can bid to win them. Agents, therefore, own intelligent behavior simulating human activities in auctions and optimizing strategies for winning. In this auctions human users participate in parallel, concurring with the agents for the win. Last, InterMarket offers request and negotiation functionality for dynamically determining prices with trading partners. Agents and human participate in parallel, able to negotiate with each other. Again, agents implement intelligent algorithms for performing optimized transactions here. Humans can authorize agents for performing the three indicated functionalities on behalf of them, according specified configurations and rules of the users. In the first step InterMarket supports only price negotiations (can be reused from existing software) and only human-to-agent negotiations. In a second step it should offer multi-attribute negotiations for more flexible and user-adapted negotiations by using more parameters to negotiate. Fully automated agent-to-agent negotiations and trading should be done with the second step of InterMarket. With InterMarket, there exist two different types of agents for different tasks on the market. Mobile agents can be configured and started by clients, which enter the marketplace via the Internet (compare with Figure 3.3). Mobile agents are responsible for the communication between clients and the e-marketplace. They carry the configuration data to even more than one marketplace. Nevertheless, mobile agents own also a kind of intelligence, such as for route planning and reacting on special events (e.g. e-marketplace are not available, no actions could be done on the current market). They access e-marketplaces on behalf of their users and therefore use their users identity. The other agent types are the stationary agents. They can be configured by mobile agents or even by users via the InterMarket application server for performing special tasks on the marketplace. Stationary agents implement the agent-based functionality of the three above-mentioned categories. Stationary agents implement the intelligent techniques and strategies for participating in auctions, requests and negotiations on the one side and on the other side they cover business workflow capabilities. Thus, you can configure several business tasks directly to the agent or you can give a goal and the agent can autonomously create a workflow for reaching the given objective. This leads to an advanced automation of business transactions. On marketplaces only the stationary agents perform tasks and encapsulate the access to the application server. Mobile agents have to transmit their configurations onto stationary agents for fulfilling tasks. Stationary agents reside on the marketplace for being activated, configured, and started and for performing work. An important goal of InterMarket is the reuse of most of the functionality by contacting the application server of an existing e-commerce platform. Figure 3.4 shows the internal structure of InterMarket. It combines two existing software solutions. It is not a monolithic block. Thus, InterMarket forms a unit for external access, but divides into separate parts inside, which are loosely coupled. InterMarket should integrate a mobile agent system with an e-commerce application server platform. Both form logical units inside InterMarket and communicate via remote APIs or standard communication protocols. Mobile agents enter the system via the agent server and can use there the e-marketplace functionality. On the other side users can access the application server and can also use the agent technique on the marketplace over the remote connection of both parts of InterMarket. 32

33 3.3. Overall Concepts Figure 3.4.: Inside the InterMarket e-marketplace. Figure 3.5.: Interconnection of agent-mediated e-commerce. The last Figure 3.5 describes a vision of the InterMarket approach. It introduces the mobile agent technology as a communicational pattern or integration framework for integrating e- marketplaces and even other e-commerce activities. The goal is a fully automated and optimized agent-mediated B2B e-commerce network offering most flexible trading capabilities and highest automation level. The mobile agent technology owns, therefore, some useful features such as platform-independency, or being a complete and consistent pattern for communication. Other e-commerce solutions can be adapted to the InterMarket approach with additional current techniques such as Web Services and XML. Thus, a company is able to use a large offer of trading 33

34 3. InterMarket Objectives opportunities using any participant or marketplace in the agent-based e-commerce network. A direct connection between customers and suppliers can be realized that way Why using Mobile Agents? As shown in the further section, there is a need to expand e-commerce functionality. Current e-commerce solutions provide catalog-based transactions and simple forms of electronic auctions and negotiations. However, user demands increase. They want to manage more complex transactions that increase the benefits of e-commerce for them. However, Tewari and Maes [69] conclude that actual e-marketplaces emphasize the prize as the only negotiation basis, which leads to a static impersonal bidding experience. Thus, their approach focuses on specifying multi-attribute preferences for enabling advanced brokering with mobile agents. Also other teams [28, 81] try to implement enhanced agent-mediated techniques for supporting more sophisticated e-commerce abilities for the businesses. Another argument for the insert of mobile agents following Harrison and Caglayan [13] is the extremely fast growth of the information amount in the WWW. That s why it is today and in the future not possible for a human to find useful information without flexible and intelligent assistants. In conclusion Harrison and Caglayan see the advantages of mobile agents on one side moving as representatives for the user through the Web, which collect data and information and observe events with the opportunity to react [13, p. 73, p. 214] and on the other side the practicable use of mobile agents for connecting mobile devices [13, p. 112]. In addition, they don t exclude the possibility of the formation of an agent-mediated free open marketplace [13, p. 112]. Now, the concrete problem should be focused after having showed the need for more advanced techniques. The next section should introduce, with regard to Section 2.2.4, the advantages of the mobile agent technology for e-marketplaces compared to the use of stationary agents with static client-server models for the communication and for justifying the decisions for InterMarket. The good properties of mobile agent technology for connecting mobile devices such as PDA, mobile phone, or laptop are a big reason for using mobile agents within InterMarket. Mobile agents seem to be suitable, because of their low network requirements (less connections with small size) regarding to small power and memory facilities as well as slow connections and small network bandwidth coupled with the problem of not guaranteeing open or available connections every time. Mobile agents can represent a user and perform tasks on e-marketplaces even in the case that the user is offline. If the mobile agents have finished work, they just wait for the home server being online for returning back. So mobile agents help to abstract from online time. In addition, mobile agents lead to an abstraction from regional restrictions because one or more mobile agents can represent a user on different e-marketplaces everywhere in the world at the same time. These two features introduce the ability for the user, to be able for global business round the clock. As consequence mobile agents can wide the trading opportunities for a user by connecting more than one e-marketplace. Because mobile agent technology is a kind of communicational framework, e-marketplaces or e-commerce applications, which are connected with it, can be developed from different vendors. Mobile agents support interoperability and also introduce platform and language independence (Java). Mobile agents also support more flexible and dynamic messaging capabilities than Client- Server, because these agents can be configured for finding the user on more than one home 34

35 3.4. Why using Mobile Agents? address and they can intelligently decide, which address they choose. This leads to advantages if one address of the user is not available at all and following to optimize support. Another big point is the communication. Mobile agents can transport any kind of data such as XML-based data, HTML, graphic data, or even Java objects. Because agents use for their communication flexible and exchangeable protocols, they can be easily adapted for interaction with other agents. Two agents exchange information about their communication facilities before starting the real interaction. Mobile agents introduce state-sensitive communication, because they can store intermediary data. Mobile agents introduce an integrated standard data format. The agents cover their internal data representation and allow users to manipulate the data only by using defined interfaces such as messages and specific communication protocols. Using mobile agents, users reduce effort for maintaining client applications and communication protocols because the mobile agents cover all the problems. The user interface only needs to implement a small interface for configuring the agent or retrieving data from it. In addition, mobile agents can include GUIs. This is even more sophisticated for the user and reduces the maintenance to the agents, because no client program is needed anymore. Agents are not only a communication format or a middleware. Mobile agents are intelligent, so they can autonomously make decisions for optimizing solutions or for finding optional possibilities for solving problems and they can learn and adapt with time to user needs. Mobile agents are configurable for adapting to user experience. Finally, by using mobile agents for mobile devices as well as for normal hosts, it provides a uniform design and adds good maintenance opportunities by specifying uniform, small, and less interfaces and components with no redundancy in comparison to implementing InterMarket with multiple techniques for separated mobile and static access to the agent-based functionality of InterMarket. It is possible to reach some of the mentioned features with other techniques. However, mobile agents can introduce the whole with one single consistent model. 35

36 3. InterMarket Objectives 36

37 4. InterMarket Requirements Chapter four introduces the requirements analysis for the InterMarkt solution. The topic is divided into two parts. First, the agent-based functional requirements are developed for describing the different agent types, communicational demands, mobile access, and the usecases, which cover agent-based activities on the InterMarket e-marketplace. The non-functional requirements are presented with the second part by considering the key features for an e-marketplace with a lower detail. Although Enfinity being an adaptable framework mainly supports all these requirements some special points should be pointed out including requirements for a combined solution of Tracy and Enfinity. These features will be evaluated too in Chapter Agent-based Functional Requirements Actors This sub-section presents the agent actors, which are involved into the InterMarket solution. They (except the human user actor) build the entities performing automated tasks on the Inter- Market framework, configurable for special issues. Figure 4.1 depicts the actors of the agentbased functions of InterMarket, which are described more detailed within this sub-section. Figure 4.1.: Actors of the agent-based features. Human Users Human users own the initial role for any activity, which is processed on InterMarket. They can create, configure, and start software agents of the e-marketplace solution for processing tasks according to the agent-based functionality. Users can apply mobile agents for performing business 37

38 4. InterMarket Requirements tasks on one or multiple e-marketplaces by using mobile devices or directly via the InterMarket application server. Users can also directly authorize stationary task agents via the application server of InterMarket for local processing of work. Humans program agents with specific parameters for concrete tasks, give rules for behavior in dynamic processes such as auction or negotiation, and can optionally set a migration route for mobile agents before starting the agents. Additionally, users must specify authentication features to allow agents e-marketplace access on behalf of them. Software Agents Software agents autonomously perform work on the e-marketplace. There exist two types of agents in InterMarket. The first agent type acts behalf on human users after being initially configured and started. These agents process the given tasks and finally present results of their work to their users. The second agent type autonomously performs management jobs on the InterMarket agent servers for ensuring a correct and efficient proceeding of agent-based tasks. Software agents demand for their work some special features. First, they need to implement special communication protocols for any agent interaction activity, such as data exchange for searching products, or for configuring agents to bid in an auction. These protocols consists of a state machine, which generates well-defined state transitions and ensures correctness of the transformation, and a set of methods, which enable agents to perform complex communications with each other. Protocols can be combined during processing, for example parallel or serial. However, it is also possible to recursively concatenate some protocols. The protocol for exchanging authentication and authorization information is the most important one and should be implemented by every agent on the InterMarket marketplace. As second, the agents require a session handling. Sessions are demanded for ensuring a correct and efficient processing of several agent interactions in parallel within a single agent. Each session manages the communication protocol state machine for ensuring state and the data dictionary, which encapsulates all data that is exchanged only within a single session. Session handling supports transactional behavior and increases security, reliability, and persistence for agents. Mobile Communication Agents InterMarket applies mobile agents for realizing mobile access to the marketplace. Mobile agents are special representatives of their users and transport configuration data for specific tasks, rules for intelligent behavior, authentication information to get access on behalf of their users, and optionally migration route information. That s why they are called mobile communication agents because they do not execute functionality. Thus, they have no access to marketplace functionality and have to interact with specific stationary task agents for executing tasks. Additionally, mobile agents are executed in a special restricted area of the InterMarket agent server for ensuring security for both, agents and agent server. Stationary Manager Agent These agents provide a scale access to stationary task agents within InterMarket and check the authentication information of incoming mobile agents for assigning permissions to the mobile agents. A manager agent activates a task agent from an agent pool and gives a reference (e.g. agent name) to the inquiring instance after a proper request, which can be send via message from mobile agents and also from the InterMarket application server (via an agent server). Stationary 38

39 4.1. Agent-based Functional Requirements manager agents manage a dynamically set of stationary task agents and support the only access to the task agents in the contact phase. The name of a manager agent is known to the system for ensuring contact to it. Figure 4.2.: Life-cycle for a stationary manager agent. Figure 4.2 presents the life-cycle of manager agents. After a manager agent is created and started, it waits for messages in the idle state. If an inquirer (mobile agent, application server via agent server) contacts the manager agent, it changes its state to active and performs the requested jobs (check authentication of mobile agents, or activate a stationary task agent and return a reference to it). After finishing a request, the agent returns back into idle state and waits for new requests. Figure 4.3.: Getting contact to a stationary task agent. Figure 4.3 contains a collaboration diagram for explaining the process for an inquirer (mobile agent or application server via agent server) to get contact to a stationary task agent. The inquirer sends first a message to the manager agent, which requests a task agent. The manager agent determines an idle task agent and sends it an activation message. The confirmation message of the task agent includes a unique reference (e.g. name of the agent), which the manager agent receives. The manager agent sends the reference with a message to the inquirer. Hence, a direct bi-directional communication can be started between an inquirer and a stationary task agent. 39

40 4. InterMarket Requirements Stationary Task Agent Stationary tasks agents process the business logic of the agent-based functionality of InterMarket. They can be configured on the one side by mobile agents and on the other side by users directly via the application server. The tasks of the stationary task agents are described in detail in subsection Task agents encapsulate and access the application server for reusing existing functionality and for ensuring security and scalability. Task agents only extend standard marketplace functionality by adding agent-based functionality, which means that existing objects such as orders, shopping carts, pre-contracts, or requests will be managed with the application server using the existing mechanisms and functions. Thus, the responsibility for business processes remains at the application server. Task agents reside in a special pool, which is managed by the manager agent for fasten execution and support better management of agent server performance (by observing the number of agents and their workload). Task agents can be activated from the pool for performing tasks and they fall back into the pool after finishing work. If task agents have to wait for longer time periods, it is possible to use these agents for multiple tasks in parallel, if no task is time critical. Additionally, they implement three features, which support their work. 1. Task agents implement a data dictionary, which is a private data storage inside an agent. This dictionary has a well-defined structure for ensuring consistent reading and writing processes of different business tasks of the agent. Thus, the dictionary enables different business processes to exchange information, which are produced by some tasks and are demanded for execution by following tasks in a workflow. 2. A workflow engine is needed for managing, assembling, and controlling the processing of several business steps in a workflow. stationary task agents can be configured to execute processes in a workflow. Additionally, they are able to assemble autonomously workflows, if they receive a special task defining only a goal, but not the way to do it. 3. Task agents need special intelligent negotiation techniques and strategies for dynamic transaction models such as auction, request and negotiation, which can be adapted by special rules that can be configured by an inquirer. Figure 4.4 depicts the task agent life cycle. After being created and started, the agent resides idle in the task agent pool having the state pooled. The agent can be activated in this state by the manager agent changing in the active state. The agent performs tasks after being configured in this state. This proceeding is only finished, if the tasks are finished, cancelled, or stopped after error. The agent returns in pooled state with reset status information in any of these cases The Main Usecase Model The main usecase model introduces a consistent approach for the agent-based functionality of InterMarket. This subsection starts with describing two scenarios, which illustrate the proceeding of agent-based functionality in InterMarket before the usecase model is developed. However, manager agents will not be considered anymore, because they are not directly involved in business process execution by only performing management tasks in the background. The first scenario in Figure 4.5 describes the remote access to InterMarket via mobile agents from client systems, which own an agent server, such as mobile devices or PC/workstations. A 40

41 4.1. Agent-based Functional Requirements Figure 4.4.: Life-cycle of a stationary task agent. user configures and starts a mobile agent for performing one or multiple tasks on its local device. Therefore, he programs the agent with task-specific data, authentication information, and optionally with a migration route. If the agent was started, it indicates the (first) e-marketplace and migrates there. If the agent has not received route information from its user, it starts retrieving data of suitable e-marketplaces on special nodes in the agent network before migrating to the first marketplace. The mobile agent authenticates at the e-marketplace and contacts a stationary task agent for transmitting data after arriving on an e-marketplace. The mobile agent configures a task agent with the tasks he was given by its user and starts the processing of a workflow of tasks at the marketplace. The task agent performs the workflow and sends back the results of the processing to the mobile agent, if all tasks are completed. If the mobile agent was configured for visiting multiple marketplaces, it would store the intermediate results and would afterwards migrate to additional marketplaces. If the mobile agent has finished his work it migrates home for presenting its results to the user. Regarding to the configuration, the user can be involved into decision-making processes by a mobile agent after certain intermediate steps in the business workflow. The user analyzes the results of the mobile agent, can make decisions, and maybe invoke another agent-based processing. Figure 4.6 presents the second scenario, which should be considered here. A user can directly configure a stationary task agent using the traditional way with storefront request to the application server. The application server transparently contacts a proper agent via an InterMarket agent server for configuring and starting the agent. After configuration, the task agent starts locally processing the tasks and returns back the results to the application server, if all tasks are completed. Finally, the application server stores the result data and tries to inform the user, maybe with sending a response or placing special information in the database, which can be recognized by the user when he loges onto InterMarket next time. It exists another scenario for business processing within InterMarket. The user also can use mobile agents directly via the InterMarket application server. However, this scenario seems to be a mixture of both, which are described yet. So you can take the first left two swimlines from scenario two and combine them with the two right swimlines from scenario one. 41

42 4. InterMarket Requirements Figure 4.5.: Mobile access to the marketplace activity diagram. The overall main usecase model is introduced with Figure 4.7 following the scenarios, but independent from special tasks. The model reflects all activities in InterMarket, which involve agents. Please take the main usecase model as an overview and refer to the following subsections for detailed information. Figure 4.6.: Stationary access to the marketplace activity diagram. 42

43 4.1. Agent-based Functional Requirements Figure 4.7.: Main model usecase diagram The Configure Agent Usecase Description Precondition Postcondition Error Error handling Actors Scenarios This usecase covers the capabilities of agents to be configured for specific business processes on the InterMarket marketplace. With InterMarket, it is possible to configure agents not only for single tasks, but additionally for a whole task workflow. This opportunity is the main feature of the configure agent usecase. The configuration of an agent with problem-specific data for a special tasks is defined using the special sub-usecases, which are shown right in Figure 4.8. Because of the indicated workflow capabilities it is possible to combine the configuration of multiple of the denoted sub-usecases. The configuration of an agent is absolutely transparent, which means that the different configuration scenarios, which are described with the scenario of this usecase, always follow the same communication protocol. The indicated sub-usecases will not be described because they play no role for the system design. The agent to be configured is alive and idle. The agent to be configured is correctly and completely configured and is able to start proceeding. The configuration data is incorrect, incomplete, or senseless. Send error message to the configuring instance: user or mobile agent. Originator, Committer being roles for the actors: user, mobile communication agent, stationary task agent The actors used in the diagram stand for roles, which actors from the main usecase model can play in InterMarket regarding to the configure usecase. This fact emphasizes the multiple application of the configure agent process in InterMarket. Which actor plays what role is described with the scenarios below. 1. A user (originator) configures a stationary task agent (committer) via the application server for local work on the current marketplace. The user sends an HTTP request to the marketplace application server including the demand for agent-based services. Application server contacts a stationary task agent 43

44 4. InterMarket Requirements and sends messages to the agent covering the configuration parameters. 2. A user (originator) configures a mobile agent (committer) using the application server for remote work at multiple marketplaces. Therefore the user sends an HTTP request including the task data and optionally the route of e-marketplaces to be visited to the application server. The application server contacts a mobile agent and sends messages to the agent covering the configuration parameters. 3. A user (originator) configures a mobile agent (committer) from its local host or portable medium for performing tasks on multiple marketplaces. Thus, the client application creates a mobile agent and passes data including the configuration settings and the route information to the agent. 4. A mobile agent (originator) configures a stationary task agent (committer) for performing local work on the current e-marketplace. Therefore the mobile agent contacts a stationary task agent and sends following the configuration data via messages The Migrate Usecase Figure 4.8.: Configure agent usecase diagram. Description Migration describes the capability of mobile agents to move through a heterogeneous network. Mobile agents can transport their code, state and data from one agent server to another (for more see Chapter 2). This denotes for InterMarket that mobile agents can be used for accessing marketplaces, initiating and performing tasks, and finally returning results back to the user. The transactions will be conducted on behalf of the agent s user. This proceeding enables InterMarket to offer two new features, mentioned in Chapter 3: 44

45 4.1. Agent-based Functional Requirements Precondition Postcondition Error Error handling Actors Scenarios mobile access to marketplaces and the interconnection of multiple marketplaces. Nevertheless, it also is possible to access InterMarket from stationary network-connected PCs/ workstations. The only necessary facility is an agent server. Because the migration is a straight-forward mechanisms, no additional sub-usecases follow. The mobile agent was correctly configured with task data and route information. The mobile agent has migrated and is correctly restarted on the destination agent server. The network connection fails. The mobile agent tries again to migrate or if possible choose another destination from its route. If both are not possible the mobile agent sends an error message to the user if it is on its home server or the agent waits until his new destination (e.g. also the home server) is again available. Mobile communication agent 1. The mobile agent migrates from a home agent server (e.g. on a PC/ workstation or portable medium) to the e-marketplace according to its route settings. 2. The mobile agent migrates from a marketplace agent server to another e-marketplace according to its route settings. 3. The mobile agent migrates from a marketplace agent server back home The Perform Tasks Usecase Description Precondition Postcondition Error Error handling The perform tasks usecase describes the ability of stationary task agents to process one or multiple business processes in a workflow. Thereby, task agents follow a given configuration or they also can autonomously assemble business steps to form a workflow for reaching a configured goal. Therefore, stationary task agents implement several business processes for realizing the execution of a business workflow. These business processes are included with special sub-usecases in the perform tasks usecase model. Most of the business tasks use access to the InterMarket application server for reusing existing functionality and for accessing the marketplace s database. The two first main objectives of InterMarket (see Chapter 3) are realized with the perform tasks usecase. On the one side this usecase describes the automation capabilities of stationary tasks agents through forming business workflows and on the other side some of the sub-usecases realize the intelligent trading and negotiation techniques. A simple example for a workflow is presented subsequent to this usecase description. The stationary task agent was correctly and completely configured. The stationary task agent has successfully finished its tasks and has saved the final results. A sub task produces an error. The stationary task agent tries to complete the remaining sub tasks. If not possible the agent sends an error message to the originator (user or mobile agent). 45

46 4. InterMarket Requirements Actors Scenario Stationary task agent First, the stationary task agent checks, whether it is already configured with a whole workflow or not. If not, the agent assembles a workflow before it starts processing the first task. If necessary, the agent contacts the application server for initializing processes there and receiving results. The agent performs own business logic for any business process. If the agent completes the current task, the produced results were saved, because they can be the foundation of following tasks in the workflow. After completing all tasks, the stationary task agent saves the final results and ends processing. How unique tasks can be processed is explained with the following sub-usecases. Figure 4.9.: Perform tasks usecase diagram. The business workflow shown with Figure 4.10 describes an ordering process. In this example, the user has determined that he is willing to order a product with a certain price. Thus, the agent workflow starts with searching the product catalogs of the e-marketplace. If the price constraint is fulfilled after a possible comparison of multiple product items, the agent places an order and following that generates an order confirmation for the user. But what happens, if the price is not suitable? Thus, the agent extends the workflow by performing additional tasks. In this example, the stationary task agent conducts an offer request to a supplier and if necessary after the offer has returned and the price is always not suitable, the agent starts and performs direct price negotiations with certain marketplace participants. If the agent does not succeed with all these steps, an error message will be generated for the user. This is of course only a simple example. Agents can process even more complex business workflows. 46

47 4.1. Agent-based Functional Requirements Figure 4.10.: Example for a simple business workflow. Perform Agent-based Search Description The stationary task agent can perform search operations in the e- marketplace s database. Precondition The agent has search criteria and data in its data dictionary. Postcondition The agent has stored search results. Error Errors can occur in case that the connection to the application server fails or the search data is incorrect. Error handling Retry a certain number and if not succeeded store an error message. Actors Scenario Stationary task agent 1. First the agent loads the search query data and criteria from the data dictionary. Then, the agent connects to and sends the query data to the application server. Now, the application server forms a database query and queries following the database, while the agent is waiting. After completion of the database request the application server sends back the search results. If an error has occurred, the search results contain an error message. The agent receives and stores the results. Perform Agent-based Compare Description The stationary task agent can compare data according to given compare criteria. Precondition The agent has compare data (the data to be compared) and compare criteria (the criteria, to which the comparison regards) in its data dictionary. Postcondition The agent has stored the comparison results. Error The compare data or criteria can be incorrect or incomplete. Error handling The agent stores an error message. Actors Stationary task agent Scenario 1. The Agent retrieves the compare data and criteria from its data dictionary and fills a special data structure for the comparison algorithm. Now the sta- 47

48 4. InterMarket Requirements tionary task agent performs the comparison algorithm. After finishing the work the stationary task agent stores the search results. Figure 4.11.: Agent-based search activity diagram. Perform Agent-based Order Description The stationary task agent can place orders in the e-marketplaces application server. Precondition The agent has order data in its data dictionary. Postcondition An order confirmation is stored. Error First, a reason for failure is the possibility, that the order data is incorrect or incomplete. Additionally, the connection to the application server can fail. Error handling The stationary task agent retries some times and if no connection is available it stores an error message. Actors Stationary task agent Scenario 1. The agent retrieves the order data from its data dictionary. Then, the agent connects to the application server and sends the order data. After that, the agent waits until a confirmation message arrives. Now, the application server uses the order data to form a database order request. Following that, the application server stores the order in the database of the marketplace. The application server sends a confirmation back to the agent to inform the agent about order placement. The agent receives the response and stores the confirmation in the data dictionary. Perform Agent-based Request Description The stationary task agent is able to requests for quotes or for proposals via the application server. Precondition The agent owns request data in its data dictionary. 48

49 4.1. Agent-based Functional Requirements Postcondition Error Error handling Actors Scenario The stationary task agent has stored offers (following RFQ) or offer requests (following RFP). The request data is incorrect or incomplete. The connection to the application server fails. The stationary task agent places an error message. Stationary task agent 1. The stationary task agent starts with retrieving the request data from its data dictionary. The agent sends this data to the application server and following waits for confirmation. Now, the application server performs its work such as transforming from the request data an offer (RFP) or offer request (RFQ) and storing the request then in the database regarding to the users that should be addressed. The application server sends a confirmation to the agent to confirm the agent the completed incoming of its requests. The agent receives and stores the confirmation and passes again in state waiting until a response comes in. Some time can be passed after this proceeding until another marketplace participant acts as responder and reacts on the request of the agent. This responder places a response in the system, so that the application server can send the offer or offer request to the agent. Now the agent receives and stores the response in the data dictionary. Perform Agent-based Auction Bidding Description The stationary task agent observes an auction and places bids according to its configuration. Precondition The agent has the auction data (for determining the proper auction) and bidding settings in its data dictionary. Postcondition The auction result is stored. Error The auction data is incorrect, following that the agent cannot find the proper auction. The bidding settings are incomplete or incorrect, so that the agent cannot make bids. And third the connection to the Application Server can fail. Error handling The stationary task agent stores an error message. Actors Stationary task agent Scenario 1. The agent retrieves the bidding settings from the internal data dictionary for filling the agent s bidding logic data structure with start parameters. Then, the stationary task agent retrieves the auction data and sends an auction status request to the application server before going in the wait state. The application server forms a status request and queries the database to retrieve the status information for the wished auction. When the application server has the status extracted, it sends back auction status to the waiting agent. Now the real logic of the agent comes into game. First thing to test, if the auction is always active and it is possible to place bids. If not, the agent bidding task ends. However, in this case must be checked, if the auction has a winner and who is it. If the auction is yet active the agent performs the decision-making logic, which was initially loaded with user bidding preferences and strategies. Now two different results are possible. If the logic induces the agent to place a new bid, 49

50 4. InterMarket Requirements the stationary task agent sends the bidding data to the application server and waits then for confirmation. The application server forms a bidding and stores it in the database. Following the application server sends back a confirmation to the agent. The agent receives and stores the confirmation. Then the agent will perform absolutely the same it would do, if the second case, the logic induces the agent not to bid, was initiated. The agent waits a certain time period before starting again the whole process with sending an auction status request to the application server. Figure 4.12.: Agent-based order activity diagram. Figure 4.13.: Agent-based request activity diagram. 50

51 4.1. Agent-based Functional Requirements Figure 4.14.: Agent-based auction bidding activity diagram. Perform Agent-based Negotiation Description The stationary task agent can perform negotiations with other businesses via the application server. Therefore, it is possible to use an agent in agent-toagent or agent-to-human negotiations. It should be absolutely transparent what actors process the negotiation. Additionally, agents can be authorized by users in negotiations on the requesting and on the responding side. The application server stores in every step the offered pre-contracts as a confidant for both trading partners in the database. Precondition The negotiation data is in the data dictionary. Postcondition The negotiation results are stored. Error The application server connection fails. The negotiation data is incorrect or incomplete. Error handling The stationary task agent stores an error message. Actors Stationary task agent 51

52 4. InterMarket Requirements Scenario 1. The agent will be used for sending requests in a negotiation. The agent retrieves the negotiation data from the data dictionary and fills with this the logical negotiation data structure. Following, the agent performs the negotiation logic, based on the logical data structure, for finding the first negotiation data to be send to the application server. The application server receives the negotiation request and forms a negotiation object that will be stored in the database. The application server also informs the trading partner that the agent wants to negotiate. After all, the application server sends a confirmation to the stationary task agent, which waits for that. Now, the agent stores the confirmation and waits again until the trading partner has placed a response in the application server, so that the server sends a response to the agent. The stationary task agent stores the response regarding to the logical negotiation data structure and performs then again the intelligent negotiation logic, if the response was still active. The logic induces the agent to send or not to send another request, which would be starting the whole process again. Such a request can also include accept or reject information instead of new negotiation product data. If the response was not active anymore, it can be containing data such as accept or reject information. Figure 4.15.: Agent-based negotiation activity diagram. 52

53 4.1. Agent-based Functional Requirements Optional scenarios 2. The stationary task agent will be used for responding on negotiation requests. However, for the agent this scenario is absolutely similar to first, because the steps to be performed are similar. The scenario also starts with the user assigning the agent to participate in a negotiation. That can be seen from the agent s point of view, that the agent in this scenario again sends the requests. The agent also sends the negotiation responses to the application server, which routes the response to the other negotiation partner, waiting following for further requests The Return Results Usecase Description This usecase describes the process of agents, which send back results after having fulfilled tasks. The sub-usecases in Figure 4.16 extend this basis functionality for returning special results according to the configuration and task performing, which were finished before. Of course, it is possible to return multiple result data in parallel, if an agent was configured to perform multiple tasks before. The sub-usecases are not described anymore, because they have no impact on the system design. Precondition Agent has finished all tasks and has stored final results. Mobile agents have to be migrated to their home agent server. Postcondition Result data was completely sent. The stationary task agents become idle and the mobile agents will be killed, if no follow-up order is initiated. Error - Error Handling - Actors Scenarios Sender, Receiver standing for roles, which the following actors can play: user, mobile communication agent, stationary task agent The actors in this usecase differ from the one in the main usecase model. However, sender and receiver are only roles for the main actors, which they play according to the configuration process, which has to be done before. An actor playing originator (committer) role in the configure agent usecase will play the receiver (sender) role here. 1. The stationary task agent (sender) sends a message containing the results to the user (receiver) via the application server. After receiving a confirmation the stationary task agent is ready. 2. The mobile agent (sender) returns results via the application server back to the user (receiver). So the mobile agent sends the result data with a message to the stationary task agent, which mediates the message to the application server. After receiving the confirmation message from the stationary task agent the mobile agent has finished. 3. The stationary task agent (sender) sends a message containing the result data to the originating mobile agent (receiver). After receiving a confirmation the agent is ready. 4. The mobile agent (sender) returns the results by sending a message back to the user (receiver) on its private home agent server (e.g. on a PC/ workstation or mobile device). After receiving the confirmation the agent has finished. 53

54 4. InterMarket Requirements Figure 4.16.: Return results usecase diagram Non-Functional Requirements Appointing the non-functional requirements for the InterMarket solution leads to some problems. It is not possible to determine the requirements for any non-functionality with hard numbers for ensuring an accurate specification. This problem depends on some characteristics of Internet-based and agent-based applications. First of all, the InterMarket approach describes not a concrete installation, but even more a framework, which must be able to adapt to a multitude of different requirements. Thus, it is not possible to specify hard numbers, because on the one side Procurement/Enfinity offers directives not facts for the non-functional requirements, because it is also a framework and on the other side there exist no general assumptions for nonfunctional requirements, because these values completely depending on specific installations and their special demands. Furthermore, there exist no assumptions or constrains for the percental fraction of agent-based tasks at the whole processing of InterMarket. Following, it is not possible to determine hard numbers for non-functional requirements for the agent-based components of InterMarket. Finally, it is nothing known about the time effort and the demands on system resources for executing agent-based features. The InterMarket non-functional requirements are a set of directives and recommendations as result of the indicated problems Integration of Application Server and Agent Server The foundation for InterMarket should be the combination of a standard e-commerce platform coupled with a mobile agent system. Therefore, the marketplace should reuse existing software for focusing on the new advanced agent-based features. Both underlying applications should be bi-directionally integrated, because in InterMarket on the one side agents access the application server for using marketplace functionality and on the other side the application server makes usage of agent functionality. If no complete integration of both solutions is realizable, both applications need to be connected via a remote bi-directional communication mechanism. This is 54

55 4.2. Non-Functional Requirements important, because the standard business logic remains on the application server and so InterMarket advances from the already implemented features there, such as transaction-based processing, scalability, reliability, and security. At the agent server reside mobile communication agents and stationary task agents, which implement the agent-based features, described in Chapter Portability of the Agent Server The most important application area for mobile agents is the connection of mobile devices to the e-marketplace. So it must be possible to migrate an agent server on those small mediums with low performance and transmission power. Thus, a downsizing of an agent server must be processed, that enables the agent server to run on the denoted small and portable systems. Additionally, InterMarket has to offer a concept for managing mobile agents in the Internet to ensure efficient processing of mobile agent tasks Performance Finding numbers for performance requirements is very hard, because e-marketplace applications do not refer to normal Web sites, such as online shops with high visitor traffic and much less orders a day. Requirements for e-marketplaces can increase even during lifetime, if acceptance of the market increases, for example. Besides, e-marketplaces are characterized with a high number of orders/transactions per day, which differentiates them heavily from online shops. Intershop suggests for a small B2B scenario between 98,000 and 226,000 orders per day and even 690,000 to 1.3 million requests per day [40, 41]. In opposite, Intershop gives for a large scenario the numbers between 847,000 and 1.2 millions orders per day and 5.4 million up to 6.7 million requests per day. Although, these numbers are more suitable for e-procurement solutions and other B2B applications, it could be possible to even have such a kind of traffic on an e-marketplace. Following these scenarios, an e-marketplace solution must support similar numbers according to the denoted traffic rates. Response times (peak and average) of an e-marketplace should be between 3 up to 5 seconds, because these time intervals obtain as ergonomically useful and users will become fast impatient if response times outrange the denoted interval. However, response times should be as fast as possible. Especially, the main page of an e-marketplace solution should be very fast. The system should extensively make usage of caching strategies, such as caching static Web pages or caching database content for ensuring maximum speed. Additionally, multimedia and graphic content can be outsourced on a fast extra directory server saving database accesses. Following the requirements for traffic and response times, the system must be able to support a certain workload, meaning the concurrently execution of a number of requests. To size a marketplace solution for handling all possible scenarios it should be sized following special peak requirements. Because there exist no universal statements for the workload of an e-commerce system the following example, emulated from [42, p.54], could give an idea how to size it properly. The example will take statistics according to a small B2B scenario, indicated above: 98,000 orders a day imply at least 98,000 users a day, the average session time should be located between 5 and 10 minutes and the whole traffic should be happen within 10 hours a day. 55

56 4. InterMarket Requirements It can be calculated first the number of parallel sessions. Having 98,000 users, each connecting about 7.5 minutes with the marketplace, leads to 98,000 x 7.5= 735,000 session minutes. Only 600 real time minutes are available for the 735,000 session minutes, because the scenario assumes that all users work within 10 hours. Thus, the number of parallel sessions can be easily calculated: 735,000 / 600 = However, this number does not tell us something about the real workload, which is denoted with parallel requests, because parallel sessions does not imply processing tasks on the server at any time. Parallel requests indicate the real number of active parallel server tasks. In the worst case it is possible that the number of parallel sessions even equals the number of parallel requests at a time. This is relatively improbable. Supposing the average thinking time of a user to be about 10 seconds and the marketplace servers respond in about 5 seconds, it is possible to determine the number of parallel requests in the system: 5 / (10 + 5) x 1225 = 408. Thus, about 410 parallel request have to be executed by the marketplace servers in the scenario. If the system would be able to respond in only 3 seconds, the number of concurrent requests can be decreased down to 3 / (10 + 3) x 1225 = 282. For reaching overall good performance, the marketplace solution should support server clusters, which offer the option for extending the system s configuration, if necessary. The system configuration should be oriented to meet the peak requirements rather than average requirements [41], because the system should be able to react fast even under the hardest conditions. The hardware requirements can be described following a simple formula: Take the most powerful and fastest hardware you can get. For example use Server hardware (e.g. Sun Sparc III, HP L3000, HP Superdome 32w) with multiple processors, highest clock speed (2 Gigahertz and higher), fastest bus communication, high maximum RAM capabilities (4 Gbyte), and fast and large hard disks (SCSI). Network connections should be also as fast as possible, such as 1 Gbit/sec for the application server and the database and 100 Mbit/sec for Web server [40]. Requirements for database amount depend heavily on the number of users, products, and orders in a system. Having for example about 100,000 users each of a size of 20 Kbyte, 350,000 products and maybe 5000 catalog and category structures each 39 Kbyte large. Thus, the database must be able to manage a about 16 GByte (see the example in [40, p.18]). There exist no special requirements regarding to mobile agents. Furthermore, the agent-based components should be able to adapt to the overall requirements Scalability Especially for e-commerce applications, concrete numbers for scalability are badly predictable. They depend too much on concrete projects, the user behavior, and the target market of a solution. Therefore, an e-marketplace solution has to scale to a heavy varying amount of users, with only a few assumptions about their behavior at the marketplace, such as interaction time with the site, page request rate, or the ratio between dynamic or static content. E-marketplaces have to face two main goals: the scalability within peak times and the scalability for an overall increasing number of users. An e-marketplace application has to focus on two approaches for reaching the goals. On the one side software scalability and on the other side hardware scalability. The goal of these techniques is to extend system resources, meaning software components and hardware facilities to adapt to every possible amount of users. The scalability hits all application layers and should provide scale access to the system by using server clusters and a scale database access by implementing scale connections to a high-scaling database product. The software scalability is supports by distributed components, services, and software servers. The hardware scalability is reached through hardware server cluster and the 56

57 4.2. Non-Functional Requirements network management for the hosts of a cluster and their interaction. Finally, Load balancing mechanisms (hardware and software) can improve scalability of e- marketplace solutions Availability E- marketplaces must be mostly available round the clock on 365 days a year, because they are designed for business transaction. This means, that every lost minute means lost money. Therefore, the system should support multiple redundant facilities for each of the three application layers. Each component (software or hardware) should exist at least twice. This induces multiple access points to the marketplace, such as Web server cluster, multiple application servers and distributed business components for redundant business logic, and even multiple databases. This proceeding enables the e-marketplace two features: Through clusters, single points of failures were prevented, because if one server or component fails another can take over. On the other side it opens the ability for maintaining parts of the system, while other parts are active. Thus, the components, to be maintained, can be switched off and substituted with other active parts. A session failover mechanism should ensure that in case of a server failure or down another server can complete active sessions. Client requests to unavailable or unresponsive components will automatically fall over to an available component transparently to the requester. This mechanism should also give the ability, that if an access point to the marketplace fails, even another access point can route requests to the correct servers with the active sessions Reliability With the marketplace solution the business logic should be separated in a special layer within an n-tier application, so that all other parts of the system are forced to consistently use this one instance through performing the business operations every time exactly the same way. Every user interacts with the system via sessions. All information and data, the user has used within the session, have to be managed that way that they are consistent and available (session tracking mechanism), even in case of one server of a server cluster fails and the user requests are routed or processed with another server (fault tolerance mechanism). All transactions, performed during a session, have to be persistently stored for recoverability in error case to ensure transactional and database integrity. The marketplace must ensure transaction-based processing within sessions and even over multiple integrated resources (database, integrated legacy systems) for guaranteeing the ACID properties and reliability normally expected only from databases. This correct processing is needed, because business-related transactions are very sensitive. A session failover mechanism for ensuring that all sessions will be completed correctly with consistent session data has to be implemented to withstand power outages and hard- or software errors Security For transmission security, meaning securing the whole external communication between clients and the system, the marketplace has to offer an encryption mechanism such as SSL. This communication covers simple HTTP requests as well as mobile agents migrating through the Web. A firewall should keep the system safe from external attacks, which is in addition supported by 57

58 4. InterMarket Requirements implementing only specific defined access points to the system, for both mobile agents (special gateway agent server) and HTTP requests (Web server). The internal communication also should be secured for preventing someone, who has passed the outer security barriers, from emulating internal communication. Therefore, internal secret keys should be exchanged between all servers. This is very important for the agent access to application server services. And additionally, the database access should also be secured with special logins and passwords, every server owns a unique one. Because internal servers can hide the storage place of internal passwords and keys, this brings a high degree of security. For ensuring correctness of specific user information and data within the marketplace, users communicate with the system only after a correct login. Every access to the marketplace is secured for both, agents and users, with logging mechanisms. This is additionally supported with authorization mechanisms and permission and role concepts for different actors (agents and users). According to a role an actor plays, it is able to invoke services and to access or change information on the marketplace. Another important point is the prevention from misuse of user sessions. Therefore, concepts are needed for ensuring that no person can use session information of any other user. For example, if a user interacts with the marketplace via a Web browser and terminates the session, it is not allowed that any user specific sensitive data can be reproduced with the Web browser history or Cookies. Halted sessions, that are incorrectly broken up and not active since a certain time period have to be deleted, so that no actor, agent or user, can apply session specific information of another user. Finally, for the agent technology special security requirements exist, because mobile agents are some kind of external code executed on the marketplace s agent server. Because fewer assumptions on the trust of mobile agents can be made, it is important to increase knowledge about agents and their owners and/or to limit the resources, agents can use. Therefore, Java offers a lot of build-in mechanisms such as Java Sandbox, bytecode verification, code signing, custom class loaders and security managers. With these techniques it should be possible to realize an agent-specific authentication and authorization model, securing the mobile agent execution. On the other side the marketplace should offer mechanisms for saving the agent from malicious access and change from agent servers. Mobile agents must be prevented from interception and manipulation by external agent servers Extensibility and Flexibility First point is to use a flexible three-tier architecture for ensuring good maintainability and separated advancement of components of a single tier independently from other tiers. The separation of presentation, business and database tier offers flexible capabilities for adapting the system to newer performance, scalability and availability requirements. The marketplace should be build using as many standards as possible, for providing clearly defined interfaces and mechanisms for flexible and easy further development. Another requirement is a flexible extension of the system s business logic or the extension and adoption of the presentation logic according to requirements of specific projects. On the one side it must be possible to implement new business logic and components in short time and to integrate this logic with existing business logic. On the other side, third-party software solutions have to be integrated easily such as marketplace participant s ERP systems as well as applications of service providers. Therefore, the solution should offer sophisticated APIs and tools for easy designing new business processes, deploying and generating code as well 58

59 4.3. Standard Functional Requirements as for adapting presentation logic of the marketplace for a complete integration. Regarding to presentation of the marketplace, it should provide capabilities for accessing the marketplace from different client devices such as GUI, Web browser or portable, mobile devices. A last point is the integration of mechanisms for flexible data exchange with the marketplace using standards or the integration of the marketplace solution with other applications. Therefore, the system has to offer APIs and tools for ensuring exchanging capabilities flexibly via many different data and exchange formats or to fast integrate new data exchange or communication techniques with the system Personalization and Internationalization Personalization and internationalization are important to reach two goals. First personalization covers capabilities for tracking user sessions and to adapt the look and feel as well as the handling of the marketplace to user preferences and needs. So the marketplace has to offer opportunities for the user to adapt the appearance of the marketplace to personal needs. The marketplace offers customer enrollment and other membership services. The second is the ability of the marketplace to serve global trade. Therefore, the system has to offer multi-currency and multi-language support. This should be possible even in parallel. Products or offers can differ from buyers currency. Thus the system has to offer facilities to convert currencies, even at runtime. Multiple languages should be supported for giving participants the ability to work on the marketplace in their native language. This increases, of course, also the personal user experience Standard Functional Requirements The reader will miss standard e-marketplace functionality. This topic is not considered within this paper, because it forms the basis of InterMarket and can be seen as foundation given with the usage of the e-commerce platform Enfinity. In fact, standard functionality does not influence the InterMarket approach. InterMarket adds agent-based functions on top of standard marketplace functionality. However, this additional functions use a set of low level features, which every marketplace solution offers. A main point for not discussing standard functionality is that these features are implemented with the Enfinity solution in combination with an add-on component. Therefore, it is referred to following references [..,...] published by Intershop. Indeed, absolutely basic knowledge is introduced with Section 2.1. To fulfill the InterMarket demands, it is sufficient to use additionally to Enfinity the Procurement cartridge from Intershop upgrading the basic Enfinity to a complete marketplace solution including facilities for auctions, negotiations and multi-byuer to multi-supplier aggregation. 59

60 4. InterMarket Requirements 60

61 5. Introduction of the underlying Applications This chapter presents the two software applications, which should be reused for building up InterMarket. For both applications, the main functionality and key techniques will be described. However, this chapter does not provide a detailed introduction and introduces only those features, which refer to the InterMarket concept. For detailed information the reader is referred at the specific positions to continuative literature Enfinity Platform The e-commerce platform Enfinity is the foundation of the InterMarket solution and should be presented first. After a general introduction, the Enfinity core components will be indicated, piecing it all together in the overall architecture. Followed by some thoughts about communication, the presentation of Enfinity is finished by describing a storefront request workflow to give the reader an insight into the processing inside the Enfinity system. Following, a special Enfinity add-on component called Procurement Solution is introduced with two sub-sections, showing the technical integration of the component and added features. The second part of the section offers a general insight at the Procurement solution, which bases on Enfinity. The main business model of the component is introduced after mentioning the general technical architecture and the actors. Finally, the description is finished by an itemization of the main functionality of the Procurement Solution Enfinity in General Enfinity is a platform, especially developed for targeting the development of e-commerce applications and offers the core functionality for building software systems regarding to all known areas of e-commerce. Enfinity is already in its basic version an enterprise-class software package for selling products and services of a company in the World Wide Web. Thus, Enfinity implements core functionality for maintaining product catalogs and managing buyers and orders. A key feature of Enfinity is its ability for adapting to specific types of e-commerce solutions (e.g. e-marketplace solution) by installing so-called cartridges for upgrading the basic functionality and for adding third-party systems and extensions as well as for integrating intelligent merchandising add-ons (e.g. auction component). Thus, it is possible to integrate Enfinity in the existing software infrastructure of a company, because it offers interfaces to other standard products such as ERP software (e.g. SAP R/3), other business systems as from Commerce One, Internet applications, and Internet services. 61

62 5. Introduction of the underlying Applications Another main key feature of Enfinity is the separation of business logic management and the core code using configurable and adaptable business flows (pipelines) composed of consecutive executed reusable logical steps. Each of these steps, called pipelet, implements a specific part of the business logic. In addition, with the pipeline concept the business logic is separated from the presentation logic by introducing special logical steps, named templates. Enfinity is fully developed based on J2EE and XML and profits from the advantages of these techniques, which leads, of course, to a high number of employment and extension scenarios Enfinity Architecture and Components The software architecture of the core Enfinity system and its components are described in this subsection. Enfinity is implemented as a 3-tier application, meaning the separation from presentation layer, business logic layer, and database layer into different tiers. This approach opens all advantages, which this architecture type introduces, such as good availability, extensibility, and reliability for the Enfinity system. Figure 5.1.: Core Enfinity 2.2 software architecture. Web Server and Web Adapter Enfinity is an Internet-based application. It supports for its clients standard Internet access through HTTP communication with a Web server. The Web server represents the gateway to the Enfinity servers, being the only entry point for external requests. Enfinity can support even multiple Web servers each running a special application called Web Adapter for good load balancing, availability, and performance. The Web Adapter is a native Web server extension, responsible for passing each incoming request to an appropriate Enfinity server. It offers even more functionality, e.g. for session tracking and session failover as well as for load balancing. Referring to the first point, the Web Adapter creates unique session IDs for the requests and uses this information along with data from the requested URL for distributing requests onto the servers. Regarding to the request distribution, the Web Adapter tries to send requests of a unique session always to the same server for increasing reliability and performance. Only if a server fails the Web Adapter will send a request to another server of the same type. For providing that failover mechanism the session data is stored persistently in the database. For the second point, the adapter uses additional information received from a server control service to distribute the requests according to the workload of the Enfinity servers. 62

63 5.1. Enfinity Platform Enfinity Catalog Server (ecs) and Enfinity Transactivity Server (ets) These two servers provide the storefront and back office services that run the e-commerce site, whereby catalog and product information are handled with the ecs and buyer and order data are managed by the ets. The Catalog Server controls the e-commerce site browsing, handles product and category data as well as provides product and catalog search and presentation. In contrast, the ets manages the user sessions, shopping baskets, orders, and all other business activities within unique sessions, including the buyer information. Talking only about storefront services, both servers in addition offer back office services such as product and catalog management (ecs) or user and order management as well as maintaining business and presentation logic (ets). The separation of these two servers is a design decision, which offers more flexibility referring to the use of both, namely for increasing load balancing, performance, and scalability of the whole solution. In addition, requests to the ets are slower because of partial writing access to the database, what decreases performance and workload. Think of a B2C scenario with almost browsing requests and only a few orders in the system. The separated design of ecs and ets offers the ability for adapting the requirements of the catalog server independent from the ones to the ets. Regarding to the scenario, it is possible to install multiple ecs for providing high browsing performance. Further, by increasing the expense for the Catalog Server the performance of the Transactivity Server is not influenced. The main components of the servers are the distributed business objects (EJB), pipelets, pipelines, and templates representing the business and presentation logic of the e-commerce site, which will be presented in Section For fulfilling their tasks, it is necessary that both servers communicate with each other. The so-called cross-server calls are described in Section Enfinity Application Server (eas) The eas runs under the ecs and ets providing basic functionality for both servers above. This includes general administrative support such as managing, which server is running as well as the communication between servers, servers and database, and servers and Web Adapters. It performs some early initializations and configurations for incoming requests such as identifying the locality of a session before passing a request to a specific server (ets or ecs). Among other duties, just as support for key requirements such as performance, scalability, and reliability, the Enfinity Application Server provides an abstraction to the database access, which is implemented with an EJB server. Enfinity integrates for that task the Persistence PowerTier application server [62], which provides a complete palette of services such as container managed persistence, transaction and life cycle management for the business objects, data object caching, database connection pooling, and database access. The Enterprise JavaBeans (EJB) are accessed from business steps in pipelines inside the ecs and ets servers through so called manager classes, which encapsulate, an often aggregated, access to more than one EJB. Relational Database Currently, Enfinity runs on an Oracle 8i relational database management system accessed directly from PowerTier EJBs. Therefore, a special communication interface is used: the Oracle Call Interface (OCI), which is a special oracle-induced interface for direct and fast database access. This communication is on a lower abstraction level, however more implementation-related, in opposite to JDBC. The combination of EJBs and the native OCI protocol allows for automated object caching to 63

64 5. Introduction of the underlying Applications increase system s performance. Enfinity also supports for performance reasons multiple separate databases, one for the ecs and one for the ets. If multiple Enfinity servers of the same type are used within a server cluster, they all connect to the same database. For example, all ecs in one cluster access the same database. More databases increase the number of concurrent sessions while decreasing response times and the database s workload. Database sharing of all servers from one type in a cluster is important for data consistence within user sessions Enfinity s Pipeline Concept In Enfinity, the business logic is separated from the core source code. By using configurable business flows, composed of re-usable logical steps Enfinity offers a mechanism to flexibly change the business logic without much coding and management effort. A pipeline is a logical model of a business flow and combines a number of business tasks, using a determined syntax to delineate the business flow. Beside normal pipelines, invoked by client requests, there exist scheduled pipelines, which can be started automatically following a given time period. And in fact, the business steps are reusable, changeable, and extensible. A pipeline consists of mainly three different types of nodes, indicated as pipelets, control nodes, and interaction nodes. Pipelets are reusable business steps, implementing core Enfinity business logic. Pipelets are Java classes performing the detailed work of handling the requests, such as contacting the database and retrieving information. Therefore, pipelets communicate with the EJBs inside the Enfinity Application Server, acting as clients for the EJBs. Pipelets extend the Pipelet class and implement a special execute() method, which handles a reference to the pipeline dictionary as a parameter (similar to command design pattern [25]). The following example for a pipelet shows the execute() method, which tries to read an enumeration of counter objects from a CounterEJB and stores the information in the data dictionary. public int execute( PipelineDictionary pipelinedictionary ) { try { // Lookup the counter home IRegistry r = Registry.getInstance(); CounterHome counterhome = (CounterHome)r.lookupEJBHome( "CounterHome" ); // Get the current domain id Domain domain = (Domain)pipelineDictionary.get( "Domain" ); String domainid = domain.getuuid(); // Select all counters of the current domain into an Enumeration Enumeration allcounters = null; } try { allcounters = counterhome.findbydomainid( domainid ); } catch( FinderException e ) { FWLogger.logMessage(FWLogger.DEBUG, "core.stdinfo1", "No counters found." ); } // Put the numerator into the pipeline dictionary pipelinedictionary.put( "Counters", allcounters ); } catch( RemoteException e ) { FWLogger.logMessage(FWLogger.ERROR, "core.stdinfo1", "RemoteException: " + e.getmessage() ); } return PIPELET_NEXT; The return parameter of this method informs the pipeline processor about successful execution, if it is PIPELET_NEXT and the pipeline continues with the next transition. In the case of 64

65 5.1. Enfinity Platform PIPELET_ERROR the pipelet causes an exception and the pipeline continues via an error transition. If important data items in the data dictionary fail but are needed for the pipelet, it will throw a PipeletExecutionException, forcing the pipeline to stop. Each pipelet owns an XML descriptor file (see the example below), which includes statements such as pipelet name, description, or full class name (full package path). Additionally, information is specified for the transactional behavior of a pipelet, with the error-connector tag (if true, an error connection branch is supported, else PIPELET_ERROR say something about the pipelet s failure behavior and the transaction tag (such as commit, rollback). The properties tag identifies the properties that a pipelet needs to perform its task or that should be provided for other pipelets to use and which are stored in the pipeline s data dictionary. A pipelet can have multiple property tags, which also can have some attributes such as key, class, and group (for detailed information see [35, p. 53]. It is possible to modify pipelets and reload them without restarting the server, because they will be dynamically reloaded just as pipelines and templates, too. Pipelet Descriptor DetermineAllCounters.xml <?xml version="1.0" encoding="utf-8"?> <pipelet> <name>determineallcounters</name> <description>determine all counters in the current domain</description> <class>com.companyname.cartridge.sample.pipelet.determineallcounters</class> <error-connector>false</error-connector> <transaction>supported</transaction> <properties> <property> <property-key>counters</property-key> <property-description>all counters in the current domain </property-description> <property-group>dictionary-out</property-group> <property-output>guaranteed</property-output> <property-class>java.util.enumeration</property-class> </property> </properties> </pipelet> Now the control nodes will be introduced. These nodes are responsible for defining the flow in a pipeline. Meaning, they define a flow chart, which describes the order of execution and dependencies between all included pipelets. Therefore, there exist four different types of control nodes. First the start nodes. Every pipeline starts its execution at a start node, which is specified with its name in the HTTP request URL, which is sent by the client. In fact, pipelines can have multiple start nodes for different access points to the pipeline s logic. Another node type are the call nodes used for calling other pipelines from inside a pipeline to even use the business logic of the others. Jump and Join nodes guide the flow inside the pipeline, the first represents a conditional branch and the second joins multiple logical threads in a pipeline s flow to one. The third node type are the interaction nodes. Here, it is distinguished between interaction end nodes and interaction continue nodes. The end nodes generate an HTTP response and can ensure session failover using persistent mode settings. The pipeline execution terminates after the end node is reached. The interaction continue nodes interact within a pipeline with the client for receiving for example additional information for continuing the pipeline business logic. However, this happens volatile and without failover security. Both nodes invoke a template generator and send template generated HTTP responses. Every Client Request invokes a pipeline in the Enfinity system, which is identified by the requested URL. For example, the following URL from an Intershop installation at Otto.de tries 65

66 5. Introduction of the underlying Applications to connect with the ecs using the pipeline OV_BrowseCatalog with the start node Start for the current request: If a pipeline is started, it first initiates the pipeline dictionary, a key-value repository for holding strings and also complex Java objects, which there are durable within pipeline runtime. The pipelets, executed with the pipeline, can read and store information for getting suitable input parameter for the own calculation or for making available their execution results for following steps in the pipeline. Even templates use the data dictionary for retrieving the information to be sent to the client. A last big point to mention is the ability of pipelines for defining transactions. The connectors between nodes can be set to transaction settings such as rollback, commit, or savepoint for ensuring correct and complete processing of tasks within Enfinity. Now, a short extract follows, which presents a pipeline definition made using XML. How can be seen in this sample, the pipeline starts with a start node Start followed by pipelet pipelet0, which needs an information with the key name CounterKey of type SampleKey from the data dictionary. Connections between the pipeline steps are defined in the second part of the XML file. For each transition the ID of the start (e.g. idref= Start ) and end node (e.g. idref= pipelet0 ) is stored. <?xml version="1.0" encoding="utf-8"?> <pipeline> <name>samplepipeline</name> <description> Increments the sample counter and shows the values of all counters in the current domain </description> <nodes> <start-node id="start"> <start-name>start</start-name> </start-node> <pipelet-node id="pipelet0"> <pipelet-name>incrementcounter</pipelet-name> <pipelet-config> <config-property> <property-key>counterkey</property-key> <property-value>samplekey</property-value> </config-property> </pipelet-config> </pipelet-node> <interaction-node id="interaction0"> <template>sampletemplate</template> </interaction-node> </nodes> <transitions> <transition> <transition-from idref="start"> <from-connector>next</from-connector> </transition-from> <transition-to idref="pipelet0"> <to-connector>in</to-connector> </transition-to> </transition> <transition> <transition-from idref="pipelet0"> <from-connector>next</from-connector> </transition-from> <transition-to idref="interaction0"> <to-connector>in</to-connector> </transition-to> </transition> 66

67 5.1. Enfinity Platform </transitions> <types> <type>storefront</type> </types> </pipeline> Communication inside Enfinity Enfinity makes often usage of HTTP for communication. As an Internet application, Enfinity uses HTTP for storefront requests. As described in Figure 5.2, it also uses HTTP for communication between Web adapter and Enfinity servers. ecs and ets receive HTTP request, and if they need to exchange data between each other, they will also connect using HTTP sending their requests via the Web Adapter. All external communication with the Enfinity system passes through the Web adapter, which can be secured using HTTP/S. The database access from Enfinity servers is realized through EJBs, which can be accessed by pipelets. However, the pipelets do not interact with the EJBs directly, but with so called manager classes, which encapsulate the access to one or more EJB and their information. The ets and ecs use the database object cache layer of the EJB server to communicate with the database. The EJB server maintains an open connection with the database server and uses a native protocol (Oracle Call Interface) to query the database. Figure 5.2.: Data communication in Enfinity [35, p. 35]. However, in Enfinity exist even more communication, which is in fact not that important regarding to InterMarket. For more information on communication please read [35] Storefront Request Workflow in Enfinity In general, our excursion starts with the Web server, which receives an HTTP request passed then from the Web adapter to the core application server, where some of the basic functionality is performed. Following the request is handled to the specific ecs or ets where, with use of the EJB server, the database is accessed and the business logic is performed. This is done in the Enfinity server by starting a pipeline, which processes the business logic, and generates a template for the response, which returns to the client. 67

68 5. Introduction of the underlying Applications In Detail The request is passed from the Web Adapter to the Request Handler Servlet part of the core application server. This HTTP Servlet class handles an HTTP request and returns an HTTP response, while maintaining state. The Servlet sets up the appropriate request, response, and session objects by using the information, which is encoded in the requested URL (e.g. session ID, language, currency). After checking some data such as login and other information the Request Handler Servlet invokes the Pipeline Processor for executing the pipeline encoded in the URL. The Pipeline Processor sets up the Pipeline Dictionary. The dictionary is filled with additional data from the request s URL. The processor manages the correct flow of the pipeline elements through the pipeline, which in addition offer transaction-based handling. Each pipelet in the pipeline fulfills a specific task and can, therefore, implement own services, can access the database via EJBs, or can even use services of the EJBs. Figure 5.3.: Workflow for a storefront request, [35, p. 46]. At the end of each pipeline an interaction node produces an output for the client. This interaction node invokes a special template processor, which can automatically generate an HTML response from a template class file, which is filled with the data from the pipeline data dic- 68

69 5.1. Enfinity Platform tionary. If the pipeline ends the pipeline processor returns back the generated response to the Request Handler Servlet, which passes the response over the Web Adapter and the Web server back to the client user. Figure 5.4.: Processing a request with pipelines, [35, p.48] Extending Enfinity using the ecapi The Enterprise Cartridge API is a bundle of interfaces and Java classes for extending existing functionality of Enfinity. Building an application using the ecapi and registering it with Enfinity, is called building a cartridge. A cartridge is an installable software module for the Enfinity business application layer, which can perform simple tasks such as adding graphical layout elements to the storefront or it can add new functionality even with integration of other applications (e.g. ERP system). Developing such a cartridge involves different aspects: on the one side the storefront development (pipelines, pipelets, services, templates) and on the other side the database access development as well as integration with third party systems using EJBs. A cartridge consists mostly of different elements: The first elements to be presented are the business components, which contain different kinds of objects that are classified by their role: Manager classes are registered as the representatives of the entire business component. All other objects within the component are accessed through these manager classes. A manager class is a session bean with responsibility for controlling life cycle of persistent data objects that are contained in the business objects of a component. Manager classes 69

70 5. Introduction of the underlying Applications also query other objects, execute complex business functions, but contain no persistent data. However, manager classes work at a higher level of the business logic and use business logic implemented in other manager classes, business objects and services. Business objects are persistent data containers for the business logic with additional functionality. Business objects are Entity Beans, which are controlled by their manager classes. Business services are elements that cover special logic and are defined through specific Java interfaces. Only a cluster of these objects and only as a group they define all aspects of a component. The next elements are the pipelines and pipelets. With a cartridge new pipelines and pipelets can be installed into Enfinity, or even, only new pipelets for the use within existing pipelines. Finally, the last elements are the EJBs, which will be accessed through pipelets when they need information from the database. Figure 5.5.: The Enfinity Cartidge API, [35, p.73]. Enfinity owns a special cartridge management implemented with the cartridge manager, which is responsible for managing all cartridges in the system, such as maintain a list of all cartridges, control the lifecycle state of all cartridges, perform a lookup for cartridges using cartridge name, maintain cartridge s configuration, or register all pipelets. Additionally, the Enfinity registry, a hub of Enfinity, can be used from all cartridge components, including services and pipelets, to locate each other. To be able to manage cartridges each cartridge implements a controller class, which contains information for the particular cartridge, including the type of business components that are contained within the cartridge. It is responsible for registering the cartridge components with the central Enfinity registry and controls the cartridge startup process. More information about the ecapi and the cartridge development can be found in [33]. 70

71 5.1. Enfinity Platform Figure 5.6.: Cartridge Management, [33, p. 26] Connecting to Enfinity using the erxi API The Enfinity Remote API is an external API for accessing data from Enfinity or inserting orders into the Enfinity system. The current version can be used for reading product or buyer information or read, write, and alter orders. The erxi supports XML encoding of Java objects as well as XML frameworks such as BizTalk and ebxml for the data exchange between Enfinity and the remote system. erxi is a simple API that can be used as a gateway for interfacing with Enfinity, but not for extending the Enfinity business logic. Thus, it is possible to integrate Enfinity in another system. Figure 5.7.: The Enfinity Remote XML API, [35, p. 72]. However, it is a framework that can be extended easily to provide additional functionality for aggregation, distribution, or exchange of different type of data. For example, it could be possible 71

72 5. Introduction of the underlying Applications to aggregate information from different Enfinity Catalog Servers of different installations for centralized usage, or maybe for the insert of an existing order from a distributor into Enfinity. Thus, erxi can be used for offering flexible mechanism for enabling automated shopping or order injection from an external source. When using the erxi, the application is usually externally compiled and runs outside Enfinity context by integrating erxi code in the external application. The erxi uses standard HTTP calls to connect to Enfinity ets and ecs in order to make a request and receive the response. The erxi uses Java objects that represent special important data objects of Enfinity such as buyer, product, which are called digital business objects. For the exchange with the Enfinity server these objects are sent with HTTP post XML-encoded, covered in XML documents. On the Enfinity server side, specific pipelines are responsible for tuning the input into correct Java objects and for processing the HTTP request. Furthermore the API provides different class types, which are introduced briefly in the following: The main interfaces and their implementations are used for writing an erxi application. For example the IConnection, IConnectionMgr are Interfaces for establishing a connection with the Enfinity servers. The IService is the basis for all erxi service interfaces such as ICatalogService (can be used to get product information). Of course, for all interfaces implementation classes exist. The digital business objects represent the data needed in the external application such as DProduct or DProductList for product data. Furthermore, Codec classes exist being responsible for de- and encoding of digital business objects from XML to Java objects and vice versa. Finally the Constant Interface holds constants needed by the erxi classes of your program and the Exception classes, implementing erxi specific errors and exceptions. Now an example follows for a better understanding of the erxi: product data is read from the Enfinity system into an external application and name and price of the products will be written to the standard output. Therefore, a special prepared test class from Enfinity (erxiexample) is shown. However for a detailed introduction in the erxi API and the given example, please refer to [34]. public class erxiexample { public static void main(string[] args) { erxiexample instance; instance = new erxiexample(); instance.execute(args); } } public void execute(string[] args) { try { /* Connect to Enfinity --- */ IConnectionMgr mgr; IConnection ecsconnection; Properties props; //create an instance of IConnectionMgr mgr = ConnectionMgr.getInstance(); 72

73 5.1. Enfinity Platform //set connection properties, required to build a connection props = new Properties(); props.put("protocol", "http"); props.put("host", "localhost"); props.put("path", "/is-bin/intershop.enfinity"); props.put("servertype", "ecs"); props.put("store", "Store"); props.put("locale", "en"); props.put("currency", "USD"); props.put("login", "MyeCSAccessLogin"); props.put("password", "MyPassword"); //create a connection object ecsconnection = mgr.createconnection("xml", props); //The key "xml" corresponds to the class RemoteXMLConnection /* Obtain a Service Object Using the Connection Object and Cast to the Specific Service --- */ ICatalogService service; // Get the catalog service from the connection service = (ICatalogService) connection.getservice("icatalogservice", null); } /* Interact with enfinity --- */ DProduct product; String login, password, pipelinename, productsku, url; // Use the login and password defined in the properties login = connection.getproperty("login"); password = connection.getproperty("password"); // Products are identified by their SKU pipelinename = "XMLProductDetails-Start"; productsku = "1053"; // Make call to service to get one product try { // Create a suitable URL, assembled from the //properties props and strings pipelinename and productsku url = " USD/XMLProductDetails-Start?ProductSKU=1053" // Request Product with SKU 1053 from enfinity CS product = service.getproduct(url, login, password); // Output product name and price System.out.println(product.getName() + ":" + product.getlistprice()); } catch (ProductNotAvailableException ex) { ex.printstacktrace(); } } catch (Exception ex) { ex.printstacktrace(); } Procurement Component in General The Procurement solution from Intershop is a complete e-commerce solution for automated electronic procurement. It is an extension for Intershop s Enfinity e-commerce platform consisting of a set of cartridges for enabling the core Enfinity to support e-procurement functionality. 73

74 5. Introduction of the underlying Applications In compound with two other business components from Intershop, the Authorization Workflow Component [36] and the Auction Component [37], this solution is able to offer a lot of additional features. First, multi vendor catalogs containing the aggregated data of several suppliers are supported beside single supplier catalogs for smart integration and management of product catalogs. Additionally, it is possible to create aggregated product catalogs on the buying side, which could be adapted to the needs of a specific group of persons inside a buying company. This group is usually subsumed as department, a representative part of the organization s administrative structure. This personal catalog is in fact only available for members of that special group. For cost control, the solution offers approval workflow and cost center definition, which are mechanisms used with flexible roles and rights assignment for monitoring and managing department budgets and order requests within a specific department. The last key features to be named should be the tendering techniques such as price negotiations, request for quotes, or auction, which are available with this solution for supporting the buy side with more sophisticated techniques for finding best offers. For more information please see [39] Procurement Component Technical Architecture This sub-section gives a short overview over the technical foundation of the Procurement solution. As mentioned before, the solution is a composition of several cartridges, extending core Enfinity functionality. This overview shows the new-added elements of the procurement cartridges and their relation to Enfinity core components. Figure 5.8.: The Procurement Solution application layer, [38, p.25]. 74

75 5.2. Tracy Starting on the lowest level of the Procurement Component new Entity Beans are introduced, which map data on special database tables created by the components (depicted in the figure as the Procurement Solution EJBs). Based on that Beans, there is a new object layer introduced, encapsulating the access to the Beans through defining model classes, clients have to use for accessing the data (Procurement Solution Object Layer in Figure 5.8). These model classes offer the ability to access even existing EJBs delivered yet with core Enfinity. The model classes are created and accessed through special manager classes, which also can refer to Enfinity manager classes. This is used more often, because Enfinity already implements basic features with own Beans or for transferring data from ecs to ets (Procurement Solution Managers in Figure 5.8). Pipelets model particular steps in the Procurement business process, next layer above. Through the underlying manager classes the pipelets can access data from Enfinity and Procurement Entity Beans. At the top of the application layers reside pipelines and templates. Here again a separated access of Enfinity and Procurement components is realized, because pipelets of both were used to use even the existing functionality. Finally, it remains to say that the Procurement Component re-purposes and modifies some Enfinity pipelines, extends business objects and introduces a lot of new business objects, for example to distinguish between specific actors such as buyer and supplier as well as new pipelines and templates for handling the extended functionality. In addition, the Procurement Component introduces some new techniques for multiple application layers. However, these changes from the standard Enfinity procedure are of more specific nature and deeper implementation details, which can be found in [38] Tracy This section introduces the Tracy mobile agent system and should give a brief insight to the Tracy infrastructure, the agent model, the agent communication, the migration, and the integration possibilities with other applications. Additionally, the software architecture of a Tracy agent server and its main components are presented with the last sub-section. The contents of this section is adapted from [9] Introduction Tracy is a Java-based mobile agent system that was developed by the software engineering team at FSU Jena during the last three years. The reason why the development of a new mobile agent system was started, although even in 1999 many systems already existed, was that none of these systems offered enough support for the main research issues the research group was interested in: migration of mobile agents. All systems available only implemented very simple migration techniques and even if they were available as source code, it would have been very difficult to implement our own ideas concerning efficient and high-performance migration. As a consequence, Tracy was developed as a complete mobile agent system, providing means for communication, security of mobile agents and servers, a graphical user interface to manage a single mobile agent server, and a technique to manage logical agent server networks. All these features are placed on top of a very sophisticated migration component. 75

76 5. Introduction of the underlying Applications From the user s perspective, Tracy was designed as a general-purpose mobile agent system, i.e. it is not restricted to any specific application domain. With the following sub-sections Tracy is introduced in an overview. Concepts and models are shown and definitions of important terms are provided. However, for a detailed introduction such as for programming agents by source code, please refer to [9] Infrastructure of a Tracy System The Tracy infrastructure consists of several platforms, on each running a Tracy agent server, which creates the environment for running several kinds of agents and offers services for receiving and sending mobile agents over the network. Each agent server is independent from the other, even though they are able to communicate with each other. The architecture of the Tracy system is, therefore, the many times repeated architecture of the singular agent server, see Figure 5.9. The agent server sits on top of a Java Virtual Machine (JVM), which is itself based on top of an operating system. On top of a Tracy agent server there can be one or many applications that use it to host application-specific agents. It is not necessary that there is a permanent connection between application and agent server. An application can start an agent server temporarily to launch agents that immediately migrate to another platform. In the same way, it is possible that an application only connects occasionally to a running agent server, e.g. to check whether new agents have arrived. If there is no application connected to the agent server, then the agent server is able to offer services on its own. An agent server has a unique name, which consists of the host name and the logical agent server name, e.g. dagobert.uni-jena.de. dagobert.uni-jena.de pluto.uni-jena.de daisy.uni-jena.de Application Application Tracy System Tracy Agent Server Tracy Agent Server Tracy Agent Server Java Virtual Machine Java Virtual Machine Java Virtual Machine Operation System Operation System Operation System Figure 5.9.: Example for a Tracy infrastructure consisting of three platforms. It is possible to start multiple agent servers on one platform by either starting multiple agent servers on one Java Virtual Machine, or starting several Virtual Machines each executing one agent server. 76

77 5.2. Tracy The Tracy Agent Model Our agent model consists of three types of agents. First, a system agent is a stationary agent that offers services related to the operating system on which the server runs, e.g. file services, printing services, etc. Second, a gateway agent, which is also stationary, is responsible for the communication to software components outside the Tracy architecture, e.g. legacy software, data base management systems, or even other mobile agent systems. The third class of agents are mobile agents that are characterized by the ability to migrate to other platforms, but have none of the above mentioned permissions. Mobile agents are strictly controlled by the agent server, so that it is impossible for mobile agents to access the underlying operating system or external software components on other than its home platform, for security reasons. In Tracy each agent has a globally, i.e. within the Tracy system, unique name as identifier and a home platform on which it was created. Both do not change after the agent was initialized once. The creation can be initiated either from outside the Tracy agent server, e.g. using the Tracy API or the graphical user interface, or from inside the server, e.g. by another agent. The execution of an agent can be suspended, i.e. stopped temporarily, and resumed, i.e. started again. An agent can be asked to quit itself, or can be killed by a user (not by other agents), e.g. if a malicious agent consumes system resources. Mobile agents can migrate to other Tracy agent servers, see Section 5.2.6, where the mobility model is presented in detail. Agents can communicate with each other either by using asynchronous messages, or by leaving information on a blackboard, see Section One of the main differences to other mobile agent systems is the fact that Tracy does not support any kind of remote communication, i.e. you cannot send messages to an agent on another agent server. This restriction comes from our interpretation of mobile agents: an agent must move to the destination platform, if it wants to communicate to other agents over there Application Integration via System and Gateway Agents As already noted in the last section, we distinguish three types of agents. Why this classification? First of all there are security reasons. Because of the ability to migrate, mobile agents are considered to be an insecure part of the agent system. So we cannot grant unrestricted access to the host. System and gateway agents are stationary agents, which are not able to migrate. Therefore, these agents are considered to be secure and they may access the host. If mobile agents need to access the host, we use stationary agents as a dynamic interface and as a security wall. They act as so called system agents. If mobile agents must be able to use local applications to solve their tasks, they may access them using gateway agents. This kind of stationary agent acts again as a dynamic interface and a security wall. However, security is not the only aspect to be considered: Gateway agents connect local applications to the agent server. The application speaks with the agent server via a gateway agent and other agents may speak with the application via a gateway agent, as well. Thus, gateway agents act also as access filters for the associated application. If a mobile agent wants to use a service of an associated application it has to communicate with the related gateway agent, and an associated application can use the whole possibilities of the agent system with the help of a related gateway agent. 77

78 5. Introduction of the underlying Applications Communication between Agents Mobile agents are a design paradigm for distributed computing, in which a mobile agent migrates to another platform to fulfill an user-defined task. This task can be done better at the remote platform or can be done only at the remote platform. The agent needs to connect to operating system services, to a database, or to another local running application at the (remote) platform. In the last section we have discussed that these services are integrated in the agent server via stationary agents. In addition, the agent server can provide more services by simply running more stationary agents. Thus, the mobile agent must be able to communicate with system and gateway agents to do its job and to get access to any information. In Tracy, agents may communicate with each other directly. This is done using asynchronous messages and not via direct method calls between agent objects. The latter effects an agent in a direct way, which is a contradiction to the concept of agent autonomy. Thus, in Tracy, messages which will be exchanged between agents are like mails. All of the three types of agents can exchange these mail-messages. Every agent has a mailbox in which new mails are stored. The agent can decide on its own how to handle these mails. It can decide to accept mails or not by closing its mailbox (even temporarily). Thus, the autonomy of an agent can be preserved. To send a mail-message the agent needs to know the name of the receiving agent. The reader could have the impression that we provide also remote communication. However, Tracy does not support any kind of remote communication, i.e. an agent cannot send messages to another agent residing on a different agent server. Even, if both agent servers were to reside on the same host sending mails between them would not be possible. This restriction is a result from our interpretation of mobile agents: an agent must move to the destination platform, if it wants to communicate to other agents overthere. Remember that local applications can send and receive messages via gateway agents only. Another feature is that the user can send messages to agents by using the Tracy GUI (for detailed information see [9]). Agents can communicate with each other not only by using asynchronous messages. Communication is also possible by leaving information on a blackboard via an interface integrated in the Agent Manager. In this second kind of communication, which is an indirect one, the agent puts some information on the blackboard like an announcement in a newspaper. Other agents can read this announced information from the blackboard via a symbolic name. The blackboard is another basic approach to provide information deposited by an agent, by the agent server, or by an application. For example, the agent server deposits information on the blackboard about services provided by the server. The blackboard is a mean to provide persistent data, too. The blackboard itself is organized like a file system there are directories and files. A directory is a container for files and other directories, where as files can only contain data of some specific types, like plain text, XML, HTML, graphic files, etc. Each entity might have an owner who defines grants to other agents to read or write this item. Besides reading and writing blackboard entities, directories and files can be observed by agents. An agent will be informed about any change of the observed entity by a message. An agent can become active when a specific blackboard entity has changed its value. Other events are adding and deleting blackboard entities. Remember that local applications can only write and read information from the blackboard via gateway agents. By these two kinds of communication, by messages and with the use of the blackboard, we have a loose coupling between agents, between agents and the agent server, and between agents and associated applications. The user (via the graphical user interface), or an associated application can use messages to communicate with agents and so agents can also receive commands. 78

79 5.2. Tracy There are also broadcast messages which can be sent by the GUI for administrative purposes and by the agent server for system state propagation, e.g. send a system failure using a broadcast message Agent Migration In the Tracy model, only the mobile agent itself can initiate the migration process by invoking one of the go -commands, which will be explained later. To provide some kind of agent server initiated migration, Tracy includes the following concept: each agent has the ability to react to incoming messages, dispatched from other agents or the agent server itself. A mobile agent may receive a message with the suggestion to leave the platform, e.g. in case of system failure. It depends on the agent s programmer, whether he cares about those messages or not. Only the agent server is allowed to send such migration invitations. From the programmer s viewpoint, Tracy currently offers a weak form of mobility, in which an agent can start a migration by a go -command that is parameterized by the name of the destination platform and the name of the method that should be invoked next. A mobile agent can use one of the following commands to start the migration process: 1. go( destination, method ), as described above, 2. go back( method ), initiates a migration back to the last platform the agent came from, and 3. go home( method ), initiates a migration back to its home platform. As already said, the mobile agent can also influence the migration strategy, and the transmission strategy that should be used for the next transfer. A mobile agent can define a default migration strategy and a default transmission strategy that will be applied for each migration. Both can be declared by optional parameters of the go-commands (for more information, please refer to [9, 10]). If the agent could not be transmitted successfully to the destination platform, the agent is reactivated on the origin platform and a pre-defined method with name migrationfailed is invoked. In the Tracy model, only the mobile agent itself can initiate the migration process by invoking one of the denoted go-commands The Architecture of a Tracy System We will now have a look at the overall architecture of an agent-based system. An agent-based system is a host that uses a Tracy server as a substantial component to offer services to external agents, or consumes services of other agent servers using their own mobile agents. Different types of agent-based systems are distinguished by the way the agent server is connected to other applications on that host. The following two examples present hosts on which an application uses an agent server to offer services to foreign agents, or use services of other agent servers using their own mobile agents. It is the privilege of applications to start gateway agents (see Section 5.2.3) that are able to offer services within the agent server and direct requests to the connected application. In the first case, there is an application written in the Java programming language that accesses a Tracy agent server using the Java Remote Method Invocation (RMI) technique. In this case, application and Tracy agent server are loosely coupled. The only connection is established by 79

80 5. Introduction of the underlying Applications method calls using the Tracy Remote Interface. This interface defines methods to control and monitor an agent server to other java-based applications. In the simplest case the application resides on the same host as the agent server. However, it is also possible that application and agent server reside on different hosts. To protect an agent server against applications, basic security checks are already implemented. Please refer to [9] for more information on the Tracy Remote Interface. In the second case, the coupling between these components is very strong. In this case the Tracy agent server is an embedded software component within an java-based application. The application uses directly the Tracy API to control the agent server. The Tracy API is detailed described in [9] The Software Architecture of a Tracy Agent Server This section provides an overview of the software architecture of a Tracy agent server. The agent server has a three layer architecture, see Figure As in the ISO-OSI architecture model, this makes higher level services independent from lower level, network oriented services. Each higher level builds on the services of the lower level, treating it as a black box with defined interface and services. Layers are, thus, exchangeable components in a framework and allow for adaptation and portability. In the following three sections we describe each layer with its main components and the task it has to fulfill within an agent server. The last section in this chapter deals with an agent server s component that is vertically spread over all three layers. This component has the function to summarize logging messages and direct them to various output devices. Agent System Layer The Agent System layer (ASL) is the upper layer of Tracy. All agents are managed within this layer. Therefore, the Agent System layer has to provide modules for controlling agents and for agent communication. All tasks related to mobile agent migration are delegated to the Package Manager layer that is arranged below. A detailed description of the ASL can be found in [9, Sec. 8.2]. As shown in Figure 5.10 it is distinguished between agents that are currently active (drawn as circles) and agents that are temporarily suspended (drawn as boxes). There exists an execution thread for each active agent, whereas suspended agents are just passive objects that are waiting to become awake again. Only active agents can communicate to the main component within this layer, i.e. the Agent Manager. The communication to the Agent Manager is controlled by an interface for each type of agent. By this it can be ensured that agents of a specific type can only access those Agent Manager services that they are allowed to use. Suspended agents cannot communicate to the Agent Manager. The Agent Manager is the core component within this layer and manages the communication between specialized sub-components. The Agent Manager serves like a facade according to the facade design pattern described by Gamma [25]. For an agent is acts like a single object which offers various services. Behind the facade it works like a manager and delegates tasks to specialized sub-components. Using a facade at this point gives the opportunity to exchange sub-components easily. All agents residing in the agent server are registered in the Agent Directory under their unique name. The Agent Directory ensures that no two agents with identical names are started at one 80

81 5.2. Tracy server at the same time. Whenever the Agent Manager needs to direct requests to a specific agent, it has to ask the Agent Directory for a reference (in the meaning of the Java programming language) to the corresponding object. Each agent is registered in the Agent Directory when it is started on the local host. It makes no difference whether the agent is started locally by the user (or an application etc.), or has migrated to the local agent server. The Agent Directory s entry exists for the whole agent s life-time on the local platform. Even when the agent is suspended, the entry remains active. When an agent is killed, dies, or when it leaves the server by migration, the Agent Directory entry is deleted. The Blackboard component is responsible for all services concerning to the blackboard functionality described in Section All agent-to-agent communication is managed by the Inter- Agent Message Handler (IAMH) component. An agent has to address messages to other agents via their name. The Agent Manager forwards message request to the IAMH which manages message spooling and their delivery. Messages are deposited in a message queue for each agent. The Migration component is responsible to send a mobile agent to a remote agent server. It uses the Package Manager for this task. In the case of a migration failure it informs the Agent Manager to restart the agent. Package Manage Layer The Package Manager layer (PML) is the intermediate layer in the agent server architecture. The PML is responsible to manage the whole migration process of a mobile agent. If an agent wants to migrate, the ASL uses services of the PML to initiate the migration process. The PML gives feedback to the ASL whether migration was successful, or not. It uses the underlying Net layer (see the following section), to transmit data via a network to a remote agent server. In case of an arriving mobile agent, the PML receives the agent from the Net layer in pieces according to our mobility model in [9, Sec ]. The PML is responsible to compose the pieces and inform the ASL to start the agent. A detailed description of this layer can be found in [9, Sec. 8.3]. The PML itself has a three-layer architecture. The upper layer is the Package Manager which is responsible to delegate the whole migration process. It uses the Agent Package Manager component and the Migration component for specific tasks. The mobility model is implemented in the PML, so this layer handles mobile agents in form of mobile units, state objects, and data items. The management of those pieces is done in the Agent Package Manager component, whereas the process of migrating units and data with different migration strategies is placed in the Migration component. For each mobile agent there exists an Agent Package Manager (APM) that maintains the agent s data and its mobile units during the entire life-time. Such an APM exists on the home platform as well as on the platform the agent actually resides at. In contrast to an Agent Directory entry in the Agent System layer, the APM is not deleted automatically when the mobile agent leaves a platform. On the agent s home platform the corresponding APM exists during the whole agent s life-time, even if the agent is currently not active on the home platform, Mobile units or data can be downloaded from this platform. All APM objects are managed by the Agent Package Manager Directory in which a reference to each APM is stored under the agent s name. The Migration component is responsible to migrate a mobile agent according to a specific Migration Strategy. As described in Section the mobile agent can choose by which strategy it wants to migrate by a name, e.g. ACTIVE. The Package Manager component uses the Strategy Factory to obtain a specific Migration Strategy object according to the given name. 81

82 5. Introduction of the underlying Applications The Migration Strategy decides which mobile units and which data items must be transmitted to which destination platform and generates a script in the Migration Definition Language (MDL) language. This script is executed by the MDL Engine and conducts the complete transmission process. For this task it uses the Transmission Manager, which establishes the connection to the Net layer. Net Layer The Net layer (NL) is the lowest layer in the agent server architecture. Agent servers communicate using this layer and exchange data. The Net layer is used by the Package Manager layer to execute specific communication tasks, e.g. to transmit a set of mobile units, together with the state information. Transmitting of data, i.e. an agent or only state information, is always done by only one call of the NL. When a transmission error occurs it gives notice to the Package Manager layer about this. In the case of an arriving agent the NL is responsible to receive all transmission pieces and prepare them to get processed by the Package Manager layer. A detailed description of the NL can be found in [9, Sec. 8.4]. The Net Manager component within this layer defines an interface for the specific communication tasks mentioned above. For the network transmission it uses an own transmission protocol, named Simple Agent Transmission Protocol (SATP) which is implemented in the SATP Engine. For the real network transmission the SATP Engine uses specific network transmission components. Each transmission component corresponds to one transmission strategy. Currently there exist two transmission components, i.e. TCP Transmission and RMI Transmission. The first one uses raw TCP/IP communication to transmit data, whereas the second uses the Java Remote Method Invocation technique to do so. Next versions of Tracy will include more sophisticated transmission techniques, e.g. secure transmission using Secure Socket Layer, or compressed data transmission. Monitor The Monitor component of the Tracy software architecture is vertically spread over all three layers mentioned above. The Monitor component is not pictured in Figure 5.10, because it does not have to exist always. A detailed description of this component can be found in [9, Sec.8.5]. The Monitor component is associated to each of the above mentioned layers and is responsible to collect logging messages and forward them to specific user-defined output devices. Within each layer logging messages are produced for a variety of reasons, e.g. when an agent migrates, or an agent arrives. Most of theses logging messages are only of interest for people who want to trace the agent server. Each logging message is typed, i.e. messages are grouped and named. Using this type information, a client can filter interesting messages, e.g. messages of a specific component. 82

83 5.2. Tracy Mobile Agents Gateway Agents System Agents Suspended Agents Agent System Layer Tracy Agent Server MobileAgentInterface Agent Directory GatewayAgentInterface Blackboard Agent Manager SystemAgentInterface Inter-Agent Message Handler Migration Manager Package Manager Layer Agent Package Manager Unit Data State APM APM Directory Package Manager Strategy Factory Migration Strategy MDL Engine Migration Transmission Manager Net Transmission Layer Net Manager Simple Agent Transfer Protocol (SATP) Engine TCP Transmission RMI Transmission TCP + SSL Transmission TCP + ZIP Transmission Figure 5.10.: Overview of the Tracy architecture. 83

84 5. Introduction of the underlying Applications 84

85 6. InterMarket Feasibility Study This chapter contains the feasibility study for the InterMarket approach. It surveys, whether the combination of both applications is suitable for realizing an agent-based e-marketplace, which were introduced in chapter five. Thereby, this chapter follows the structure from Chapter 4. Thus, it starts with validating the agent-based functionality followed by a section, which covers the non-functional behavior of an InterMarket system. The study checks foregrounding the feasibility for every indicated feature. However, if options or variants exist for a specific requirement, all alternatives were discussed. Please note, that this study only tests the capabilities for combining the given two solutions. It does not design a concrete realization of InterMarket at all Agent-based Functionality The Configure Agent Usecase The validation of this usecase has to be distinguished into four scenarios according to the scenarios, which were specified in the configuration usecase model in Section Scenario 1: A user configures a mobile agent via the application server In this scenario a mobile agent will be configured by a user for performing actions not only on a current marketplace, which the user is logged in. Thus, a user interacts with the InterMarket application server via his Web browser to create and configure a mobile agent. For example, the user fills a set of forms with information, which specifies agent type, tasks, task data, and optional a migration route. The user triggers a pipeline inside the application server with a final confirmation of his actions, which is executed following the mechanism that is described in Section One of the pipelets inside the pipeline starts a remote communication to a Tracy agent server for sending a creation message for a mobile agent including configuration data. The agent server confirms the request and the execution of the agent with a response to the pipelet, when it is able to ensure transactional behavior (e.g. after an intermediate save or maybe even after migration of the mobile agent). The concrete proceeding of the communication between Tracy and Enfinity is described in detail in Section Of course, the user is informed by the executed pipeline that his order was started. Scenario 2: A user configures a stationary agent via the application server This scenario is processed similar to Scenario 1. The difference between both is that in Scenario 2 the user configures a stationary task agent to perform agent-based tasks on the current e- marketplace. Again, the user interacts via storefront requests with the application server of InterMarket. A pipeline is triggered, which contacts an agent server for sending the configuration 85

86 6. InterMarket Feasibility Study data and receiving the confirmation message. Finally, the pipeline informs the user that his order was correctly placed in the system. Figure 6.1.: A user configures a mobile agent via the application server. Scenario 3: A user configures a mobile agent via a client agent server This scenario occurs, if a user tries to access InterMarket using mobile agents from a mobile device or a stationary client host, which runs an agent server. Access to that local agent server can be established using several techniques such as Web browser (maybe with a plug-in), a special GUI application (covering the agent server as component or getting remotely contact via the Tracy Remote API), or remotely from an existing application (e.g. ERP software). Thus, after having established a connection to the agent server, the user is able to use functions of it for creating, configuring, and starting mobile agents. Scenario 4: A mobile agent configures a stationary agent on the marketplace This is the simplest scenario. A mobile agent, which resides on an agent server of an e- marketplace, contacts a stationary task agent using the mechanism depicted in Figure 4.3. After the mobile agent has received a unique ID of a stationary task agent from the manager agent, it is able to interact with the stationary task agent directly via sending messages. Thus, the mobile agent can configure and start the stationary task agent The Migration Usecase Migration of mobile agents is a key feature of the Tracy agent system and is already completely implemented. Tracy also offers an approach for managing agent networks with a special concept introduced in [8] for ensuring efficient and correct migration routes The Perform Tasks Usecase The feasibility of this usecase is presented with several models regarding to sub-usecases in Section Main goal of this InterMarket functionality is the intensive reuse of business logic and workflow in the Enfinity subsystem. The feasibility of the sub-usecases will be presented in the following paragraphs. 86

87 6.1. Agent-based Functionality However, it must be mentioned that Tracy agents currently do not implement a workflow engine or something similar. Thus, Tracy must be extended to implement the indicated mechanism for a successful realization of InterMarket. Agent-based search A stationary agent, which is correctly and completely configured, performs a search task by simply simulating a storefront request to the Enfinity subsystem of InterMarket, as denoted in Section The agent waits after sending its request until it receives a response. The response will be send by the application server after it has finished its database query. Now the agent can store and evaluate the result data. This scenario introduces good reusability of the Enfinity business logic for database searching. Agent-based Compare In this task, the stationary task agent performs independently the necessary calculations. Thus, this usecase is absolutely feasible. There exists no problems, except some implementation effort. Agent-based Order The agent-based order usecase can be processed absolutely similar to the agent-based search. Again, the stationary task agent simulates storefront requests (see Section 6.2.1) and waits until the application server has responded. Agent-based order provides a good reusability of Enfinity business logic for placing orders. Agent-based Request This task splits into two scenarios. Scenario 1 describes the activity, if a stationary task agent places an offer request in the system. This can be realized by the agent simulating a simple storefront request (see Section 6.2.1). The task agent sends offer request data to the application server for storing it in the database. Existing business logic of the Procurement solution can be reused for this step. After placing the data in the database, another sub-pipeline must be started that tries to inform the requested user via , SMS, or a special message information, which is stored in the database, if the user is inactive on the marketplace or via a special onscreen message, if the user is active. Finally, the main pipeline, which was triggered by the storefront request of the agent returns a confirmation response to the stationary task agent. The offer request data was send together with a unique reference (agent name + agent server name) from the agent to the application server for enabling the application server to send offers referring to the agent s request back to the task agent, which waits on the agent server. Scenario 2 describes the situation, if the agent receives offers from the requested marketplace participants. Therefore, a pipeline is triggered by every responding user, which places a response according to the offer request in the InterMarket system. Inside this pipeline, a pipelet opens a connection to the agent server (which hosts the agent) and sends offer data to the agent. This proceeding is executed following Section for the Enfinity to Tracy direction. Finally, the agent sends back a confirmation response. Thus, the pipeline is able to create an output to the user, that his offer is correctly stored. Agent-based Auction A main primitive of InterMarket is to reuse existing mechanisms. Therefore, the auction mechanism of the Procurement solution (see [37]) should be the foundation for agent-based auction 87

88 6. InterMarket Feasibility Study bidding. Thus, auctions will be handled inside the application server and agents have to use the following indicated mechanisms to participate in auctions. In addition, in this version of InterMarket only human user should be able to start auctions. The auction bidding for agents can be divided into three steps. The first step is to place a starting bid after finding a suitable auction. This process can be similarly done like normal users do, by simulating a storefront request (see Section 6.2.1). Thus, a bidding object will be placed in the application server of InterMarket covering all bidding activities of the agent within the named auction (see [37]). The second step for the agent is to observe the auction status, which means a periodically examination of the auction parameters. However, the InterMarket approach and the Procurement solution Auction Component [37] offer several possible mechanisms for doing that. An agent sends periodically storefront requests to the InterMarket application server for receiving auction data. This approach offers the disadvantage that in case of a high number of bidding agents the performance of the InterMarket system decreases noticeable. Enfinity offers the opportunity of scheduled pipelines, which are automatically invoked by the system after certain time periods. Thus, it could be used, if agents place their bidding object from step 1, and register them with a special instance in the system. A scheduled pipeline can periodically read the auction status and sends this data to all registered agents. This proceeding is similar to the AutoBidder mechanisms of the Auction Component [37, Ch. 3]. The Auction Component offers users the ability to perform real time auctions using applets. This applets, however, do not send storefront requests. Instead they read a special file on the Web Server, which pools always the current auction data [37, Ch. 3]. This mechanism could be copied by agents. Agents can read periodically this special file for being up to date. A last approach is to simulate the Auction Watcher mechanims from Auction Component [37, Ch. 3]. Here, a scheduled pipeline checks all AuctionWatcher objects and informs the corresponding users, if a special event occurs such as auction starts, ends, or a special price is reached. Thus, agents could place similar objects, with additional information about events, which an agent wants to know for an auction, in the application server and get then messages from the scheduled pipeline, when a special event is released. This approach is relatively similar to A, but it reuses some more existing business logic. The third step is to evaluate currently received auction parameters. Therefore, agents process a special bidding logic, which was set up with parameters by the configuring user before. Thus, agents act on behalf of their users briefing. In case of an active auction and the necessity for setting a new bidding, the agent uses the storefront request mechanism for placing a new bid in the corresponding bidding object in the application server of InterMarket. This process is again performed using the mechanism, which is described in Section If an auction is finished or cancelled, the agent can read this from the auction data it has received in step two and can following store the auction end data in its private repository and can finish its auction bidding task. In the agent-based auction functionality remains one big problem. How could all participating agents fairly treated? It is a performance and schedule problem to ensure that all bidding agents were informed about changes in the auction in parallel. 88

89 6.1. Agent-based Functionality Agent-based Negotiation With InterMarket, price negotiations will be implemented reusing existing functionality of the Procurement solution (see [38, 39]). The agent-based negotiation mechanism is very similar to the request mechanism described above. The only difference is that in agent-based negotiations the offer requests and offers will not be exchanged only one time, but multiple times in an iteration process. Thus, the two steps from the agent-based requests functionality will be multiple executed. The first step is absolutely similar except the data, which is exchanged. The agent places a negotiation request in the system via simulating storefront requests and reusing then functionality of the Procurement solution for placing negotiation requests in the system. The second step differs a little bit. After the waiting agent has received a negotiation response from the negotiation partner via the application server, it does not finish execution, but performs a special intelligent logic for determining, whether it wants to place a new negotiation request or not. With this mechanism another iteration can be triggered in the negotiation process, which again starts with step one. It is also possible to assign stationary task agents to react on a negotiation request via the application server. However, the proceeding of this scenario does not vary from the one, which is indicated above. Following, agent-to-human and agent-to-agent negotiations are possible. The negotiation process is observed and mediated by the application server, which introduces a consistent approach. Thus, it is absolutely transparent for a negotiation partner (agent or human) with whom it interacts. This approach offers the advantages of the application server such as reuse of transactional processing (ACID), security, and reliability. Because in every iteration step the pre-contracts (request and response) of the two negotiating parties are stored in the InterMarket database, the ability to manipulate negotiation contracts and results is taken from the participants of a negotiation process The Return Results Usecase The feasibility of the return result usecase is presented with some different scenarios, according to the scenarios from Section Scenario 1: A stationary agent returns results to a mobile agent This scenario is simple and can be realized just by sending messages from one agent to another. Because the mobile agent has configured the stationary task agent before, the task agent has a reference to the mobile agent for contacting it. Scenario 2: A stationary agent returns result to a user via the application server For fulfilling this task, the agent again uses the storefront mechanism. Because the agent owns a reference of the user, which it has received during configuration, it is able to trigger a pipeline in the application server. This pipeline will store the information in the database using the unique reference and will try to inform the user, which has started the agent-based task before. More detailed, a sub-pipeline tries to inform the user. If the user is active, it sends a onscreen message or, otherwise, the pipeline can generate an or SMS. Finally, the pipeline returns a response to the agent to confirm the proceeding. Scenario 3: A mobile agent returns results to a user via application server This scenario can be implemented similar to Scenario 2. However, the stationary task agent 89

90 6. InterMarket Feasibility Study from scenario 2, which sends the result data to the application server, is configured and started to do that task by a mobile agent. The confirmation send back from the application server to the stationary agent will be mediated also to the mobile agent. Thus, the mobile agent is able to return results back to a user. Figure 6.2.: A stationary agent returns results to a user via application server. Scenario 4: A mobile agent returns results to a user on a mobile device Returning results on the client side of InterMarket using mobile agents is no problem. Depending on the kind of application using a Tracy mobile agent server, the results will be returned. This can be implemented using the following approaches: 1. Use the Tracy Remote API, which offers services, where listeners can register themselves for being informed in case of special agent-mediated events (e.g. a mobile agent has returned). 2. Asynchronous communication between the mobile agent and the calling application. The agent places its information on the blackboard and the application is responsible for reading the data from there. This could be done using a specific key word on the blackboard. For this, the mobile agent has not to authorize a stationary agent. 3. The mobile agent sends the results to a special stationary agent, which holds a connection to the client application and can mediate the result data to the application Non-functional Behavior Integration of Agent Server and Application Server Both applications are platform-independent, because of being built with the Java programming language: Tracy (J2SE version 1.2), Enfinity/Procurement(J2EE version 1.2). Both solutions offer support for different operating systems: Tracy (Win9x, NT4.0, Linux, Solaris (Sparc), Tru- Unix 64/OSF4 (Alpha)), Enfinity (W2k, Solaris, NT4.0, HP-UX). Therefore, both applications could be fully integrated. However, as we will see in the following section the integration between Tracy and Enfinity can be realized only with a remote connection. 90

91 6.2. Non-functional Behavior Enfinity offers two possible approaches for integrating with it. The first is to use the erxi API, which is introduced in Section The erxi API offers access to Enfinity for using a limited number of functions in the standard version. For sophisticated remote access to application server functionality the API offers some interfaces and classes for extending the remote API and adapting to project needs. The API simply uses HTTP requests which will be routed via the Web server to a proper application server of Enfinity following the process described with Section However, this API was designed for cross-server calls inside the Enfinity system and does not use the normal Enfinity processes for performing tasks. The second possible way to access Enfinity is to simulate normal storefront requests using HTTP requests, which will be send to Enfinity Web servers. Enfinity is optimized for handling such requests and is able to produce fast responses. Thus, you can send data and the name for a special pipeline to Enfinity for performing tasks with the data and receiving suitable results. For the integration with other applications Enfinity offers the ecapi introduced in Section Thus, it is possible to implement new functions in Enfinity, which can access Tracy and can use software agents. Tracy offers a remote API for the remote access to Tracy. With this, you can create, configure, and start agents and you can react on events, which are triggered by agents. Currently, this API uses RMI. A high integrative way for integrating Tracy is to use Tracy as a component within Enfinity, but how we will see, it is not possible with InterMarket. For the integration of other applications with Tracy, Tracy offers stationary agents. With these agents you can integrate with any application, which offers remote access by an API or a special external connector program (Web Service). Now let us look at the communication between Tracy and Enfinity. Both applications interact using remote access to the other. First we start with the Tracy to Enfinity direction. It is recommended to simulate simple storefront requests using HTTP from agents, because it offers the following advantages: Enfinity is optimized for processing storefront requests (see Section 5.1.5) and offers that way the reuse of session and transaction management of Enfinity without programming effort for ensuring transactional processing, reliability, security and data integrity on the application server, the approach provides the reuse of several existing business logic in Enfinity/Procurement, there exist no restrictions of the erxi, the integration can be adapted to special needs, it keeps InterMarket simple and fast. In Figure 6.3 a communication process between a Tracy stationary agent and Enfinity is presented. Stationary agents are able to send requests and receive responses autonomously, which could imply advantages for scalability of the connection (a central point that is mostly a problem, does not exist). The agent retrieves information about a proper Enfinity URL from a database or the blackboard inside the agent system. After the agent has all necessary data for performing the request, it is able to establish an HTTP connection to the Enfinity Web server. This could be simply done by using a Java Socket class, Java URL class, or Java URLConnection class. The agent sends an HTTP request to the Enfinity system and waits for response. Inside Enfinity the request is executed such as any storefront request. The final step in the pipeline produces the response that way, that the agent can retrieve information from it, for example by using XML 91

92 6. InterMarket Feasibility Study or a special XML dialect such as ebxml or BizTalk. When Enfinity sends back the response and the agent has received it, the agent can process the data from the response, close the socket (connection), and continue with the execution of its code. Figure 6.3.: Communication from Tracy to Enfinity. After developing a possible scenario for the Tracy to Enfinity communication, we now look at the reverse direction (Enfinity to Tracy). Here you can find three approaches, which will be introduced briefly in the following. The first approach realizes access from Enfinity to Tracy using HTTP request. Users send storefront requests to Enfinity. One of those requests starts a business processing, which includes agent-based tasks. Therefore, in Enfinity it is possible to open a socket from inside a pipelet for performing a request (similar to agents). The pipelet receives the information for the connection from the data dictionary. The Tracy agent servers implement a mechanism, which enables them to receive such requests and to perform the wished action such as creating, configuring, and starting an agent. After the agent server is able to ensure correct execution of the given tasks or after processing the task it sends back a response to the waiting pipelet. In Enfinity the processing follows Section and produces finally a response for the users, which started the whole process before. This approach has the advantages that it ensures a consistent communication protocol for both directions of the communication and that the data objects to be exchanged have to be designed only with one shape. Additionally, it offers good capabilities for load balancing and scalability mechanisms in Tracy for multiple agent servers, because it is simple. The second approach is similar to the first. However this uses RMI from inside EJBs. RMI connections should be reusable because they are expensive (when they will be opened and closed periodically) and that is why they will be accessed from pipelines out of EJBs. Beans encapsulate the remote execution and only return back results to the calling pipelets. Thus, the Proxy objects for agent servers (in the beans) can be shared by multiple pipelines and sessions. However, the rest of the execution of an agent-based task using Enfinity to Tracy communication is performed similar to the Figure 6.4. Advantage of this approach is the reuse of the existing remote API of Tracy, but it leads to a design of multiple different data objects for both directions of the communication and represents no consistent communication pattern between Tracy and Enfinity. 92

93 6.2. Non-functional Behavior Figure 6.4.: Communication from Enfinity to Tracy of the first approach. The third approach is only for completeness. Tracy is a compact application, which can be integrated in other applications as a component. Thus, agents can be managed with normal Java method invocations, which use Tracy as an object of the application. This has to be done in an EJB in Enfinity because only here Tracy would be accessible for multiple pipelines and sessions. But this is not possible, because the agent server performs tasks, which are not allowed inside an EJB container such as thread management. Additionally, this approach would not be scalable and would provide low performance, because of: 1. cross-server calls inside Enfinity from one of the both servers (ecs, ets) to the other, if it takes usage of agent-based functionality, 2. too many threads on one machine if the number of agent increases, 3. the Tracy server would need the whole machine power and the Enfinity system would crash. Agents often perform time consuming tasks, so that it is recommended that Enfinity does not wait for the results, because of system performance (too many parallel threads). Thus, synchronization could be done using the database of Enfinity. If agents have fulfilled a task they send a storefront request to Enfinity for sending the results. The results will be stored in the database and a sub-pipeline tries to inform the user. If the user is online this can be done with an onscreen message, otherwise Enfinity can use or SMS. For giving the user the possibility to access the results, these results are stored yet in the database. Another requirement is that Tracy, Enfinity, and their connection scale for being able to adapt to any performance and scalability demands. Enfinity fulfills this requirement and as mentioned with the approaches for bi-directional communication the connection between Tracy and Enfinity, too. However, Tracy does not fulfill the requirement. In [8] an approach is presented for managing agent server clusters, which can be extended for load balancing and scalability needs. Therefore, in the following scenario a gateway server is introduced, which can manage multiple other agent servers. Another advantage can be, that incoming mobile agents have to authenticate only at the gateway server, which will be routed without additional time-consuming security checks in the agent server sub-net. 93

94 6. InterMarket Feasibility Study Figure 6.5.: Scale communication between both InterMarket sub-systems. As Figure 6.5 shows, not only Enfinity, but also the Tracy sub-system has a 3-tier architecture. The architecture of Enfinity is clear (see Section 5.1.2). In Tracy, there is a gateway agent server (similar to the Web server from Enfinity), which is responsible for receiving and distributing incoming mobile agents from the Internet as well as requests from Enfinity servers onto the agent server sub-net. The agent servers from the sub-net are a kind of server cluster for a scale distribution of the workload. In the back-end of the Tracy sub-net exists a database, which is responsible for persistence and reliability of the agents and their execution. Because this is a central point in the system and agents will be executed transaction-based, a session failover becomes possible. If one agent server fails, another will take over and can continue agent execution. Both sub-systems will interact with the other via the defined entry points of each system (Web server, gateway agent server). Thus, both InterMarket sub systems scale to any demands. Conclusion 1. Tracy interacts with Enfinity simulating storefront requests using HTTP. Stationary tasks agents implement sockets (Socket, URLConnection) for autonomously communicating with Enfinity. 2. Enfinity interacts with Tracy either using the remote API of Tracy with RMI or a HTTP connection, which has to be implemented an analysis must be done to decide, which risk is better to solve. Enfinity, therefore, communicates with Tracy from sockets inside pipelets or with proxy objects from inside EJBs. 3. Tracy has to realize a scalable architecture. Therefore, Tracy must be reworked to adapt to a three tier architecture, with scaling tiers. If all points are fulfilled, InterMarket can be realized with an architecture, which is presented with the follwoing Figure