During the information analysis of the IPSI project, it was recognized that the electronic commerce portal serves as an integration platform for different heterogeneous subsystems. Based on a 3-tier-architecture, the user interface and data repository are separated from the functional application logic (Lewandowski, 1998). On the level of the functional application logic, the following subsystems of an electronic commerce portal have been identified:

• Office System: (1) The office system manages contact addresses and scheduled appointments. For addresses, remote data and local data are distinguished: While remote data is managed by the partner management system of the insurance company, local data is managed by an office system on the user's computer in order to satisfy his privacy requirements.
   
• Content Management System: Information of any kind is supplied by the content management system. Each employee of a company (e.g. management, back office employees or agents of the insurance company) can provide information for all others. Governed by individual access rights, every employee can get information from or put information into the content management system for every other employee (e.g. new product portfolio, handbooks, marketing materials, comments to the law, decisions in the context of insurances, etc.). The content management system will organize this information using different views and access rights.
   
• Procurement System: The procurement system offers consumer goods (e.g. laser printers, toner, pencils, etc.) and services (e.g. courses, trainings, seminars, etc.). Every insurance agent can order consumer goods for his daily work. The management can monitor the orders and control the costs caused by the insurance agents.
   
• Communications System: The communications system represents the interface to telecommunications media like mobile phones, fax and e-mail. The communications system is able to send documents, notifications or reminders by e-mail, Short Message Service (SMS) or fax. Notifications and reminders are sent at a pre-defined time set by the office system.
   
• Portal Administration System: The portal administration system serves as the single point of login, i.e. the user of the electronic commerce portal does not need to authorize himself at each subsystem of the portal. The second purpose of the portal administration system is the analyzation and presentation of the log files of the subsystems.
   
• Search System: The search system allows the user to search for information in the entire electronic commerce portal, based either on full text scan retrieval or predefined keywords. The results of a search request can be appointments, addresses of customers, information from the content management system, ordered goods or a combination of these elements.
   
• Legacy System: A legacy system is an external system not included in, but connected to the electronic commerce portal. Legacy systems are realized as host applications.

The portal user interface consists of web pages written in Hypertext Markup Language (HTML). For data management, a relational database management system is used if the subsystems do not have their own repository. Now, let's take a closer look at the system architecture (Figure 1):

Figure 1. System Architecture

Office, content management, procurement, legacy and communications are all external systems. To avoid building these from scratch, it was decided to integrate existing solutions into the electronic commerce portal.

Since the interfaces used to access the external systems are very different, each one is connected to the central middleware "backbone" via an individual adaptor. Each adaptor provides a set of methods to the middleware that encapsulates the native interface of the external system. This way, the (possibly complicated) native interface does not need to be publicly known in order to access its functionality. Instead, other subsystems can simply use the methods provided by the adaptor. For example, to send an e-mail via the communications system, it is sufficient to call the respective method of the communications adaptor which will then take care of constructing a RFC822-compliant message (Crocker, 1982) from the supplied parameters, setting up a session with the SMTP server and sending the e-mail. Furthermore, the encapsulation allows for an easy change of external systems: If a system's native interface changes, only its own adaptor must be rewritten while all other subsystems remain untouched.

The user interacts with the electronic commerce portal primarily via a web browser (other user agents such as mobile phones are also allowed by the system architecture). This has important implications for the control flow within the system: In traditional software systems, the dialog can be controlled by the system to a large extent: For example, the system can open a modal dialog box at any time, forcing the user to take some specific action before he can do anything else (Nielsen, 1997). On the web, however, all actions are initiated by the user. The server cannot push information to the browser that the user did not request (2).

Consequently, the external systems (office, content management etc.) of the electronic commerce portal remain passive and act only on user requests passed to them via the path depicted in Figure 2:

Figure 2. Communication within the Electronic Commerce Portal

Every user action like clicking on a link or submitting a form generates an HTTP request (Fielding et al., 1999) which is received by a central dispatcher. The dispatcher parses the HTTP request string, builds a request object from its contents and passes it to the controller that is responsible for handling the requested task. The search controller and admin controller implement the functionality of the search and portal administration systems mentioned earlier; all other transactions involving the external systems are handled by the workflow controller.

