Intelligent Enterprises of the 21st Century

2017-07-07 02:10:07

Software agents can support a flexible and a scalable architecture for B2B commerce, where highly autonomous entities working in unison are required to provide the right information and processing at the right time. The agent-based architecture presented in this section supports intelligent agents that automate most of the decision making process in a B2B environment. The major design goals include the following:

Creating an integration backbone to power the information exchange to enable agents to obtain information appropriately

Support for highly dynamic and real-time events

Integration of multiple types of applications such as mobile, desktop and enterprise level

Integration of different business events and transactions

Support continuously changing business entities and models

Ability to coordinate events between different business systems

Capability to authenticate and secure transactions at a very granular level

Support scalability

Creating a secure environment for B2B transactions

Support automated decision making by agents

To illustrate these points we take into consideration a sample scenario of B2B e-exchange, where various enterprises have to coordinate in order to provide services and conduct business. We provide a high-level view of this scenario, discuss the applicability of the agent-based architecture, and provide a comprehensive agent-based architecture for an e-exchange and participant side B2B interface system components.

B2B e-Exchange

A typical B2B e-exchange, whether they are private or public, involves several different participants from various communities (see Figure 1). This includes:

Exchange owners or administrators

Different buyers belonging to the buyers in the exchange

Different sellers selling various items in the exchange

Support service providers that provide the necessary infrastructure for facilitating business transactions, such as financial and shipping services

Figure 1: An e-Exchange Environment.

It is imperative that all participants in this exchange have a highly automated information exchange and decision-making infrastructure. Information about supplier items, buyer interests, inventory and others must flow seamlessly. Decisions must be taken and actions be executed based on this information. For the current scenario, no comprehensive reference architecture exists in the open literature. The sections below describe some foundational components of a comprehensive architecture.

E-Exchange Architecture

The high-level logical view of the proposed architecture for an e-exchange is presented in Figure 2. This architecture mirrors the "real world" exchanges where human players, possessing domain specific knowledge, use services and interact with other humans. There are three categories of agents in this architecture: (1) agents that represent participants in the e-exchange; (2) agents that enterprise B2B systems at participant locations; and (3) agents that implement various services in the e-exchange. An e-exchange presents a platform where agents interact with other agents in the virtual trading arena to conduct commerce. All resources required by buyers and sellers to exchange information, products, services, and money are provided by the e-exchange.

Figure 2: Logical View of an e-Exchange.

The architecture presented is not monolithic. Instead, this architecture supports the distribution of agents and services over multiple platforms. For example, the financing service and financing agents can reside on machines that are optimized for this service. Furthermore, various services could be replicated on multiple platforms thereby facilitating scalability. These platforms are networked to support the logical view in Figure 2.

Services

Many services are supported by the e-exchange architecture. New services can be easily added due to the open-systems nature of the architecture, thereby enabling extensibility. Every service supports a set of application program interface (API) functions that are used by various agents to interact with the service. The generic service architecture is illustrated in Figure 3. It can be seen from Figure 3, that a service is self-contained as it includes an object model, methods implementing the service logic based on the object model, and facilities for data storage. The object model for a service represents metadata of business process and rules for that service, that are independent of the physical implementation.

Figure 3: High-Level Service Architecture.

The service architecture can be explained using the following example. In the case of the catalog service, data on products, etc., are stored in the database. Supplier agents using catalog service methods are able to update product information in the database. Buyer transaction agents use the catalog service methods to query the catalog database for product information. The catalog service logic can be distributed as well as be replicated among multiple agents. For example, for every transaction received by the catalog service, a separate agent within the catalog service and possessing the logic to manage the transaction can be spawned.

The various services are described as follows.

Communication Service. This service supports communication between: agentagent, agent-service, and service-service. The transport protocol used is TCP/IP. This service is capable of routing SOAP envelopes that carry XML messages.

Security Service. The security service provides authentication and encryption and is linked to the public key infrastructure (PKI). The security service can be extended to support new authentication and encryption mechanisms.

Management Service. This service provides tools for managing the e-exchange such as tools for configuration, performance tuning, data collection etc.

Registration Service. The registration service allows participants to register with the e-exchange.

