Architectural Overview of Managed Electronic Commerce

Framework 1: Optimized eCommerce Processes
The first framework optimizes eCommerce processes, thus managing overall process execution efficiency. Figure 1 shows optimization occurring for each player (x) and transaction pair (y), or the entire roundtrip process for invocation and completion of any given transaction.

Figure 1. Representation of Performance Optimization of Players (x), Transaction Pairs (y), and Roundtrip Process Transaction

Framework 2: Managed eCommerce Process Components
The second framework manages all components and/or tasks associated with e-commerce processes, thus managing/monitoring the overall health of process execution. This health management includes state determination of the eCommunity (e.g., systems, networks, subscribers, users, components); process recovery whenever an interruption occurs; and/or alternate path selection options, all of which leverage the essential precursor philosophy of the Internet.

The economic benefits derived from ICI's managed electronic commerce solutions stem from the transition from a tried-and-true paradigm of use and interaction to a revolutionary one that transcends previous thinking. It means taking a different direction across the well-traveled internetscape to one that offers many paths for optimum transversal for e-commerce transactions.

For users, the new paradigm of managed electronic commerce means faster fulfillment and increased assurance that the transaction processes are more reliable, visible, well defined, have a known state, are understandable, trusted, and believable.

Individual service providers achieve higher volumes and guaranteed transactions when they become the optimal providers for the given transaction. Financial institutions garner greater efficiencies and higher transactional throughput.

ICI's eCommerce environment provides an unrestricted retail presence to virtual storeowners, where company size no longer matters, nor is it readily apparent. Moreover, our approach projects the same component-based, reusable software technology gains into the electronic-enabled marketplace, thereby transcending the commonly held "packetized" view currently in vogue today. Such a strategy leads to dynamically negotiated business deals, which could also be described as virtually instantaneous nodal network optimization, where the nodes represent each of the e-commerce players.

The Foundation Underlying the Architecture
The Managed Electronic Commerce architecture focuses on tying together distributed processing elements into workflows, where each workflow describes and implements both a business process and process management status for measuring and managing workflow progress, system security, system integrity, etc. The architecture encourages loose interconnections among processing elements, supports both dynamic and static creation of relationships among processing elements, and easy insertion or removal of processing elements.

As mentioned previously, the system supports management of electronic commerce in two dimensions. First, enterprise management tools monitor and manage the tools. Second, the electronic commerce processes are themselves managed, with the goal of achieving optimal execution of electronic commerce tasks.

A processing element (i.e., a "cluster") in this architecture generally implements a service such as a product catalog, credit-card authorization, a search engine, multiple catalog searches, negotiation of transaction terms between a buyer and seller, and so on. The architecture requires all clusters to provide a uniform interface, including elements that support management of the cluster and the cluster services, as well as the elements required to participate in workflows. This cluster-based architecture is an object-oriented, component-based framework for task planning and execution systems.

The platform-independent system components operate in a highly distributed environment connected via local- and wide-area networks. Clusters exchange information to perform tasks, carry out those tasks autonomously and in parallel, and then exchange results that can serve as input for other tasks. The system replicates the basic building block, the cluster, to support many concurrent requests. A small collection of clusters, typically interconnected using a high-speed network, is called a Community. The collection of all clusters is called the Society. To be a member of the Society means that a cluster correctly implements the interfaces defined by the architecture, both the syntactic syntax and dynamic behavior. Clusters can be configured independently to accomplish diverse tasks by integrating custom support for those specialized tasks. The architecture provides for customization by encouraging dynamic loading of "plug-ins," where a plug-in is a service smaller than a cluster that extends the cluster capabilities.

An important system design requirement is to produce a common system for all facets of electronic commerce operations: planning, execution, training, and operations, from fixed or mobile locations. The system operates in the same way, and presents the same interfaces to users in all of these environments.

Elements of the system continuously plan, execute, and monitor events. As soon as one processing cycle ends, the next cycle begins. Each cycle uses the most up-to-date real-world information as well as the results from the previous cycle within MEC. As each cycle completes, the results of that cycle are assessed, events are propagated to parts of the MEC system that control and modify tasks, and are further propagated to users, as appropriate.

Figure 2. Representation of Managers, Service Providers, and User Proxies in Action

The MEC system monitors appropriate databases, typically using events or triggers for changes in the real world, such as a change in inventory status as a result of a transaction that occurred outside the MEC system, or a shipment delay being reflected in the shipper's database. As a result of this continuous monitoring of change, each processing cycle within the MEC system will work from the most current information.

