integrating mobile agent technology into an e-marketplace solution

Integrating Mobile Agent Technologyinto an e-Marketplace Solution

- The InterMarket Marketplace -

Friedrich-Schiller-University JenaComputer Science Department

Ingo Muller, Peter Braun, Wilhelm RossakFriedrich-Schiller-University JenaComputer Science Department

Ernst-Abbe-Platz 1-4D-07743 Jena, GermanyTel. +49 (0)3641 / 946331Fax. +49 (0)3641 / 946302

E-Mail: [email protected]

Abstract

E-marketplaces are trading platforms that offer e-commerce online trade between several buyingand selling companies. They enable good trading possibilities by supporting different businessmodels such as multi-supplier catalog-based e-sales and e-procurement, pinboard or exchangesystem as well as several types of auctions. E-marketplaces give their participants the abilityon the one side to acquire new trading partners or even new markets and on the other side tosimplify their procurement and sales processes for reducing costs. This sector of e-commerceis growing rapidly and is predicted to reach 37 percent of overall e-commerce, generating totalrevenues 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 tobring different trading partners together. However, the requirements on e-marketplaces alreadyincreased within this phase. Companies demand additional features for lowering costs and forautomation and optimization of their business processes. According to this, the ostensible taskfor e-marketplaces in the second phase from 1998 to 2001 was to offer more value adding ser-vices through intensively support the value chain such as with offering services for initiation,fulfillment, and completion of trading transactions including shipment, payment and logistic ser-vices. Nevertheless, today’s e-marketplaces lack of fully automated business processes and stillrequire a significant manual effort by human users.

The mobile agent technology might take e-commerce trading to the next phase. Mobile agentsare intelligent, independent, and pro active electronic representatives of businesses such as buy-ers, suppliers, customers, or even whole companies which can relieve marketplace participantsfrom lots of routine works. The mobile agent technology can be a suitable approach for resolv-ing the given problems. On the one hand intelligent stationary agents add automated tradingcapabilities and intelligent negotiation models for example for auctions, request for quotes, andrequest for proposals and on the other hand mobile agents can easily offer connections to mobiledevices such as personal digital assistants or mobile phones.

Besides, mobile agents add even more business opportunities because they can represent acompany on different marketplaces everywhere in the world at the same time without humaninvolvement. 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-marketplacecalled InterMarket, which integrates the mobile agent technology. A feasibility study, made fortwo existing software applications, the mobile-agent system Tracy and the e-commerce plat-form Enfinity, investigates the ability to combine both solutions to form the new agent-basede-marketplace. In conclusion, recommendations are made for not yet fulfilled features to reachthe identified requirements. Finally, a general architecture should be the foundation for furtherrefinement and for a possible research project.

3

Contents

1. Introduction 91.1. Structure of the Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . .101.2. Requirements for Reading this Document. . . . . . . . . . . . . . . . . . . . . 10

2. InterMarket Foundations 112.1. E-Marketplaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

2.1.1. Definition of E-Marketplaces. . . . . . . . . . . . . . . . . . . . . . . . 112.1.2. Transaction Functionality. . . . . . . . . . . . . . . . . . . . . . . . .122.1.3. Fulfillment Functionality. . . . . . . . . . . . . . . . . . . . . . . . . .152.1.4. Integration Capabilities of E-Marketplaces. . . . . . . . . . . . . . . . 152.1.5. Information Providing. . . . . . . . . . . . . . . . . . . . . . . . . . .162.1.6. Additional Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.1.7. Consulting Function. . . . . . . . . . . . . . . . . . . . . . . . . . . .162.1.8. Overall E-Marketplace Architecture. . . . . . . . . . . . . . . . . . . . 17

2.2. Mobile Agent Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.2.1. Definition of Mobile Agents. . . . . . . . . . . . . . . . . . . . . . . . 202.2.2. Mobile Agent Environment . . . . . . . . . . . . . . . . . . . . . . . . 212.2.3. Migration of Mobile Agents. . . . . . . . . . . . . . . . . . . . . . . . 222.2.4. Advantages of Mobile Agents. . . . . . . . . . . . . . . . . . . . . . . 232.2.5. Problems with Mobile Agents. . . . . . . . . . . . . . . . . . . . . . . 24

3. InterMarket Objectives 273.1. Motivation for a New Marketplace Solution. . . . . . . . . . . . . . . . . . . . 273.2. Main Objectives of InterMarket. . . . . . . . . . . . . . . . . . . . . . . . . . .273.3. Overall Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313.4. Why using Mobile Agents?. . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

4. InterMarket Requirements 374.1. Agent-based Functional Requirements. . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1. Actors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374.1.2. The Main Usecase Model. . . . . . . . . . . . . . . . . . . . . . . . .404.1.3. The Configure Agent Usecase. . . . . . . . . . . . . . . . . . . . . . . 434.1.4. The Migrate Usecase. . . . . . . . . . . . . . . . . . . . . . . . . . . .444.1.5. The Perform Tasks Usecase. . . . . . . . . . . . . . . . . . . . . . . . 454.1.6. The Return Results Usecase. . . . . . . . . . . . . . . . . . . . . . . . 53

4.2. Non-Functional Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . .544.2.1. Integration of Application Server and Agent Server. . . . . . . . . . . . 54

5

Contents

4.2.2. Portability of the Agent Server. . . . . . . . . . . . . . . . . . . . . . . 554.2.3. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .554.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564.2.5. Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574.2.6. Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574.2.7. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574.2.8. Extensibility and Flexibility . . . . . . . . . . . . . . . . . . . . . . . . 584.2.9. Personalization and Internationalization. . . . . . . . . . . . . . . . . . 59

4.3. Standard Functional Requirements. . . . . . . . . . . . . . . . . . . . . . . . .59

5. Introduction of the underlying Applications 615.1. Enfinity Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

5.1.1. Enfinity in General. . . . . . . . . . . . . . . . . . . . . . . . . . . . .615.1.2. Enfinity Architecture and Components. . . . . . . . . . . . . . . . . . . 625.1.3. Enfinity’s Pipeline Concept. . . . . . . . . . . . . . . . . . . . . . . . 645.1.4. Communication inside Enfinity. . . . . . . . . . . . . . . . . . . . . . 675.1.5. Storefront Request Workflow in Enfinity. . . . . . . . . . . . . . . . . . 675.1.6. Extending Enfinity using the eCAPI. . . . . . . . . . . . . . . . . . . . 695.1.7. Connecting to Enfinity using the eRXI API. . . . . . . . . . . . . . . . 715.1.8. Procurement Component in General. . . . . . . . . . . . . . . . . . . . 735.1.9. Procurement Component Technical Architecture. . . . . . . . . . . . . 74

5.2. Tracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .755.2.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .755.2.2. Infrastructure of a Tracy System. . . . . . . . . . . . . . . . . . . . . . 765.2.3. The Tracy Agent Model. . . . . . . . . . . . . . . . . . . . . . . . . .775.2.4. Application Integration via System and Gateway Agents. . . . . . . . . 775.2.5. Communication between Agents. . . . . . . . . . . . . . . . . . . . . . 785.2.6. Agent Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .795.2.7. The Architecture of a Tracy System. . . . . . . . . . . . . . . . . . . . 795.2.8. The Software Architecture of a Tracy Agent Server. . . . . . . . . . . . 80

6. InterMarket Feasibility Study 856.1. Agent-based Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

6.1.1. The Configure Agent Usecase. . . . . . . . . . . . . . . . . . . . . . . 856.1.2. The Migration Usecase. . . . . . . . . . . . . . . . . . . . . . . . . . .866.1.3. The Perform Tasks Usecase. . . . . . . . . . . . . . . . . . . . . . . . 866.1.4. The Return Results Usecase. . . . . . . . . . . . . . . . . . . . . . . . 89

6.2. Non-functional Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .906.2.1. Integration of Agent Server and Application Server. . . . . . . . . . . . 906.2.2. Portability of the Agent Server. . . . . . . . . . . . . . . . . . . . . . . 956.2.3. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .956.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .976.2.5. Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .996.2.6. Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1006.2.7. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1006.2.8. Extensibility and Flexibility . . . . . . . . . . . . . . . . . . . . . . . .1016.2.9. Personalization and Internationalization. . . . . . . . . . . . . . . . . .102

6

Contents

7. Conclusion and Future Work 1057.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1057.2. Future Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

Bibliography 114

List of Figures 116

A. References for Basic Knowledge 117

7

Contents

8

1. Introduction

The following paper deals with the evaluation of two existing software applications in order toform a new kind of e-marketplace system. This e-marketplace shall provide new advanced auto-mated 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 andstationary software agents, which are electronic representatives of human traders on e-market-places. The agents can act autonomously on behalf of their users after a suitable configurationand can fulfill different tasks along the supply chain such as finding proper products or tradingpartners, bidding in auctions, or negotiating goods directly with other marketplace participantswithout involvement of human users. Accordingly, the software agents represent companies one-marketplaces and can initiate, fulfill, and complete trading transactions and place contractswithout the presence of humans, which leads to time effort and cost reduction while increasingtrading opportunities.

Referring to the introduced main objectives, the first point to mention is a mechanism foraggregating different business steps to build automated workflows. For example, it could bepossible to combine tasks for finding a suitable offer on several e-marketplaces. This procedurewould include all necessary tasks such as visiting several e-marketplaces or comparing the re-ceived data and retrieving the best offer. Composing all these steps takes routine work from usersand helps, therefore, to save time and costs. This scenario could be even extended with regard tomobile agent technology. By spreading mobile agents over several e-marketplaces for represent-ing their users, they can enter these marketplaces for managing business activities or observingimportant 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 marketchanges.

The second objective is to support more advanced purchasing techniques by implementingintelligent and automated trading mechanisms, for example for negotiations and auctions. Sta-tionary 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 partic-ipate in such advanced price finding processes representing a company and leading to time andcost savings as well as offering more trading opportunities to their users. In addition, softwareagents can use these advanced techniques in combination with the above-mentioned workflowsto 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, orother 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 inde-pendently through the Internet. Therefore, the mobile device, mostly restricted by transmissionquality and time, must hold no open connection while the agent is working. Thus, the mo-

9

1. Introduction

bile agent technique introduces a suitable technology for connecting small portable devices toe-marketplaces.

For implementing the agent-based functionality in a realistic industrial scenario a professionale-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 thestandard functionality required for e-commerce activities. In combination with the mobile agentsystem Tracy, from Friedrich Schiller University Jena, it should be validated in the followingdocument, whether both applications combined are able to provide an e-marketplace offeringadvanced agent-based features. The new constructed solution is called InterMarket in the further.

1.1. Structure of the Document

After the introduction, we start with presenting the foundations of InterMarket by defining thee-marketplace term and giving an overview over the mobile agent technology in Chapter 2. Themain concepts and goals of the InterMarket approach will be described in the following Chapter3 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 twocandidates, Tracy and Enfinity, are introduced in Chapter 5. These insights are mainly focusedon the functions and features, which affect the InterMarket solution. After forming the basis, thefeasibility 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 empha-sized for every requirement and if necessary, recommendations for further work or adaptationsare made. If several opportunities remain for solving an important feature of InterMarket allsuitable approaches were discussed in detail. The last chapter finishes the document by giving afinal conclusion and explaining future work.

1.2. Requirements for Reading this Document

This document contains a multitude of information basing on several fundamentals of softwareengineering and standard techniques of software development. Therefore, the reader is expectedto 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 asEnterprise 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 ap-pendix. There, the reader can obtain references of suitable literature for all listed topics.

10

2. InterMarket Foundations

Chapter two gives an overview of the basics, which underlie the InterMarket approach and servesin the further as foundation for all following chapters. The chapter starts with an introductionin the topic of e-marketplaces. After a general definition, e-marketplace functions and featuresare in the focus followed by a short survey of current architectures and technologies used withe-marketplace systems. Of course, this part is not complete at all. Please refer to [66] formore 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 informationabout 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 completeoverview.

2.1. E-Marketplaces

2.1.1. Definition of E-Marketplaces

The opinions about the definition of e-marketplaces diverge. They range from emphasizing onlythe Internet-based character of e-marketplaces [59] up to describing more the functionality toshow the value-added features of e-marketplaces [58]. Thus, the definition heavily dependson 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 ap-plications, which offer abilities for e-commerce online trade between several buying and sellingcompanies.

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 2001. Forrester Research and theGartner Group [26] predict that 37 percent of B2B e-commerce transactions will be done bye-marketplaces in 2004 [44], which are a big part of forecasted 6 trillion US dollar overall B2Brevenues in that year.

E-marketplaces offer different business models such as multi-vendor catalogs for e-sales ore-procurement as well as several types of auctions or exchange systems for enabling companiesdynamic trading opportunities. In addition, e-marketplaces can provide even more value-addedfunctions such as payment, transaction completion, and fulfillment services as well as contentmanagement or integration capabilities for existing legacy systems of the companies.

E-marketplaces offer their participants the ability to meet new trading partners, to automatetheir procurement or sales strategies, and to use more advanced and automated techniques forfinding best offers and prices to lower costs and cycle times. The offered services vary betweendifferent e-marketplaces depending on the type of industry they try to cover [66, p.10], [21].

11


As indicated above, e-marketplaces are more than simple e-commerce sites for selling or buy-ing products or services. E-marketplaces provide functionality along the supply chain, whichoffer multiple services for each stage. Figure2.1maps e-marketplace functionality and servicesto supply chain stages. The functionality presented in the figure will be described with the fol-lowing subsections.

Figure 2.1.:E-marketplaces enable services along the supply chain [66, p.19].

2.1.2. Transaction Functionality

The transaction functionality envelops the core mechanisms of e-marketplaces. It enables com-panies to meet, to exchange information, and to trade products and services. Foregrounding, thisfunctionality contains services for matching suppliers and buyers and mostly provides a catalogand order management. The matching describes the opportunity to group marketplace partici-pants according to industry types and offers search and browse mechanisms to them for findingtrading partners on the e-marketplaces. The catalog and order management cover functional-ity 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 automati-cally distributed to these suppliers. For both, buy and sell side, the order status can be trackedfor informing about their current transactions. In addition, most e-marketplaces implement dy-namic pricing and negotiation models such as auctions or exchange systems for offering theirparticipants various mechanisms for finding best offers and prices.

E-marketplaces must implement suitable transaction models according to the goods, whichare traded on them. Currently there exist mainly four different transaction models: multi-vendorcatalog, pinboard, exchange system, and auction. When to use which type of model regardingto the kind of goods and the regularity of purchases is depicted in Figure2.2. Goods are dis-tinguished between production goods and MRO goods. Production inputs are more complexgoods having passed through a preprocessing and will receive further processing in the buyingcompany. Sheet metal components for the car industry are a possible example. MRO standsfor 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. Purchasingregularity is distinguished between regular and irregular traded goods. For example it makes nosense to offer irregular purchased products in a catalog system, because the price is mostly vari-

12

2.1. E-Marketplaces

able and is new negotiated for every single transaction. In this case it seems to be more usefulto support an auction or exchange system. The particular models of the transaction functionalityare described in the follow.

Figure 2.2.:Proper use of transaction models [66, p.23].

Multi-vendor Catalogis a data structure containing aggregated product catalogs of different suppliers centralized. Thecatalog structure is a kind of hierarchy divided by suppliers and categories. Suppliers have theability for uploading, importing and manipulating supplier catalog data using standard classifi-cation schemes such as eCl@ss [18] or UN/SPSC [19] and standard catalog exchange formatssuch as BizTalk [54] or ebXML [47].

Buyers can browse the catalog maybe regarding to a specific view and can choose requiredproduct items for getting information or putting them into a shopping cart. E-marketplaces of-fer shopping carts, which are containers for chosen products within a single user session. Thecontents of the shopping carts can be ordered. Most of the marketplaces offer an additionalmechanism, sometimes called shopping history or shopping lists, for reusing shopping cart con-tents 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, includingonly the items they provide. Both trading partners, buyers and suppliers, can observe the statusof orders in all marketplace solutions.

Multi-vendor catalogs additionally support options for discount specifications for special buy-ers or products, for buying communities (a group of smaller companies that want to advancefrom amount discounts) or even for specific quantities.

Pinboardis a platform for advertisings and petitions mostly realized as a directory with a simple searchand find mechanism for requested order or offer entries, such as requests for quotes (RFQ) andrequests for proposal (RFP). An entry in the directory is not only a link to a Web site of acompany, 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 theactor’s roles: everybody can be supplier and buyer at the same time. E-marketplaces enable

13


their businesses to meet and also can add completion and fulfillment services for a transactioninitialized at the pinboard. However, the trading transaction is independently processed by thetrading partners. If a trader accepts an offer, the trading partner is informed via e-mail or SMS.Then both traders complete the transaction without involving the e-marketplace. The pinboardmodel enables two special forms of advertising mediation:

RFQ 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 toa supplier directly. Every registered supplier can read the entry on the directory andcan make a specific offer. The buyer chooses the most attractive offer and initiates atransaction with the supplier following the arranged terms.

RFP Request for proposal is a special offer of a supplier to trade goods with the suggestedconditions. The offer is published using a directory service such as pinboard or is sentdirectly to a buyer. If a buyer accepts trading conditions a trading transaction can beinitialized.

Exchange Systemis an extension of the pinboard transaction model. It also provides services to bring businessestogether, but additionally offers services for transaction completion and price negotiations. Theexchange system delegates the best offers to a seller. Double auctions are an example of anexchange system. Although the name is something confusing, double auctions realize pricefinding similar to trading stocks at a stock exchange through opposing supply and demand.

Auctionis similar to the exchange system, but less flexible. The characteristics of the product to beauctioned have to be clearly describable and the price must be the only trading criteria. Mostauctions are non-durable and live only for a certain time period. Several auction models existand can be mixed up. The e-marketplace providers manage the proper auction type regardingto the kind of the market and the behavior of the participants. There mainly exist the followingauction types:

English Auction This auction starts with a low price set by the supplier for the product to beauctioned. The price increases with every bidding by a certain value unlessno buyer places a bid. Finally the highest voting wins.

Dutch Auction Here the auction starts at a high price. The price lowers in time intervalsduring the auction by a certain amount. The buyer who accepts first theactual price wins the auction.

Public Auction is also called open auction. All participants in a public auction know theidentities and bidding amounts of all other auction participant.

Private Auction is also called closed auction. An auction participant doesn’t know anythingabout the other participants of the auction.

14

2.1. E-Marketplaces

Selling Auction A supplier offers a product or service and different buyers bid to buy thegood.

Reverse Auction A buyer specifies the product/service he wants to buy. Different supplierscan then place their offers to bid. Normally, the offer with the lowest pricewins.

2.1.3. Fulfillment Functionality

The fulfillment functionality offers support for the value chain stages completion and long-termsupplier relations. The supported services ease the transaction processing by offering add-onsfor initiation, fulfillment and completion of trading transactions.

E-marketplaces offer tools forchecking credit-worthinessof potential contract partners foran initiation phase of a transaction. In addition, e-marketplaces can provide techniques forchecking product quality, for example by supporting a voting mechanisms for buyers to de-termine the qualities of specific offers and suppliers. By integratingshipping and logisticserviceswith e-marketplaces it is possible to execute orders immediately. Thus, a supplier isassigned with the delivery of the order. Of course, e-marketplaces offer the ability forintegrat-ing with companies’ ERP systems(see Section2.1.4) for the fulfillment phase for supportingautomated transaction workflow. In addition, e-marketplaces can offer even additional featuressuch asinsurance servicesfor insuring order items and deliveries or atrustee functionality forguaranteeing complete delivery in time and payment guaranty. E-marketplaces can provide apayment servicefor automating and simplifying currency transfer andclearing services, whichhelp to check order and delivery correctness as well as invoicing for the final stage of a businesstransaction, the completion.

Berlecon predicts, that e-marketplace solutions must implement these value-added services toincrease 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 totransparent and easy transaction processes, businesses would prefer most.[66, Ch. 4.1.2, pp. 45]

2.1.4. Integration Capabilities of E-Marketplaces

The integration functionality supports the same supply chain stages like the fulfillment function-ality, because a main task for the integration functionality is to enable e-marketplace solutionsfor offering advanced fulfillment services. Providing a large variety of interfaces for integrationwith nearly any external software solution would give marketplaces the opportunity for flexibleadaptation and extension of themselves regarding to the market needs. Therefore, such kind ofe-marketplaces can offer their participants many useful fulfillment and other services.

The integration with companies’ ERP/CRM applications and other standard inventory soft-ware is the most important integration type, because this opens the ability for high automationof business processes and a high integration of e-marketplaces into the supply chains of theirparticipants. E-marketplaces are able to offer additional value-added functionality such as forpayment, 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 de-scribes also the opportunity for connecting to several other systems such as DBMSs or directoryservers, which is important for the overall functionality of marketplace systems.

15


Finally, Berlecon points out that the most cost saving factor of e-marketplaces is to automat-ically adapt different data formats [66, box on p.35]. Thus, e-marketplaces should be able tointegrate other solutions using standard data formats. In addition, Berlecon emphasizes the im-portance of supporting lots of interfaces for the integration of additional features and services toacquire participants and hold them for high frequently long term trading relations [66, pp. 33].

2.1.5. 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 andproducts (e.g. implemented with yellow pages or a business directory) as well as market newsand industry-related articles (e.g. offered with newsletters and white papers), is a good approachfor acquiring participants and create opportunities for them to increase their value-added throughe-marketplaces [66, Ch. 3.5, pp. 35].

The information offer could be even improved by installing a discussion forum on the mar-ketplace for helping businesses by solving problems through offering easy access to informa-tion or knowledge from other marketplace participants. Thus, participants can interact and ex-change knowledge directly with their trading partners. Of course, the information spread withe-marketplaces can include graphics and multimedia contents.

2.1.6. Additional Services

Additional services are supported for all stages along the supply chain. They should supporte-marketplace participants by using the new media and as second they should enable users toobserve their business activities within e-markets.

Market reports are the most important feature. The participants should be given the capabilityto create transaction-based market reports of their business activities for analyzing sales andturnovers as well as product or order-related information. E-marketplaces should provide toolsfor creating and outputting graphical reports on business metrics even via multiple data formatsto 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 fastand uncomplicated help or by supporting a messaging system for simplifying contacting withother marketplace participants or for exchanging information with them.

A further important service is to offer multiple currencies and languages if the e-marketplacesare focused on global trade.

Additional services can also stand for application server providing (ASP) or sale-site hostingfor an easing market entry of potential participants. Renting these resources is much cheaper forthe businesses than buying, if they want to test e-marketplace capabilities for their company.

2.1.7. Consulting Function

