Application of middleware in the three tier client/server database design methodology

Fong, Joseph; Hui, Riemann

doi:10.1590/S0104-65001999000200005

Acessibilidade / Reportar erro

Brasil

Journal of the Brazilian Computer Society

Español English

Brasil

Español English

sumário « anterior atual seguinte »

Sumário

• J. Braz. Comp. Soc. 6 (1) • July 1999 • https://doi.org/10.1590/S0104-65001999000200005 copy

Application of middleware in the three tier client/server database design methodology

Authorship SCIMAGO INSTITUTIONS RANKINGS

With the popularity of personal computers and powerful workstations, today’s users are no longer satisfied with the traditional data processing. They demand eagerly to putting up graphics on existing applications, putting a lot of pressure in system re-engineering. The Client/Server architecture is a less risky and less costly approach in adding a Graphical User Interface for users. The developer has to determine data and program logic distribution among client, middleware server, and the top-tier server. Middleware is a kind of software that links programs running on different platforms, transmitting messages and data. It plays an important role in 3-tier architecture. There are two types of middlewares: the first connects client programs to server programs, and the second provides data access connections to heterogeneous data sources. The developer also needs to separate on-line transaction processing, project-oriented data processing, and history data from each other. In view of no existing standard method in developing a middleware server, this paper outlines a methodology to design a 3-tier Client/Server database system. It identifies the role of middleware as temporary storage for better performance and as database gateway for Database Management Systems connectivity. Case studies are used to illustrate the steps.

3-tier client/server system; heterogeneous databases; middleware; data distribution; logic distribution; on-line transaction processing project-oriented data processing; history data

Sociedade Brasileira de Computação Sociedade Brasileira de Computação - UFRGS, Av. Bento Gonçalves 9500, B. Agronomia, Caixa Postal 15064, 91501-970 Porto Alegre, RS - Brazil, Tel. / Fax: (55 51) 316.6835 - Campinas - SP - Brazil
E-mail: jbcs@icmc.sc.usp.br

Acompanhe os números deste periódico no seu leitor de RSS

Processing technique	Description
Data Passing	A communication link is established between the client and the top tier server. Data is passing through from one process to the other along three tiers, either through real-time connection oriented communication path, or through file transfer. Each tier has a process which continually monitors the incoming data, and trigger subsequent database update if deemed necessary.
Remote Execution	Database update at a tier and will invoke a program at other tier to update remote database. Sometimes parameters are required for the execution of the remote programs.
Interactive Execution	A connection oriented communication link is established between the client and the top tier. The program which updates the database in a tier will update databases in other tiers simultaneously. Databases being involved must support the same set of Data Manipulation Language. They need sophisticated transaction management such as two-phase commit [5] to ensure database integrity and consistency.

Processing technique	Kinds of data being processed
On-line Transaction Processing	Reflects the current value of data which affects the business operation of the company and may use all three techniques in table 2 to maintain data consistency among all tiers.
Project-oriented data	Handles data which require instant value during the execution of a project, and is only interesting for a particular group of people inside the company. It requires the use of Data Passing-file transfer technique at project initialization, subsequently use either of the three techniques in table 2 to maintain up-to-date data information in all tiers.
History related data processing	Used to provide statistics data so as to support management decisions. It can use Data Passing-file transfer technique to update data at specific period.

Data allocation	Description
Centralized data	All data access are referring to central server(s) at the top-tier, the middleware server(s) serves as a communication server(s), with limited application logic. The client performs the function of formatting data into desired user interface. The advantage of this approach can provide excellent data integrity. However, it requires justification against a 2-tier C/S approach which is less complicated, and less costly.
Distributed data among servers	Data are distributed among the top-tier servers and the middleware servers. The client performs the functions of formatting data into desired user interface. The database at the mid-way server could be different from the top-tier, allowing the accommodation of different database platforms. The aim of this approach is to reduce database access-time and to provide flexibility in large volume data environment. It can also match with business organization structure, where autonomous data by individual business unit is required, with the top-tier database providing referential data, and maintaining data history. In order to maintain data integrity, remote execution or interactive execution techniques are used between the middleware server and the top-tier servers, and is transparent to clients.
Distributed data among servers and clients	Data are distributed among clients and servers. The databases at each platform can be different to satisfy specific requirement. This is best for autonomous business units data resident at the middleware server, with the top-tier server provides reference and any up-to-date information. The client workstations contains static data. The middleware server keeps update data for all client workstations, allowing them to process inter-related information. Another usage is for project-oriented task where data is initially extracted from the top-tier server into the "project server" in the middle-tier. Subsequent update at the top tier will invoke remote execution at (or passing data to) the middleware server, which contains static data, or data required for pair-wise client process (i.e. a user needs at least 2 workstations to process information). The client-stations maintain instance of data and perform GUI activities. Inter-client related data are passed to the middleware server. Data is passing to top-tier by request, or at the completion of a project using data passing technique.
Virtual database in heterogeneous environment	Its 3-tier architecture provides the ability to create a "virtual database" that ties together multiple different databases. The benefits of this functions is a virtual database that contains data from geographically distributed databases can be created. Since the virtual database effectively hides the differences in accessing data in multiple databases, it enables users and application programmers to perceive heterogeneous data source as a single homogeneous data source. Users and applications dont have to track the details and locations of different databases. Instead, they only access their virtual database, which tracks all of this information for them.

