object naming, security, event / message propagation, as well as the use ... List dept. Products. Contains. Product ID. Product Name. Quantity in Stock. Reorder ...
Design of a Virtual Store using Distributed Object Technology Desmond Chambers I.T. Centre, N.U.I., Galway. Abstract This paper describes aspects of a current PhD research project in the area of distributed object technology. The main focus of the project is the use of this technology within the domains of Groupware and Multimedia applications. Groupware applications typically involve co-operation between several users and are often expressed in terms of operations on shared (and possibly distributed) objects e.g. shared document editors, virtual reality environments or indeed shared network based services. Multimedia applications involve the use and transport of special forms of program data e.g. images, sound and audio / video streams. The main hypothesis of this project is that distributed object technology can be used effectively within these application domains, but that further research is required to determine the best way to use and deploy the available technology standards. CORBA (Common Object Request Broker Architecture) has emerged as the de-facto industry standard for how remote objects can communicate and be deployed in a heterogeneous, distributed environment. Competing standards include Java RMI (Remote Method Invocation) and DCOM (Distributed Component Object Model) from Microsoft.
1. Introduction Groupware has been defined [1] as software designed to allow groups of people to use computers to work closely to achieve a common task. Groupware encompasses application classes such as shared document editors, multi-user virtual reality environments, teleconferencing systems, hypertext document management systems, as well as collaborative design tools. Real-time Groupware Applications [2] share many of the same requirements and characteristics as Multimedia applications in so far as they are both usually highly interactive, they often require real-time notification of
events (possibly generated by other participants) and they may operate in a shared environment e.g. a multi-user virtual reality application. They also have special Quality of Service requirements if they are based in an environment of interacting distributed objects.
1.1 CORBA interfaces CORBA specifies a system which provides interoperability between objects in a heterogeneous, distributed environment and in a way transparent to the programmer. It’s design is based on the Object Management Group (OMG) Object Model [3]. This Model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation independent way. In this model clients request services from objects (which are implemented as servers) through a well-defined interface. CORBA is now the de-facto industry standard for how objects communicate with one another across a network. This is formed around a client / server pairing, in which each object provides services to another. (These are only roles for an object within a system, and a given object may be either a client, a server, or both at any given instant.) The CORBA standard allows object services to be accessed by name rather than location - this feature can be used to allow an application to locate available or unloaded servers in preference to specific machines running specific servers [4]. The server object interface is specified in OMG IDL (Interface Definition Language). A client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters (if any). The object reference is an object name that defines an object reliably. The Object Request Broker (ORB), is at the heart of the CORBA standard. It defines the services that are available to the outside world. Every service must create at least one ORB, although there is nothing to stop more
OMG also specifies a set of Object Services. These are a collection of services (interfaces and objects) [5] that support basic functions for using and implementing objects. Services are necessary to construct any distributed application and are always independent of application domains. They are specified by the OMG as domain-independent interfaces that may be used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain [6]. There are Object Service specifications for locating objects, lifecycle management, security, transactions, and event notification, as well as many others.
• Design of components of an object-based platform to support the construction of multimedia and groupware applications. Some of these issues are partly addressed within the current OMG Object Services Specification and some are currently being standardised by OMG task forces e.g. the CORBAtel Telecommunications Task Force is in the process of formalising an RFP [7] relating to the management and manipulation of Isochronous Streams within a CORBA environment. These are Streams for audio and video data that have special quality of service requirements due to their isochronous nature. Groupware and Multimedia applications that use the OMG Object Services as the basis for their design have a requirement for efficient implementations of these services. There are not currently many commercial implementations of some of these services and there are no real benchmarks available for how efficient these are or how well they address the problems identified above. Further research is required to identify optimum implementation models, both for the services themselves and how different application classes might use these services effectively.
2. Research hypothesis
2.1 Related research
The main hypothesis of this project is that distributed object technology can be used effectively within the Groupware and Multimedia application domains, but that further research is required to determine the best way to use and deploy the available technology. A lot of work has been done in this area (particularly on issues relating to groupware) by researchers at Queen Mary & Westfield College, London, and they have identified the following areas as still requiring further research: • Concurrency Control - this relates to how multiple application users can concurrently and safely interact in a shared distributed environment. • Persistency - how the client is bound to the server. In some cases remote objects may persist long after the initial interaction and their state may even be stored in a database to be loaded some time in the future when a new request arrives. • Object Security - in terms of access control and levels of privilege. • Consistency of distributed object replicas - important for availability and recovery in the event of failure of an individual server.
There are a lot of University research groups, both in Europe and the U.S. engaged in research into distributed systems and distributed object technology. • In the case of Groupware applications most of the prior research has not focused specifically on using CORBA as the enabling technology, rather the focus has been on the design of general-purpose distributed object systems that have appropriate functionality for the support of groupware (co-operative work) applications. Key requirements that need to be addressed arise from the need for shared access to dynamic information in multi-user interactive applications [8]. • There has also been some research on using CORBA for Multimedia applications and the main focus has been on addressing end-to-end QOS issues and how to adapt CORBA for stream oriented data transfer [9].
than one being created. The ORB is the unit that is brokered to make a given service accessible. ORBIX is one of the leading commercial implementations of the CORBA standard and implements the ORB itself in the form of a set of runtime libraries that are distributed with each application component.
1.2 CORBA services
Orbix and OrbixWeb Technologies.
are
Registered
Trademarks
of
IONA
3. Virtual store concept While the overall research project is still in it’s early stages, a lot of work has already been done on the development of a CORBA based test environment, using the concept of a virtual store accessible over the internet. The virtual store is fully object-oriented, it is designed to accommodate multimedia data streams and it can be accessed concurrently by multiple end-users. The objects within the store are created dynamically and have their state saved periodically in an ODBC database. The store objects include Departments, Products, Users and
Trolleys. Issues addressed by the design include object security, concurrency, persistence of object state and session recovery. The remainder of this paper describes the design of the virtual store. It also includes some descriptions of the technologies and methodologies used. Future project research will involve the development and evaluation of efficient implementations of both CORBA and nonCORBA based object services e.g. services to facilitate object naming, security, event / message propagation, as well as the use of audio / video streams.
4. Technical overview
Figure 1 - Top Level System Design 7KH&XVWRPHU,QWHUIDFHLV
7KH9B6WRUH6HUYHULV
LPSOHPHQWHGDVD-DYDDSSOHW
LPSOHPHQWHGLQ9LVXDO&
UXQQLQJLQDEURZVHU
9B6WRUH &XVWRPHU
&OLHQW
4.1 Top level system design The top level design is detailed in Figure 1. The system is based on distributed objects, resident in the server, accessed via CORBA enabled Java Applets downloaded via a suitable Web browser. These applets are used to implement the main Customer Interface as well as the Remote Management Interface.
6HUYHU
25%
&XVWRPHU ,QWHUIDFH &OLHQW
The aim was to build an electronic / virtual shopping store where shoppers can come and purchase products. This is not in itself a novel idea - the difference in this case is that the store was implemented entirely using distributed object technology. Upon first entering the store potential customers - if not already an existing registered customer - will first have to register as a customer. Once registration is complete they can then proceed to ‘go shopping’ in the store. Each time the shopper enters the store they are given a virtual shopping trolley. The shopper can add and remove products from the trolley at will. Once the shopper has completed their shopping they then proceed to the checkout where they pay for their purchases by credit card. The store is managed by store managers who have the ability to add, delete and update product details and also the ability to add, remove, update departments in the store. Store managers also have the ability to obtain management reports. These reports include a daily store customers report which details the customers who came and shopped in the store that day. A daily details report on the products which were purchased by customers in the store. A daily log report which details the time of entry and exit from the store by customers and also whether they successfully logged out or checkout out OK. The final report which can be produced from the Virtual Store is a daily products report which details which products have fallen below their reorder level and need to be reorder by the store managers. Another ability which store managers have is to add, remove, update users details such as their address or password as needed.
25%
,QWHUIDFH
25%
&OLHQW
'DWDEDVH
&OLHQW6HUYHULQWHUDFWLRQLV
&XVWRPHU ,QWHUIDFH
06$FFHVV
25%
YLD&25%$FRPSOLDQWUHPRWH PHWKRGLQYRFDWLRQ
1HWZRUN ,QWHUQHW
0DQDJHPHQW ,QWHUIDFH &OLHQW
25%
7KH0DQDJHPHQW,QWHUIDFHLVDOVR LPSOHPHQWHGDVD-DYDDSSOHW UXQQLQJLQDEURZVHU
An interesting aspect of this design is that the server and client interfaces were implemented using different programming languages, the server was implemented using C++ while the client interfaces are Java based. CORBA made the integration of these into a unified application relatively easy and, in general, solves the problems associated with heterogeneity and object distribution. Orbix and OrbixWeb were used as the enabling middleware technologies. Orbix is based on C++ and was used to implement the server. OrbixWeb is similar, but produces a CORBA IDL to Java mapping, and was used in the implementation of the client interfaces. The server also used Open Database Connectivity (ODBC) for database access - this ensures that the resulting code is more portable across different database implementations. The full interface design (as specific in the IDL file) is shown (using OMT style notation) in Figure 2.
Figure 2 - Interfaces Defined (Specified in IDL) Store
Trolley Cost of Products List of Products
Has
Name Holds
Enter Store Checkout Exit Store
Contains
Product Product ID Product Name Quantity in Stock Reorder level Description Image Source Sound Source Video Source Add a product Remove a product Update product details
Has Selects
Add a product Remove a product Get trolley Cost Browse Trolley Contents
Uses
User Reg_ID UserName Password Name Address Add a new user Remove a user Update User details Verify registration details Verify UserName and password
Department Name Add dept. Remove dept. List dept Products Manager Manages
Certain privileged functions
Generates Report
Customer
Manager flag Customer related functions
Views
Name Print report
5. Server design details The design of the Virtual Store’s server is explained under the following headings: • Database Schema and Session Recovery • Checkout / Exit Functions • Security Mechanism • Multi-user Capabilities / Concurrency • Server Implementation Class Diagrams
5.1 Database schema and session recovery The database is located on the server and holds the details necessary for the successful operation of the virtual store. There are a total of nine tables in the database: Departments Table - used to hold details as to the departments in the store. Departments Products Table - used to hold details as to the products which are contained in each department. There exists one record in this table for each of the products that are contained in the department. Products Table - used to keep track of details relating to the products which are on offer in the store. Registrations Table - used to hold the details of all the people who are registered to enter the store. These
include customers and also store managers who are in charge of the shop. User History Table - used to hold details such as the time that the shopper entered the store and also the time that they left at. It also has a flag to indicate whether the shopping session of a customer was successfully completed by the shopper, i.e. that they checked out or exited correctly. Shoppers Purchases Table - used to hold details of the purchases made by the shopper in the store and is important for keeping a list of the products that need to be shipped out to the customer. Shipments Table - used to hold the details necessary to send the purchased products to the customer. It is only when the customer actually checks out and supplies their credit card details that their details are recorded in these two tables i.e. shipments table and shoppers purchases table. Trolleys Table - used to implement persistence and a certain amount of fault recovery. Contain details as to the trolleys created for the customers when they came to shop in the store. Trolley Contents Table - used to hold the details of the contents of each trolley. This table holds details as to the products held in the trolley at the time that the trolley record is written to the Trolley Table. There exists one record in this table for each of the products that are contained in the shoppers trolley.
5.2 Session recovery mechanism The User History table is used to hold details of a shoppers visit’s to the store. Once a customer enters the store a record is written to this table with the timestamp of their time of entry, their user ID and the checkout / log out flag set to ‘NO’ (assume failure), the TimeStamp_Exit is set to ‘NULL’. Once a person is in the store and purchases a few goods they go to the checkout and pay for their goods or go to the exit without buying any goods. In each case the user clicks on a checkout or exit button. This activates a search for the last record that relates to this shopper in the User History Table, the time stamp of their departure is then recorded in this table. The checkout / log out successful flag is set to ‘YES’ and the record written back to the User History table. When the user logs back in later they are informed that they have a previous session outstanding and given the opportunity to restore their previous session that was incomplete. This restoration of previous sessions works in conjunction with the fault recovery tables outlined i.e. Trolleys Table and Trolley Contents Table.
5.3 Checkout / exit functions
When the user goes to check out of the store and pay for their goods they proceed to a checkout where they are asked for their credit card details. Once these have being obtained they are submitted to the server. Checkout of a customer from the store requires the contents of the shoppers trolley to be saved in the Shoppers Purchases table as well as a time stamp. The Shipments table contains the user ID of the shopper and also their credit card details as well as the timestamp at which they last checked out. This timestamp is the same as the one in the shoppers purchases table for each of the products that a shopper bought. This idea allows for multiple visits to the store by the customer in the one day and a record to be kept of the individual shopping habits of the shoppers. Once the checkout details of the customer have been saved to the database the User History table record is updated with the timestamp of the time that the session ended and also on successful checkout sets the checkout / log out flag in the User History Record to ‘YES’. If a user chooses to exit the system without checking out, then the goods contained in their trolley are all placed back on the shelves and the trolley details are also deleted after the shopper has been asked to confirm that they wish to exit. The User History table is updated with the time they left the store and the checkout / log out flag set to ‘YES’ which also results in the fault recovery records being deleted for that particular shoppers session.
5.4 Security mechanism Further enhancements which have been made to the overall development is the addition of security features based on the use of object capabilities: 1. Once the user logs in the store object returns an object reference to the remote user object as well as a capability for that particular user. The capability returned depends on whether the user is a manager or a customer. Managers receive a capability that allows them to perform various functions to manage the store. This also allows a greater level of security to be applied to the system. 2. There are currently two categories of user (sub-classed in the IDL file) i.e. customer and manager. When a user object (on the server) is requested to generate a capability it returns a capability as an out parameter when the user logs in or registers as a new customer.
Figure 3 - Server Implementation Class Diagram Store 06$FFH VV ' DWDE DVH
Trolley Cost of Products List of Products
Has
Name Holds
Enter Store Checkout Exit Store
Contains Contains Has
Checkout
Department
Purchases Purchases Cost
Name
Get trolley details
Add a product Remove a product Get trolley Cost Browse Trolley Contents
Product Product ID Product Name Quantity in Stock Reorder level Description Image Source Sound Source Video Source Add a product Remove a product Update product details
Selects
Uses
Reg. Users Reg_ID UserName Password Name Address Add a new user Remove a user Update User details Verify registration details Verify UserName and password
Add dept. Remove dept. List dept Products
5.5 Capability composition The capability is generated using mode bits added to a unique (hard to guess) random number. The random number used is initialised during object creation and is stored with the server state for a particular object. It never changes during the lifetime of an object. This is then encrypted before being made available to a requesting client. This process makes it difficult for a client to mimic increased privileges, as it will need to know the encryption algorithm in order to create a valid capability. Mode = (Read Only || Full Access) Opaque Part = Encrypted (Mode + Random Number)
Mode Bits
Opaque Data
5.6 Multi-user capabilities / concurrency Another area which has been addressed is the multiuser capabilities of the system. The store must allow for multiple shoppers and also multiple managers to be present in the store ant any one time. This raises problems of concurrency and security in relation to the holding of details in the system. A certain amount of multi-threading has to be built into the server side to handle the accessing of the database and also handling the talk option and various other options in the system. From the outset the problem of concurrency was dealt with in relation to the database as a whole. Read / write locks are established on the various tables so as to
elevate the possibility of having two customers accessing the same details together which could cause problems of deadlock if not dealt with correctly. The main server implementation classes are shown in Figure 3 and Figure 4. These represent the server runtime classes created to implement the interfaces defined in the IDL file. The store itself exists as a top level factory object which is used to create and manage departments, products and users as required. Figure 4 - Server Implementation Class Diagram (continued) Reg. Users Reg_ID UserName Password Name Address
Store Name Enter Store Checkout Exit Store
Add a new user Remove a user Update User details Verify registration details Verify UserName and password
Manages
Generates
Manager
Customer
Manager flag Certain privileged functions
physical access to the server. This would allow for maintenance of the registration details held in the registrations table and also details contained in other tables in the database, without the need for a manager.
5.8 Server database optimisations Other server enhancements would be in relation to the database. Running MS-SQL Server 6.5, for example, could greatly improve the database speed and also usability from a programming approach. The ability to create triggers and constraints in the database would improve the ability to keep all the database details in sync: • Database security could be built into the database itself by using the actual mechanisms supplied by the database engine which would allow for ease of creation of groups of users and also the management of same and also possibly a greater deal of security. • The ability to view all details held in the database. More management reports on the server’s operation. These could be presented graphically using such features as bar charts and also possibly pie charts which would enhance the information greatly. • Transactions would need to be built into the code so as to allow even further control of the information held in the database. • Moving the entire server application and placing it on a Windows NT machine (instead of the current Windows95 platform) running Microsoft BackOffice and SQL Server would improve the speed of accessing information in the database.
6. User interface (client) implementation
Views
Report Name Print report
5.7 Future server enhancements A further enhancement that must be added to the server application will allow a system administrator to set-up manager accounts on the system. This would also allow the system administrator to add, delete and update any details contained in the database that is located on the server. For security reasons this application should only be run on the server and the password should be hard coded into the system so that it cannot be changed without
The virtual store is a client / server application. Once the user starts the client application / applet running they are presented with a start up screen which details various aspects of the store and invite them to join. This screen could offer more information to the visitor if they so wish through the use of command buttons that could be linked to multimedia clips. This screen has command buttons on it to allow the user to select the option that they wish. The current options are outlined below: 1. Enter the store and begin shopping. 2. Register as a shopper / customer. 3. Help on registration.
6.1 Store entrance This first option is for users who have already registered with the virtual store and wish to begin shopping. This option displays a form on screen to the user and ask them to enter their user name and password. Once they have entered the details the user clicks on a
button that submits the username and password entered to the server, which then validates the combination. If they are valid then the user is allowed to enter the store, if not they are given a chance to return to the main screen and re-enter the details. What happens next depends on whether the user is a customer or a manager. If the user is a customer then they are presented with the main store interface which allows the user to go shopping in the store. If the user is a manager then the store then the management interface is displayed which allows the manager to manage the store.
5. An exit facility which allows the shopper to exit out of the shop. 6. Current List of Shoppers and Managers. 7. Talk option to interact with other users. 8. Change Preferences Option. 9. Suspend a shopping session. A customer can request to talk to any manager currently available in the store but can not send out a store wide message or an individual message and can not talk to other customers.
6.4 Management interface implementation 6.2 Customer registration This option allows a new shopper to register with the virtual store as a shopper/customer only, as registration of managers is taken care of on the server through the use of the main system administration password. This option (customer registration) displays a form on screen which allows the user to enter details about themselves which are needed for registration. Figure 5 - Main Customer Interface
The main management interface is also implemented as a Java applet and is shown in Figure 6. This interface is the one that management uses to manage the store. It has various options that facilitate the manager in the running of the store. From this interface the manager is able to: 1. Update Product details. 2. Add a new Product. 3. Remove an existing product. 4. Access Reports menu. 5. Update department details. 6. Add a new department. 7. Remove a department and all its products. 8. Update a users details. 9. Remove a user. 10. Change a users password. A manager is able to send a store wide message and an individual message to any user currently logged in to the store. A manager cannot engage in conversation with a customer but can engage in conversation with another manager who is currently in the store by selecting them and clicking on the “Request Talk” option.
6.5 Management reports
6.3 Begin shopping Once the shopper wishes to commence shopping in the store there a trolley is allocated to them. The details that relate to the trolley are recorded in the trolleys table on the server. The main store interface is then displayed (see Figure 5). It has options contained on it to do the following: 1. A browse facility. 2. Add / Select a product. 3. Remove product from the trolley. 4. A checkout facility.
There are a total of four reports currently available on the system for managers to view. Further report options could easily be added based on the current design: • Daily Store Customers report details the customer who have come into the store today. • Daily Sales Details Report details what products have been purchased in the store today. From this report it is possible to see which products are selling well in the store, and it is also possible to calculate the daily total sales in the store from the information contained in this report. • Daily Log Report which details the time of entry and exit from the store by customers and also whether they successfully checked out. • Product Re-Order Report details the products whose stock levels have dropped below their re-order levels.
Figure 6 - Store Management Interface [6] CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments, S. Vinoski, IEEE Communications Magazine, Vol. 14, No. 2, February 1997. [7] Control and Management of A/V Streams Request For Proposals, OMG Document telecom/96-08-01, August 1996. [8] Replicated Secure Shared Objects for Groupware Applications, A. Rowley, J. Dollimore, Technical Report 716, Dept. of Computer Science, QMW College, London, March 1995. [9] Architectural Support for Quality of Service for CORBA Objects, J. Zinky, D. Bakken, R. Schantz, Theory and Practice of Object systems, Vol. 3 No. 1, January 1997.
7. Conclusion The project work to date has demonstrated that distributed object technology provides a robust and convenient framework for implementing and deploying internet based client / server applications. The virtual store will be used mainly as a test bed application to develop and evaluate efficient implementations of a number of object services. It will also be used to evaluate “quality of service” and implementation issues associated with using multimedia data streams. Current project work is focused on providing optimised and value added implementations of a number of these object services. A Java based implementation of the Corba Event Service, with additional support for multicasting and multimedia message types, has already been implemented and is currently being tested. Future research will involve the integration and benchmarking of these services with a number of test applications, including the internet based Virtual Store described.
8. References [1] Object Groups for Groupware Applications: Application Requirements and Design Issues, R. Achmatowicz, T. Kindberg, Proceedings of European Research Seminar on Advances in Distributed Systems, pp. 269-274, September 1994. [2] Groupware: Some Issues and Experiences, C.A. Ellis, S.J. Gibbs, G.L. Rein, Communications of the ACM, January 1991. [3] CORBA 2.0 Standard, The Object Management Group, 1995. [4] Experiences with Distributed Objects, A. Carlson, W. Brook, C. Haynes, AT&T Technical Journal, March / April 1996. [5] Common Object Services Specification, The Object Management Group, 1995.