This functionality marks a new trend in e-commerce, which is also known as collaborative com-merce (c-commerce). It adds concrete support for business processes to help e-marketplaceparticipants to optimize their business processes by offering services for planning, transactingand improving processes. C-commerce provides virtual offices for temporary collaborations ofseveral businesses. The cooperation partners can on the one side easily synchronize their data

16

2.1. E-Marketplaces

and product exchange or even their corporate business workflow. On the other side they can holdmeetings via the Internet (e-meetings).

E-marketplace solutions providing these features, which increase value for their participants[66, ch. 3.6.1, pp.37]. In fact, there is a trend of e-marketplaces specializing only on this area ofe-commerce by providing mainly c-commerce features for their users.

2.1.8. Overall E-Marketplace Architecture

E-marketplaces are built as Internet-based Client/Server software systems offering access for alarge number of users maybe spread over the whole world. Berlecon finds out that in 2001 thetop German e-marketplace installations had over 40.000 participants [66, p.11]. And that is notthe highest number, when thinking of the increasing overall e-commerce. Thus, it is necessaryto provide mechanisms that satisfy such a large number of users by ensuring accurate and fastaccess 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-commercesolutions, using a three-tired architecture consisting of a client tier, a middle tier and a back-endtier (presented by Figure2.3). Of course, e-marketplace architectures are designed for support-ing 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 andforms the foundation for developing large scalable applications with good maintainability andextensibility [77]. Thus, e-marketplaces can be extended to extreme large systems installed onmultiple machines, following the separation of the logical layers. E-marketplace solutions sup-port several standards such as J2EE, XML, or CORBA and implement a distributed componentmodel 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 onthe other side for system architecture to ensure a platform-independent, language-independent,and application-independent solution, for example using Java J2EE.

17


The Client Tiercovers the parts of the application as well as the communication protocols used by client usersfor 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 ofknowledge about users of e-markets and the facts that most participants own PC/ workstationcomputers and e-marketplaces are Internet-based. This brings advantages introducing easy andfast access to the market, independence for the users from maintainability works of the businesslogic, and consistent processing. Thin clients do not own business logic, because they are onlyresponsible 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. Ad-ditionally, XML can be employed on top of the HTTP. Using this simple communication strat-egy implies that the more sophisticated logic resides on the server side. Some more advancedtechniques such as applets or ActiveX controls are used for thin clients (for example when im-plementing a real-time auction mechanism) only in a few cases.

However, there exists another kind of user, which introduce more control over their capabil-ities. The marketplace’s administrative users such as the marketplace organizers connect to themarketplaces mostly over an Intranet, which offers more network speed and bandwidth. Theyuse thick clients, which implement a connection using for example Java RMI, CORBA/ IIOP, orDCOM 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 somebusiness logic. Despite of the mentioned disadvantages such as lower performance or problemsafter 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 Tiersupports several important components, which the Web server should be the first componentto be mentioned. It connects with the clients using HTTP for sending HTML pages coveringtext, graphics, and multimedia contents or maybe also applets. Client requests cause the Webserver to send static pages. A Web server is used with special techniques, such as page cachingor storing multimedia data on extra directory servers, for enabling fast access to optimize theresponse times to the clients.

The Servlet Engine is the second component to be mentioned. A client request can initiate thegeneration of dynamic HTML pages using special techniques such as ASP or JSP/Servlet, andthe invocation of distributed objects (e.g. EJBs) from the application server. With other wordsthe Servlet Engine allows for dynamic interaction with the user.

However, the application server is the most important part of the middle tier, because it isresponsible for processing the business logic of a marketplace solution. The application server isdefined 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 augmentsthe traditional Web server. The application server provides middleware services for applicationssuch as security and the maintenance of state and persistence for transactions, which leads toaccessing and managing data in a consistent way. The application server offers a frameworkfor e-business combining the former isolated stages building, deploying, and managing in one

18

2.1. E-Marketplaces

solution [52, 79]. Therefore, it offers visual deployment tools for the building step, a distributedcomponent model for the deployment step, and administration and management tools for themanagement of the system [52, pp. 130]. The application server offers through the distributedcomponent model possibilities to integrate with other systems (e.g. RDBMS, ERP software) viadefined data exchange and connection standards on the one side and on the other side allows forbusiness process integration. This means that it is possible to combine different business stepsinto a workflow. Therefore, the application server mostly implements an additional logical layerabove the distributed business objects and even additional graphical tools for giving marketplaceproviders capabilities for flexibly defining more sophisticated business workflow. For a discus-sion 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, scal-ability, availability, security, and extensibility introducing re-usability and easy distribution overseveral servers through the insert of distributed component models such as EJB or MS DCOM,and CORBA ORB. Figure2.4 shows the architecture of a J2EE-based application server. Formore information on application servers, please see [52] and the references of leading applica-tion 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 pro-vide services for the management of application server business logic, the distributed compo-nents, and the e-commerce site contents on the one side and on the other side offer services formanaging the application server cluster.

In practice, the mentioned components of the middle tier never stand alone, but they are com-bined 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 ofservers it is often spoken from the n-tier architecture when meaning three tier architecture. Forexample 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


189] and availability. The second server group covers the application server and Administra-tion and Control Server functionality. Most application servers own administrative capabilities.Application server receive dynamic request from the Web server, for example, for placing itemsin the shopping cart or for placing orders or filling product information in catalog pages. Mostapplication servers implement Web server functionality to receive requests from the Web server.

The Back-end Tiercovers relational database management systems (RDBMS), inventory and ERP/ CRM applica-tions as well as other systems that can be accessed from the middle tier using several techniquessuch as HTTP, RMI, CORBA/ IIOP, or DCOM. The main task of this tier is to provide informa-tion and data persistence for the Middle tier business logic. It is possible to use XML for dataexchange on top of the named protocols. E-marketplaces mainly implement a database with thistier for storing data of catalogs, users, orders, transactions, sessions, and etc.

2.2. Mobile Agent Technology

2.2.1. Definition of Mobile Agents

The agent term was already introduced into the computer science in the late 1970s within theartificial intelligence (AI) research (see Nwanda [60]). Agent stands for autonomous intelligentbehavior including the ability for communication, which is subsumed in a general introductionof the agent term in the AI research by Wooldridge and Jennings [76]. Accordingly, an agentis thought of as a software entity or component in the modern software engineering owning thefollowing 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 byperforming special standard or optional processes depending on the event

• adaptation, an agent can be configured to match special user experiences or to solve prob-lems in a specific way

• intelligence, an agent own on the one side decision-making abilities and on the other sidelearning algorithms for learning about its user’s behavior

Since the early 1990s software agents are brought into context with the development of dis-tributed systems. Related to this, not only the above-mentioned properties playing a role, butadditionally a special feature called mobility. Mobility describes the ability of a mobile agent tomove through a heterogeneous electronic network and deciding autonomously when and whereto go [60], [10, p. 8]. This proceeding is presented with the following Figure2.5. In the figure,a mobile agent migrates for example from a platform A to another platform B to access servicesof applications or to retrieve data from a database, which are only offered at the target platformof its migration. However, the graphic should emphasize another feature of the mobile agent

20


approach. These agents can only live in a special software environment (see Section2.2.2). Theenvironment offers two important communication capabilities. External applications are able tointeract 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 programminglanguage. An example for an object-oriented approach is given in Chapter five with the intro-duction of the mobile agent system Tracy.

Braun [10, p. 8] concludes, that many authors see mobile agents as a new paradigm for thedevelopment of large distributed systems [56, 71] or for the communication within [5], becausemobile agents introduce a completely new approach by sending the code to the data and not viceversa. Finally, some special features of mobile agents should be mentioned differentiating theagent approach from other distributed techniques such as RPC, RMI, and CORBA, as listed byBraun [10, p. 9]:

• Mobile agents work in large and heterogeneous networks, where no assumptions aboutreliability and security of the involved platforms can be made.

• The migration is controlled by the programmer, which means that the program itself andnot the operating system decides when and where to go.

• The execution of the program is not location-transparent, but the program moves to aspecific 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 gettingan idea of the capabilities, which arise with mobile agents for business applications.

Figure 2.5.:Mobile agents migrate through heterogeneous networks.

2.2.2. Mobile Agent Environment

Mobile agents need a special software system as a living environment on each platform, whichshould participate in a mobile agent network. Thus, every platform in the network covers anetwork-connected host with a special application for receiving, sending, starting, and execut-ing 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


mobile agents as well as defining a place on a host where mobile agents can be secured exe-cuted.

Figure2.6 shows the most important services of an agent environment such assecurity (fordata and code of mobile agents as well as for the system services for protection against mis-use and destruction by mobile agents),communication (for enabling agent interaction),man-agement(for controlling agents, their resources and communication),migration (see Section2.2.3), persistence(for persistently storing agents and their data) anddirectory services (forstoring specific content). Figure2.6 also depicts the ability of other applications for enablingaccess to mobile agents for configuring and starting agents and for exchanging data with them.

Figure 2.6.:Mobile agent environment.

2.2.3. Migration of Mobile Agents

Migration describes the process of a mobile agent moving from one host to another. Althoughmigration is only one out of many features of mobile agents, lets focus on it, because it is mostsignificant.

Mobile agent systems mostly use for the network transmission the TCP/ IP protocol. A mobileagent only has to inform the agent environment about the IP address of its target host and thename of the agent environment there before the transmission will be started [10]. Right for thequestion how the agent will be transferred there exist two approaches.

First, thestrong migration should be introduced with its representative mobile agent systemssuch as Telescript from General Magic [73] and NOMAD [68]. After the agent has signalizedits wish for migration with a specialgo -command the agent environment freezes the agentexecution and starts packing agent’s code, data, and current state (enveloping the contents of thelocal variables of the current method as well as the Call Stack, Operand Stack, and the InstructionPointer) for migration. After the transmission, the agent will be restarted on the platform withthe transferred code, data, and state. The agent execution starts then with the first command afterthego instruction.

Although this approach is very comfortable for the programmer, because migration is almosttransparent, 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, theprogrammer 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


induces no restart of the mobile agent after transmission with the first statement following thego -command. Moreover, the programmer has to indicate a method before the migration, whichthe mobile agent executes instead on the new host.

In fact, weak migration is easier to implement. However, this advantage is paid off with moreprogramming effort and the need for higher programmer skills at all. Finally, some exampleagent systems implementing weak migration shall be named: Aglets [50], Grasshopper [32], orTracy [9].

However, there exist even more techniques and optimization strategies for the migration pro-cess, being not subject here. For more information about this topic, see [10, 11, 20].

2.2.4. Advantages of Mobile Agents

To understand the decision for using mobile agents with InterMarket it is necessary to know theadvantages 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 helpimprove current architectures.

AsynchronousComputations could be outsourced to other powerful systems if the local resources arecompletely overused. The agent could visit a host, which is able to process the giventasks and the agent could even pay for the service. Thus, during execution no networkconnection is required, it is very applicable for mobile devices with less computingpower and memory.

Reaction on remote events in real timeA mobile agent can react as representative for a human on events on a remote sys-tem, which saves the costs for the network latency in contrast to contacting a centricdecision-making instance.

Robustness and failure toleranceA mobile agent is able to move to another system if the current host fails even in caseof a routine shut down for maintaining works.

State sensitive communicationA mobile agent carries its own state and so even the intermediate data within a com-munication process. Thus, agents reduce network traffic in contrast to RPC.

ScalabilityMobile agents reduce long network transactions for example in case of performingmany calculation steps or processing a large data amount to a minimum because theytransform remote processing in local execution.

Semantic RoutingDetailed knowledge is not required about server names, offered services and their pa-rameters in contrast to Client/Server. Agents are able to autonomously find informationabout servers and services by exchanging key words with servers.

23


Personalized servicesAgents enable user-specific task processing.

SecuritySensitive data can be encrypted and safely carried inside agents through the Internetusing their own keys.

Mobile computingMobile users can take advantage using agents in three points [29, p. 7]. A mobile usercan save network connection time, because of the short connection period, requiredfor sending and receiving single agents. The agent fulfills the tasks while the user isoffline and a user has to be connected again after starting a mobile agent only for ashort period to receive the results.Most mobile devices own slow network connections. Therefore mobile agents can helpto increase efficiency through an agent-mediated pre-selection, reducing the amount oftransferred data.Mobile users have smaller computing power and memory capacities. The shiftingof computations to servers via mobile agents can help to save resources on mobiledevices. Only the results are sent back to the users’ devices.

2.2.5. Problems with Mobile Agents

This subsection summarizes in an overview some main problems with mobile agents. It is not acomplete nomination, but important points in the areas security, management, and interoperabil-ity are mentioned.

Securityis 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 shortinsight. The agent server is normally protected through a sandbox, which limits the capabilitiesfor mobile agents to access functions, which they are not allowed to do. However, some problemsremain. How could be ensured, that mobile agents do not attack the agent server? They can tryto pretend bad identities or maybe try to overload the server, to crash it. This pretending problemcan be solved maybe using some kind of encryption features with private and public shared keyssimilar to normal Client/Server approaches. However, an agent server cannot decide whethera mobile agent performs only its tasks or it tries to crash the agent server through performinguseless tasks [12] only for lowering server performance.

The security problem is also active in the vice versa direction. How could be a mobile agentsaved from malicious agent servers? Because the agent executes in a container of the agentserver, it could be possible for the server to get access to private data and maybe algorithmsof the agents. The agent server can try to change the execution of a mobile agent, can read orchange the private data, or can even prevent the agent from execution. Additionally, it is possiblethat malicious agent servers try to infiltrate unauthorized mobile agents to other agent servers.

24


Therefore, it is very important to save the mobile agent from interception by malicious agentservers 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 accessprivate data or even to change it. On the other side it could be possible, that agents try to preventother agents from execution or they crash the agent by sending thousands of bad messages to thevictim agent.

Management Problemsarise, when a mobile agent system is used to form a dynamic local or global network. Questionsform, such as how could be managed dynamically changing networks? A possible agent-basedapproach 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 determiningif an agent has completed its tasks [1] are less easy problems, which lead to a high managementeffort. This can be extended by the problems of finding orphans, which are mobile agents withouthuman users anymore.

Interoperabilityis the last big problem area. Here you may find problems such as how communicate mobileagents in a multi-agent approach [3] regarding to the possibility of agents descending from dif-ferent agent systems. How looks a general approach for forming cooperation between differentagent systems? Today it does not exist a generally accepted standard for exchanging agentsbetween different agent systems. Standards such as MASIF [57] and FIPA [24] do not really hit.

25


26

3. InterMarket Objectives

This chapter presents the main objectives of InterMarket. The chapter starts with a short motiva-tion, which justifies the InterMarket approach. The following parts introduce the main objectivesby describing the advanced features of the agent-based marketplace solution. After giving somethoughts on the overall concept of InterMarket, a final discussion should clarify the question,why mobile agents should be used with the InterMarket approach.

3.1. 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 willsurpass 1,9 trillion US Dollar in 2002 and will reach about 6 trillion US Dollar in 2004. Togetherwith Forrester Research [22] the Gartner Group forecasts, that thereof a fraction of 37 percentwill fall to B2B marketplaces in the same year. These numbers point out the dynamic and rapidgrowth of the e-marketplace segment.

However, the B2B market is not a straightforward automatism. A hard competition for marketshares has already raised in 2001, forcing e-marketplace providers to improve their offers accord-ing 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 transactionfunctionality, but additionally fulfillment and other additional services. At the moment they donot cover the whole value chain for their participants. Berlecon subsumed, that e-marketplaceshave to offer through integration and business process support value-added services along thesupply 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 onthese problems, InterMarket should introduce new features, which base on the mobile agenttechnology and will be presented in the following subsection.

3.2. Main Objectives of InterMarket

Business Processes IntegrationIn a poll with buying departments of German companies, the research center Explido [21] posed

27


the question, for what the employees use the Internet. The most mentioned points were searchingfor suppliers (98 percent), searching for detailed information (87 percent) and placing requestsfor quotations (60 percent). Only 44 percent of the interviewees indicated to use e-marketplacesfor their daily work [75, Ch. 1]. These facts tell mainly two things. On the one side employeesperform many jobs by hand and on the other side e-marketplaces do not seem to offer a widevariety of sufficient services, from which users can take a real advantage. Thus, it remains agreat potential for automation of daily work of the denoted employees, which can lead to timeand costs savings.

That’s why InterMarket should offer capabilities to relieve employees by assigning routinework to software agents. Software agents can be configured for a single task or even for a wholeworkflow of tasks according to their users’ needs. Thereby, the sequence of tasks should beexactly configurable by human users or should be even completely left to the agents. Theseagents cannot only cover tasks of the first steps of the value chain such as searching for andcomparing of trading partners and their offers or performing product ordering, but also tasks offurther 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 tech-niques.

Lets think about a little example, which is illustrated with Figure3.1. Imagine, a depart-ment manager of a company wants to order new hardware equipment for his employees. Heauthorizes 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 onthe 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 thee-marketplace for retrieving offers. Thereby, the agent performs many different tasks follow-ing an autonomously created workflow. The executed tasks range from more simple tasks suchas catalog search and comparison up to advanced activities such as search for special offers ona pinboard or negotiating directly with other marketplace participants. The agent informs themanager automatically after finishing its work. In addition, the agent can collect not only offers,

28

3.2. Main Objectives of InterMarket

but also detailed information about products and techniques to increase the manager’s knowl-edge base. Finally, the manager only has to explore the agent’s results and has to make an orderdecision 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 wholetransaction and reports to the manager, for example by sending order confirmations or messageswith track information. However, the agent can perform even additional tasks such as informinga logistic provider for delivering the goods, or interacting with a payment service to manage thecurrency transfer on behalf of the manager. Finally, the manager only receives the delivery ofthe ordered hardware. Please see [46, 80] for information on business process and workflowmanagement with software agents and see [27, 45, 72] for an overall introduction of workflowmanagement.

Providing Intelligent Trading and Negotiation TechniquesAgents, that automatize value chain stages, must be able to simulate human behavior in someparticular situations of several business processes. For example, agents can take part in auctionsand negotiations on the InterMarket marketplace. Therefore, agents have to implement specialadvanced functions, which realize artificial intelligence for the software agents. The indicatedfunctions need a set of parameters to adapt to a specific user behavior. Because agents act onbehalf of their users, they receive rules and conditions during the configuration by their humanusers before starting activities.

How mentioned in the example above, the manager can authorize an agent on the e-marketplaceto 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 suit-able offer in the marketplace catalogs and on the pinboard. Thus, the agent can try to directlynegotiate offers with several marketplace suppliers according to the product features, which itwas configured by the manager. On the other side it could be possible, that the agent detects anauction, which offers the proper products. So the agent starts bidding until the auction does nolonger hit the demands of the manager wishes. The intelligent techniques of software agents areillustrated in the workflow cycle at the right top of Figure3.1.

A main objective of InterMarket should be not only providing prize negotiation strategies foragents, but also more advanced negotiation models such as multi-attribute negotiations, whichdepend not only on the price. This leads to an additional improvement of some business pro-cesses along the value chain. And in fact, nearly two-thirds of participants from a current pollmade by Deloitte Research see the most important improvements for realizing value-added fea-tures on e-marketplaces through modification of business processes [17, box, p. 15]. Please referto [49, 51, 55, 81] for an overview over current research and state of the art applications on thearea of intelligent agent-mediated e-commerce.

Interconnection of multiple E-MarketplacesDeloitte Research predicts, that e-marketplaces will form strategic alliances, because they areforced 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], whichbuild 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


through mobile agent technology, which is a possible form of a middleware. InterMarket-basedmarketplaces 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 tocontact stationary agents for security and scalability reasons. A consistent approach is definedthrough this multi-agent technique, offering in addition management services to locate agent-based e-marketplaces in the World Wide Web.

Regarding to Figure3.2, the manager is not further limited to use only one e-marketplaceor to visit several e-marketplaces by hand. Mobile agents are able to migrate and connect todifferent e-marketplaces, which using agent technology. Thus, the manager can extend his capa-bilities to reach selling companies, to transparently search, request, and order products such asthe workstation equipment from the former example, across the world. The agent technique caneven adapt and handle problems evolving in world wide trading actions across borders such asfor example languages, continents, and currencies by providing for example multi-language ormulti-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 devicesInterMarket offers the capability of directly connecting even new devices such as PDA, mobilephones, or other wireless-connected or portable devices to an e-marketplace. The mobile agenttechnology enables management of mobile and distributed networks. This approach fits very wellto today’s increasing dynamic and heterogeneous IT landscape. The portability of the mobileagent technology forms the foundation for the InterMarket approach. Advantages of mobileagent technique can be the lower network traffic, the smaller demands on network quality andbandwidth (because mobile agents do need only for a short period of time, the migration, an opennetwork connection) compared with other middleware approaches. Please see a benchmark forthe 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 theresomething about the latest hardware equipment. He is so enthusiastic that he wants to update hisdepartment. Thus, the manager just uses his laptop or PDA and starts an ordering process with a

30

3.3. Overall Concepts

mobile agent from this mobile devices from somewhere in the world, how depicted in Figure3.2.Mobile agents can run from mobile devices owning an agent server by using a transient networkconnection.


The main difference between InterMarket and current e-marketplace solutions is that InterMarketoffers access not only for humans, but additionally for mobile software agents. Furthermore, theagent-based processing of tasks on the marketplace marks a new approach. InterMarket realizesnot only classic human-to-human, but also human-to-agent trading capabilities. The tradingtransactions 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 ofFigure3.3). First of all for standard users using a web Browser on a PC/workstation. Throughthe insert of mobile agents are additionally mobile users able to enter the marketplace from theirmobile devices. Therefore, InterMarket offers a portable agent server, which is the foundationfor mobile access. Of course, it is possible even to use mobile agents from stationary hosts, onlyby installing a proper agent server. Finally remains to mention that even machines can use agentfunctionality of the InterMarket marketplace for machine-to-machine commerce, indeed over astandard HTTP connection. User can choose the best way for them using an e-marketplace.

31


On the marketplace itself, there will be offered beside conventional e-marketplace function-ality agent-based services from three categories, which can be used by mobile agents as wellas by standard users (via HTTP) (see Figure3.3). InterMarket implements catalog-based trad-ing 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, InterMarketsupports 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 optimiz-ing strategies for winning. In this auctions human users participate in parallel, concurring withthe agents for the win. Last, InterMarket offers request and negotiation functionality for dy-namically determining prices with trading partners. Agents and human participate in parallel,able to negotiate with each other. Again, agents implement intelligent algorithms for performingoptimized transactions here. Humans can authorize agents for performing the three indicatedfunctionalities on behalf of them, according specified configurations and rules of the users. Inthe 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 negoti-ations 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 ofInterMarket.

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 In-ternet (compare with Figure3.3). Mobile agents are responsible for the communication betweenclients and the e-marketplace. They carry the configuration data to even more than one market-place. Nevertheless, mobile agents own also a kind of intelligence, such as for route planningand reacting on special events (e.g. e-marketplace are not available, no actions could be done onthe current market). They access e-marketplaces on behalf of their users and therefore use theirusers’ identity.