Catalog Service. The catalog service maintains the catalog of all products and services that are traded in the e-exchange. To maintain consistency in the names of products from various vendors, ontology of products and services is used by the catalog service. A supplier agent, while shipping data for catalog updates is required to follow the ontology. This greatly reduces the maintenance of data. Sometimes, suppliers do not provide detailed information on product and services such as price, as they like to store it at their own location within their firewalls. In such situations, upon receiving a product query request, the catalog service in turn sends messages to various supplier agents for the requested information. The catalog service supports parametric searches for buyer queries.

Translation Service. The messages exchanged within the e-exchange are required to be XML versions of X.12 messages or some other standards that are encapsulated by SOAP. Some participants of the exchange may not be equipped to send messages in the correct format. In which case, the translation service translates messages received from the participants into appropriate XML/SOAP messages. While sending messages back to the participant, the translation service converts XML/SOAP messages back to the format acceptable to the participants. Hence, the translation services enables participants to send messages to the e-exchange in a variety of formats.

Auction Service. The auction service has the logic to conduct auctions. This service can spawn multiple auctions, enforce the auction rules and receive and record bids from all the agents representing auction participants. The auction service can launch a service agent to manage a particular auction instance.

Order Service. The order service is responsible for processing orders for different ordering styles. Request for proposals/quotations (RFP/RFQ) sent by the buyer transaction agent are received by the order service, which in turn delivers them to the relevant seller agents. The various proposals and quotations from sellers received by the order service are then forwarded to the buyer transaction agent. A buyer transaction agent sends an order document to the order service, which in turn after recording the order details, sends it to the seller agent. The order service sends out the purchase order acknowledgment received from the seller agent to the buyer transaction agent. The order service also supports negotiations between buyers and sellers as well as transactions involving bartering and basket deals.

Settlement Service. This service manages the settlement of a transaction. This involves processing payments made via credit card, checks, bank-credit, and procurement cards. All settlement information is duly recorded by this service.

Maintenance and Warranty Service. Many buying transactions involve the purchase of extended warranty, insurance, etc. The maintenance and warranty service maintains a database of warranty and insurance service providers as well as records of all maintenance and warranty transactions. This service maintains links with all agents that represent maintenance and warranty service providers in the e-exchange.

Financing Service. The financing service maintains a directory of all financing companies who participate in the e-exchange. Financing agents in the e-exchange represent financing companies. A transaction requiring financing is sent to the financing service, which in turn, contacts the financing agents. The financing service can be configured to support reverse auction, whereby financing agents bid on the financing terms based on the buyer's profile and transaction information provided by the financing service. The financing service can choose the bid with the best terms or pass on all the bids to the buyer transaction agent.

Shipping Service. This service maintains a database of all shippers that participate in the e-exchange. Agents represent various shippers in the e-exchange. A transaction requiring shipping is sent to the shipping service, which in turn contacts the various shipping agents representing the shippers. The shipping service can be configured to support various market mechanisms such as reverse auction to obtain bids from shippers. The shipping service can itself choose the bid with the best terms or pass on all the bids to the buyer transaction agent that represents the buyer.

Agent Categories

Agents can play many roles in the e-exchange. Approaches such as Role-Algebraic Multi-Agent System Design (RAMASD) can be used to map agents to one or more roles (Karageorgos et al., 2002). When viewed at a higher level, agents can belong to three categories: agents that represent the participants in the e-exchange, agents of participant-side B2B systems and agents that implement service logic. Agents that represent participants can be customized to the needs of the participant, thereby enabling "stickiness" of the participants to the e-exchange. The following types of agents are used in the e-exchange.

Agents Representing Participants in E-Exchange

Buyer Agent: A buyer agent is launched for each transaction that involves a buyer. This agent relays messages from the personal assistant agent of the user, or other agents on the buyer's protected site, to agents and services in the e-exchange and vice versa. The buyer agent may have embedded workflow logic to keep track of transactions from start to finish. It may also have the intelligence to make buying decisions autonomously. However, for security reasons, especially when the exchange platform is not trusted, a buyer agent may not encapsulate sensitive decision rules, logic and other propriety information. In this situation, a buyer agent may let agents located on a secure platform at the buyer's site make buying decisions. The buyer agent can spawn new child transactions. For example, when the buyer requires a bundle of items, the buyer agent may source the items in the bundle from multiple suppliers based on cost considerations, thereby leading to multiple child transactions. The buyer agent can participate in auctions on behalf of the buyer and use the parameters specified by the buyer to enter bids.