The controllers might be considered the brains of the electronic commerce portal: They evaluate the request objects passed by the dispatcher. Depending on the type of request, they send commands to or query information from the external systems, consolidate the results and return them to the dispatcher. To achieve this, the specific workflow necessary to fulfill any given request is hard-coded into the respective controller. For example, upon receiving a request to search for a particular person in all the external systems, the search controller queries the office, content management and legacy systems and returns the combined results to the dispatcher.

The dispatcher then forwards the response object received from the controller to the formatter. This subsystem is responsible for converting the information contained in the response object into a format the user agent can render. In most situations, the preferred output format will be Hypertext Markup Language (HTML) (Pemberton et al., 2000) which is accessible with a wide range of user agents. For more exotic user agents such as WAP phones and organizers, other formatters can generate output formats like Wireless Markup Language (WML) (WAP Forum, 1999). This flexibility is one main advantage of the separation between formatters and controllers: Since the implementation of the user interface is concentrated in one dedicated system, the visual presentation of information can be changed or expanded without touching any of the systems actually providing the information.

Because of performance considerations and special system requirements, most external subsystems and the web server run on separate computers. This distributed architecture requires a middleware like CORBA to coordinate the calling of methods and passing of objects among the different subsystems. Of course, using the middleware is not necesssary within single subsystems such as the user interface: For example, the dispatcher calls a method of the formatter directly to pass a response object received from a controller.

The dispatcher and the controllers, however, might run on different machines. Thus, they exchange objects via the middleware. Two models of communication were considered during the design phase of the project:

1. Publisher/Subscriber Model: The dispatcher publishes a request object via the middleware and announces its availability with an event that describes the type of request. Controllers can subscribe to events that are relevant to them and get a copy of the respective request object from the middleware.
    
2. Explicit Call Model: Based on the type of request, the dispatcher decides which controller(s) it must call to pass the request object to via the middleware.

In the publisher/subscriber model, the dispatcher is effectively reduced to a mechanism for converting HTTP request strings to request objects since it does not know which controller is responsible for which type of request. While this may at first seem like an elegant decoupling, there are some pitfalls: Although the "sending" part of the dispatcher does not need to be changed when a new controller is added to the subscriber list, the "receiving" part must still be prepared to accept result objects from the additional controller. Regarding the effort for defining interfaces between the dispatcher and the controllers, the publisher/subscriber model holds no advantage over the explicit call model: Both dispatcher and controllers need to know which attributes are defined for request objects of any type, regardless of the means by which the objects are transported. More problems arise from the multi-user environment of the electronic commerce portal: The dispatcher needs to know which result object returned by the controller corresponds to which request object passed to it. In the explicit call model, this mapping is implicitly provided by the call stack of the middleware. In the publisher/subscriber model, each request object (and the objects passed between controllers and subsystems) would have to be tagged with a unique identifier in order to track the incoming result objects - an unnecessary overhead.

Controllers and subsystems communicate by exchanging "business objects", i.e. entities that are central to the workflow in the electronic commerce portal. The following business objects are therefore known to all controllers and subsystems:

• User
• Contact
• Appointment
• Task
• Message
• Shop Item
• Order
• Order History
• Search Request
• Search Result

To schedule an appointment, for example, the workflow controller creates an appointment object from the data received by the dispatcher and passes it to a method of the office subsystem that adds the appointment to the user's calendar. If the user chooses to be reminded of the appointment by e-mail in time, the workflow controller additionally creates a message object, connects a copy of the appointment object to it and passes it to the communications system which will queue it for e-mail delivery at the time requested by the user.

1. The management of addresses is realized by a traditional host system like IBM MVS (for remote data) and additionally by a local office system like Lotus Organizer or Microsoft Outlook (for local data). Access to the remote data is provided by the electronic commerce portal via an XML interface. The synchronization of remote and local data is also guaranteed by the electronic commerce portal. (back)
    
2. This is true for a user interface built from plain HTML pages. Of course, one might conceive a client-side Java applet displaying information pushed to it by the server. However, this would require a Java-capable user agent, ruling out most of the currently available mobile agents like WAP phones, organizers etc. Plain HTML, on the other hand, makes the least assumptions about the target platform, and the subsystems producing it can easily be adapted to generate similar formats like Wireless Markup Language (WML). (back)

< Introduction | Realization >