The other agent types are the stationary agents. They can be configured by mobile agents oreven by users via the InterMarket application server for performing special tasks on the market-place. Stationary agents implement the agent-based functionality of the three above-mentionedcategories. Stationary agents implement the intelligent techniques and strategies for participatingin auctions, requests and negotiations on the one side and on the other side they cover businessworkflow capabilities. Thus, you can configure several business tasks directly to the agent oryou can give a goal and the agent can autonomously create a workflow for reaching the givenobjective. This leads to an advanced automation of business transactions. On marketplaces onlythe stationary agents perform tasks and encapsulate the access to the application server. Mobileagents have to transmit their configurations onto stationary agents for fulfilling tasks. Stationaryagents reside on the marketplace for being activated, configured, and started and for performingwork. An important goal of InterMarket is the reuse of most of the functionality by contactingthe application server of an existing e-commerce platform.

Figure3.4shows the internal structure of InterMarket. It combines two existing software so-lutions. It is not a monolithic block. Thus, InterMarket forms a unit for external access, butdivides into separate parts inside, which are loosely coupled. InterMarket should integrate a mo-bile agent system with an e-commerce application server platform. Both form logical units insideInterMarket and communicate via remote APIs or standard communication protocols. Mobileagents 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 onthe marketplace over the remote connection of both parts of InterMarket.

32


Figure 3.4.:Inside the InterMarket e-marketplace.

Figure 3.5.:Interconnection of agent-mediated e-commerce.

The last Figure3.5 describes a vision of the InterMarket approach. It introduces the mo-bile 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 high-est automation level. The mobile agent technology owns, therefore, some useful features suchas platform-independency, or being a complete and consistent pattern for communication. Othere-commerce solutions can be adapted to the InterMarket approach with additional current tech-niques such as Web Services and XML. Thus, a company is able to use a large offer of trading

33


opportunities using any participant or marketplace in the agent-based e-commerce network. Adirect connection between customers and suppliers can be realized that way.

3.4. Why using Mobile Agents?

As shown in the further section, there is a need to expand e-commerce functionality. Currente-commerce solutions provide catalog-based transactions and simple forms of electronic auc-tions and negotiations. However, user demands increase. They want to manage more complextransactions 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, whichleads to ”a static impersonal bidding experience”. Thus, their approach focuses on specify-ing multi-attribute preferences for enabling advanced brokering with mobile agents. Also otherteams [28, 81] try to implement enhanced agent-mediated techniques for supporting more so-phisticated e-commerce abilities for the businesses.

Another argument for the insert of mobile agents following Harrison and Caglayan [13] is theextremely fast growth of the information amount in the WWW. That’s why it is today and inthe future not possible for a human to find useful information without flexible and intelligentassistants. In conclusion Harrison and Caglayan see the advantages of mobile agents on oneside moving as representatives for the user through the Web, which collect data and informationand observe events with the opportunity to react [13, p. 73, p. 214] and on the other side thepracticable use of mobile agents for connecting mobile devices [13, p. 112]. In addition, theydon’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 advancedtechniques. The next section should introduce, with regard to Section2.2.4, the advantages of themobile agent technology for e-marketplaces compared to the use of stationary agents with staticclient-server models for the communication and for justifying the decisions for InterMarket.

The good properties of mobile agent technology forconnecting mobile devicessuch as PDA,mobile phone, or laptop are a big reason for using mobile agents within InterMarket. Mobileagents seem to be suitable, because of their low network requirements (less connections withsmall size) regarding to small power and memory facilities as well as slow connections and smallnetwork bandwidth coupled with the problem of not guaranteeing open or available connectionsevery time.

Mobile agents can represent a user and perform tasks on e-marketplaces even in the casethat the user is offline. If the mobile agents have finished work, they just wait for the homeserver being online for returning back. So mobile agents help toabstract from online time. Inaddition, mobile agents lead to anabstraction from regional restrictions because one or moremobile agents can represent a user on different e-marketplaces everywhere in the world at thesame time. These two features introduce the ability for the user, to be able for global businessround the clock. As consequence mobile agents can wide the trading opportunities for a userby connecting more than one e-marketplace. Because mobile agent technology is a kind ofcommunicational framework, e-marketplaces or e-commerce applications, which are connectedwith it, can be developed from different vendors. Mobile agents supportinteroperability andalso introduceplatform 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

3.4. Why using Mobile Agents?

address and they can intelligently decide, which address they choose. This leads to advantagesif one address of the user is not available at all and following to optimize support.

Another big point is the communication. Mobile agents cantransport any kind of data suchas XML-based data , HTML, graphic data, or even Java objects. Because agents use for theircommunication flexible and exchangeable protocols, they can be easily adapted for interactionwith other agents. Two agents exchange information about their communication facilities beforestarting the real interaction. Mobile agents introducestate-sensitive communication, becausethey can store intermediary data.

Mobile agents introduce anintegrated standard data format. The agents cover their internaldata representation and allow users to manipulate the data only by using defined interfaces suchas messages and specific communication protocols.

Using mobile agents, usersreduce effort for maintaining client applications and communi-cation protocols because the mobile agents cover all the problems. The user interface only needsto 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 themaintenance 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 pos-sibilities for solving problems and they can learn and adapt with time to user needs.Mobileagents are configurablefor adapting to user experience.

Finally, by using mobile agents for mobile devices as well as for normal hosts, it provides auniform design and adds good maintenance opportunities by specifyinguniform, small, and lessinterfaces and componentswith no redundancy in comparison to implementing InterMarketwith multiple techniques for separated mobile and static access to the agent-based functionalityof 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

4. InterMarket Requirements

Chapter four introduces the requirements analysis for the InterMarkt solution. The topic is di-vided into two parts. First, the agent-based functional requirements are developed for describingthe different agent types, communicational demands, mobile access, and the usecases, whichcover agent-based activities on the InterMarket e-marketplace. The non-functional requirementsare presented with the second part by considering the key features for an e-marketplace with alower detail. Although Enfinity being an adaptable framework mainly supports all these require-ments some special points should be pointed out including requirements for a combined solutionof Tracy and Enfinity. These features will be evaluated too in Chapter 6.

4.1. Agent-based Functional Requirements

4.1.1. 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. Figure4.1 depicts the actors of the agent-based functions of InterMarket, which are described more detailed within this sub-section.

Figure 4.1.:Actors of the agent-based features.

Human UsersHuman users own the initial role for any activity, which is processed on InterMarket. They cancreate, configure, and start software agents of the e-marketplace solution for processing tasks ac-cording to the agent-based functionality. Users can apply mobile agents for performing business

37


tasks on one or multiple e-marketplaces by using mobile devices or directly via the InterMarketapplication server. Users can also directly authorize stationary task agents via the applicationserver of InterMarket for local processing of work. Humans program agents with specific pa-rameters for concrete tasks, give rules for behavior in dynamic processes such as auction ornegotiation, 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 onbehalf of them.

Software AgentsSoftware agents autonomously perform work on the e-marketplace. There exist two types ofagents in InterMarket. The first agent type acts behalf on human users after being initially con-figured and started. These agents process the given tasks and finally present results of theirwork to their users. The second agent type autonomously performs management jobs on theInterMarket 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 implementspecial communication protocols for any agent interaction activity, such as data exchange forsearching products, or for configuring agents to bid in an auction. These protocols consists ofa state machine, which generates well-defined state transitions and ensures correctness of thetransformation, and a set of methods, which enable agents to perform complex communicationswith 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 ex-changing authentication and authorization information is the most important one and should beimplemented by every agent on the InterMarket marketplace.

As second, the agents require a session handling. Sessions are demanded for ensuring a cor-rect and efficient processing of several agent interactions in parallel within a single agent. Eachsession manages the communication protocol state machine for ensuring state and the data dic-tionary, which encapsulates all data that is exchanged only within a single session. Sessionhandling supports transactional behavior and increases security, reliability, and persistence foragents.

Mobile Communication AgentsInterMarket applies mobile agents for realizing mobile access to the marketplace. Mobile agentsare special representatives of their users and transport configuration data for specific tasks, rulesfor intelligent behavior, authentication information to get access on behalf of their users, andoptionally migration route information. That’s why they are called mobile communication agentsbecause they do not execute functionality. Thus, they have no access to marketplace functionalityand have to interact with specific stationary task agents for executing tasks. Additionally, mobileagents are executed in a special restricted area of the InterMarket agent server for ensuringsecurity for both, agents and agent server.

Stationary Manager AgentThese agents provide a scale access to stationary task agents within InterMarket and check theauthentication information of incoming mobile agents for assigning permissions to the mobileagents. 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 frommobile agents and also from the InterMarket application server (via an agent server). Stationary

38


manager agents manage a dynamically set of stationary task agents and support the only accessto the task agents in the contact phase. The name of a manager agent is known to the system forensuring contact to it.

Figure 4.2.:Life-cycle for a stationary manager agent.

Figure4.2 presents the life-cycle of manager agents. After a manager agent is created andstarted, it waits for messages in theidle state. If an inquirer (mobile agent, application servervia agent server) contacts the manager agent, it changes its state toactive and performs therequested jobs (check authentication of mobile agents, or activate a stationary task agent andreturn a reference to it). After finishing a request, the agent returns back intoidle state andwaits for new requests.

Figure 4.3.:Getting contact to a stationary task agent.

Figure4.3contains a collaboration diagram for explaining the process for an inquirer (mobileagent or application server via agent server) to get contact to a stationary task agent. The inquirersends first a message to the manager agent, which requests a task agent. The manager agentdetermines an idle task agent and sends it an activation message. The confirmation message ofthe task agent includes a unique reference (e.g. name of the agent), which the manager agentreceives. The manager agent sends the reference with a message to the inquirer. Hence, a directbi-directional communication can be started between an inquirer and a stationary task agent.

39


Stationary Task AgentStationary tasks agents process the business logic of the agent-based functionality of InterMar-ket. They can be configured on the one side by mobile agents and on the other side by usersdirectly via the application server. The tasks of the stationary task agents are described in detailin subsection4.1.5. Task agents encapsulate and access the application server for reusing ex-isting functionality and for ensuring security and scalability. Task agents only extend standardmarketplace functionality by adding agent-based functionality, which means that existing objectssuch as orders, shopping carts, pre-contracts, or requests will be managed with the applicationserver using the existing mechanisms and functions. Thus, the responsibility for business pro-cesses remains at the application server. Task agents reside in a special pool, which is managedby the manager agent for fasten execution and support better management of agent server per-formance (by observing the number of agents and their workload). Task agents can be activatedfrom the pool for performing tasks and they fall back into the pool after finishing work. If taskagents have to wait for longer time periods, it is possible to use these agents for multiple tasksin parallel, if no task is time critical. Additionally, they implement three features, which supporttheir 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 writingprocesses of different business tasks of the agent. Thus, the dictionary enables differentbusiness processes to exchange information, which are produced by some tasks and aredemanded for execution by following tasks in a workflow.

2. A workflow engine is needed for managing, assembling, and controlling the processing ofseveral business steps in a workflow. stationary task agents can be configured to executeprocesses 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 dynamictransaction models such as auction, request and negotiation, which can be adapted byspecial rules that can be configured by an inquirer.

Figure4.4depicts the task agent life cycle. After being created and started, the agent residesidle in the task agent pool having the statepooled . The agent can be activated in this stateby the manager agent changing in theactive state. The agent performs tasks after beingconfigured in this state. This proceeding is only finished, if the tasks are finished, cancelled, orstopped after error. The agent returns inpooled state with reset status information in any ofthese cases.

4.1.2. The Main Usecase Model

The main usecase model introduces a consistent approach for the agent-based functionality ofInterMarket. This subsection starts with describing two scenarios, which illustrate the proceed-ing 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 busi-ness process execution by only performing management tasks in the background.

The first scenario in Figure4.5describes the remote access to InterMarket via mobile agentsfrom client systems, which own an agent server, such as mobile devices or PC/workstations. A

40


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 op-tionally with a migration route. If the agent was started, it indicates the (first) e-marketplace andmigrates there. If the agent has not received route information from its user, it starts retrievingdata of suitable e-marketplaces on special nodes in the agent network before migrating to thefirst marketplace. The mobile agent authenticates at the e-marketplace and contacts a stationarytask agent for transmitting data after arriving on an e-marketplace. The mobile agent configuresa task agent with the tasks he was given by its user and starts the processing of a workflow oftasks at the marketplace. The task agent performs the workflow and sends back the results of theprocessing to the mobile agent, if all tasks are completed. If the mobile agent was configuredfor visiting multiple marketplaces, it would store the intermediate results and would afterwardsmigrate to additional marketplaces. If the mobile agent has finished his work it migrates homefor presenting its results to the user. Regarding to the configuration, the user can be involvedinto decision-making processes by a mobile agent after certain intermediate steps in the businessworkflow. The user analyzes the results of the mobile agent, can make decisions, and maybeinvoke another agent-based processing.

Figure4.6presents the second scenario, which should be considered here. A user can directlyconfigure a stationary task agent using the traditional way with storefront request to the appli-cation server. The application server transparently contacts a proper agent via an InterMarketagent server for configuring and starting the agent. After configuration, the task agent startslocally processing the tasks and returns back the results to the application server, if all tasksare 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 berecognized by the user when he loges onto InterMarket next time.

It exists another scenario for business processing within InterMarket. The user also can usemobile agents directly via the InterMarket application server. However, this scenario seems tobe a mixture of both, which are described yet. So you can take the first left two swimlines fromscenario two and combine them with the two right swimlines from scenario one.

41


Figure 4.5.:Mobile access to the marketplace activity diagram.

The overall main usecase model is introduced with Figure4.7 following the scenarios, butindependent from special tasks. The model reflects all activities in InterMarket, which involveagents. Please take the main usecase model as an overview and refer to the following subsectionsfor detailed information.

Figure 4.6.:Stationary access to the marketplace activity diagram.

42


Figure 4.7.:Main model usecase diagram.

4.1.3. The Configure Agent Usecase

Description This usecase covers the capabilities of agents to be configured for specificbusiness processes on the InterMarket marketplace. With InterMarket, it ispossible to configure agents not only for single tasks, but additionally for awhole task workflow. This opportunity is the main feature of the configureagent usecase. The configuration of an agent with problem-specific data for aspecial tasks is defined using the special sub-usecases, which are shown rightin Figure4.8. Because of the indicated workflow capabilities it is possible tocombine the configuration of multiple of the denoted sub-usecases. The con-figuration of an agent is absolutely transparent, which means that the differentconfiguration scenarios, which are described with the scenario of this usecase,always follow the same communication protocol. The indicated sub-usecaseswill not be described because they play no role for the system design.

Precondition The agent to be configured is alive and idle.Postcondition The agent to be configured is correctly and completely configured and is able

to start proceeding.Error The configuration data is incorrect, incomplete, or senseless.Error handling Send error message to the configuring instance: user or mobile agent.Actors Originator, Committer being roles for the actors: user, mobile communication

agent, stationary task agentThe actors used in the diagram stand for roles, which actors from the mainusecase model can play in InterMarket regarding to the configure usecase.This fact emphasizes the multiple application of the configure agent processin InterMarket. Which actor plays what role is described with the scenariosbelow.

Scenarios 1. A user (originator) configures a stationary task agent (committer) via theapplication server for local work on the current marketplace. The user sendsan HTTP request to the marketplace application server including the demandfor agent-based services. Application server contacts a stationary task agent

43


and sends messages to the agent covering the configuration parameters.2. A user (originator) configures a mobile agent (committer) using the appli-cation server for remote work at multiple marketplaces. Therefore the usersends an HTTP request including the task data and optionally the route ofe-marketplaces to be visited to the application server. The application servercontacts a mobile agent and sends messages to the agent covering the config-uration parameters.3. A user (originator) configures a mobile agent (committer) from its localhost or portable medium for performing tasks on multiple marketplaces. Thus,the client application creates a mobile agent and passes data including theconfiguration 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 mobileagent contacts a stationary task agent and sends following the configurationdata via messages.

Figure 4.8.:Configure agent usecase diagram.

4.1.4. The Migrate Usecase

Description Migration describes the capability of mobile agents to move through a het-erogeneous network. Mobile agents can transport their code, state and datafrom one agent server to another (for more see Chapter2). This denotes forInterMarket that mobile agents can be used for accessing marketplaces, initi-ating and performing tasks, and finally returning results back to the user. Thetransactions will be conducted on behalf of the agent’s user. This proceedingenables InterMarket to offer two new features, mentioned in Chapter3:

44


mobile access to marketplaces and the interconnection of multiple market-places. Nevertheless, it also is possible to access InterMarket from stationarynetwork-connected PCs/ workstations. The only necessary facility is an agentserver. Because the migration is a straight-forward mechanisms, no additionalsub-usecases follow.

Precondition The mobile agent was correctly configured with task data and route informa-tion.

Postcondition The mobile agent has migrated and is correctly restarted on the destinationagent server.

Error The network connection fails.Error handling The mobile agent tries again to migrate or if possible choose another destina-

tion from its route. If both are not possible the mobile agent sends an errormessage to the user if it is on its home server or the agent waits until his newdestination (e.g. also the home server) is again available.

Actors Mobile communication agentScenarios 1. The mobile agent migrates from a home agent server (e.g. on a PC/ work-

station or portable medium) to the e-marketplace according to its route set-tings.2. The mobile agent migrates from a marketplace agent server to anothere-marketplace according to its route settings.3. The mobile agent migrates from a marketplace agent server back home.

4.1.5. The Perform Tasks Usecase

Description The perform tasks usecase describes the ability of stationary task agents toprocess one or multiple business processes in a workflow. Thereby, taskagents follow a given configuration or they also can autonomously assemblebusiness steps to form a workflow for reaching a configured goal. Therefore,stationary task agents implement several business processes for realizing theexecution of a business workflow. These business processes are included withspecial sub-usecases in the perform tasks usecase model. Most of the busi-ness tasks use access to the InterMarket application server for reusing existingfunctionality and for accessing the marketplace’s database. The two first mainobjectives of InterMarket (see Chapter 3) are realized with the perform tasksusecase. On the one side this usecase describes the automation capabilities ofstationary tasks agents through forming business workflows and on the otherside some of the sub-usecases realize the intelligent trading and negotiationtechniques. A simple example for a workflow is presented subsequent to thisusecase description.

Precondition The stationary task agent was correctly and completely configured.Postcondition The stationary task agent has successfully finished its tasks and has saved the

final results.Error A sub task produces an error.Error handling 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 mobileagent).

45


Actors Stationary task agentScenario 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 startsprocessing the first task. If necessary, the agent contacts the application serverfor initializing processes there and receiving results. The agent performs ownbusiness logic for any business process. If the agent completes the currenttask, the produced results were saved, because they can be the foundation offollowing tasks in the workflow. After completing all tasks, the stationarytask agent saves the final results and ends processing. How unique tasks canbe processed is explained with the following sub-usecases.

Figure 4.9.:Perform tasks usecase diagram.

The business workflow shown with Figure4.10describes an ordering process. In this example,the user has determined that he is willing to order a product with a certain price. Thus, the agentworkflow starts with searching the product catalogs of the e-marketplace. If the price constraintis fulfilled after a possible comparison of multiple product items, the agent places an order andfollowing that generates an order confirmation for the user. But what happens, if the price isnot suitable? Thus, the agent extends the workflow by performing additional tasks. In thisexample, the stationary task agent conducts an offer request to a supplier and if necessary afterthe offer has returned and the price is always not suitable, the agent starts and performs directprice negotiations with certain marketplace participants. If the agent does not succeed with allthese steps, an error message will be generated for the user. This is of course only a simpleexample. Agents can process even more complex business workflows.

46


Figure 4.10.:Example for a simple business workflow.

Perform Agent-based SearchDescription 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 Stationary task agentScenario 1. First the agent loads the search query data and criteria from the data dictio-

nary. Then, the agent connects to and sends the query data to the applicationserver. Now, the application server forms a database query and queries follow-ing the database, while the agent is waiting. After completion of the databaserequest the application server sends back the search results. If an error hasoccurred, the search results contain an error message. The agent receives andstores the results.

Perform Agent-based CompareDescription The stationary task agent can compare data according to given compare crite-

ria.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 agentScenario 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


tionary task agent performs the comparison algorithm. After finishing thework the stationary task agent stores the search results.

Figure 4.11.:Agent-based search activity diagram.

Perform Agent-based OrderDescription 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 agentScenario 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, theagent waits until a confirmation message arrives. Now, the application serveruses the order data to form a database order request. Following that, the ap-plication server stores the order in the database of the marketplace. The appli-cation server sends a confirmation back to the agent to inform the agent aboutorder placement. The agent receives the response and stores the confirmationin the data dictionary.

Perform Agent-based RequestDescription 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


Postcondition The stationary task agent has stored offers (following RFQ) or offer requests(following RFP).

Error The request data is incorrect or incomplete. The connection to the applicationserver fails.

Error handling The stationary task agent places an error message.Actors Stationary task agentScenario 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 followingwaits for confirmation. Now, the application server performs its work such astransforming from the request data an offer (RFP) or offer request (RFQ) andstoring the request then in the database regarding to the users that should beaddressed.The application server sends a confirmation to the agent to confirm the agentthe completed incoming of its requests. The agent receives and stores the con-firmation and passes again in state waiting until a response comes in. Sometime can be passed after this proceeding until another marketplace participantacts as responder and reacts on the request of the agent. This responder placesa response in the system, so that the application server can send the offer oroffer request to the agent. Now the agent receives and stores the response inthe data dictionary.

Perform Agent-based Auction BiddingDescription 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 bid-

ding 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 agentcannot make bids. And third the connection to the Application Server canfail.

Error handling The stationary task agent stores an error message.Actors Stationary task agentScenario 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 statusrequest to the application server before going in the wait state. The applicationserver forms a status request and queries the database to retrieve the statusinformation for the wished auction. When the application server has the statusextracted, it sends back auction status to the waiting agent. Now the real logicof the agent comes into game. First thing to test, if the auction is always activeand 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. Ifthe auction is yet active the agent performs the decision-making logic, whichwas initially loaded with user bidding preferences and strategies. Now twodifferent results are possible. If the logic induces the agent to place a new bid,

49