Seller Agent: A seller agent is associated with every transaction involving a specific seller. This agent relays messages from the personal assistant agent, or other agents located at the seller's protected site, to agents and services in the e-exchange and vice versa. The seller agent may have embedded workflow logic and intelligence to keep track of transactions involving the seller from start to finish. It can relay purchase orders to the seller system, bid in reverse auctions based on seller specified parameters, invoke catalog service API's to update catalog data pertaining to the seller, and communicate messages such as proposals and quotations, purchase order acknowledgment, order status, as well as participate in reverse auctions. Due to security reasons however, the seller agent may not always encapsulate sensitive decision rules, logic and other propriety information, and let an agent located on a secure platform at the seller's site make selling decisions.

Shipping Agent: A shipping agent is associated with every transaction involving a specific shipping company. This agent relays messages from the shipping company's gateway agent (located at the shipping company's site) to agents and services in the e-exchange and vice versa. The shipping agent may have embedded workflow logic and intelligence to handle transactions pertaining to shipping. It can relay shipping RFQ/RFP to the shipping company's gateway agent as well as participate in reverse auctions involving shipping bids. Due to security reasons, the financing agent may not encapsulate sensitive decision rules, logic and other propriety information, and let an agent located on a secure platform at the shipping company's site make shipping decisions.

Financing Agent: The financing agent represents a financing company in the e-exchange and is involved with every transaction involving the financing company. This agent relays messages from the financing company's gateway agent (located at the financing company's site) to agents and services in the e-exchange and vice versa. The financing agent may have embedded workflow logic and intelligence to handle transactions pertaining to financing. It can relay financing RFQ/RFP to the financing company's gateway agent as well as participate in reverse auctions involving financing bids. Due to security reasons, the financing agent may not encapsulate sensitive decision rules, logic and other propriety information, and let an agent located on a secure platform at the financing company's site make financing decisions.

Maintenance & Warranty Agent: The maintenance and warranty agent represents maintenance and warranty/insurance companies in the e-exchange and is involved with every transaction involving the company. This agent relays messages from the company's gateway agent (located at the company's site) to agents and services in the e-exchange and vice versa. The maintenance and warranty agent may have embedded workflow logic and intelligence to handle transactions pertaining to maintenance and warranty/insurance. It can relay RFQ/RFP to the maintenance/warranty/insurance company's gateway agent as well as participate in reverse auctions. Again due to security reasons, the maintenance and warranty agent may not encapsulate sensitive decision rules, logic and other propriety information, and let an agent located on a secure platform at the maintenance and warranty/insurance company's site make decisions.

Agents of Participant's Enterprise Systems

There are three types of agents located at the participant B2B systems: gateway agents, personal assistants, and decision agents. Gateway agents are located just inside the firewalls of an enterprise participating in an e-exchange. These agents have a global view of the participant enterprises as they maintain the organization profile. Gateway agents are intelligent and have embedded workflow rules to filter or route transactions initiated from within the enterprise to external e-exchanges as well as to other entities within the enterprise. All messages to external e-exchanges have to pass through the gateway agent.

Personal assistant agents are associated with persons in the participating enterprises that interact with an e-exchange (i.e., users) or with supply-chain processes. These agents incorporate user/process preferences, and maintain user/process profile. They support interfaces that allow users/processes to issue requests. These requests are then shipped to the gateway agent for further routing.

Decision agents for making buying and selling decisions may be located on a trusted platform within the enterprise. When the exchange platform is not trusted, the agents representing an enterprise on the e-exchange platform may not encapsulate sensitive information and logic, and are thus prevented from making decisions autonomously. In which case, the decision agents that encapsulate sensitive information and logic may drive the decision making process and the agents representing the enterprise on the exchange may follow the instructions of the decision agents.

Agents Implementing Services in the E-Exchange

Agents implement service logic on an e-exchange, thereby enabling various services to be scalable and to be easily replicated. For example, in the case of the order service, mediator agents could mediate negotiation transactions; barter agents could manage barter transactions, etc. Similarly, the auction service contains agents with auction specific embedded rules to conduct auctions in the auction arena. Such as the English auction manager, Dutch auction manager, etc.

