Design and Performance of a CORBA-Based Mediator

Linking Distributed and Heterogeneous School Databases

) Proc. of The International Conference on Internet Computing (IC 2001), CSREA Press, pp.814-820, Las Vegas, Jun. 2001.

Taeyoung Kim, Sangwook Chung and Hyunjong Choi

Dept. of Computer Education

Korea National University of Education

Chungbuk, Korea, 363-791

{tykim, ccomo, blueland}@cc.knue.ac.kr

Objective

□A part of DW project for KEDI (Korea Educational Development Institute)

□'Feasibility study'

① Investigating practical and currently available technologies for distributed processing

② Building an actual prototype of a data integrator

③ Measuring its performance by experiments

□Data Warehouse: OLAP (On-Line Analytical Processing)

Introduction

□ESISS (Educational Statistics Information Service System)

- On-line service provider for educational information (http://std.kedi.re.kr)

e.g., students, teachers, school facilities, financial status, etc.

- Developed and serviced by KEDI since 1996

- South Korea (http://www.knto.or.kr)

- The basic data on each school begin to be collected on Apr. 1st

by LBOs (Local Branch Offices).

- Each PEGO (Provincial Education Governmental Offices) collects and processes data from the LBOs in its region and sends them to the ESISS center in KEDI.

∀ 16 PEGOs for 9 provinces and 7 metropolitan cities.

- KEDI provides both Web-based services and publications for the public, researchers in institutes and policy makers in the Ministry of Education (MOE).

□SIMS (School Information Management System)

- Stand-alone Information Processing System for schools

- Developed by the MOE and installed in over 10,300 elementary/middle/high schools since 1997

- Stores valuable data related to students, teachers, facilities and financial status, etc.

□Observations

- ESISS and SIMS have been developed 'separatedly'.

∀ They are not connected yet.

- Data in SIMS can be used by ESISS.

∀ SIMSs can be utilized as 'data sources' for ESISS.

∀ Thus, two systems should be integrated.

- By integration, we can

① Automatically collect educational data 'on-line'.

② Provide 'real-time' information service.

③ Make school personnel 'avoid redundant' data collection/input work for both systems.

- The features of SIMS

① Distributed: They are distributed all over the country.

② Heterogeneous: A variety of platforms, i.e., different hardware, operating systems and DBMSs are used.

③ Autonomous: School data is inserted, deleted and updated individually by each school unit.

∀ How do we integrate them?

∀ Build a 'mediator' that extracts/collects necessary data from SIMSs

- Approximately 50 schools under an LBO on average

Background

□Mediator

- Takes a global query from the user and transforms it into local queries.

∀ After each local query is finished, it integrates all the results into a global answer that is delivered to the user.

□Three-Tier Client/Server Architecture

- In the middle of the database server and the user interface client

∀ The separate 'application logic' component has connection between presentation and data management.

- Manage the problems caused by direct m×n connections between clients and servers in two-tier C/S architecture.

∀ Middleware

- Two-tier C/S system: Direct m×n connections between clients and servers

□Application: Data Mgmt. + Appl. Logic + Presentation

- Middleware

□Applications for the three-tier C/S architecture are built on middleware.

□Deals with problems caused by multiple servers and a large no. of clients

∀ Supports network transparency, load balancing and system flexibility

□Three types of Middleware

① Database Access

- Provides uniform access to heterogeneous DBMSs.

- ODBC(MS), IDAPI(Borland), CLI(SAG), Glue(Oracle)

② OLTP

- Provides an application server with distributed transaction processing

- X/Open, Tuxedo, Encina

③ Distributed Object

- Provides access to remote objects.

- DCE(OSF), JavaBeans(Sun), CORBA(OMG), DCOM(MS)

□CORBA (Common Object Request Broker Architecture)

- Distributed object middleware specification

- CORBA 1.1 was established in 1991 by the OMG (Object Management Group).	∀ Commercial products have been introduced in the market since then.

- CORBA 2.3 was announced in Dec. 1998.

∀ CORBA 2.5 is currently available.

∀ CORBA 3.0 is presently in progress.

- CORBAservices (http://www.omg.org)

- CORBA Architecture

- ORB (Object Request Broker)

□Provides comm. between the server and client objects

∀ An object on the client can execute the methods of another object on the server.

∀ Not necessary for the client to know detail information on the server object.

∀ Needs only to know 'interface' information with the server objects.

- Server objects are registered on the Object Adapter.

∀ Manages communication with the ORB for many objects.

∀ Object location management

- Method Invocation

① Static Method Invocation: Hard-code the name of the server and the name of the object that it wants to contact at 'compile' time.

② Dynamic Interface Invocation: Use DII to discover which objects have the required interface at 'run/execution' time.

- Comm. through standard protocols such as General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP) that is especially designed for the ORB comm. on the TCP/IP network.

- ORB Products

□JavaIDL (Sun)	: http://java.sun.com/products/jdk/idl/

□JacORB (Gerald Brose): http://www.jacorb.org/

□Orbix (IONA)	: http://www.iona.com/

□ORBacus (IONA)	: http://www.ooc.com/ob/

□OmniORB2 (AT&T Lab. Cambridge): http://www.uk.research.att.com/omniORB/

□Visibroker (Inprise)	: http://www.inprise.com/

□e*ORB (Vertel)	: http://www.vertel.com/

- CORBA Programming

□IDL (Interface Definition Language): Describe the "interface" that a remote object has.

□DB Connectivity by using Java

- Four types of JDBC drivers

(http://java.sun.com/products/jdbc/driverdesc.html)

Type	Name	JDBC-API- Translated-into	DB Access- through	Codes-used	Provide-by
1	JDBC-ODBC bridge	ODBC API	Client-side ODBC driver	Depends on the ODBC driver	Sun etc.
2	Native-API Partly Java	DBMS dependent client-side API	Client-side DB driver	Partly Java	DBMS vendor
3	Net-Protocol Fully Java	DBMS independent protocol	Translated into the server-side protocol	Fully Java	Middleware vendor
4	Native-Protocol Fully Java	DBMS dependent protocol	Direct connection to the server	Fully Java	DBMS vendor

- JDBC drivers

Type 1	Type 2

Type 3	Type 4

□ Case Studies

① WIDD

- J. Kim et. al., □A CORBA-Based Multi-Database System on the Web□, The Journal of KISS, 1997

- POSTECH

- MDB Server

② VHDBS (Verteilte Heterogene Datenbanksysteme)

- Xuequn Wu, "A CORBA-Based Architecture for Integrating Distributed and Heterogeneous Databases", Proceedings of the 5th IEEE International Conf. on Engineering of Complex Computer Systems, 1999. 10

- Deutsche Telekom

- Federated Server

③ SBD (Simulation Based Design) program

- Padmanabh Dabke, "Enterprise Integration via CORBA-Based Information Agents", IEEE Internet Computing, V.3(5), 1999. 9.

- Sponsored by DARPA and partnering defense organizations

- Core Processing System

④ Proceedings of the 1st ∼ 5th IEEE International Enterprise Distributed Object Computing Conference (EDOC)

⑤ etc.

Design and Implementation

□Design

- Prototype of a mediator for collecting/extracting school data

- Composed of clients, a mediator server and wrappers.

- The client requests a global query that is conveyed to the mediator server.

- The mediator server responds back by integrating individual local results.

∀ The GQP (Global Query Processor) divides a global query into local SQL queries.

∀ The TC (Transaction Controller) executes the local queries by invoking related LDA (Local Database Adapter) objects.

∀ The GQP combines local query results and responds back to the client with an integrated result.

- The wrapper is composed of an LDA object that executes the local query on the individual DBMS through JDBC.

□Implementation

- Programmed as the distributed objects of CORBA by using Java 1.3.

- Communicate with one another through JavaIDL 1.3

- Mediator

- Client

Performance

□Environment for Experiments

- Measure the response time of global queries

- Parameters

□The no. of clients

□The no. of LDAs

- Each LDA has 40 tuples per table (82 bytes per tuple).

- H/W and S/W used

	OS	Hardware	JDBC	JDBC's Vendor
MS Access	Windows2000 Server	PentiumⅢ (600MHz/256MB)	JDBC-ODBC	Sun
MS SQL Server 7.0	Windows2000 Server	PentiumⅢ (600MHz/256MB)	JDBC(Type 4)	tiptips.net
Oracle 8.16	Redhat Linux 6.1	PentiumⅢ (733MHz/256MB)	JDBC(Type 4)	Oracle

□Performance Results

① Case I: The performance of MS Access as local sources and Type 1 JDBC driver.

② Case II: The performance of MS SQL Server 7.0 as local sources and Type 4 JDBC driver.

③ Case III: The performance of Oracle 8 as local sources and Type 4 JDBC driver.

□Conclusions

-  Mainly dependent on the number of local information sources.

- A local legacy source is influenced by the increasing number of simultaneously connecting clients.

∀ It hardly affects the response time in the case of local DBMS sources.

- It is possible for LBOs to integrate the school systems in its region.

∀ But, depends on the bandwidth and reliability of the network.

- How about PEGOs?

∀ Less locations (LBOs), but more data should be collected.

- How about KEDI?

∀ 16 PEGOs, but much more data

Future Works

□Prototypes by using other options

- ORB: Multi-threaded ORBs

- Distributed Object: JavaRMI/JavaBeans

- Wrapper: Other JDBC drivers

∀ How much speedup?

□Real world experiments

∀ Build/Test a practical mediator for LBOs, PEGOs and KEDI

Thank you...