the stationary task agent sends the bidding data to the application server andwaits then for confirmation. The application server forms a bidding and storesit in the database. Following the application server sends back a confirmationto the agent. The agent receives and stores the confirmation. Then the agentwill perform absolutely the same it would do, if the second case, the logicinduces the agent not to bid, was initiated. The agent waits a certain timeperiod before starting again the whole process with sending an auction statusrequest to the application server.

Figure 4.12.:Agent-based order activity diagram.

Figure 4.13.:Agent-based request activity diagram.

50


Figure 4.14.:Agent-based auction bidding activity diagram.

Perform Agent-based NegotiationDescription The stationary task agent can perform negotiations with other businesses via

the application server. Therefore, it is possible to use an agent in agent-to-agent or agent-to-human negotiations. It should be absolutely transparentwhat actors process the negotiation. Additionally, agents can be authorizedby users in negotiations on the requesting and on the responding side. Theapplication server stores in every step the offered pre-contracts as a confidantfor 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


Scenario 1. The agent will be used for sending requests in a negotiation. The agentretrieves the negotiation data from the data dictionary and fills with this thelogical negotiation data structure. Following, the agent performs the negoti-ation logic, based on the logical data structure, for finding the first negotia-tion data to be send to the application server. The application server receivesthe negotiation request and forms a negotiation object that will be stored inthe database. The application server also informs the trading partner that theagent wants to negotiate. After all, the application server sends a confirmationto the stationary task agent, which waits for that. Now, the agent stores theconfirmation and waits again until the trading partner has placed a responsein the application server, so that the server sends a response to the agent. Thestationary task agent stores the response regarding to the logical negotiationdata structure and performs then again the intelligent negotiation logic, if theresponse was still active. The logic induces the agent to send or not to sendanother request, which would be starting the whole process again. Such a re-quest can also include accept or reject information instead of new negotiationproduct data. If the response was not active anymore, it can be containingdata such as accept or reject information.

Figure 4.15.:Agent-based negotiation activity diagram.

52


Optional scenarios 2. The stationary task agent will be used for responding on negotiation re-quests. However, for the agent this scenario is absolutely similar to first,because the steps to be performed are similar. The scenario also starts withthe user assigning the agent to participate in a negotiation. That can be seenfrom the agent’s point of view, that the agent in this scenario again sends therequests. The agent also sends the negotiation responses to the applicationserver, which routes the response to the other negotiation partner, waiting fol-lowing for further requests.

4.1.6. The Return Results Usecase

Description This usecase describes the process of agents, which send back results afterhaving fulfilled tasks. The sub-usecases in Figure4.16extend this basis func-tionality for returning special results according to the configuration and taskperforming, which were finished before. Of course, it is possible to returnmultiple result data in parallel, if an agent was configured to perform multipletasks before. The sub-usecases are not described anymore, because they haveno impact on the system design.

Precondition Agent has finished all tasks and has stored final results. Mobile agents haveto be migrated to their home agent server.

Postcondition Result data was completely sent. The stationary task agents become idle andthe mobile agents will be killed, if no follow-up order is initiated.

Error -Error Handling -Actors Sender, Receiver standing for roles, which the following actors can play: user,

mobile communication agent, stationary task agentThe 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 theyplay according to the configuration process, which has to be done before. Anactor playing originator (committer) role in the configure agent usecase willplay the receiver (sender) role here.

Scenarios 1. The stationary task agent (sender) sends a message containing the resultsto the user (receiver) via the application server. After receiving a confirmationthe stationary task agent is ready.2. The mobile agent (sender) returns results via the application server back tothe user (receiver). So the mobile agent sends the result data with a messageto the stationary task agent, which mediates the message to the applicationserver. After receiving the confirmation message from the stationary taskagent the mobile agent has finished.3. The stationary task agent (sender) sends a message containing the resultdata to the originating mobile agent (receiver). After receiving a confirmationthe agent is ready.4. The mobile agent (sender) returns the results by sending a message back tothe user (receiver) on its private home agent server (e.g. on a PC/ workstationor mobile device). After receiving the confirmation the agent has finished.

53


Figure 4.16.:Return results usecase diagram.

4.2. Non-Functional Requirements

Appointing the non-functional requirements for the InterMarket solution leads to some prob-lems. It is not possible to determine the requirements for any non-functionality with hard num-bers for ensuring an accurate specification. This problem depends on some characteristics ofInternet-based and agent-based applications. First of all, the InterMarket approach describesnot a concrete installation, but even more a framework, which must be able to adapt to a multi-tude of different requirements. Thus, it is not possible to specify hard numbers, because on theone 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 non-functional requirements, because these values completely depending on specific installations andtheir special demands. Furthermore, there exist no assumptions or constrains for the percentalfraction of agent-based tasks at the whole processing of InterMarket. Following, it is not possi-ble to determine hard numbers for non-functional requirements for the agent-based componentsof InterMarket. Finally, it is nothing known about the time effort and the demands on systemresources for executing agent-based features. The InterMarket non-functional requirements area set of directives and recommendations as result of the indicated problems.

4.2.1. Integration of Application Server and Agent Server

The foundation for InterMarket should be the combination of a standard e-commerce platformcoupled with a mobile agent system. Therefore, the marketplace should reuse existing softwarefor focusing on the new advanced agent-based features. Both underlying applications should bebi-directionally integrated , because in InterMarket on the one side agents access the applica-tion server for using marketplace functionality and on the other side the application server makesusage of agent functionality. If no complete integration of both solutions is realizable, both appli-cations need to be connected via aremote bi-directional communication mechanism. This is

54


important, because the standard business logic remains on the application server and so InterMar-ket advances from the already implemented features there, such as transaction-based processing,scalability, reliability, and security. At the agent server reside mobile communication agents andstationary task agents, which implement the agent-based features, described in Chapter3.

4.2.2. Portability of the Agent Server

The most important application area for mobile agents is the connection of mobile devices tothe e-marketplace. So it must be possible to migrate an agent server on those small mediumswith low performance and transmission power. Thus, a downsizing of an agent server mustbe 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 toensure efficient processing of mobile agent tasks.

4.2.3. Performance

Finding numbers for performance requirements is very hard, because e-marketplace applicationsdo not refer to normal Web sites, such as online shops with high visitor traffic and much lessorders a day. Requirements for e-marketplaces can increase even during lifetime, if acceptanceof the market increases, for example. Besides, e-marketplaces are characterized with a highnumber 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 andeven 690,000 to 1.3 million requests per day [40, 41]. In opposite, Intershop gives for a largescenario the numbers between 847,000 and 1.2 millions orders per day and 5.4 million up to6.7 million requests per day. Although, these numbers are more suitable for e-procurementsolutions and other B2B applications, it could be possible to even have such a kind of trafficon an e-marketplace. Following these scenarios, an e-marketplace solution must support similarnumbers 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 impatientif response times outrange the denoted interval. However, response times should be as fastas possible. Especially, the main page of an e-marketplace solution should be very fast. Thesystem should extensively make usage of caching strategies, such as caching static Web pagesor caching database content for ensuring maximum speed. Additionally, multimedia and graphiccontent 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 supporta certain workload, meaning the concurrently execution of a number of requests. To size a mar-ketplace solution for handling all possible scenarios it should be sized following special peakrequirements. Because there exist no universal statements for the workload of an e-commercesystem the following example, emulated from [42, p.54], could give an idea how to size it prop-erly.

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


It can be calculated first the number of parallel sessions. Having 98,000 users, each connect-ing 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 scenarioassumes that all users work within 10 hours. Thus, the number of parallel sessions can be easilycalculated: 735,000 / 600 = 1225. However, this number does not tell us something about thereal workload, which is denoted with parallel requests, because parallel sessions does not implyprocessing tasks on the server at any time. Parallel requests indicate the real number of activeparallel server tasks. In the worst case it is possible that the number of parallel sessions evenequals the number of parallel requests at a time. This is relatively improbable. Supposing theaverage thinking time of a user to be about 10 seconds and the marketplace servers respond inabout 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 marketplaceservers in the scenario. If the system would be able to respond in only 3 seconds, the number ofconcurrent requests can be decreased down to 3 / (10 + 3) x 1225 = 282.

For reaching overall good performance, the marketplace solution should support server clus-ters, which offer the option for extending the system’s configuration, if necessary. The systemconfiguration 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 pow-erful 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 Gigahertzand higher), fastest bus communication, high maximum RAM capabilities (4 Gbyte), and fastand large hard disks (SCSI). Network connections should be also as fast as possible, such as 1Gbit/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, andorders 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-basedcomponents should be able to adapt to the overall requirements.

4.2.4. 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 onlya 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 scala-bility for an overall increasing number of users. An e-marketplace application has to focus ontwo approaches for reaching the goals. On the one side software scalability and on the otherside hardware scalability. The goal of these techniques is to extend system resources, meaningsoftware components and hardware facilities to adapt to every possible amount of users. Thescalability hits all application layers and should provide scale access to the system by usingserver clusters and a scale database access by implementing scale connections to a high-scalingdatabase product. The software scalability is supports by distributed components, services, andsoftware servers. The hardware scalability is reached through hardware server cluster and the

56


network management for the hosts of a cluster and their interaction. Finally, Load balancingmechanisms (hardware and software) can improve scalability of e- marketplace solutions.

4.2.5. Availability

E- marketplaces must be mostly available round the clock on 365 days a year, because they aredesigned for business transaction. This means, that every lost minute means lost money. There-fore, the system should support multiple redundant facilities for each of the three applicationlayers. Each component (software or hardware) should exist at least twice. This induces multi-ple access points to the marketplace, such as Web server cluster, multiple application servers anddistributed business components for redundant business logic, and even multiple databases.

This proceeding enables the e-marketplace two features: Through clusters, single points offailures were prevented, because if one server or component fails another can take over. On theother 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 activeparts.

A session failover mechanism should ensure that in case of a server failure or down anotherserver can complete active sessions. Client requests to unavailable or unresponsive componentswill automatically fall over to an available component transparently to the requester. This mech-anism should also give the ability, that if an access point to the marketplace fails, even anotheraccess point can route requests to the correct servers with the active sessions.

4.2.6. Reliability

With the marketplace solution the business logic should be separated in a special layer withinan n-tier application, so that all other parts of the system are forced to consistently use this oneinstance 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 usedwithin the session, have to be managed that way that they are consistent and available (sessiontracking mechanism), even in case of one server of a server cluster fails and the user requestsare routed or processed with another server (fault tolerance mechanism). All transactions, per-formed during a session, have to be persistently stored for recoverability in error case to ensuretransactional and database integrity.

The marketplace must ensure transaction-based processing within sessions and even over mul-tiple integrated resources (database, integrated legacy systems) for guaranteeing the ACID prop-erties 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 withconsistent session data has to be implemented to withstand power outages and hard- or softwareerrors.

4.2.7. Security

For transmission security, meaning securing the whole external communication between clientsand the system, the marketplace has to offer an encryption mechanism such as SSL. This com-munication 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


implementing only specific defined access points to the system, for both mobile agents (specialgateway agent server) and HTTP requests (Web server).

The internal communication also should be secured for preventing someone, who has passedthe outer security barriers, from emulating internal communication. Therefore, internal secretkeys should be exchanged between all servers. This is very important for the agent access toapplication server services. And additionally, the database access should also be secured withspecial logins and passwords, every server owns a unique one. Because internal servers can hidethe 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, userscommunicate with the system only after a correct login. Every access to the marketplace issecured for both, agents and users, with logging mechanisms. This is additionally supportedwith authorization mechanisms and permission and role concepts for different actors (agents andusers). According to a role an actor plays, it is able to invoke services and to access or changeinformation on the marketplace.

Another important point is the prevention from misuse of user sessions. Therefore, conceptsare needed for ensuring that no person can use session information of any other user. For exam-ple, if a user interacts with the marketplace via a Web browser and terminates the session, it isnot allowed that any user specific sensitive data can be reproduced with the Web browser historyor Cookies. Halted sessions, that are incorrectly broken up and not active since a certain timeperiod have to be deleted, so that no actor, agent or user, can apply session specific informationof another user.

Finally, for the agent technology special security requirements exist, because mobile agentsare some kind of external code executed on the marketplace’s agent server. Because fewer as-sumptions on the trust of mobile agents can be made, it is important to increase knowledge aboutagents and their owners and/or to limit the resources, agents can use. Therefore, Java offers alot of build-in mechanisms such as Java Sandbox, bytecode verification, code signing, customclass loaders and security managers. With these techniques it should be possible to realize anagent-specific authentication and authorization model, securing the mobile agent execution. Onthe other side the marketplace should offer mechanisms for saving the agent from maliciousaccess and change from agent servers. Mobile agents must be prevented from interception andmanipulation by external agent servers.

4.2.8. Extensibility and Flexibility

First point is to use a flexible three-tier architecture for ensuring good maintainability and sepa-rated advancement of components of a single tier independently from other tiers. The separationof presentation, business and database tier offers flexible capabilities for adapting the system tonewer performance, scalability and availability requirements. The marketplace should be buildusing as many standards as possible, for providing clearly defined interfaces and mechanisms forflexible and easy further development.

Another requirement is a flexible extension of the system’s business logic or the extensionand adoption of the presentation logic according to requirements of specific projects. On theone side it must be possible to implement new business logic and components in short timeand to integrate this logic with existing business logic. On the other side, third-party softwaresolutions have to be integrated easily such as marketplace participant’s ERP systems as wellas applications of service providers. Therefore, the solution should offer sophisticated APIsand tools for easy designing new business processes, deploying and generating code as well

58

4.3. Standard Functional Requirements

as for adapting presentation logic of the marketplace for a complete integration. Regarding topresentation of the marketplace, it should provide capabilities for accessing the marketplace fromdifferent 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 marketplaceusing 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 manydifferent data and exchange formats or to fast integrate new data exchange or communicationtechniques with the system.

4.2.9. Personalization and Internationalization

Personalization and internationalization are important to reach two goals. First personalizationcovers capabilities for tracking user sessions and to adapt the look and feel as well as the handlingof the marketplace to user preferences and needs. So the marketplace has to offer opportunitiesfor the user to adapt the appearance of the marketplace to personal needs. The marketplace offerscustomer enrollment and other membership services.

The second is the ability of the marketplace to serve global trade. Therefore, the system has tooffer multi-currency and multi-language support. This should be possible even in parallel. Prod-ucts or offers can differ from buyers currency. Thus the system has to offer facilities to convertcurrencies, even at runtime. Multiple languages should be supported for giving participants theability to work on the marketplace in their native language. This increases, of course, also thepersonal user experience.

4.3. Standard Functional Requirements

The reader will miss standard e-marketplace functionality. This topic is not considered withinthis paper, because it forms the basis of InterMarket and can be seen as foundation given with theusage of the e-commerce platform Enfinity. In fact, standard functionality does not influence theInterMarket approach. InterMarket adds agent-based functions on top of standard marketplacefunctionality. However, this additional functions use a set of low level features, which everymarketplace solution offers. A main point for not discussing standard functionality is that thesefeatures are implemented with the Enfinity solution in combination with an add-on component.Therefore, it is referred to following references [.., ...] published by Intershop. Indeed, abso-lutely basic knowledge is introduced with Section 2.1. To fulfill the InterMarket demands, it issufficient to use additionally to Enfinity the Procurement cartridge from Intershop upgrading thebasic Enfinity to a complete marketplace solution including facilities for auctions, negotiationsand multi-byuer to multi-supplier aggregation.

59


60

5. Introduction of the underlyingApplications

This chapter presents the two software applications, which should be reused for building upInterMarket. 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 thespecific positions to continuative literature.

5.1. Enfinity Platform

The e-commerce platform Enfinity is the foundation of the InterMarket solution and should bepresented 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 communica-tion, the presentation of Enfinity is finished by describing a storefront request workflow to givethe reader an insight into the processing inside the Enfinity system. Following, a special Enfinityadd-on component called Procurement Solution is introduced with two sub-sections, showingthe technical integration of the component and added features. The second part of the sectionoffers a general insight at the Procurement solution, which bases on Enfinity. The main businessmodel of the component is introduced after mentioning the general technical architecture andthe actors. Finally, the description is finished by an itemization of the main functionality of theProcurement Solution.

5.1.1. Enfinity in General

Enfinity is a platform, especially developed for targeting the development of e-commerce ap-plications and offers the core functionality for building software systems regarding to all knownareas of e-commerce. Enfinity is already in its basic version an enterprise-class software packagefor selling products and services of a company in the World Wide Web. Thus, Enfinity imple-ments 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 func-tionality and for adding third-party systems and extensions as well as for integrating intelligentmerchandising add-ons (e.g. auction component). Thus, it is possible to integrate Enfinity inthe existing software infrastructure of a company, because it offers interfaces to other standardproducts such as ERP software (e.g. SAP R/3), other business systems as from Commerce One,Internet applications, and Internet services.

61

5. Introduction of the underlying Applications

Another main key feature of Enfinity is the separation of business logic management and thecore code using configurable and adaptable business flows (pipelines) composed of consecutiveexecuted reusable logical steps. Each of these steps, called pipelet, implements a specific part ofthe business logic. In addition, with the pipeline concept the business logic is separated from thepresentation logic by introducing special logical steps, named templates.

Enfinity is fully developed based on J2EE and XML and profits from the advantages of thesetechniques, which leads, of course, to a high number of employment and extension scenarios.

5.1.2. Enfinity Architecture and Components

The software architecture of the core Enfinity system and its components are described in thissubsection. Enfinity is implemented as a 3-tier application, meaning the separation from presen-tation layer, business logic layer, and database layer into different tiers. This approach opens alladvantages, which this architecture type introduces, such as good availability, extensibility, andreliability for the Enfinity system.

Figure 5.1.:Core Enfinity 2.2 software architecture.

Web Server and Web AdapterEnfinity is an Internet-based application. It supports for its clients standard Internet accessthrough HTTP communication with a Web server. The Web server represents the gateway tothe Enfinity servers, being the only entry point for external requests. Enfinity can support evenmultiple Web servers each running a special application called Web Adapter for good load bal-ancing, availability, and performance.

The Web Adapter is a native Web server extension, responsible for passing each incomingrequest to an appropriate Enfinity server. It offers even more functionality, e.g. for sessiontracking and session failover as well as for load balancing. Referring to the first point, theWeb Adapter creates unique session IDs for the requests and uses this information along withdata from the requested URL for distributing requests onto the servers. Regarding to the requestdistribution, the Web Adapter tries to send requests of a unique session always to the same serverfor increasing reliability and performance. Only if a server fails the Web Adapter will send arequest to another server of the same type. For providing that failover mechanism the sessiondata is stored persistently in the database. For the second point, the adapter uses additionalinformation received from a server control service to distribute the requests according to theworkload of the Enfinity servers.

62


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 aremanaged by the eTS. The Catalog Server controls the e-commerce site browsing, handles productand 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 activitieswithin 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 refer-ring to the use of both, namely for increasing load balancing, performance, and scalability ofthe whole solution. In addition, requests to the eTS are slower because of partial writing ac-cess to the database, what decreases performance and workload. Think of a B2C scenario withalmost browsing requests and only a few orders in the system. The separated design of eCSand eTS offers the ability for adapting the requirements of the catalog server independent fromthe ones to the eTS. Regarding to the scenario, it is possible to install multiple eCS for provid-ing high browsing performance. Further, by increasing the expense for the Catalog Server theperformance 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-commercesite, which will be presented in Section5.1.3.

For fulfilling their tasks, it is necessary that both servers communicate with each other. Theso-called cross-server calls are described in Section5.1.4.

Enfinity Application Server (eAS)The eAS runs under the eCS and eTS providing basic functionality for both servers above. Thisincludes general administrative support such as managing, which server is running as well asthe communication between servers, servers and database, and servers and Web Adapters. Itperforms some early initializations and configurations for incoming requests such as identifyingthe 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 Pow-erTier application server [62], which provides a complete palette of services such as containermanaged persistence, transaction and life cycle management for the business objects, data objectcaching, 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 calledmanager classes, which encapsulate, an often aggregated, access to more than one EJB.

