FIESTA

FIESTA – A Distributed Entertainment System from Salsa Inc.

Distributed object technology coupled with powerful communications infrastructure enables the development of distributed applications that can interoperate across disparate networks and operating systems. Salsa Inc. with its FIESTA product is proposing to develop such a distributed service that entertainment service providers like restaurants, theatres, sporting events can register with and customers using a familiar web interface can reserve and purchase the offered entertainment services.

Since 1989, the Object Management Group (OMG), a consortium of platform vendors, ISVs and end users have been specifying the architecture for an open software bus on which objects written by different vendors can interoperate across networks and operating systems. The OMG group has specified the Common Object Request Broker Architecture (CORBA) that describes a software bus called an Object Request Broker (ORB), that provides the infrastructure for distributed object computing. The CORBA specification also includes a protocol for ORB interoperability called the Internet Inter-ORB Protocol (IIOP). IIOP is robust, scalable and transaction oriented, and runs on top of TCP/IP, the dominant protocol used by the Internet. FIESTA uses the CORBA and IIOP technologies. CORBA provides a number of benefits. It is an open solution based on a published specification. It is implemented and supported on a wide variety of hardware and operating system platforms. A COBRA software object has a defined interface. All communications go through that interface. The object can change without affecting other objects as long as the object’s interface remains the same. The CORBA objects communicate using IIOP an are fully interoperable even if different vendors develop them.

System Architecture

   Fig. #1: FIESTA System Architecture

Figure #1 is the architecture for FIESTA. FIESTA consists of the following modules: the Front-End Client and the Web Server, the Gatekeeper, FIESTA Servers, Administrator Module, the Back-End Consistency Server and the Service Client (Service Provider Adapters and Databases). The remaining of the proposal describes each module in brief.

Front-End Client – Web Server

A Front-End Client is any user that accesses the FIESTA Web Server in order to engage in a permissible transaction such as making restaurant reservations, viewing restaurant/theatre information (menu, type of cuisine, location) and purchasing theatre tickets. The back-end modules (FIESTA Servers and Service Client Databases) handle the details of the transaction. As shown in Fig. #2, the information flow between the front-end modules (Client and the Web Server) is as follows:

• The user from an ORB-enabled browser (Netscape Communicator) requests the main Entertainment page (http://cerf.ini.cmu.edu/index.html) from a local Web Server (Netscape Enterprise).
• The Web Server uses HTTP to deliver a Web page with an embedded Java applet.
• The applet is loaded into the user’s machine; client can then request the services of remotely located objects (Restaurant_Menu, Restaurant_Type, Theater_Name, etc..) by filling in the necessary fields in the applet.
• The user submits the information, which is handled by the client side ORB (Netscape Internet Service Broker).
• The client ORB, using the Internet Inter-ORB Protocol (IIOP), passes the information to the GateKeeper Module, which is in charge of maintaining the load balanced between a set of CORBA-compliant servers (FIESTA Server).
• Once the requested service/object is available to the client, the information is passed from a FIESTA Server directly to the client ORB.
• The client ORB then unmarshalls the data and passes it to the original Java applet that requested the information. The results are then displayed on the client’s Web browser.

 Fig. #2: Front-End Client – Web Server

Gatekeeper

As described in the previous paragraph the gatekeeper primarily performs the load balancing function. For the first version of FIESTA, the gatekeeper will perform a very simple load balancing function that will distribute the front-end client requests to the FIESTA servers in a round-robin manner.

FIESTA Servers

Each instance of FIESTA server is associated with an individual client. The process is done at the FIESTA Server in the following order:

• The FIESTA Server receives a request from a client through the Gatekeeper.
• FIESTA server sends the queries to the Administrator (Fig. #1) to determine whether there is any Service Provider that can fulfill the client’s request. If there is none, a message is sent back to inform the client. The client can then either give other service parameters, which will be used in a new query by the FIESTA server, or terminate the session. If multiple Service Providers can fulfill the client’s need, the client is informed. The client can then make a selection and inform the FIESTA server.
• After the client selects the service provider to use the FIESTA Server forwards the request with the specified service provider name to the Back-End Consistency Server.

Administrator

The Administrator consists of several modules: the Naming Server, the Service Catalog, and the System Monitor. The function of each module is described as below:

• The Naming Server: a name resolver for mapping between logical names to object implementations. Most of the FIESTA modules’ ORBs will need to contact the Naming Server before executing remote methods or communicating with each other.
• The Service Catalog: a database that contains listing of service providers registered with FIESTA. The listings also include some characteristics of the service providers; enabling search for service providers based on client’s preference.
• The System Monitor: a module that monitors the status of the other modules in the Administrator part of FIESTA. Since the other modules need to be highly available, they are replicated using a primary-backup approach. When the System Monitor detects a failure in the primary modules(s), it will attempt to restart the failing module(s) to restore the high-availability status of the system.
• Service Registration GUI: an applet served by the web server to enable service provider to register their service offerings through FIESTA. The registration information will be saved in Service Catalog.

Back-End Consistency Server

The Back-End Consistency Server receives client’s request from the FIESTA servers, and check for consistency to ensure no conflict among multiple client requests. This is necessary especially in the case of high-demand services that require transactions to be done in first-come-first-serve basis. The Back-End Consistency Server ensures the fairness in serving the requests, while also guarantees that there is no duplicate or other incorrectness. It then passes the requests to the appropriate Service Provider Adapter.

Service Client

The Service Provider Adapter is the front-end of the Service Client. The adapter serves as an interface between the FIESTA system and the local service provider database. It uses ODBC approach to connect with local database so that FIESTA system will be able to serve various types of database (E.g. MSSQL, Oracle, etc.).

Example

The following diagram (Fig. #3) describes the information flow of a simple transaction using the FIESTA architecture:

Fig. #3: Simple transaction using FIESTA

Send comments or suggestions to jmroman@andrew.cmu.edu
All original artwork was created using Adobe Photoshop
Copyright 1998. SALSA Inc.

Site last updated 2/16/98 3:00 AM