Interfaces & Enabling Technologies

In order for an exchange to succeed it must use several different enabling technologies and provide interfaces that can be used to easily enable the participation of supplier, buyers and providers. Some important interfaces and potential enabling technologies that our architecture would support are discussed below.

Transport Interfaces

At the lowest level an e-exchange needs to be able to do very efficient data integration and provide an infrastructure that enables the exchange participants to exchange information very efficiently. Within the exchange, the architecture ensures that data integration is accomplished in a cohesive fashion across these different types of transport interfaces. Examples of transport interfaces include:

Batch data movement interface that enables movement of bulk data to and from the exchange. This interface is useful for operations such as initial catalog upload, periodic synchronization, audit, billing and transaction log transfer.

Messaging interfaces enable data integration using asynchronous messages and provide such additional features as assured delivery and location transparency.

Internet Protocols such as HTTP, SMIME, IMAP interfaces support data integration since these serve as low-cost interfaces that are widely supported.

Object Model

One of the key elements that we propose is for an exchange to have a flexible implementation of the business models in the form of object models that are extensible and decoupled from the actual physical database implementations. A key consideration for the success of an exchange is to be highly dynamic and cater to the requirements of the trading community at business speed and not at IT speed. This means that representations of business entities within the exchanges, such as items, prices, buyers, sellers, providers, transactions and trading models are not hard coded, but easily extensible and modifiable. Static relational model implementations will constrain the exchange and might eventually cause the exchange to fail.

Secondly, for the autonomous agents to be most efficient they need to be associated with the business issues that they operate on appropriately. For example, a negotiation agent that is responsible for automatically negotiating the price must have proper associations with specific instances of the issues such as item, price, quantity, and events that change these instances. This requires a sophisticated object model representation of business issues and different associations between them.

Lastly, by appropriately representing the entities and capturing them in a flexible manner, an exchange can introduce new business models much more readily. For example, if an exchange already provides basic auction capabilities, with a flexible object model, introducing reverse, Dutch and Yankee auctions would simply require creating new agents and business rules. With a fixed data model, this will require a complete reengineering of the representations.

XML/SOAP Messages

The messages exchanged between agents within the e-exchange are required to be XML messages encapsulated in a SOAP envelope. XML enables the creation of custom tags for various application domains. This provides the needed flexibility for a particular domain. Standard bodies such as HL7 (www.hl7.org) have come up with XML-based message standards for healthcare. Many other standard bodies and consortia have XML-based standards for various other domains (Chari & Seshadri). The XML message can be easily encapsulated in a SOAP envelope. The SOAP envelope can, not only facilitate the routing of the XML messages to various agents, but it can also enable destination methods to be invoked in order to process an XML/SOAP message. Figure 4 illustrates an XML message encapsulated in a SOAP envelope sent to the catalog service for price request. The response sent is shown in Figure 5.

POST /CatalogService HTTP/1.1 Host: www.AgentBasedB2B.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.AgentBasedB2B.com/CatalogService" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encoding/> <SOAP-ENV:Body> <m:GetItemPrice xmlns:m="http://www.AgentBasedB2B.com/CatalogService/catalog"> <Item> <SKU> 10010011 </SKU> <ItemName>Nuts-1/4</ItemName> <ItemDescription> ¹/4 inch nuts </ItemDescription> </Item> </m:GetItemPrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Figure 4: "Get Item Price" Message in SOAP/XML Format.

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encoding/> <SOAP-ENV:Body> <m:GetItemPriceResponse xmlns:m="http://www.AgentBasedB2B.com/CatalogService/catalog"> <Item> <SKU> 10010011 </SKU> <ItemName>Nuts-1/4</ItemName> <ItemDescription> ¹/4 inch nuts </ItemDescription> </Item> <Price> <PriceValue> 10 </PriceValue> <Currency> US Dollars </Currency> <PriceQuantity> pack of 50 </PriceQuantity> </Price> <Seller-Item> <Seller-ID> 12345 </Seller-ID> </Seller-Item> </m:GetItemPriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Figure 5: "Get Item Price Response" Message in SOAP/XML Format.