Relational DatabaseCurrently, Enfinity runs on an Oracle 8i relational database management system accessed directlyfrom PowerTier EJBs. Therefore, a special communication interface is used: the Oracle CallInterface (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, inopposite to JDBC.

The combination of EJBs and the native OCI protocol allows for automated object caching to

63


increase system’s performance. Enfinity also supports for performance reasons multiple separatedatabases, one for the eCS and one for the eTS. If multiple Enfinity servers of the same type areused within a server cluster, they all connect to the same database. For example, all eCS in onecluster access the same database. More databases increase the number of concurrent sessionswhile decreasing response times and the database’s workload. Database sharing of all serversfrom one type in a cluster is important for data consistence within user sessions.

5.1.3. Enfinity’s Pipeline Concept

In Enfinity, the business logic is separated from the core source code. By using configurable busi-ness flows, composed of re-usable logical steps Enfinity offers a mechanism to flexibly changethe business logic without much coding and management effort. A pipeline is a logical model ofa business flow and combines a number of business tasks, using a determined syntax to delineatethe business flow. Beside normal pipelines, invoked by client requests, there exist scheduledpipelines, which can be started automatically following a given time period. And in fact, thebusiness steps are reusable, changeable, and extensible. A pipeline consists of mainly threedifferent types of nodes, indicated as pipelets, control nodes, and interaction nodes.

Pipelets are reusable business steps, implementing core Enfinity business logic. Pipeletsare Java classes performing the detailed work of handling the requests, such as contacting thedatabase and retrieving information. Therefore, pipelets communicate with the EJBs inside theEnfinity Application Server, acting as clients for the EJBs. Pipelets extend thePipelet classand implement a specialexecute() method, which handles a reference to the pipeline dic-tionary as a parameter (similar to command design pattern [25]). The following example for apipelet shows theexecute() method, which tries to read an enumeration of counter objectsfrom a CounterEJB and stores the information in the data dictionary.

public int execute( PipelineDictionary pipelineDictionary ) {try {

// Lookup the counter homeIRegistry r = Registry.getInstance();CounterHome counterHome = (CounterHome)r.lookupEJBHome( "CounterHome" );// Get the current domain idDomain domain = (Domain)pipelineDictionary.get( "Domain" );String domainId = domain.getUUID();// Select all counters of the current domain into an EnumerationEnumeration 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 dictionarypipelineDictionary.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 execu-tion, if it is PIPELET_NEXTand the pipeline continues with the next transition. In the case of

64


PIPELET_ERRORthe pipelet causes an exception and the pipeline continues via an error transi-tion. If important data items in the data dictionary fail but are needed for the pipelet, it will throwa PipeletExecutionException, forcing the pipeline to stop. Each pipelet owns an XML descriptorfile (see the example below), which includes statements such as pipelet name, description, orfull class name (full package path). Additionally, information is specified for the transactionalbehavior of a pipelet, with theerror-connector tag (if true, an error connection branch issupported, elsePIPELET_ERRORsay something about the pipelet’s failure behavior and thetransaction tag (such as commit, rollback). Theproperties tag identifies the properties thata pipelet needs to perform its task or that should be provided for other pipelets to use and whichare stored in the pipeline’s data dictionary. A pipelet can have multiple property tags, which alsocan 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 willbe 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 flowin a pipeline. Meaning, they define a flow chart, which describes the order of execution anddependencies between all included pipelets. Therefore, there exist four different types of controlnodes. First the start nodes. Every pipeline starts its execution at a start node, which is specifiedwith its name in the HTTP request URL, which is sent by the client. In fact, pipelines can havemultiple 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 pipelineto even use the business logic of the others. Jump and Join nodes guide the flow inside thepipeline, the first represents a conditional branch and the second joins multiple logical threads ina pipeline’s flow to one.

The third node type are the interaction nodes. Here, it is distinguished between interactionend nodes and interaction continue nodes. The end nodes generate an HTTP response and canensure session failover using persistent mode settings. The pipeline execution terminates afterthe end node is reached. The interaction continue nodes interact within a pipeline with theclient for receiving for example additional information for continuing the pipeline business logic.However, this happens volatile and without failover security. Both nodes invoke a templategenerator and send template generated HTTP responses.

Every Client Request invokes a pipeline in the Enfinity system, which is identified by therequested URL. For example, the following URL from an Intershop installation at Otto.de tries

65


to connect with the eCS using the pipelineOV_BrowseCatalog with the start nodeStartfor the current request:

http://www.neu.otto.de/is-bin/INTERSHOP.enfinity/eCS/Store/de_DE/-/EUR/OV_BrowseCatalog-Start

If a pipeline is started, it first initiates the pipeline dictionary, a key-value repository for hold-ing strings and also complex Java objects, which there are durable within pipeline runtime. Thepipelets, executed with the pipeline, can read and store information for getting suitable inputparameter for the own calculation or for making available their execution results for followingsteps in the pipeline. Even templates use the data dictionary for retrieving the information to besent to the client.

A last big point to mention is the ability of pipelines for defining transactions. The connec-tors between nodes can be set to transaction settings such as rollback, commit, or savepoint forensuring correct and complete processing of tasks within Enfinity.

Now, a short extract follows, which presents a pipeline definition made using XML. Howcan be seen in this sample, the pipeline starts with a start nodeStart followed by pipeletpipelet0 , which needs an information with the key nameCounterKey of typeSampleKeyfrom the data dictionary. Connections between the pipeline steps are defined in the second partof 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 valuesof 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


</transitions><types>

<type>storefront</type></types>

</pipeline>

5.1.4. Communication inside Enfinity

Enfinity makes often usage of HTTP for communication. As an Internet application, Enfinityuses HTTP for storefront requests. As described in Figure5.2, it also uses HTTP for commu-nication between Web adapter and Enfinity servers. eCS and eTS receive HTTP request, andif they need to exchange data between each other, they will also connect using HTTP sendingtheir requests via the Web Adapter. All external communication with the Enfinity system passesthrough the Web adapter, which can be secured using HTTP/S.

The database access from Enfinity servers is realized through EJBs, which can be accessedby pipelets. However, the pipelets do not interact with the EJBs directly, but with so calledmanager classes, which encapsulate the access to one or more EJB and their information. TheeTS and eCS use the database object cache layer of the EJB server to communicate with thedatabase. The EJB server maintains an open connection with the database server and uses anative 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 importantregarding to InterMarket. For more information on communication please read [35].

5.1.5. Storefront Request Workflow in Enfinity

In general, our excursion starts with the Web server, which receives an HTTP request passedthen from the Web adapter to the core application server, where some of the basic functionalityis performed. Following the request is handled to the specific eCS or eTS where, with use ofthe EJB server, the database is accessed and the business logic is performed. This is done inthe Enfinity server by starting a pipeline, which processes the business logic, and generates atemplate for the response, which returns to the client.

67


In DetailThe request is passed from the Web Adapter to the Request Handler Servlet part of the coreapplication server. This HTTP Servlet class handles an HTTP request and returns an HTTPresponse, while maintaining state. The Servlet sets up the appropriate request, response, andsession objects by using the information, which is encoded in the requested URL (e.g. sessionID, language, currency). After checking some data such as login and other information theRequest Handler Servlet invokes the Pipeline Processor for executing the pipeline encoded inthe URL. The Pipeline Processor sets up the Pipeline Dictionary. The dictionary is filled withadditional data from the request’s URL. The processor manages the correct flow of the pipelineelements through the pipeline, which in addition offer transaction-based handling. Each pipeletin the pipeline fulfills a specific task and can, therefore, implement own services, can access thedatabase 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 inter-action node invokes a special template processor, which can automatically generate an HTMLresponse from a template class file, which is filled with the data from the pipeline data dic-

68


tionary. If the pipeline ends the pipeline processor returns back the generated response to theRequest Handler Servlet, which passes the response over the Web Adapter and the Web serverback to the client user.

Figure 5.4.:Processing a request with pipelines, [35, p.48].

5.1.6. Extending Enfinity using the eCAPI

The Enterprise Cartridge API is a bundle of interfaces and Java classes for extending existingfunctionality of Enfinity. Building an application using the eCAPI and registering it with Enfin-ity, is called building a cartridge.

A cartridge is an installable software module for the Enfinity business application layer, whichcan perform simple tasks such as adding graphical layout elements to the storefront or it can addnew functionality even with integration of other applications (e.g. ERP system). Developingsuch 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 wellas integration with third party systems using EJBs. A cartridge consists mostly of differentelements:

The first elements to be presented are the business components, which contain different kindsof objects that are classified by their role:

• Manager classesare registered as the representatives of the entire business component.All other objects within the component are accessed through these manager classes. Amanager class is a session bean with responsibility for controlling life cycle of persistentdata objects that are contained in the business objects of a component. Manager classes

69


also query other objects, execute complex business functions, but contain no persistentdata. However, manager classes work at a higher level of the business logic and use busi-ness logic implemented in other manager classes, business objects and services.

• Business objectsare persistent data containers for the business logic with additional func-tionality. Business objects are Entity Beans, which are controlled by their manager classes.

• Business servicesare elements that cover special logic and are defined through specificJava 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 pipeletscan 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 theyneed 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, whichis 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, ahub of Enfinity, can be used from all cartridge components, including services and pipelets, tolocate each other.

To be able to manage cartridges each cartridge implements a controller class, which containsinformation for the particular cartridge, including the type of business components that are con-tained within the cartridge. It is responsible for registering the cartridge components with thecentral Enfinity registry and controls the cartridge startup process. More information about theeCAPI and the cartridge development can be found in [33].

70


Figure 5.6.:Cartridge Management, [33, p. 26].

5.1.7. Connecting to Enfinity using the eRXI API

The Enfinity Remote API is an external API for accessing data from Enfinity or inserting ordersinto the Enfinity system. The current version can be used for reading product or buyer informa-tion or read, write, and alter orders. The eRXI supports XML encoding of Java objects as well asXML frameworks such as BizTalk and ebXML for the data exchange between Enfinity and theremote 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 inanother 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 foraggregation, distribution, or exchange of different type of data. For example, it could be possible

71


to aggregate information from different Enfinity Catalog Servers of different installations forcentralized 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 ororder injection from an external source.

When using the eRXI, the application is usually externally compiled and runs outside Enfinitycontext by integrating eRXI code in the external application. The eRXI uses standard HTTPcalls 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 asbuyer, product, which are called digital business objects. For the exchange with the Enfinityserver these objects are sent with HTTP post XML-encoded, covered in XML documents. Onthe Enfinity server side, specific pipelines are responsible for tuning the input into correct Javaobjects and for processing the HTTP request.

Furthermore the API provides different class types, which are introduced briefly in the follow-ing:

• The main interfaces and their implementations are used for writing an eRXI application.For example the IConnection, IConnectionMgr are Interfaces for establishing a connectionwith the Enfinity servers. The IService is the basis for all eRXI service interfaces such asICatalogService (can be used to get product information). Of course, for all interfacesimplementation classes exist.

• The digital business objects represent the data needed in the external application such asDProduct or DProductList for product data.

• Furthermore, Codec classes exist being responsible for de- and encoding of digital businessobjects from XML to Java objects and vice versa.

• Finally the Constant Interface holds constants needed by the eRXI classes of your programand 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 theEnfinity system into an external application and name and price of the products will be writtento the standard output. Therefore, a special prepared test class from Enfinity (eRXIExample) isshown. However for a detailed introduction in the eRXI API and the given example, please referto [34].

public class eRXIExample {public static void main(String[] args) {

eRXIExample instance;instance = new eRXIExample();instance.execute(args);

}}

public void execute(String[] args) {try {

/* --- 1. Connect to Enfinity --- */IConnectionMgr mgr;IConnection eCSConnection;Properties props;

//create an instance of IConnectionMgrmgr = ConnectionMgr.getInstance();

72


//set connection properties, required to build a connectionprops = 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 objecteCSConnection = mgr.createConnection("xml", props);//The key "xml" corresponds to the class RemoteXMLConnection

/* --- 2. Obtain a Service Object Using the Connection Object andCast to the Specific Service --- */

ICatalogService service;// Get the catalog service from the connectionservice = (ICatalogService) connection.getService("ICatalogService", null);

/* --- 3. Interact with enfinity --- */DProduct product;String login, password, pipelineName, productSKU, url;

// Use the login and password defined in the propertieslogin = connection.getProperty("login");password = connection.getProperty("password");

// Products are identified by their SKUpipelineName = "XMLProductDetails-Start";productSKU = "1053";

// Make call to service to get one producttry {

// Create a suitable URL, assembled from the//properties props and strings pipelineName and productSKUurl = "http://localhost/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/XMLProductDetails-Start?ProductSKU=1053"

// Request Product with SKU 1053 from enfinity CSproduct = service.getProduct(url, login, password);

// Output product name and priceSystem.out.println(product.getName() + ":" + product.getListPrice());

}catch (ProductNotAvailableException ex) {

ex.printStackTrace();}

}catch (Exception ex) {

ex.printStackTrace();}

}

5.1.8. Procurement Component in General

The Procurement solution from Intershop is a complete e-commerce solution for automated elec-tronic procurement. It is an extension for Intershop’s Enfinity e-commerce platform consistingof a set of cartridges for enabling the core Enfinity to support e-procurement functionality.

73


In compound with two other business components from Intershop, the Authorization Work-flow Component [36] and the Auction Component [37], this solution is able to offer a lot ofadditional features.

First, multi vendor catalogs containing the aggregated data of several suppliers are supportedbeside single supplier catalogs for smart integration and management of product catalogs. Ad-ditionally, it is possible to create aggregated product catalogs on the buying side, which couldbe adapted to the needs of a specific group of persons inside a buying company. This group isusually subsumed as department, a representative part of the organization’s administrative struc-ture. This ”personal”catalog is in fact only available for members of that special group. For costcontrol, the solution offers approval workflow and cost center definition, which are mechanismsused with flexible roles and rights assignment for monitoring and managing department budgetsand order requests within a specific department. The last key features to be named should bethe tendering techniques such as price negotiations, request for quotes, or auction, which areavailable with this solution for supporting the buy side with more sophisticated techniques forfinding best offers. For more information please see [39].

5.1.9. Procurement Component Technical Architecture

This sub-section gives a short overview over the technical foundation of the Procurement solu-tion. As mentioned before, the solution is a composition of several cartridges, extending coreEnfinity functionality. This overview shows the new-added elements of the procurement car-tridges and their relation to Enfinity core components.

Figure 5.8.:The Procurement Solution application layer, [38, p.25].

74

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 asthe Procurement Solution EJBs).

Based on that Beans, there is a new object layer introduced, encapsulating the access to theBeans through defining model classes, clients have to use for accessing the data (ProcurementSolution Object Layer in Figure5.8). These model classes offer the ability to access even existingEJBs delivered yet with core Enfinity.

The model classes are created and accessed through special manager classes, which also canrefer to Enfinity manager classes. This is used more often, because Enfinity already implementsbasic features with own Beans or for transferring data from eCS to eTS (Procurement SolutionManagers in Figure5.8).

Pipelets model particular steps in the Procurement business process, next layer above. Throughthe underlying manager classes the pipelets can access data from Enfinity and Procurement En-tity Beans.

At the top of the application layers reside pipelines and templates. Here again a separatedaccess of Enfinity and Procurement components is realized, because pipelets of both were usedto use even the existing functionality.

Finally, it remains to say that the Procurement Component re-purposes and modifies someEnfinity pipelines, extends business objects and introduces a lot of new business objects, for ex-ample to distinguish between specific actors such as buyer and supplier as well as new pipelinesand templates for handling the extended functionality.

In addition, the Procurement Component introduces some new techniques for multiple appli-cation layers. However, these changes from the standard Enfinity procedure are of more specificnature and deeper implementation details, which can be found in [38].

5.2. Tracy

This section introduces the Tracy mobile agent system and should give a brief insight to the Tracyinfrastructure, the agent model, the agent communication, the migration, and the integrationpossibilities with other applications. Additionally, the software architecture of a Tracy agentserver and its main components are presented with the last sub-section. The contents of thissection is adapted from [9].

5.2.1. Introduction

Tracy is a Java-based mobile agent system that was developed by the software engineering teamat FSU Jena during the last three years. The reason why the development of a new mobile agentsystem was started, although even in 1999 many systems already existed, was that none of thesesystems offered enough support for the main research issues the research group was interestedin: migration of mobile agents. All systems available only implemented very simple migrationtechniques and even if they were available as source code, it would have been very difficult toimplement our own ideas concerning efficient and high-performance migration.

As a consequence, Tracy was developed as a complete mobile agent system, providing meansfor communication, security of mobile agents and servers, a graphical user interface to managea single mobile agent server, and a technique to manage logical agent server networks. All thesefeatures are placed on top of a very sophisticated migration component.

75


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 modelsare shown and definitions of important terms are provided. However, for a detailed introductionsuch as for programming agents by source code, please refer to [9].

5.2.2. 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 re-ceiving and sending mobile agents over the network. Each agent server is independent from theother, even though they are able to communicate with each other. The architecture of the Tracysystem is, therefore, the many times repeated architecture of the singular agent server, see Figure5.9.

The agent server sits on top of a Java Virtual Machine (JVM), which is itself based on top ofan operating system. On top of a Tracy agent server there can be one or many applications thatuse it to host application-specific agents. It is not necessary that there is a permanent connectionbetween application and agent server. An application can start an agent server temporarily tolaunch agents that immediately migrate to another platform. In the same way, it is possible thatan application only connects occasionally to a running agent server, e.g. to check whether newagents have arrived. If there is no application connected to the agent server, then the agent serveris able to offer services on its own. An agent server has a unique name, which consists of thehost name and the logical agent server name, e.g. dagobert.uni-jena.de.

Application

Tracy Agent Server

Java Virtual Machine

Operation System

Tra

cy S

yste

m

daisy.uni-jena.dedagobert.uni-jena.de pluto.uni-jena.de

Application

Tracy Agent Server


Operation System

Tracy Agent Server


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 agentservers on one Java Virtual Machine, or starting several Virtual Machines each executing oneagent server.

76

5.2. Tracy

5.2.3. The Tracy Agent Model

Our agent model consists of three types of agents. First, asystem agentis a stationary agentthat offers services related to the operating system on which the server runs, e.g. file services,printing services, etc. Second, agateway agent, which is also stationary, is responsible for thecommunication 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 agentsaremobile agentsthat are characterized by the ability to migrate to other platforms, but havenone of the above mentioned permissions. Mobile agents are strictly controlled by the agentserver, so that it is impossible for mobile agents to access the underlying operating system orexternal 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 anda 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 APIor the graphical user interface, or from inside the server, e.g. by another agent. The execution ofan agent can be suspended, i.e. stopped temporarily, and resumed, i.e. started again. An agentcan be asked to quit itself, or can be killed by a user (not by other agents), e.g. if a maliciousagent consumes system resources. Mobile agents can migrate to other Tracy agent servers, seeSection5.2.6, where the mobility model is presented in detail. Agents can communicate witheach other either by using asynchronous messages, or by leaving information on a blackboard,see Section5.2.5.

One of the main differences to other mobile agent systems is the fact that Tracy does notsupport any kind of remote communication, i.e. you cannot send messages to an agent on anotheragent server. This restriction comes from our interpretation of mobile agents: an agent mustmove to the destination platform, if it wants to communicate to other agents over there.

5.2.4. 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 con-sidered to be an insecure part of the agent system. So we cannot grant unrestricted access to thehost. 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 toaccess the host, we use stationary agents as a dynamic interface and as a security wall. They actas so called system agents. If mobile agents must be able to use local applications to solve theirtasks, they may access them using gateway agents. This kind of stationary agent acts again as adynamic 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 theagent server via a gateway agent and other agents may “speak” with the application via a gate-way 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 withthe related gateway agent, and an associated application can use the whole possibilities of theagent system with the help of a related gateway agent.

77


5.2.5. Communication between Agents

Mobile agents are a design paradigm for distributed computing, in which a mobile agent migratesto another platform to fulfill an user-defined task. This task can be done better at the remoteplatform or can be done only at the remote platform. The agent needs to connect to operatingsystem 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 viastationary agents. In addition, the agent server can provide more services by simply runningmore stationary agents. Thus, the mobile agent must be able to communicate with system andgateway 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 asynchronousmessages and not via direct method calls between agent objects. The latter effects an agent in adirect way, which is a contradiction to the concept of agent autonomy. Thus, in Tracy, messageswhich will be exchanged between agents are like mails. All of the three types of agents canexchange these mail-messages. Every agent has a mailbox in which new mails are stored. Theagent can decide on its own how to handle these mails. It can decide to accept mails or not byclosing its mailbox (even temporarily). Thus, the autonomy of an agent can be preserved. Tosend 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 messagesto another agent residing on a different agent server. Even, if both agent servers were to resideon the same host sending mails between them would not be possible. This restriction is a resultfrom our interpretation of mobile agents: an agent must move to the destination platform, if itwants to communicate to other agents overthere. Remember that local applications can send andreceive messages via gateway agents only. Another feature is that the user can send messages toagents by using the Tracy GUI (for detailed information see [9]).

Agents can communicate with each other not only by using asynchronous messages. Com-munication is also possible by leaving information on a blackboard via an interface integrated inthe Agent Manager. In this second kind of communication, which is an indirect one, the agentputs some information on the blackboard like an announcement in a newspaper. Other agentscan read this announced information from the blackboard via a symbolic name. The blackboardis another basic approach to provide information deposited by an agent, by the agent server, orby an application. For example, the agent server deposits information on the blackboard aboutservices 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 directoryis a container for files and other directories, where as files can only contain data of some specifictypes, like plain text, XML, HTML, graphic files, etc. Each entity might have an owner whodefines grants to other agents to read or write this item.

Besides reading and writing blackboard entities, directories and files can be observed byagents. An agent will be informed about any change of the observed entity by a message. Anagent can become active when a specific blackboard entity has changed its value. Other eventsare adding and deleting blackboard entities. Remember that local applications can only writeand read information from the blackboard via gateway agents.

By these two kinds of communication, by messages and with the use of the blackboard, wehave a loose coupling between agents, between agents and the agent server, and between agentsand associated applications. The user (via the graphical user interface), or an associated appli-cation can use messages to communicate with agents and so agents can also receive commands.

78

5.2. Tracy

There are also broadcast messages which can be sent by the GUI for administrative purposes andby the agent server for system state propagation, e.g. send a system failure using a broadcastmessage.

5.2.6. Agent Migration

In the Tracy model, only the mobile agent itself can initiate the migration process by invokingone of thego -commands, which will be explained later. To provide some kind of agent serverinitiated migration, Tracy includes the following concept: each agent has the ability to react toincoming messages, dispatched from other agents or the agent server itself. A mobile agent mayreceive a message with the suggestion to leave the platform, e.g. in case of system failure. Itdepends on the agent’s programmer, whether he cares about those messages or not. Only theagent server is allowed to send such migration invitations.

From the programmer’s viewpoint, Tracy currently offers a weak form of mobility, in whichan agent can start a migration by ago -command that is parameterized by the name of thedestination platform and the name of the method that should be invoked next. A mobile agentcan 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 camefrom, 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 transmis-sion strategy that should be used for the next transfer. A mobile agent can define a default migra-tion strategy and a default transmission strategy that will be applied for each migration. Both canbe declared by optional parameters of thego-commands (for more information, please refer to[9, 10]). If the agent could not be transmitted successfully to the destination platform, the agentis reactivated on the origin platform and a pre-defined method with namemigrationFailedis invoked. In the Tracy model, only the mobile agent itself can initiate the migration process byinvoking one of the denotedgo-commands.

5.2.7. The Architecture of a Tracy System

We will now have a look at the overall architecture of an agent-based system. An agent-basedsystem is a host that uses a Tracy server as a substantial component to offer services to externalagents, or consumes services of other agent servers using their own mobile agents. Differenttypes of agent-based systems are distinguished by the way the agent server is connected to otherapplications on that host. The following two examples present hosts on which an applicationuses an agent server to offer services to foreign agents, or use services of other agent serversusing their own mobile agents. It is the privilege of applications to start gateway agents (seeSection5.2.3) that are able to offer services within the agent server and direct requests to theconnected application.

In the first case, there is an application written in the Java programming language that accessesa 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


method calls using the Tracy Remote Interface. This interface defines methods to control andmonitor an agent server to other java-based applications. In the simplest case the applicationresides on the same host as the agent server. However, it is also possible that application andagent server reside on different hosts. To protect an agent server against applications, basicsecurity checks are already implemented. Please refer to [9] for more information on the TracyRemote Interface.

In the second case, the coupling between these components is very strong. In this case theTracy agent server is an embedded software component within an java-based application. Theapplication uses directly the Tracy API to control the agent server. The Tracy API is detaileddescribed in [9].

5.2.8. The Software Architecture of a Tracy Agent Server

This section provides an overview of the software architecture of a Tracy agent server. The agentserver has a three layer architecture, see Figure5.10.

As in the ISO-OSI architecture model, this makes higher level services independent fromlower 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, exchangeablecomponents in a framework and allow for adaptation and portability. In the following threesections we describe each layer with its main components and the task it has to fulfill withinan agent server. The last section in this chapter deals with an agent server’s component that isvertically spread over all three layers. This component has the function to summarize loggingmessages and direct them to various output devices.

Agent System LayerTheAgent System layer(ASL) is the upper layer of Tracy. All agents are managed within thislayer. Therefore, the Agent System layer has to provide modules for controlling agents and foragent communication. All tasks related to mobile agent migration are delegated to thePackageManager layerthat is arranged below. A detailed description of the ASL can be found in [9, Sec.8.2].

As shown in Figure5.10it is distinguished between agents that are currently active (drawn ascircles) and agents that are temporarily suspended (drawn as boxes). There exists an executionthread for each active agent, whereas suspended agents are just passive objects that are waitingto become awake again. Only active agents can communicate to the main component withinthis layer, i.e. theAgent Manager. The communication to the Agent Manager is controlled byan interface for each type of agent. By this it can be ensured that agents of a specific type canonly access those Agent Manager services that they are allowed to use. Suspended agents cannotcommunicate to the Agent Manager.

The Agent Manager is the core component within this layer and manages the communicationbetween specialized sub-components. The Agent Manager serves like afacadeaccording tothe facade design pattern described by Gamma [25]. For an agent is acts like a single objectwhich offers various services. Behind the facade it works like a manager and delegates tasksto specialized sub-components. Using a facade at this point gives the opportunity to exchangesub-components easily.

All agents residing in the agent server are registered in theAgent Directory under their uniquename. The Agent Directory ensures that no two agents with identical names are started at one

80

5.2. Tracy

server at the same time. Whenever the Agent Manager needs to direct requests to a specificagent, it has to ask the Agent Directory for a reference (in the meaning of the Java programminglanguage) to the corresponding object. Each agent is registered in the Agent Directory when it isstarted 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 entryexists 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.

TheBlackboard component is responsible for all services concerning to the blackboard func-tionality described in Section5.2.5. All agent-to-agent communication is managed by theInter-Agent Message Handler(IAMH) component. An agent has to address messages to other agentsvia their name. The Agent Manager forwards message request to the IAMH which manages mes-sage spooling and their delivery. Messages are deposited in a message queue for each agent. TheMigration component is responsible to send a mobile agent to a remote agent server. It uses thePackage Managerfor this task. In the case of a migration failure it informs the Agent Managerto restart the agent.

Package Manage LayerThe 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 agentwants to migrate, the ASL uses services of the PML to initiate the migration process. The PMLgives feedback to the ASL whether migration was successful, or not. It uses the underlyingNetlayer (see the following section), to transmit data via a network to a remote agent server. In caseof an arriving mobile agent, the PML receives the agent from the Net layer in pieces according toour mobility model in [9, Sec. 2.6.3]. The PML is responsible to compose the pieces and informthe 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 thePackage Managerwhichis responsible to delegate the whole migration process. It uses theAgent Package Managercomponent and theMigration component for specific tasks. The mobility model is implementedin the PML, so this layer handles mobile agents in form of mobile units, state objects, and dataitems. 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 inthe Migration component.

For each mobile agent there exists anAgent Package Manager(APM) that maintains theagent’s data and its mobile units during the entire life-time. Such an APM exists on the homeplatform as well as on the platform the agent actually resides at. In contrast to an Agent Directoryentry in the Agent System layer, the APM is not deleted automatically when the mobile agentleaves a platform. On the agent’s home platform the corresponding APM exists during the wholeagent’s life-time, even if the agent is currently not active on the home platform, Mobile unitsor data can be downloaded from this platform. All APM objects are managed by theAgentPackage Manager Directory in which a reference to each APM is stored under the agent’sname.

The Migration component is responsible to migrate a mobile agent according to a specificMigration Strategy. As described in Section5.2.6the mobile agent can choose by which strat-egy it wants to migrate by a name, e.g.ACTIVE. The Package Manager component uses theStrategy Factory to obtain a specific Migration Strategy object according to the given name.

81


The Migration Strategy decides which mobile units and which data items must be transmitted towhich destination platform and generates a script in theMigration Definition Language (MDL)language. This script is executed by theMDL Engine and conducts the complete transmissionprocess. For this task it uses theTransmission Manager, which establishes the connection totheNet layer.

Net LayerTheNet layer (NL) is the lowest layer in the agent server architecture. Agent servers commu-nicate using this layer and exchange data. The Net layer is used by the Package Manager layerto execute specific communication tasks, e.g. to transmit a set of mobile units, together with thestate information. Transmitting of data, i.e. an agent or only state information, is always done byonly one call of the NL. When a transmission error occurs it gives notice to the Package Managerlayer about this. In the case of an arriving agent the NL is responsible to receive all transmissionpieces and prepare them to get processed by the Package Manager layer. A detailed descriptionof the NL can be found in [9, Sec. 8.4].

TheNet Managercomponent within this layer defines an interface for the specific communi-cation tasks mentioned above. For the network transmission it uses an own transmission proto-col, namedSimple Agent Transmission Protocol(SATP) which is implemented in theSATPEngine. For the real network transmission the SATP Engine uses specific network transmissioncomponents. Each transmission component corresponds to onetransmission strategy. Cur-rently 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 theJava Remote Method Invocation technique to do so. Next versions of Tracy will include moresophisticated transmission techniques, e.g. secure transmission using Secure Socket Layer, orcompressed data transmission.

MonitorThe Monitor component of the Tracy software architecture is vertically spread over all threelayers mentioned above. The Monitor component is not pictured in Figure5.10, because it doesnot 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 responsibleto collect logging messages and forward them to specific user-defined output devices. Withineach 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 wantto 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 specificcomponent.

82

5.2. Tracy

Package Manager

APMDirectoryData

State

Unit

MDLEngine

Transmission Manager

Mobile Agents Gateway Agents System Agents Suspended Agents

MobileAgentInterface SystemAgentInterfaceGatewayAgentInterface

BlackboardAgent Directory

Agent Manager

Inter-AgentMessage Handler

MigrationManager

Tra

cy A

gent

Ser

ver

Migration

Age

nt S

yste

m L

ayer

Age

nt P

acka

ge M

anag

er

Pack

age

Man

ager

Lay

er

APMStrategyFactory

MigrationStrategy

Net Manager

Simple Agent Transfer Protocol (SATP) Engine

TCP Transmission RMI Transmission TCP + SSLTransmission Transmission

TCP + ZIPNet

Tra

nsm

issi

on L

ayer

Figure 5.10.:Overview of the Tracy architecture.

83


84

6. InterMarket Feasibility Study

This chapter contains the feasibility study for the InterMarket approach. It surveys, whether thecombination of both applications is suitable for realizing an agent-based e-marketplace, whichwere 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 cov-ers the non-functional behavior of an InterMarket system. The study checks foregrounding thefeasibility for every indicated feature. However, if options or variants exist for a specific require-ment, all alternatives were discussed. Please note, that this study only tests the capabilities forcombining the given two solutions. It does not design a concrete realization of InterMarket atall.

6.1. Agent-based Functionality

6.1.1. The Configure Agent Usecase

The validation of this usecase has to be distinguished into four scenarios according to the sce-narios, which were specified in the configuration usecase model in Section4.1.3.

Scenario 1: A user configures a mobile agent via the application serverIn this scenario a mobile agent will be configured by a user for performing actions not only ona current marketplace, which the user is logged in. Thus, a user interacts with the InterMarketapplication 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, andoptional a migration route. The user triggers a pipeline inside the application server with a finalconfirmation of his actions, which is executed following the mechanism that is described inSection5.1.5. One of the pipelets inside the pipeline starts a remote communication to a Tracyagent server for sending a creation message for a mobile agent including configuration data. Theagent 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 evenafter migration of the mobile agent). The concrete proceeding of the communication betweenTracy and Enfinity is described in detail in Section6.2.1. Of course, the user is informed by theexecuted pipeline that his order was started.

Scenario 2: A user configures a stationary agent via the application serverThis scenario is processed similar to Scenario 1. The difference between both is that in Scenario2 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 ofInterMarket. A pipeline is triggered, which contacts an agent server for sending the configuration

85


data and receiving the confirmation message. Finally, the pipeline informs the user that his orderwas 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 serverThis scenario occurs, if a user tries to access InterMarket using mobile agents from a mobiledevice or a stationary client host, which runs an agent server. Access to that local agent servercan be established using several techniques such as Web browser (maybe with a plug-in), aspecial GUI application (covering the agent server as component or getting remotely contact viathe 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 forcreating, configuring, and starting mobile agents.

Scenario 4: A mobile agent configures a stationary agent on the marketplaceThis 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 Figure4.3. Afterthe mobile agent has received a unique ID of a stationary task agent from the manager agent, itis able to interact with the stationary task agent directly via sending messages. Thus, the mobileagent can configure and start the stationary task agent.

6.1.2. The Migration Usecase

Migration of mobile agents is a key feature of the Tracy agent system and is already completelyimplemented. Tracy also offers an approach for managing agent networks with a special conceptintroduced in [8] for ensuring efficient and correct migration routes.

6.1.3. The Perform Tasks Usecase

The feasibility of this usecase is presented with several models regarding to sub-usecases inSection4.1.5. Main goal of this InterMarket functionality is the intensive reuse of business logicand workflow in the Enfinity subsystem. The feasibility of the sub-usecases will be presented inthe following paragraphs.

86


However, it must be mentioned that Tracy agents currently do not implement a workflow en-gine or something similar. Thus, Tracy must be extended to implement the indicated mechanismfor a successful realization of InterMarket.

Agent-based searchA stationary agent, which is correctly and completely configured, performs a search task bysimply simulating a storefront request to the Enfinity subsystem of InterMarket, as denoted inSection6.2.1. The agent waits after sending its request until it receives a response. The responsewill be send by the application server after it has finished its database query. Now the agentcan store and evaluate the result data. This scenario introduces good reusability of the Enfinitybusiness logic for database searching.

Agent-based CompareIn 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 OrderThe agent-based order usecase can be processed absolutely similar to the agent-based search.Again, the stationary task agent simulates storefront requests (see Section6.2.1) and waits untilthe application server has responded. Agent-based order provides a good reusability of Enfinitybusiness logic for placing orders.

Agent-based RequestThis task splits into two scenarios. Scenario 1 describes the activity, if a stationary task agentplaces an offer request in the system. This can be realized by the agent simulating a simplestorefront request (see Section6.2.1). The task agent sends offer request data to the applicationserver for storing it in the database. Existing business logic of the Procurement solution can bereused for this step. After placing the data in the database, another sub-pipeline must be startedthat tries to inform the requested user via e-mail, SMS, or a special message information, whichis stored in the database, if the user is inactive on the marketplace or via a special onscreenmessage, if the user is active. Finally, the main pipeline, which was triggered by the storefrontrequest of the agent returns a confirmation response to the stationary task agent. The offer requestdata was send together with a unique reference (agent name + agent server name) from the agentto the application server for enabling the application server to send offers referring to the agent’srequest back to the task agent, which waits on the agent server.

Scenario 2 describes the situation, if the agent receives offers from the requested marketplaceparticipants. Therefore, a pipeline is triggered by every responding user, which places a responseaccording to the offer request in the InterMarket system. Inside this pipeline, a pipelet opens aconnection to the agent server (which hosts the agent) and sends offer data to the agent. Thisproceeding is executed following Section6.2.1for the Enfinity to Tracy direction. Finally, theagent sends back a confirmation response. Thus, the pipeline is able to create an output to theuser, that his offer is correctly stored.

Agent-based AuctionA main primitive of InterMarket is to reuse existing mechanisms. Therefore, the auction mech-anism of the Procurement solution (see [37]) should be the foundation for agent-based auction

87


bidding. Thus, auctions will be handled inside the application server and agents have to usethe following indicated mechanisms to participate in auctions. In addition, in this version ofInterMarket 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 astarting bid after finding a suitable auction. This process can be similarly done like normal usersdo, by simulating a storefront request (see Section6.2.1). Thus, a bidding object will be placedin the application server of InterMarket covering all bidding activities of the agent within thenamed auction (see [37]).

The second step for the agent is to observe the auction status, which means a periodicallyexamination of the auction parameters. However, the InterMarket approach and the Procurementsolution Auction Component [37] offer several possible mechanisms for doing that.

• An agent sends periodically storefront requests to the InterMarket application server forreceiving auction data. This approach offers the disadvantage that in case of a high numberof bidding agents the performance of the InterMarket system decreases noticeable.

• Enfinity offers the opportunity of scheduled pipelines, which are automatically invoked bythe system after certain time periods. Thus, it could be used, if agents place their biddingobject from step 1, and register them with a special instance in the system. A scheduledpipeline 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 ap-plets. This applets, however, do not send storefront requests. Instead they read a specialfile on the Web Server, which pools always the current auction data [37, Ch. 3]. Thismechanism could be copied by agents. Agents can read periodically this special file forbeing 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 informsthe corresponding users, if a special event occurs such as auction starts, ends, or a specialprice is reached. Thus, agents could place similar objects, with additional informationabout events, which an agent wants to know for an auction, in the application server andget then messages from the scheduled pipeline, when a special event is released. Thisapproach 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 processa 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 forsetting a new bidding, the agent uses the storefront request mechanism for placing a new bid inthe corresponding bidding object in the application server of InterMarket. This process is againperformed using the mechanism, which is described in Section6.2.1. If an auction is finishedor cancelled, the agent can read this from the auction data it has received in step two and canfollowing store the auction end data in its private repository and can finish its auction biddingtask.

In the agent-based auction functionality remains one big problem. How could all participatingagents fairly treated? It is a performance and schedule problem to ensure that all bidding agentswere informed about changes in the auction in parallel.

88


Agent-based NegotiationWith InterMarket, price negotiations will be implemented reusing existing functionality of theProcurement solution (see [38, 39]). The agent-based negotiation mechanism is very similar tothe request mechanism described above. The only difference is that in agent-based negotiationsthe offer requests and offers will not be exchanged only one time, but multiple times in aniteration process. Thus, the two steps from the agent-based requests functionality will be multipleexecuted. The first step is absolutely similar except the data, which is exchanged. The agentplaces a negotiation request in the system via simulating storefront requests and reusing thenfunctionality 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 responsefrom the negotiation partner via the application server, it does not finish execution, but performsa special intelligent logic for determining, whether it wants to place a new negotiation requestor not. With this mechanism another iteration can be triggered in the negotiation process, whichagain starts with step one.

It is also possible to assign stationary task agents to react on a negotiation request via theapplication server. However, the proceeding of this scenario does not vary from the one, whichis 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 aconsistent 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 asreuse of transactional processing (ACID), security, and reliability. Because in every iterationstep the pre-contracts (request and response) of the two negotiating parties are stored in theInterMarket database, the ability to manipulate negotiation contracts and results is taken fromthe participants of a negotiation process.

6.1.4. The Return Results Usecase

The feasibility of the return result usecase is presented with some different scenarios, accordingto the scenarios from Section4.1.6.

Scenario 1: A stationary agent returns results to a mobile agentThis 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 areference to the mobile agent for contacting it.

Scenario 2: A stationary agent returns result to a user via the application serverFor fulfilling this task, the agent again uses the storefront mechanism. Because the agent owns areference of the user, which it has received during configuration, it is able to trigger a pipeline inthe application server. This pipeline will store the information in the database using the uniquereference and will try to inform the user, which has started the agent-based task before. Moredetailed, a sub-pipeline tries to inform the user. If the user is active, it sends a onscreen messageor, otherwise, the pipeline can generate an e-mail or SMS. Finally, the pipeline returns a responseto the agent to confirm the proceeding.

Scenario 3: A mobile agent returns results to a user via application serverThis scenario can be implemented similar to Scenario 2. However, the stationary task agent

89


from scenario 2, which sends the result data to the application server, is configured and startedto do that task by a mobile agent. The confirmation send back from the application server tothe stationary agent will be mediated also to the mobile agent. Thus, the mobile agent is able toreturn 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 deviceReturning results on the client side of InterMarket using mobile agents is no problem. Dependingon the kind of application using a Tracy mobile agent server, the results will be returned. Thiscan be implemented using the following approaches:

1. Use the Tracy Remote API, which offers services, where listeners can register themselvesfor being informed in case of special agent-mediated events (e.g. a mobile agent hasreturned).

2. Asynchronous communication between the mobile agent and the calling application. Theagent places its information on the blackboard and the application is responsible for read-ing 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 connectionto the client application and can mediate the result data to the application.

6.2. Non-functional Behavior

6.2.1. Integration of Agent Server and Application Server

Both applications are platform-independent, because of being built with the Java programminglanguage: Tracy (J2SE version 1.2), Enfinity/Procurement(J2EE version 1.2). Both solutionsoffer 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 applicationscould be fully integrated. However, as we will see in the following section the integration be-tween Tracy and Enfinity can be realized only with a remote connection.

90


Enfinity offers two possible approaches for integrating with it. The first is to use the eRXI API,which is introduced in Section5.1.7. The eRXI API offers access to Enfinity for using a limitednumber of functions in the standard version. For sophisticated remote access to applicationserver functionality the API offers some interfaces and classes for extending the remote API andadapting to project needs. The API simply uses HTTP requests which will be routed via the Webserver to a proper application server of Enfinity following the process described with Section5.1.5. However, this API was designed for cross-server calls inside the Enfinity system and doesnot use the normal Enfinity processes for performing tasks.

The second possible way to access Enfinity is to simulate normal storefront requests usingHTTP requests, which will be send to Enfinity Web servers. Enfinity is optimized for handlingsuch requests and is able to produce fast responses. Thus, you can send data and the name for aspecial 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 Section5.1.6. Thus, it is possible to implement new functions in Enfinity, which can access Tracy andcan 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 APIuses RMI. A high integrative way for integrating Tracy is to use Tracy as a component withinEnfinity, but how we will see, it is not possible with InterMarket.

For the integration of other applications with Tracy, Tracy offers stationary agents. With theseagents you can integrate with any application, which offers remote access by an API or a specialexternal connector program (Web Service).

Now let us look at the communication between Tracy and Enfinity. Both applications interactusing remote access to the other. First we start with theTracy to Enfinity direction .

It is recommended to simulate simple storefront requests using HTTP from agents, because itoffers the following advantages:

• Enfinity is optimized for processing storefront requests (see Section5.1.5) and offers thatway the reuse of session and transaction management of Enfinity without programmingeffort for ensuring transactional processing, reliability, security and data integrity on theapplication 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 Figure6.3a communication process between a Tracy stationary agent and Enfinity is pre-sented. Stationary agents are able to send requests and receive responses autonomously, whichcould 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 databaseor the blackboard inside the agent system. After the agent has all necessary data for performingthe request, it is able to establish an HTTP connection to the Enfinity Web server. This could besimply done by using a Java Socket class, Java URL class, or Java URLConnection class. Theagent sends an HTTP request to the Enfinity system and waits for response. Inside Enfinity therequest is executed such as any storefront request. The final step in the pipeline produces theresponse that way, that the agent can retrieve information from it, for example by using XML

91


or a special XML dialect such as ebXML or BizTalk. When Enfinity sends back the responseand 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 lookat the reverse direction (Enfinity to Tracy ). Here you can find three approaches, which will beintroduced briefly in the following.

The first approach realizes access from Enfinity to Tracy using HTTP request. Users sendstorefront requests to Enfinity. One of those requests starts a business processing, which includesagent-based tasks. Therefore, in Enfinity it is possible to open a socket from inside a pipelet forperforming a request (similar to agents). The pipelet receives the information for the connectionfrom the data dictionary. The Tracy agent servers implement a mechanism, which enables themto receive such requests and to perform the wished action such as creating, configuring, andstarting an agent. After the agent server is able to ensure correct execution of the given tasks orafter processing the task it sends back a response to the waiting pipelet. In Enfinity the processingfollows Section5.1.5 and produces finally a response for the users, which started the wholeprocess before. This approach has the advantages that it ensures a consistent communicationprotocol for both directions of the communication and that the data objects to be exchanged haveto be designed only with one shape. Additionally, it offers good capabilities for load balancingand 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. RMIconnections should be reusable because they are expensive (when they will be opened and closedperiodically) and that is why they will be accessed from pipelines out of EJBs. Beans encapsulatethe remote execution and only return back results to the calling pipelets. Thus, the Proxy objectsfor agent servers (in the beans) can be shared by multiple pipelines and sessions. However, therest of the execution of an agent-based task using Enfinity to Tracy communication is performedsimilar to the Figure6.4. Advantage of this approach is the reuse of the existing remote APIof Tracy, but it leads to a design of multiple different data objects for both directions of thecommunication and represents no consistent communication pattern between Tracy and Enfinity.

92


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 beintegrated in other applications as a component. Thus, agents can be managed with normal Javamethod invocations, which use Tracy as an object of the application. This has to be done in anEJB 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 insidean EJB container such as thread management. Additionally, this approach would not be scalableand would provide low performance, because of:

1. cross-server calls inside Enfinity from one of the both servers (eCS, eTS) to the other, if ittakes 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 wouldcrash.

Agents often perform time consuming tasks, so that it is recommended that Enfinity does notwait for the results, because of system performance (too many parallel threads). Thus, synchro-nization could be done using the database of Enfinity. If agents have fulfilled a task they send astorefront request to Enfinity for sending the results. The results will be stored in the databaseand a sub-pipeline tries to inform the user. If the user is online this can be done with an onscreenmessage, otherwise Enfinity can use e-mail or SMS. For giving the user the possibility to accessthe results, these results are stored yet in the database.

Another requirement is that Tracy, Enfinity, and their connection scale for being able to adaptto any performance and scalability demands. Enfinity fulfills this requirement and as mentionedwith the approaches for bi-directional communication the connection between Tracy and Enfin-ity, too. However, Tracy does not fulfill the requirement. In [8] an approach is presented formanaging 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 multipleother agent servers. Another advantage can be, that incoming mobile agents have to authenti-cate only at the gateway server, which will be routed without additional time-consuming securitychecks in the agent server sub-net.

93


Figure 6.5.:Scale communication between both InterMarket sub-systems.

As Figure6.5shows, not only Enfinity, but also the Tracy sub-system has a 3-tier architecture.The architecture of Enfinity is clear (see Section5.1.2). In Tracy, there is a gateway agent server(similar to the Web server from Enfinity), which is responsible for receiving and distributing in-coming mobile agents from the Internet as well as requests from Enfinity servers onto the agentserver sub-net. The agent servers from the sub-net are a kind of server cluster for a scale distribu-tion of the workload. In the back-end of the Tracy sub-net exists a database, which is responsiblefor persistence and reliability of the agents and their execution. Because this is a central pointin the system and agents will be executed transaction-based, a session failover becomes possi-ble. If one agent server fails, another will take over and can continue agent execution. Bothsub-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 tasksagents implement sockets (Socket, URLConnection) for autonomously communicatingwith Enfinity.

2. Enfinity interacts with Tracy either using the remote API of Tracy with RMI or a HTTPconnection, which has to be implemented an analysis must be done to decide, which risk isbetter to solve. Enfinity, therefore, communicates with Tracy from sockets inside pipeletsor with proxy objects from inside EJBs.

3. Tracy has to realize a scalable architecture. Therefore, Tracy must be reworked to adapt toa three tier architecture, with scaling tiers.

If all points are fulfilled, InterMarket can be realized with an architecture, which is presentedwith the follwoing Figure 6.6.

94


Figure 6.6.:Overall InterMarket software architecture.

6.2.2. Portability of the Agent Server

Mobile devices (PDA, iPac) that can run more complex applications by supporting operatingsystems such as WinCE or Linux. It is possible to establish on these operating systems Java anda JVM [53] or a smaller version, the KVM [63] (Java for small devices). Tracy is 100 percentJava code and so able to be run on the mentioned systems. The Tracy2 design, which is currentlyunder development realizes a modular partitioning of the agent system into logical units such ascore components (every agent system demands) and add-ons and extensions (features that makethe agent system complex such as non-fundamental security, persistence, transport mechanismse.g.). With this design it is possible to downsize Tracy for reducing the memory and performancedemands of Tracy for adapting it even to small devices. However, downsizing of the Tracy agentserver remains a task, which has to be done for a realization of InterMarket with Tracy.

6.2.3. Performance

EnfinityBecause Enfinity is a high scalable n-tier software system it is easily adaptable to all possibleperformance needs such as concurrent sessions, workload, or peak and average response timesby extending hardware and software components.

For learning more about recommendations and rules for sizing and configuring an Enfinitysystem please read the Performance and Configuration Guide for Intershop Enfinity ([42, ch.Performance Tuning and Sizing]). For general information please see Inside Intershop Enfinity[35].

The caching technique is the key approach for high performance in Enfinity through the re-duction of eCS, eTS, and database workload and the saving of database connections. On the

95


one side Enfinity maintains a page cache for reducing the number of dynamically generated re-sponses, leading up to 10 times faster responses (see [42, p.11, 54 ]. On the other hand the EJBservers administers cached objects such as session objects or other EntityBeans caching infor-mation from database tables (e.g. product data). For additional improvement the data amount ofdatabase queries can be reduced through outsourcing images and other multimedia content or anLDAP-compatible file server. In addition, the EJB Server pools database connections reducingthe connection time. Enfinity uses multiple databases for faster concurrent database sessions andthe EJBs are not located via RMI by calling them directly via an internal registry saving a RMIcall for each invocation.

Next point is to speed up parallel execution of requests in the system. By installing multipleWeb server and Web Adapter, eCSs, and eTSs each on an own machine (at least one CPU perserver) built with the latest hardware improves system’s performance, because requests can berouted and handled by several components. Having multiple eCSs improves for example thespeed for browsing catalogs and products. Moreover, the use of load balancing hardware forWeb Adapters paired with the Enfinity load balancing mechanism of the Web Adapters leads toa higher distribution rate of requests inside of Enfinity.

Another way for better performance is to speed up the client session by using the HTTPpersistent connection mechanism (see [78, ch.8]) and by caching the session objects containingthe tracked data within a single session.

For getting an idea of realistic Enfinity system configurations please read the Intershop En-finity 2.2 Benchmark Report for Sun Solaris [41] or Intershop Enfinity 2.2 Benchmark Reportfor Hewlett-Packard HP-UX [40]. These guides also include information about the operatingsystem-specific hardware.

Full Suite TestOverall sessions/ hour 19,434Browsing sessions/ hour 6,036Add-to-basket sessions/ hour 10,759Order small sessions/ hour 2,539Overall pages/ hour 114,578Storefront home pages/ hour 19,531Catalog pages/ hour 30,335Product pages/ hour 43,682Add-to-basket/ hour 13,302Checkout/ hour 2,543Order/ hour 2,539Average response time 3.13 secondsStorefront home page 1.0 secondsCatalog page 4.98 secondsProduct page 3.1 secondsAdd-to-basket 2.5 secondsLogin 2.35 secondsCheckout 1.68 secondsOrder 3.4 seconds

In conclusion Enfinity offers good performance for all scenarios using mostly reading actions.However if a critical number of writing operations are executed the system slows down rapidly.

96


Last but not least a summary from a performance test is presented with the above table sim-ulating a B2C scenario (70 percent browsing users, 20 percent add-to basket users, 10 percentsmall order users) with an early version of Enfinity 2.2. For detailed information please read[43].

TracyMost important points within an agent system are the transmission time of agents, the executiontime on an agent server (depending on the job the agents have to do) and the capabilities of agentservers, according to concurrent execution speed for multiple agents, message system, and more.

At time, there only exist some test results for agent transmission in [11]. However, this tests donot depend on a business scenario and information about maximum throughput of agent serveror concurrent agent execution are not available. For Tracy, there do not exist any statementsabout performance under real project conditions such as multiple parallel agents migrating andcommunicating or executing on agent servers as well as agent server clusters.

Finally, it remains that the performance of the agent system heavily depends on the jobs theagents do or the systems, which are remotely contacted by stationary agents (application servers,databases).

However, Tracy agent servers are currently not tested under real world scenarios. That is whyperformance is not measured yet. Thus, on the Tracy site remains work for adapting the agentsystem to hit requirements for InterMarket. Here all possible scenarios have to be tested andall available techniques should be used, such as caching, load balancing, or clustering of agentservers. Because agent tasks combine mostly multiple business steps, the performance for Tracyshould orientate at Enfinity/Procurement. However, by combining multiple steps Tracy will becertainly slower.

6.2.4. Scalability

EnfinityAs every n-tier application, Enfinity offers the possibility for adding extra resources to everylayer: presentation layer, business logic layer, and database layer. In addition these layers can bedistributed over multiple machines, so it is simply possible to build server clusters for managingeach of the layers. In fact, through the installation of multiple Web Adapters and Enfinity serversEnfinity can be extended with very large clusters not limited by the managing instances of thesystem.

Enfinity spreads the business logic onto different servers, the eCS and eTS, adding even morescalability because requests for product data on the one side and buyer and order informationon the other side are not send to a single point in the system. Of course, it is recommended byIntershop to install each server on a single machine (the same for Web Adapters), which improvesnot only the scalability but also performance. To increase the scalability of the business logiclayer the Web Adapter can use a mechanism for distributing requests regarding to the load of theservers.

For scaling the database layer, Enfinity includes a powerful, scalable database solution fromOracle. Enfinity uses a number of it to reduce requirements for a maximum amount of concur-rent database connections for a single database. Each online eCS and eTS accesses their owndatabase. However, all servers of the same type (e.g. eCS) in a cluster connect to the samedatabase for data consistence reasons. Additional improvement of database scalability can be

97


provided using Oracle Parallel Server or hardware clustering, like Solaris clusters.The following examples for determining scalability of the Enfinity system are taken from the

Intershop Enfinity 2.2 Benchmark Report for Sun Solaris [41]. Please read this guide for moreinformation on the benchmark environment and the measurement methodology. However, thefollowing numbers are kept without using any form of page caching.

Example for the scalability of the Enfinity 2.2 Web Adapter

Number of Web Adapters Number of requests/ day1 9.1 million2 18.1 million4 35.4 million5 42.1 million

The Web Adapter scaling rate is about 97 percent.Example for scalability of the Enfinity 2.2 Catalog Server

Number of eCSs Number of browsing requests/ day1 1.2 million2 2.1 million4 4.1 million10 10.0 million20 19.8 million

This leads to an eCS-scaling rate of approximately 87 percent.Example for the scalability of the Enfinity 2.2 Transactivity Server

Number of eTSs Number of orders/ day1 98,0002 186,0004 356,00010 847,00012 983,000

Leading to an eTS-scaling rate of approximately 89 percent.

TracyCurrently Tracy does not support scalability of agent servers in a cluster. However, the DomainManager concept (see [8]) can offer a suitable approach. The domain manager is an agent server,which provides access for external mobile agents to an agent server subnet. This fact can be usedfor a load balancing mechanisms, which does not only allow access to a subnet of agent servers,but additionally distributes automatically external mobile agents onto the agent servers in thecluster. Therefore, the Domain Manager concept has to be extended for realizing the indicateddemands.

However, the scalability problem does not only exist for mobile agents, but also for requestsfrom the Enfinity/Procurement system. It is possible to realize a mechanisms similar to theDomain Manager concept. Enfinity interacts with Tracy via the Tracy Remote API. The requestscould also be send first to the gateway agent server, which distributes the requests onto agent

98


servers in the subnet following the load balancing mechanism.Both scalability problems can be solved even using another approach. Because the commu-

nication from Tracy to Enfinity is performed using HTTP request it can be suitable to form aconsistent communication pattern by using HTTP request also in the reverse direction. So a Webserver can distribute incoming requests from Enfinity onto agent servers in the agent serve sub-net. For load balancing the Web server and the agent servers must be registered with a controlservice, which periodically updates agent server workload and availability for the Web server.However, using this approach there exist two gateways to the Tracy agent server cluster: One formobile agents via the domain manager and another via the Web server for HTTP requests.

Giving scale access to stationary agents for mobile agents should be solved with the stationarymanager agent and its functionality, just as mentioned in Section4.1.1.

6.2.5. Availability

EnfinityBecause Enfinity is a n-tier application dependencies on a particular server or machine decreasesespecially by using server clusters for every layer of the system.

Installing Enfinity with multiple Web servers, Web Adapters, and eTSs, eCSs each, on a singlemachine, the mentioned demand is fulfilled and every system component of Enfinity exists atleast twice and can take over, if any other component of the same type fails. This is especiallyvalid for Web servers. If one fails, another can take over. Additional improvements of availabilityof the e-commerce site can be reached by using load balancing hardware, front-end hardware orsoftware solutions.

The guaranteed session failover in Enfinity is build on three foundations, first the persistentsession data stored in session objects, second the cookie handling and URL Encoding for everyrequest within a session, and third the Control Service, which periodically sends an updatedmapping between session ID’s and servers to the Web Adapters. With a few words, the sessiontracking mechanism.

Using the URL Encoding or cookies and the updated mapping from the Control Service a WebAdapter can determine for every request its session and current server. If the server is down theWeb Adapter then routes the request to another server of the same type. The new server recoversthe session data from the database, because it was stored persistently and executes business logicfor generating the response.

Finally, the availability of the database can be increased by using Oracle Parallel Server orhardware clustering, like Solaris clusters.

TracyThrough the Domain Manager concept (see [8]) Tracy is able to support availability. By dynam-ically determining a gateway agent server from a subset of agent servers, Tracy can ensure anactive gateway to an agent server cluster. If the current gateway agent server fails, the remainingagent servers vote for a new gateway server. Following this, it is possible to ensure an alwaysactive agent server subnet. However, the Domain Manager concept does not provide featuresfor load balancing, persistence of agents, and session failover. Therefore, the concept has to beadapted to these demands. The both latter mechanisms are important to ensure availability evenin that case a normal working agent server from the subnet goes down. Then, all agent must bereproducible on another agent server and the agent sessions must be restarted at the last transac-

99


tion step before the crash. This scenario induces the usage of one database for all agent server inthe subnet cluster.

6.2.6. Reliability

EnfinitySeparating the business logic in a special layer within a n-tier application all other parts of thesystem are forced to use this one instance for performing the business operations every time ex-actly the same way. Additionally J2EE, used within Enfinity, offers to group business operationsinto transactions giving the application the same reliability normally expected from databases. InEnfinity reliability is guaranteed using three main mechanisms, named as session tracking, ses-sion failover, and the J2EE features coming into game with Persistence PowerTier EJB Server.

Starting with the last, Enfinity uses the container managed persistence (CMP), EJB Containertransaction, and life-cycle management for supporting transaction updates and data integrity.Transaction management can happen at the Bean-level instead of relying on the database or thebusiness logic code for supporting ACID properties, even in case, if Enfinity is extended withnew functionality.

The session tracking mechanism ensures consistent data within a unique session. This isreached by sending the session ID (URL encoding) with every request for always routing allrequests of a session with the Web Adapter to the same server. Thus, it is possible to use sessionobjects represented by Entity Beans being able to be persistently stored and being able to trackall activities and data a user touches in a session. This process is even emphasized by the oppor-tunity to define the mode of storefront pipelines as persistent for storing the data and state of thepipeline. This is of course only possible, because all Enfinity servers of the same type connectto the same database.

So the last technique, the session failover, can handle the session data, if an eCS or eTS fails.Meaning the client session will be handled without break because the Web Adapter is able tofind another server of the same type through using a periodically updated mapping from sessionIDs to servers for restoring the session data from the database and completing the session.

TracyCurrently, Tracy does not support reliability and even integrates with no DBMS for storing agentspersistently. Thus, Tracy does not provide transaction-based processing (ACID) of agent-basedtasks, which must be implemented. There even exists no mechanism for detecting dead or mali-cious agents on the agent server. Additionally, a session failover mechanisms and a mechanismfor ensuring reliability, if an agent is lost during migration have to be realized to increase re-liability of the Tracy agent server. Goal of the reliability is to ensure a reproducible, reliableexecution of agents and agent-based transactions. Therefore, the mentioned points have to befulfilled for guaranteeing a realization of InterMarket with Tracy.

6.2.7. Security

EnfinityEnfinity/Procurement offer several mechanisms for ensuring a secure processing of trading trans-actions. The external communication to the system can be performed using HTTP/S and the En-finity solution is secured from malicious access with a firewall. additionally, all external requests

100


have to flow to a central point in the Enfinity system, the Web server, which is able to check se-curity features and only accepts simple HTTP request, but nothing additional. Direct access toapplication servers or the database is not possible for external users, because these servers canbe only invoked by the Web server/ Web adapter and in addition, they are secured with a hiddensecret key, which must be used for every interaction.

Of course, Enfinity provides all standard authentication and authorization mechanisms forits users. Users must specify their login name and password, before entering the system. Forauthorization, Enfinity supports several user roles each owning special permissions according tothe tasks the role is thought to fulfill.

TracySecurity in a mobile agent system induces special problems, because the mobile agents are for-eign code that will be executed on a platform. Thus, mobile agents have no access to any localresource and are executed in a special save environment (e.g. Java Sandbox) inside the agentserver. For accessing local services, mobile agents always have to contact special stationaryagents (see Section5.2.4). Tracy offers further mechanisms and features, which should be onlylisted here. For more information on security of mobile agent system and the realization in Tracy,please refer to [9, 70].

Tracy offers:

• Asynchronous messages between agents,

• SSL security for transmission (agent migration),

• Code signing,

• Bytecode verification,

• Custom class loader for carrying out specialized security checks before passing the byte-codes to the VM,

• Security manager checks whether a specific operation is permitted,

• Simple user management mechanism (for humans only).

However, one security feature remains, which should be solved for realizing InterMarket withTracy. Tracy currently does not support a authentication and authorization mechanisms for mo-bile agents. Mobile agents must be forced to identify first, before they use services of the agentserver. According to the authentication it should be possible to assign the mobile agents specialpermissions or roles on the agent server, which ensure correct and secure access to InterMarketfunctionality.

6.2.8. Extensibility and Flexibility

EnfinityEnfinity/Procurement offer good extensibility and flexibility, because of some special features.First, they are built using many standards such as Java J2EE, XML, HTTP, CORBA/IIOP, orSSL. Enfinity can be easily extended using the eCAPI or can be integrated in other applicationsremotely via the eRXI API. The eCAPI, additionally, supports integration of other systems by

101


extending core functionality with cartridges, e.g. for connect to companies’ ERP software, pay-ment services, shipping services, tax number series, inventory systems, and currency exchangerates. These cartridges, developed with the eCAPI, can be used for extending or adapting currentfunctionality, by implementing new business logic, pipelines, pipelets, EJBs, or database tableswith a lot of integrative tools.

Because Enfinity bases on pipelines and pipelets, the business logic is separated from thepresentation logic and the core code. Thus, it is flexibly possible to adapt or extend of thedenoted layers without affecting the others.

Enfinity/Procurement are very flexible and extensible, because of an overall n-tier architec-ture, which decouples client, middle, and backend tier and groups the components of every tierin clusters. This offers high flexibility for extending the system and for dealing with higheroverall performance and high scalability as well as better availability only by adding more Webservers, Web Adapters, eCS and eTS. Every new component must simply register with the Con-trol Service. Enfinity provides flexible tools for the management of the server clusters.

Finally, data exchange with the Enfinity/Procurement system is very flexible through the us-age of XML for communication and some of its main dialects such as BizTalk. Thus, a metadefinition of the information that should be exchanged could be also transmitted, which enablesother system to retrieve proper information from messages.

TracyTracy offers on the one side flexible software agents and on the other side a remote API, whichis based on RMI. The software agents induce a very good extensibility and flexibility, becausethey are components that can be easily implemented and deployed for extending the system’sfunctionality. New agents in the agent system can easily interact with existing agents followingthe standard communication mechanisms. Additionally, agents provide capabilities even forimplementing GUI elements for a flexible adapting of specific look and feels. All mentionedchanges can be done within run-time.

However, it is possible that the current Tracy Remote API do not offer a suitable protocol forInterMarket. Therefore, the Remote API should support more communication mechanisms suchas SOAP or HTTP.

6.2.9. Personalization and Internationalization

EnfinityEnfinity/Procurement offer personalization features through the usage of cookies and URL en-coding as well as persistent user information in combination with session objects and sessiontracking. Therefore, Enfinity/Procurement are able to support a user preferences management,which provides, e.g. capabilities to adapt the user’s look and feel according to languages, cur-rencies, and colors. Additionally, they provide abilities to users for referring to older shoppingsessions and statistics, a shopping history for reordering, and a buyer notification, which sendsnotifications to the user, if orders have passed a specific stage in the order workflow or supplierhave responded on requests or price negotiation requests. Following, Enfinity/Procurement offerpowerful mechanisms for a user-specific business experience and customization.

The main points for internationalization are the support of multiple currencies and languages.First, the multi-currency model of Enfinity/Procurement offers abilities for not only generatingHTML pages including different currencies for price declarations, but also for internal calculat-

102


ing and storing prices into different currencies using exchange rates, which can be automaticallyupdated. Thus, it is possible to manage all prices in Euro, while a specific buyer’s currencyis, e.g. US Dollar. The prices will be automatically calculated from Euro into Dollar. Enfin-ity/Procurement allow a multi-currency payment through supporting special advanced paymentservice functionality. Second, Intershop offers for Enfinity/Procurement a high number of lan-guage packs to enable internationalization. In addition, it can be handled product and catalogdata in different languages through the use of Unicode and double-byte characters in the businesslogic.

TracyCurrently, Tracy can support internationalization or personalization. Software agents are verypersonal representatives of human user, which can be adapted visually and behaviorally to spe-cific user demands or to support multiple currencies and languages. Mobile agents are able toconduct in trades all over the world with other agents independent from their locality and cur-rency by using special standardized communication protocols.

103


104

7. Conclusion and Future Work

7.1. Conclusion

This paper was made with the goal of creating a feasibility study for the InterMarket approach,which should be realized using two existing software solutions. Therefore, underlying knowl-edge was collected such as information about e-marketplaces and mobile agent technology andthe objectives of the InterMarket approach were presented. Furthermore, the requirements forInterMarket were developed and both existing applications were introduced. Then, the feasibilitystudy was made building on the given foundations. Results of the study are usability statementsand recommendations for special features and requirements, which give reasons for the feasibil-ity of InterMarket with Tracy and Enfinity/Procurement. The document discusses even severalapproaches making a feature feasible, when necessary. The main results of the study should besummarized in this section.

Result 1InterMarket can be realized reusing the Tracy agent system and the Enfinity/Procurement solu-tion from Intershop by establishing a bi-directional communication between both candidates.

Result 2Enfinity/Procurement fulfills all required standard functional and non-functional requirements.

Result 3Tracy can be used for realizing the agent-based functions of InterMarket. However, Tracy mustbe adapted and extended with some functionality for fully adapting to InterMarket needs andhas to realize a software architecture similar to Enfinity for being able to flexibly adapt to anyscalability and performance requirements.

Result 4However, some risks remain having to be solved for a complete and successful realization of anInterMarket solution:

• Hard numbers for the non-functional requirements for Tracy cannot be found, becausethere even exist no hard numbers for e-marketplaces, the execution effort and the requiredresources for agent-based tasks are unknown, and the portion out of the whole workloadof InterMarket, which have to be run on Tracy is also unknown.

• The communication between Tracy and Enfinity has to be scalable and efficiently realized.The system needs a control mechanism for multiple agents and pipelets, which are able toseparately open connections.

105


• Currently, there exists no knowledge about downsizing of an agent server on a mobiledevice. However, this is more an implementation problem for realizing portability of theTracy agent server onto small devices.

• Enfinity is optimized for Internet-shops or procurement solutions, which are applicationswith a high browsing and a low ordering behavior of the users. Therefore, it is possiblethat the Enfinity system’s performance decreases, if a high number of order transactionhave to be performed, which are typically for e-marketplaces.

• The Tracy architecture must be adapted to scalability demands. Additionally, a load bal-ancing mechanism should be implemented for distributing mobile agents as well as com-munication requests from the Enfinity sub-system in an agent server cluster.

• Tracy agents do not offer transactional processing. However, it is an important point toensure the ACID properties for enabling correct business transactions with InterMarket.

• Tracy has to implement mechanisms for ensuring reliable processing after an error orcrash. Accordingly, some key words are persistence and session failover of agents.

• A workflow engine must be implemented with Tracy agents to realize the indicated work-flow capabilities of stationary task agents.

• Currently, Tracy agents cannot realize complex communication protocols. Therefore, asuitable mechanism (e.g. including a state machine) must be implemented with Tracy.

7.2. Future Work

Further research work can be seen as the evolution from InterMarket to a fully automated agent-based e-marketplace. Therefore, some ideas should be denoted following.

1. The negotiation mechanism of InterMarket could be improved to support multi-attributenegotiations. This means that not only the price is a variable parameter, but additionallyother features of the product, which should be traded.

2. InterMarket could be developed from a current application server-centric solution to anfully agent-based solution. This means that agents interact directly without the intermedi-ate step of contacting the application server, which is currently needed.

3. A high degree of automation can be reached through the insert of stationary companyagents, which resides on the marketplace as representative of a company and manages allactivities, which can be initiated by other marketplace participants. Thus, this agent cangive access to the company’s catalogs, can respond autonomously on requests or negoti-ation requests, and can participate in auctions. Stationary company agents act on behalfof their companies according to the given configuration (intelligent behavior for dynamicexchanges, price limits, discounts, information etc.). These agents would only present theusers of their company pre-contracts, contracts, or received offers for involving companyrepresentatives into decision-making processes.

106

7.2. Future Work

4. Marketplace users can configure mobile agents for spreading on several e-marketplaces.These agents should fulfill their special tasks such as observing specific events or informa-tion sources, presenting time-limited offers, and autonomously starting auctions for gettingspecific products. After a complete transaction the agents migrate home to present theirusers pre-contracts or even complete results of their work.

5. If companies have an agent server on the client side, mobile agents could be used forautomating catalog updates on the marketplace. The agents autonomously can observethe home database and if for example time stamps change, the agent can migrate to themarketplace for updating catalogs there.

107


108

Bibliography

[1] Joachim Baumann. A protocol for orphan detection and termination in mobileagent systems. Technical Report 1997/09, University Stuttgart, Fakult”at f”urInformatik, July 1997. 25 p.

[2] Joachim Baumann, Kurt Rothermel. The shadow approach: An orphan de-tection protocol for mobile agents. Technical Report 1998/08, UniversityStuttgart, Fakult”at f”ur Informatik, 1998. 17p.

[3] Joachim Baumann, Fritz Hohl, Nikolaos Rodouniklis, Kurt Rothermel, MarkusStra”ser. Communication concepts for mobile agent systems. In Kurt Rother-mel, editor, Proceedings of the First International Workshop on Mobile Agents(MA ’97), Berlin, April 1997, volume 1219 of Lecture Notes in ComputerScience, pages 123-125, Berlin, 1997. Springer Verlag.

[4] BEA, www.bea.com, Information about BEA WebLogic Application Server

[5] Y. Berbers, B. De Decker, W.Joosen. Infrastructure for Mobile Agents. In Sev-enth ACM SIGOPS European Workshop: System Support for Worldwide Ap-plications, Connemara (Ireland), September 1996, pages 173-180, New York,1996. ACM Press.

[6] Berlecon Research, http://www.berlecon.de

[7] J. Bradshaw. Introduction to Software Agents. In J. Bradshaw, editor, SoftwareAgents, pages 3-46. The MIT Press, Menlo Park, CA, 1996.

[8] Peter Braun, Jan Eismann, Wilhelm R. Rossak. A Multi-Agent Approach ToManage a Network of Mobile Agent Servers. Technical Report No. 12/01,Computer Science Department, Friedrich Schiller University Jena (publ. asJenaer Schriften zur Mathematik und Informatik), Juni 2001.

[9] Peter Braun, Christian Erfurth, Wilhelm R. Rossak. An Introduction to theTracy Mobile Agent System. Technical Report No. 2000/24, Computer ScienceDepartment, Friedrich Schiller University Jena (publ. as Jenaer Schriften zurMathematik und Informatik), September 2000.

[10] Peter Braun. ”Uber die Migration bei mobilen Agenten. Math/Inf/99/13, Com-puter Science Department, Friedrich Schiller University Jena (publ. as JenaerSchriften zur Mathematik und Informatik), April 1999, 52 p.

109

Bibliography

[11] Peter Braun, Jan Eismann, Wilhelm R. Rossak, Various Performance Exper-iments With the Mobile Agent System Tracy. Technical Report No. 11/01,Computer Science Department, Friedrich Schiller University Jena (publ. asJenaer Schriften zur Mathematik und Informatik), Juni 2001.

[12] Jonathan Bredin, David Kotz, Daniela Rus. Market-based resource control formobile agents. In Katia P.Sycara, editor, Proceedings of the Second Interna-tional Conference on Autonomous Agents, Minneapolis/ St.Paul, May 1998,pages 197-204, New York, 1998. ACM Press.

[13] A.K. Caglayan, C.G. Harrison . Intelligente Software-Agenten, Grundla-gen, Technik und praktische Anwendung im Unternehmen. Hanser Verlag,M”unchen, 1998.

[14] W.R. Cockayne, M.Zyda (contributor). Mobile Agents. Prentice Hall, 1998.

[15] Deloitte Research, http://www.dc.com

[16] Deloitte Research. B2B Darwinism: How e-Marketplaces Survive (and Suc-ceed). http://www.dc.com

[17] Deloitte Research. The Future of B2B: A New Genesis. http://www.dc.com

[18] eClass Specification, on http://www.eclass.de

[19] Electronic Commerce Code Management Association, Technical Secretariat.UNSPSC Technical Manual. on http://www.eccma.org, 29.11.2001

[20] Christian Erfurth, Peter Braun, Wilhelm R. Rossak. Some Thoughts on Mi-gration Intelligence for Mobile Agents. Technical Report No. 09/01, Com-puter Science Department, Friedrich Schiller University Jena (publ. as JenaerSchriften zur Mathematik und Informatik), Mai 2001.

[21] Explido, http://www.explido.de

[22] Forrester Research, http://www.forrester.com

[23] John Fou. Web Services and Mobile Agents. 2001. e-book, Tect Ltd, November2001

[24] Foundation for Intelligent Physical Agents (FIPA). http://www.fipa.org, June2001

[25] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994.

[26] Gartner Research, http://www.gartner.com

[27] D. Georgakopoulos, M. Hornik, A. Sheth. An Overview of Workflow Manage-ment: from Process Modeling to Work on Automation Infrastructure, Distri-uted and Parallel Databases. 3,119-153, 1995

110

Bibliography

[28] Steven Gjerstad, John Dickhaut. Price Formation in Double Auctions. In Jim-ing Liu, Yiming Ye (editor), E-Commerce Agents - Marketplace Solutions,Security Issues, and Supply and Demand, volume 2033 of Lecture Notes inArtificial Intelligence 2033, Springer Verlag, Berlin 2001

[29] C.G. Harrison, D.M. Chess, A. Kershenbaum. Mobile agents: Are they a goodidea? Research Report RC 19887, IBM Research Division, 1995.

[30] HP, http://www.bluestone.com. Information about HP application server

[31] IBM, http://www.ibm.com, Information about Web Sphere Application Server

[32] IKV++ GmbH, Grasshopper Basics and Concepts Release 2.2.Berlin, March2001, on http://www.Grasshopper.de

[33] Intershop, http://www.intershop.de, Enfinity 2.2 Developer Guide: Using theEnfinity Cartridge API, internal paper, Intershop GmbH, 2001

[34] Intershop, http://www.intershop.de, Enfinity 2.2 Developer Guide: Program-ming with Enfinity Remote XML Interface, internal paper, Intershop GmbH,2001

[35] Intershop, http://www.intershop.de, Inside Intershop Enfinity, internal paper,Intershop GmbH, 2001

[36] Intershop, http://www.intershop.de, Intershop Business Components: Autho-rization Workflow Component for Intershop Enfinity 2 (Developer Guide), in-ternal paper, Intershop GmbH Jena, 2001.

[37] Intershop, http://www.intershop.de, Intershop Business Components: Procure-ment Solution for Intershop Enfinity 2 (Auction Component Developer Guide),internal paper, Intershop GmbH Jena, 2001.

[38] Intershop, http://www.intershop.de, Intershop Business Components: Procure-ment Solution for Intershop Enfinity 2 (Purchasing Component DeveloperGuide), internal paper, Intershop GmbH Jena, 2002.

[39] Intershop, http://www.intershop.de, Intershop Business Components: Procure-ment Solution for Intershop Enfinity 2 (User Guide), internal paper, IntershopGmbH Jena, 2002.

[40] Intershop, http://www.intershop.de, Intershop Enfinity 2.2 Benchmark Reportfor Hewlett Packard HP-UX, internal paper, Intershop GmbH Jena, 2001.

[41] Intershop, http://www.intershop.de, Intershop Enfinity 2.2 Benchmark Reportfor Sun Solaris, internal paper, Intershop GmbH Jena, 2001.

[42] Intershop, http://www.intershop.de, Performance and Configuration Guide forIntershop Enfinity, internal paper, Intershop GmbH Jena, 2001.

[43] Intershop, http://www.intershop.de, PerformanceResultsEnfinity2.2.pdf, inter-nal paper, Intershop GmbH Jena, 2001.

111

Bibliography

[44] itworks.be. Information on Electronic Marketplaces, B2B Exchanges, B2BHubs and Net Markets. on http://www.itworks.be/marketplaces/index.html,June 2002

[45] S. Jablonski, C. Bußler. Workflow Management: Modeling Concepts, Archi-tecture and Implementation. International Thomson Computer Press, London,1996

[46] N.R. Jennings, P. Faratin, T.J. Norman, P. O’brien and B. Odgers, AutonomousAgents for Business Process Management, Int. Journal of Applied ArtificialIntelligence 14 (2) 145-189. (2000).

[47] Alan Kotok, David R. R. Webber, David RR Webber. ebXML: The New GlobalStandard for Doing Business on the Internet. New Riders Publishing, 1st edi-tion, 2001

[48] Ryszard Kowalczyk, Peter Braun, Jan Eismann, Bogdan Franczyk, Wilhelm R.Rossak, Andreas Speck. InterMarket - Towards Intelligent Mobile Agent-basede-Marketplaces. Proceedings of the 9th Annual IEEE Conference and Work-shop on the Engineering of Computer based Systems (ECBS), Lund (Schwe-den), April 2002, S. 268-275.

[49] R. Kowalczyk, V. Bui. On Constraint-based Reasoning in eNegotiation Agents.In F. Dignum and U. Cortes, editor, Agent Mediated Electronic Commerce III,LNAI(2000), Springer Verlag, pp. 31-46

[50] D.B. Lange, M. Ishima. Program and Deploying Java Mobile Agents withAgelets. Addison- Wesley, Reading, MA, 1998.

[51] P.W. Lei, M.I. Heywood, C.R.Chatwin. Negotiation Agents in ManufacturingDecision Making Processes. In Jiming Liu, Yiming Ye (editor), E-CommerceAgents - Marketplace Solutions, Security Issues, and Supply and Demand, vol-ume 2033 of Lecture Notes in Artificial Intelligence, Springer Verlag, Berlin,2001

[52] Lisa M. Lindgren. Application Servers for E-Business. CRC Press, 2001

[53] T. Lindholm, F. Yellin. Java Virtual Machine Specification,The. Second edition. Sun Microsystems Press, Palo Alto,CA, 1999. or on http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html, April 2002

[54] David Lowe, Xin Chen (contributor), Todd Mondor, Tomislav Rus, Ned Ryn-earson, Steve Wright (contributor), Tom Xu. BizTalk(TM) Server: The Com-plete Reference. Osborne McGraw-Hill, 1st edition, 2001

[55] Magnet, http://www.cs.umn.edu/Research/airvl/magnet/, June 2002

[56] F. Mattern. Mobile Agenten. It+it - Informationstechnik und Technische Infor-matik, (4):12-17, 1998

112

Bibliography

[57] D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman,K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran,J.White. MASIF: The OMG Mobile Agent System Interoperability facility. InKurt Rothermel, editor, Proceedings of the Second International Workshop onMobile Agents (MA’ 98), Stuttgart, September 1998, volume 1477 of LectureNotes in Computer Science, pages 50-67, Berlin, 1998. Springer Verlag. orhttp://www.fokus.gmd.de/research/cc/ecco/masif

[58] mySupplyChain.co.uk. What are B2B Marketplaces?. onhttp://www.mysupplychain.co.uk/B2B/b2bintroduction.htm, June 2002

[59] Toshiyuki Nishimura. Foreign and Domestic Trendsin the e-Marketplace. on E-Commerce Journal Japan.http://www.ecom.or.jp/ecome/latest/ecomjournalno1/topic-02.html, April2002

[60] H.S. Nwanda. Software agents: An overview. Knowledge Engineering Review,11(3): 205-244, 1996.

[61] ObjectSpace Inc. ObjectSpace Voyager Core Package Technical Overview:The Agent ORB for Java, December 1997.

[62] Persistence, www.persistence.com, Information about Persistence PowerTierApplication Server

[63] Roger Riggs, Antero Taivalsaari, Mark Vandenbrink, Jim Holliday. Pro-gramming Wireless Devices with the Java(TM) 2 Platform (Micro Edition).Addison-Wesley, 1st edition, June 2001 or on http://sun.com

[64] Kurt Rothermel, Markus Stra”ser. A protocol for preserving the exactly-onceproperty of mobile agents. Technical Report 1997/18, University Stuttgart,Fakult”at f”ur Informatik, 1997.

[65] Hans Albrecht Schmid. An Architecture for Internet Business Applicationswith Business Components. In Leonora Barroca, John Hall and Patrick Hall(editor), Software Architectures- Advances and Applications, 2nd print 2000,London, Springer Verlag

[66] Dorit Spiller, Nicole Dufft, Dr. Thorsten Wichmann. Vom Vermittler zum Di-enstleister: B2B- Marktpl”atze in Deutschland 2001. erschienen bei BerleconResearch GmbH, http://www.berlecon.de , Berlin, Mai 2001

[67] Sun Microsystems, http://www.sun.com, Information about SUN ONE Appli-cation Server

[68] Niranjan Suri, Jeffrey M. Bradshaw, Maggie R. Breedy, Paul T. Groth, GregoryA. Hill, and Renia Jeffers. Strong Mobility and Fine-Grained Resource Controlin NOMADS. In David Kotz, Friedemann Mattern (editor), Agent Systems,Mobile Agents, and Applications, volume 1882 of Lecture Notes in ComputerScience, pages 2-15, Berlin, 2000. Springer Verlag.

113

Bibliography

[69] Gaurav Tewari, Pattie Maes. A Generalized Platform for the Specification, Val-uation, and Brokering of Heterogeneous Resources in Electronic Markets. InJiming Liu, Yiming Ye (editor), E-Commerce Agents - Marketplace Solutions,Security Issues, and Supply and Demand, volume 2033 of Lecture Notes inArtificial Intelligence, Springer Verlag, Berlin 2001.

[70] G. Vigna. Mobile Agents and Security, volume 1419 of Lecture Notes in Com-puter Science. Springer Verlag, New York, 1999.

[71] G. Vigna. Mobile Code Technologies, Paradigms, and Applications. PhD the-sis, Politecnico di Milano, February 1998. 84 p.

[72] M. Weske. Workflow Management Systems: Formal Foundation, ConceptualDesign, Implementation Aspects. Habilitationsschrift Fachbereich Mathematikund Informatik, University M”unster, 2000

[73] J.E. White. Telescript technology: Mobile agents. The MIT Press, Menlo Park,CA, 1996. Also available as General Magic White Paper.

[74] J.E. White. Mobile Agents. In J. Bradshaw (editor), Software Agents, AAAIPress/MIT Press, Menlo Park, CA, 1996.

[75] Wilking, Lux, Eisinger, Hilger. Elektronische Marktplatze in der Einkauf-spraxis. Explido GmbH & Co KG, 2001, http://www.explido.de, orhttp://www.beschaffungswelt.de/explidostudie/explidostudie.html

[76] M. Wooldridge, N.R. Jennings. Intelligent agents: Theory and practice. TheKnowledge Engineering Review, 10(2): 115-152, 1995

[77] Mark Wutka. Special Edition Using Java 2 Enterprise Edition (J2EE): WithJSP, Servlets, EJB 2.0, JNDI, JMS, JDBC, CORBA, XML and RMI. Que, 1stedition, 2001

[78] W3C, Hypertext Transfer Protocol - HTTP/1.1. RFC 2616,http://www.w3c.org, June 1999.

[79] Andre Yee, Atul Apte. Integrating Your e-Business Enterprise. Sams Publish-ing, Indianapolis, 2001

[80] L. Yu, B.F. Schmid, A conceptual framework for agent-oriented and role-basedworkflow modeling, in G. Wagner and E. Yu, editors, Proc of the 1st Int. Work-shop on Agent-Oriented Information Systems, 1999.

[81] Giorgos Zacharia, Theodoros Evgeniou, Alexandros Moukas, PetrosBoufounos, Pattie Maes. Economics of Dynamic Pricing in a Reputation Bro-kered Agent Mediated Marketplace. In Jiming Liu, Yiming Ye (editor), E-Commerce Agents - Marketplace Solutions, Security Issues, and Supply andDemand, volume 2033 of Lecture Notes in Artificial Intelligence, SpringerVerlag, Berlin 2001

114

List of Figures

2.1. E-marketplaces enable services along the supply chain [66, p.19]. . . . . . . . . 122.2. Proper use of transaction models [66, p.23]. . . . . . . . . . . . . . . . . . . . . 132.3. Standard e-commerce three-tier architecture.. . . . . . . . . . . . . . . . . . . . 172.4. Architecture of a J2EE standard application server [52, p.145]. . . . . . . . . . . 192.5. Mobile agents migrate through heterogeneous networks.. . . . . . . . . . . . . 212.6. Mobile agent environment.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

3.1. Agent-based automated business workflows including intelligent negotiation tech-niques.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

3.2. Mobile agents provide marketplace access and interconnection via mobile devices.303.3. Agent-based features of an InterMarket e-marketplace.. . . . . . . . . . . . . . 313.4. Inside the InterMarket e-marketplace.. . . . . . . . . . . . . . . . . . . . . . . 333.5. Interconnection of agent-mediated e-commerce.. . . . . . . . . . . . . . . . . . 33

4.1. Actors of the agent-based features.. . . . . . . . . . . . . . . . . . . . . . . . .374.2. Life-cycle for a stationary manager agent.. . . . . . . . . . . . . . . . . . . . . 394.3. Getting contact to a stationary task agent.. . . . . . . . . . . . . . . . . . . . . 394.4. Life-cycle of a stationary task agent.. . . . . . . . . . . . . . . . . . . . . . . . 414.5. Mobile access to the marketplace activity diagram.. . . . . . . . . . . . . . . . 424.6. Stationary access to the marketplace activity diagram.. . . . . . . . . . . . . . . 424.7. Main model usecase diagram.. . . . . . . . . . . . . . . . . . . . . . . . . . . .434.8. Configure agent usecase diagram.. . . . . . . . . . . . . . . . . . . . . . . . .444.9. Perform tasks usecase diagram.. . . . . . . . . . . . . . . . . . . . . . . . . . .464.10. Example for a simple business workflow.. . . . . . . . . . . . . . . . . . . . . . 474.11. Agent-based search activity diagram.. . . . . . . . . . . . . . . . . . . . . . . . 484.12. Agent-based order activity diagram.. . . . . . . . . . . . . . . . . . . . . . . . 504.13. Agent-based request activity diagram.. . . . . . . . . . . . . . . . . . . . . . . 504.14. Agent-based auction bidding activity diagram.. . . . . . . . . . . . . . . . . . . 514.15. Agent-based negotiation activity diagram.. . . . . . . . . . . . . . . . . . . . . 524.16. Return results usecase diagram.. . . . . . . . . . . . . . . . . . . . . . . . . . .54

5.1. Core Enfinity 2.2 software architecture.. . . . . . . . . . . . . . . . . . . . . . 625.2. Data communication in Enfinity [35, p. 35]. . . . . . . . . . . . . . . . . . . . . 675.3. Workflow for a storefront request, [35, p. 46]. . . . . . . . . . . . . . . . . . . . 685.4. Processing a request with pipelines, [35, p.48]. . . . . . . . . . . . . . . . . . . 695.5. The Enfinity Cartidge API, [35, p.73]. . . . . . . . . . . . . . . . . . . . . . . . 705.6. Cartridge Management, [33, p. 26]. . . . . . . . . . . . . . . . . . . . . . . . . 715.7. The Enfinity Remote XML API, [35, p. 72]. . . . . . . . . . . . . . . . . . . . . 71

115

List of Figures

5.8. The Procurement Solution application layer, [38, p.25]. . . . . . . . . . . . . . . 745.9. Example for a Tracy infrastructure consisting of three platforms.. . . . . . . . . 765.10. Overview of the Tracy architecture.. . . . . . . . . . . . . . . . . . . . . . . . 83

6.1. A user configures a mobile agent via the application server.. . . . . . . . . . . . 866.2. A stationary agent returns results to a user via application server.. . . . . . . . . 906.3. Communication from Tracy to Enfinity.. . . . . . . . . . . . . . . . . . . . . . 926.4. Communication from Enfinity to Tracy of the first approach.. . . . . . . . . . . 936.5. Scale communication between both InterMarket sub-systems.. . . . . . . . . . . 946.6. Overall InterMarket software architecture.. . . . . . . . . . . . . . . . . . . . . 95

116

A. References for Basic Knowledge

Object-oriented analysis and design and UML

• Developing Software with Uml: Object-Oriented Analysis and Design in Practice, byBernd Oestereich, Addison Wesley Professional, 2nd edition (July 15, 2002)

• The Unified Modeling Language User Guide, by Grady Booch, Ivar Jacobson, James Rum-baugh, Jim Rumbaugh, Addison-Wesley Pub Co, 1st edition (October 30, 1998)

Component-based software development and software architectures

• Component Based Software Engineering: Putting the Pieces Together, by George T. Heine-man, William T. Councill, Addison-Wesley Pub Co, 1st edition (June 8, 2001)

• Design and Use of Software Architectures, by Jan Bosch, Addison-Wesley Pub Co, 1stedition (May 19, 2000)

• Software Architecture in Practice, by Len Bass, Paul Clements, Rick Kazman, Ken Bass,Addison-Wesley Pub Co, 1st edition (January 1998)

Java 2 and Java 2 Enterprise Edition (J2EE)

• Core Java 2, Volume 1: Fundamentals (5th Edition), by Cay S. Horstmann, Gary Cornell,Prentice Hall PTR, 5th edition (December 18, 2000)

• Special Edition Using Java 2 Enterprise Edition (J2EE): With JSP, Servlets, EJB 2.0, JNDI,JMS, JDBC, CORBA, XML and RMI, by Mark Wutka, Que, 1st edition (May 8, 2001)

Communication protocols such as HTTP, RMI, and CORBA

• HTTP Essentials: Protocols for Secure, Scaleable Web Sites, by Stephen Thomas, JohnWiley & Sons, Bk&Cd-Rom edition (March 8, 2001)

• Java RMI, by William Grosso, O’Reilly & Associates, 1st edition (October 15, 2001)

• Client/Server Programming with Java and CORBA, 2nd Edition, by Dan Harkey, RobertOrfali, John Wiley & Sons, 2nd Bk&cdr edition (March 10, 1998)

Fundamentals of XML

• Beginning XML, by David Hunter, Jeff Rafter, Jon Pinnock, Chris Dix, Kurt Cagle, RogerKovack, Wrox Press Inc, 2nd edition (November 2001)

117

integrating mobile agent technology into an e-marketplace solution

Documents