Tier	Data
Top-tier Server	Relation Yardmap ( yd_blk#) Relation Yardloc ( yd_blk#, container#, yd_stack, yd_row #, yd_tier#) Relation Bayplan (company_code, vessel_code, voyage#, bay#) Relation Bayloc ( bay#, container#, row#, tier#) Relation Container (company_code, vessel_code, voyage#, bay#, container#, size , yd_blk#, yd_stack, yd_tier#, weight, IMCO)
Middleware Server	Vessel_list (company_code, vessel_code, vessel_name) Vessel_structure (company_code, vessel_code, bay#, ondeck_underdeck, position) Vessel_bay_plan ¹1 Move from top-tier server2 intermediate storage from top-tier server to be download to client, or the completion of ship planning for selected vessel (company_code, vessel_code, bay#, row#, tier#) temporary Active_vessel_containers ²1 Move from top-tier server2 intermediate storage from top-tier server to be download to client, or the completion of ship planning for selected vessel (vessel_code, voyage#, container#, size, yd_blk#, yd_stack, yd_row#, yd_tier#, weight, IMCO, bay#,row#,tier#) Active_Vessel_Status (vessel_code, voyage#, status, yard_map_workstation#, bay_plan_workstation#
Client Work-station	either Active_Vessel_Bay_Plan (company_code, vessel_code, voayage#, bay#, row#, tier#, container#, weight, IMCO, bay_operation_sequence) or Active_Yard_Map_List (yd_blk#, yd_stack, yd_row,yd_tier#, container#, vessel_code, voyage#, weight, IMCO, bay_plan_status)

Tier	Logic distribution	Processing technique
Client	-screen input/output facilities such as editing or formatting -maintain low-interaction and quasi-static data -manipulate local data -process application logic -receive result from middle-tier server -format and present results -computation/condition	Application Program Interface should include proper communication software to talk to the mid-way server. Derived data should be processed close to client for user interface.
Middleware	(to client): -accept request from client - process database request - database integrity checking - maintain database overhead data - maintain fragments of business and database processing logic - concurrent access control - perform recovery - optimize query process - back-end DBMS processing - format/transmit data to client - format/transmit data to top-tier server. (to top-tier server): - receive data from top-tier server - process database update request - database integrity checking	For data which requires current update at the top-tier server, use data passing, or remote execution, or interactive execution technique to transmit update request to top-tier server. For project base data: - request initial download data from top-tier server - receive data from top-tier server using file transfer - set up project information for client process - at end of the project, transmit the whole project data to top-tier server using file transfer technique - freeze project data - purge project data at desirable period. Local autonomous non-derivable data should be processed close to the middleware server for performance reason. Triggers in procedures are executed automatically when certain event happens, e.g. database integrity check. Contains program routines for clients call up. Where possible, two phase commit [14] should be part of integrity enforcement command to ensure database synchronization.
Top-tier Server	- accept request from middleware server - process database request - database integrity checking - maintain database overhead data - maintain majority of the business processing logic - concurrent access control - perform recovery - optimize query process - back-end DBMS processing - format/transmit data to middleware server	For data which requires immediate notification to middleware server, use data passing, or remote execution, or interactive execution technique to transmit update request to middleware server. For project base data: - upon receiving data download request, transmit data to middleware server using file transfer technique. - maintain project status - upon end of project notification , receive project data from middleware server - set project status to finish. Global non-derivable data should be processed at the top-tier server. Triggers in procedures are executed automatically when certain event happens, e.g. database integrity check. Where possible, two phase commit should be part of integrity enforcement command to ensure database synchronization.

Logic	Description
Client	- perform all input/output for ship planning activities. - initiate vessel data request - complete vessel data report - update changes of container info as sent by middleware server - create/update static vessel structure, and bay plan; pass data to update middleware server - submit backup request to middleware server - the GUI front end processing screen at each client station is shown in Figure 5 and Figure 6(note that every user requires 2 workstations to perform ship stowage planning duty)
Middleware	- receive vessel structure/bay plan data from client station, update database - submit request of initial ship stowage planning data download to top-tier server - receive initial download - identify client responsibility code(yard map or bay plan) - transmit static bay plan, and initial dowload containers to client workstations - receive changes of selected vessel container information from top-tier - transmit update container information to relevant client workstation - receive completed active bay plan from client workstation - validate active bay plans by calculating vessel stability - transmit active bay plan to top-tier server - receive deletion status of completed vessel operation from top-tier server - perform housekeeping routine (delete stowage planning data related to selected vessel) - backup client data on request
Top tier Server	- receive initial ship stowage planning data download request - transmit selected vessel containers to middleware server - set voyage_schedule project status to active - check changes made to active vessel containers, transmit them to middleware server - receive active bay plan from middleware server - set vessel status to planned - transmit deletion flag of completed vessel operation to middleware server - execute other system functions (unchanged)

Program	Storage
OLTP programs	Should be sharable across 3-tier C/S by duplicate stored the programs at the top-tier server and the middleware server.
Project-oriented programs	Should be mainly stored in the middleware server for clients workstations sharable access.
History related programs	Should be stored at the top-tier server, with the graphical user interface programs reside in the client workstations