The MEC system is highly distributed. Each cluster contains a set of basic component software and a specialized set for the tasks that the cluster performs. Different clusters and even different components of the same cluster can reside on different machines that communicate over local- and wide- area networks.

Figure 3. The 3 Independent Orthogonal Dimensions of the MEC System

Architectural Components
The society of clusters supports organizations consisting of managers, service providers, and requesters or user proxies. Managers can task a service provider to perform certain activities. The providers respond with the "cost" associated with performing that function. Requesters send specific support directives to the service providers. The service providers respond with assigned resources to satisfy that request and can generate an exception event indicating the request cannot be satisfied. Service providers can also act as requesters when they require services from another provider. See Figure 2 for a graphical representation of the relationships of these organizations.

User proxies are clusters that represent the individual or business user specified in the particular electronic commerce process. These clusters represent the source of anticipated and actual requests for goods and services, either for individuals or for business units. Figure 3 depicts three independent, orthogonal dimensions of the managed electronic commerce system: workflow dimension, MEC cluster dimension, and persistence dimension.

Workflow Dimension: A workflow is a set of related tasks and capabilities leading to the achievement of a goal. An MEC template workflow contains subtasks, their dependencies, start time relative to the parent's, expected duration of the individual workflow steps, and a description of the resources necessary to execute the workflow. As the workflow execution occurs, the Workflow Manager monitors the workflow progress to understand when a workflow step should complete and how to manage events flagged during workflow operations.

MEC Cluster Dimension: A cluster develops and monitors the eCommerce plan, and

  • Expands directives using template workflows to create expanded workflows (Expander Service)
  • Allocates assets to an expanded workflow for a given time to create an allocated workflow (Allocator Service)
  • Assesses whether the assigned assets and expanded workflow and schedule meet the original objectives (Assessor Service).

Figure 4. Representation of the MEC Cluster Dimension in Action

Persistence Dimension: Manages data that survives the execution of any one computer program. The Expander, Allocator, and Assessor services read and write long-lived data via the Data Services interface. Within an MEC cluster, Expanders expand the specified tasks into implied tasks (if necessary) that Allocators can fulfill. Tasks can be allocated to other MEC clusters that actually allocate resources to fulfill the specified task.

Cluster Content
Each cluster contains three entities with independent execution threads and two collections of services. Workflow steps, Workflow management, and Cluster management all contain independent execution threads. The Expander Service and Allocator Service each provide passive services.

Expander Service
The task expander receives all unexpanded tasks from the directives list. The task expander's role is to expand incoming directives into support and implied tasks.

Allocator Services
Inputs to the Allocator include all local directives, all locally owned resources, and existing locally generated entries in an e-commerce plan, which are the time-phased relations between local directives and local resources. The outputs from the Allocator include allocated directives to resources or clusters, tasks, orders, new or updated entries in the e-Commerce plan, and exceptions, for cases in which a directive cannot be satisfied within the current constraints.

Workflow Manager
The Workflow Manager monitors real-world events as they relate to an eCommerce plan, and judges the plan's conformance to threshold values. Nonconforming events generate exceptions for out-of-bound conditions.

The job of the Workflow Manager is to (1) monitor the current and future development and execution of an eCommerce plan, and to (2) perform specified actions whenever a plan element ventures outside of prescribed boundary conditions.

Data Management
Data management will be carried out on newly emerging capabilities of Computer Associate's JasmineŽ infrastructure. ICI will use Jasmine to facilitate the electronic commerce workflow representation for supporting persistent storage of object instances for the managed eCommerce cluster and cluster components. ICI has successfully used the Jasmine OODB underpinning in existing electronic commerce web sites and service offerings. The Jasmine infrastructure will maintain the existing host application and database access, and extend access to several new types of logic and data.

Managed eCommerce Management Components SNMP entities consist of applications that either serve as command generators or notification receivers. Some applications can contain both elements. Managed information typically is represented as a value to variable mapping for physical devices in the network, where the structure of that information is described in a management information base (MIB).

The SNMP and MIB specifications are ideal for specifying interoperable management protocols for a family of important electronic commerce activities.

By leveraging our experience and expertise in the development of SNMP agents, we will implement the appropriate agent policy for the managed eCommerce component suite. This agent policy will include the following:

  • Class spec of objects in the managed eCommerce component suite to be managed
  • Data within the managed eCommerce component suite required to manage objects
  • Mechanisms or applications used to gather data for MEC components
  • Rules for correlating management data into the relevant views of electronic commerce process views
  • Actions necessary based on the correlated data, and the definition and implementation of the presentation of raw/correlated data