A Computing Model of Product Lines for Distributed Processing Systems, its Product Sets, and its Applications Yoshitomi Morisawa Nihon Unisys, Ltd., Tokyo, Japan : Graduate School of Information Science, Nara Institute of Science and Technology, Nara, Japan
[email protected] Key words:
Client/server model, distributed computing model, distributed systems, open solution framework, product line, software architecture
Abstract:
When implementing an application system in a distributed computing environment, several architectural questions arise, such as how and where computing resources are distributed, and how the communication among computing resources should be implemented. To simplify the process of making these choices, we have developed a distributed computing model. The model classifies product lines for distributed processing systems into seven categories based on the location of data storage and the style of processing between client and server. This paper describes our model and its uses in selecting a product set in a kernel reference model of the Open Solution Framework and in planning the infrastructure of a new system for one of our customers.
1.
INTRODUCTION
Currently, there are many software products for implementing Client/Server (C/S) systems available commercially. When a user implements an application utilizing these products, it is common to spend a large amount of time and effort testing the interconnectivity and interoperability, known as conformance testing, among the products to be used. At Nihon Unisys, Ltd.(NUL), we have developed a body of expertise and experience in conformance testing by submitting proposals to customers, providing consultation in information technology, and supporting the 1
2
Yoshitomi Morisawa
implementation of our customers’ applications. In order to share this expertise and experience, as well as reduce the cost of developing new customer applications, we needed to create a framework which includes: a software architecture for implementing C/S systems; an intuitive and simple model of product lines for distributed processing, including C/S processing; and combinations of products based on this model. NUL named this framework the Open Solution Framework (OSFW) and the distributed processing model the Client/Server Solution (C/SS) model, and announced it in January 1996 (Morisawa, et al. 1996a, 1996b). When implementing an application system in a distributed computing environment, several architectural questions arise such as, how and where computing resources are distributed, and how the communication among computing resources should be implemented. A distributed computing model represents a typical configuration of computing resources and intercommunication among them. It is useful in answering these questions and in supporting the implementation of application systems. A distributed computing system can be viewed as a multi-tiered environment from the perspective of hardware platforms and as cooperative client/server processing from the viewpoint of functional distribution (Berson 1992). An example of the former is the traditional three-tiered platform model that consists of mainframe hosts, servers, and workstations. The three-tiered model has traditionally been used by mainframe vendors to position their mainframes in an information system. Other vendors have used this view to position enterprise level servers and divisional level servers. The cooperative client/server view shows the distribution of presentation functions, application logic and data between client and server. This is the view discussed in this paper. The main motivation for introducing the C/SS model was to provide a classification of the processing style of C/S systems, to provide proven software tools, called product sets, for implementing C/S systems in each style, to reduce the total system integration cost, and to construct stable systems with lower cost in a shorter time. To achieve the above goals, we developed the OSFW as a framework of C/S system architecture and are using the C/SS model as its kernel reference model of product lines. Product sets are periodically revised to reflect latest technology and used with this model for configuring our customers’ services. This paper introduces our framework including the models, architecture and product sets. It also shows its use as a reference model for designing the infrastructure of a new financial system for a Japanese company under our Information Technology Infrastructure Planning (ITIP) methodology (Morisawa et al. 1998).
A Computing Model of Product Lines
2.
3
RELATED WORKS
Alex Berson classified cooperative processing systems into five styles: Distributed Presentation, Remote Presentation, Distributed Business Logic, Remote Data Management and Distributed Data Management (Berson 1992). The Gartner group has also defined five styles of C/S computing which are very similar to Berson’s model and are using the model in their research reports and conference presentations for aiding in the discussion of C/S applications (Cassell 1994). This model is based on the distribution points of presentation functions, application logic functions, and data management functions. However, this model does not account for asynchronous processing, making it difficult to model groupware applications and e-mail type applications. This is shown in Figure 1. Distributed Presentation
Remote Presentation
Distributed Logic
Remote Data Management
Distributed Database
Data Management
Data Management
Data Management
Data Management
Data Management
Application Logic
Application Logic
Application Logic
Presentation
Server
Client Presentation
Presentation
Netw
ork
Data Management
Application Logic
Application Logic
Application Logic
Presentation
Presentation
Presentation
Figure 1: Distributed computing model
IBM Corporation classified C/S systems into six templates in their guidance for C/S systems. They are: Front-ending, Resource Centric, HostDistributed Logic, LAN-Distributed, Data Staging, and Multi-Application. These templates are used as a reference model in C/S engineering (IBM 1994). The templates were the result of the survey of approximately 50 realworld solutions designed or implemented by IBM’s typical customers till the early 1990s (Shedletsky et al. 1993). However, the criteria for applying these templates are not clear to users and the templates do not guarantee coverage of all types of C/S systems. Our C/SS model was developed to overcome the weakness in these two models by adding asynchronous processing introducing viewpoints to make the model more understandable.
4
3.
Yoshitomi Morisawa
CLIENT/SERVER SOLUTION MODEL
When developing a C/S system, it is necessary to decide the location of data storage based on its administration, its security, and its computer facilities. It is also necessary to decide the processing style between original data in a client and its data storage in server(s). These decisions are required relatively early in the design phase of practical system implementation. Therefore, we classified C/S systems into seven basic models from the viewpoints of the location of data storage and the processing style between client and server. Location is classified as centralized or distributed. Distributed data is further classified as vertical (e.g. divisional and enterprise data) and horizontal (e.g. data from different divisions). This view is easy to understand and adopt by field system engineers implementing practical systems. The processing style is classified as synchronous or asynchronous. Synchronous processing is divided into two categories, Transaction and Request/Reply, depending on the characteristics of the messaging between the client and the server. This classification scheme led us to develop seven models of distributed processing systems which are illustrated in Table 1. The design goal of this model is that it provides an intuitive, easy and simple model for usual field system engineers. Collectively, these seven models are known as the C/SS model. Table 1: C/SS model (TP = transaction processing, DP = data processing) Data Style Centralized Distributed Processing Style horizontal Transaction Processing Centralized TP model Distributed TP model Request/Reply Processing Remote DP model Distributed DP model Delayed Processing Centralized messaging Chained messaging model model
Distributed vertical same same Data staging model
An actual C/S system may be constructed using a combination of one or more of the basic models. This classification introduces the concept of time and vertical/horizontal data distribution in the conventional client/server model. As a general rule, we presume that "Presentation" is in a client side and "Data" is in a server side. The meanings of the terms used in Table 1 are as follows. - "Data style" indicates the location of the data storage used. However, personal data or personal database is not included. - "Centralized" means that the data is stored in only one place. - "Distributed, Vertical" means that the data is vertically distributed along an organizational hierarchy. This style focuses on the differences in the processing power of the servers.
A Computing Model of Product Lines
5
- "Distributed, Horizontal" means that the data is horizontally distributed along a horizontal spread of organizations. In this style, data is distributed into multiple servers which have an equivalent level of processing power. - "Processing Style" indicates the processing style between client(s) and server(s). - "Transaction Processing" is transaction processing with ACID (atomicity, consistency, isolation, and durability) characteristics. - "Request/Reply Processing" indicates that a reply from the server is synchronized with a request from a client. - "Delayed Processing" indicates that the server process is not synchronized with a client request. The followings are symbols used in this paper. - Pn: Presentation - APn: Application Logic - DM n:Data Management - Dn: Data The following sections provide a description of each model.
3.1
Centralized Transaction Processing Model
There is a single database held centrally on a single server and the style of processing between a client and the server is Transaction Processing with ACID characteristics. The typical structure of this model is shown in Figure 2.
DM Server(s)
D
AP
Client P
Figure 2: Centralized transaction processing model
6
Yoshitomi Morisawa
An explanation of message and process flow: P on a client sends a transaction to AP on a server. According to the result of AP, DM retrieves, updates, adds, and/or deletes data in D. The result of the process is then returned to the client. AP and DM may be on different servers. This model is suited to transaction processing that uses a transaction management program and usually adds and updates data in a single database. When the transaction has a heavy load, a server side may be divided into an application server and a database server. Examples of this model include an order entry system, a stock management system, a stock ordering system, a production management system, a retail POS(Point of Sales) system, etc..
3.2
Distributed Transaction Processing Model
There are multiple databases on multiple servers and the style of processing between a client and the servers is Transaction Processing with ACID characteristics. The typical structure of this model is shown in Figure 3.
DM1 Servers
Client
AP 1
D1
DM2
D2
AP 2
AP 0 P
Figure 3: Distributed transaction processing model
An explanation of message and process flow: AP0 on a client sends a transaction to AP1. Using a part of the processing result of AP1, DM 1 retrieves, updates, adds, and/or deletes data in D1. Then, the part of this transaction that was not processed, or the processing result of AP1 , is sent to AP2. According to the processing result of AP2, DM 2 retrieves, updates, adds and/or deletes data in D2. Then, the processing result is sent back to the client. If required, a mechanism is used to maintain the integrity of D1 and D2. There may be different servers for APn and DM n.
A Computing Model of Product Lines
7
This model is suited to transaction processing for a core business which involves complicated update and query of multiple databases. When there is a heavy transaction load, the server side may be divided into an application server and a database server. In the case of asynchronous processing, if message queuing is used by the transaction management program, it is classified as Centralized Messaging Model, Chained Messaging Model or Data Staging Model. Examples of this include a core business system of banking, a seats reservation system, a factory production management system, etc..
3.3
Remote Data Processing Model
There is a single database held centrally on a single server and the style of processing between a client and the server is Request/Reply. The typical structure of this model is shown in Figure 4.
DM
D
Server(s)
Client AP P
Figure 4: Remote data processing model
An explanation of message and process flow: AP on the client side sends a message (SQL, etc.) to DM. According to the requirements represented by the message format, DM retrieves, updates, adds, and/or deletes data in D. Then, the processing result is sent back to the client. This model is suited to End User Computing (EUC) such as in a decision support system. AP functions with heavy load and AP facilities common to multiple clients may be put onto a server. Examples of EUC are various statistics, analysis and reporting, such as in budget planning, financial analysis, market research and analysis, sales analysis, capacity planning, demand forecast, etc.. Examples of query and reply processing include customer services, sales support, various inquiry processing, information
8
Yoshitomi Morisawa
providing services, etc..
3.4
Distributed Data Processing Model
There are multiple databases on multiple servers and the style of processing between a client and the servers is Request/Reply. The typical structure of this model is shown in Figure 5.
Servers
DM1
D1
DM2
D2
Client AP P
Figure 5: Distributed data processing model
An explanation of message and process flow: AP on the client sends a message (SQL, etc) to DM 1. According to (a part of) the requirements of the message, DM 1 retrieves, updates, adds, and/or deletes data in D1. The part of the message not processed, or the message of the processing result, is sent to DM 2; then, DM 2 retrieves, updates, adds, and/or deletes data in D2. The processing result is sent back to the client. If required, a mechanism is adopted to maintain the consistency of D1 and D2. This model is suited to EUC with simultaneous access to multiple databases and files and to the inquiry-intensive immediate processing. This enables effective utilization of information by sharing existing databases. This includes almost all of applications of Remote Data Processing model. Other applications are an enterprise sales statistics, an enterprise productivity data analysis, etc.
3.5
Centralized Messaging Model
There is a single database held centrally on a single server and the style of processing between a client and the server is Delayed Processing. The typical structure of this model is shown in Figure 6.
A Computing Model of Product Lines
9
DM Server
AP 3
D AP 4
Delayed
Clients AP 1
AP 2
P1
P2
Figure 6: Centralized messaging model
An explanation of message and process flow: AP1 on a client sends a message (SQL, document, etc.) to AP3. According to the result of the message, DM retrieves, updates, adds, and/or deletes data in D. After the modification of D, with appropriate timing, AP2 on the other client sends a message to AP4 and its message is processed using D, which has been modified. This model is suited to the automation of simple workflow within a group or an organization. Examples of this application include shipping and forwarding of internal memos and documents, events notification, internal document filing, execution / monitoring / reporting of business flow, etc..
3.6
Chained Messaging Model
Multiple servers contain horizontally distributed databases and the style of processing between a client and the server is Delayed Processing. The typical structure of this model is shown in Figure 7. An explanation of message and process flow: AP1 on the client sends a message (SQL, etc.) to AP2. According to the requirement of this message, DM 1 retrieves, updates, adds, and/or deletes data in D1. A new message generated by process AP2 is sent to AP3. The processed result then is sent back to the client of AP1. At appropriate timing such as kicking from AP3, a message is sent from AP4 on another client to AP3 , and DM 2 retrieves, updates, adds, and/or deletes data on D2 depending on the message already sent by AP2. The processed result is sent back to AP4 for the other client.
10
Yoshitomi Morisawa
Servers
Client(s)
DM1
D1
DM2
AP2
Delayed
AP3
D2
AP1
AP4
P1
P2
Figure 7: Chained messaging model
This model is suited to the loose integration by cooperations of independent multiple applications or systems. Examples of such applications are: 1. Workflow between groups or organizations. - Shipping and forwarding of internal memos and documents, and event notification by E-mail. - Forwarding and authorization of internal Ringi (business decisions authorized by executives); circulating the draft for sanction. 2. Integration of cooperating applications between enterprise systems. - Integration of production planning, Stock management, Process control, etc. using message delivery. - Integration of orders, buying, stocks, shipping and billing systems. 3. Cooperating systems between enterprises, such as electronic data interchange (EDI). - Order entry system cooperating with the customer system - Parts supply management system cooperating with suppliers' systems - Packed travel reservation system cooperating with related companies' systems
3.7
Data Staging Model
Multi-tiered servers contain vertically distributed databases and the style of processing between a client and the server is Delayed Processing. The typical structure of this model is shown in Figure 8. An explanation of message and process flow: AP0 on the client sends a message (SQL, etc) to AP1. According to the requirements of the message,
A Computing Model of Product Lines
11
DM 1 retrieves, updates, adds and/or deletes data in D1. A new message generated by the process of AP1 is sent to AP2. Then, the processing result is sent back to the client of AP0. At appropriate timing, such as kicking from AP1, AP2 and DM 2 on another server retrieve, update, add, and/or delete data on D2 depending on the message already sent by AP1.
DM2
D2
AP 2
Delayed
DM1 Servers
Client
AP 1
D1
AP 0 P
Figure 8: Data staging model
Typical utilization of this model is in an application such that data in D1 on a lower server is updated (down loaded) using a part (or all) of the data in D2 on an upper server; or, in the opposite way, data in D2 is updated (up loaded) using data in D1. PDA(Personal Digital Assistance) and mobile computing (which is called a client of client) are treated as a moving object (child client) and are integrated with a parent of the client at a suitable time. These are included in this model. This model is suited to an application to promote the management and utilization of information by asynchronous sharing of data. Example s are: - Asynchronous update of replicated data, such as a personal information system or accounting system across multiple branches. - Information utilization by downloading part of a database in business domains such as decision support systems (DSS) and enterprise
12
Yoshitomi Morisawa
information systems (EIS), using Daifukucho (an old-fashioned account book in Japan) and multi-dimensional databases. - Uploading of transaction data collected at branches or departments, such as combining the uploading of order data collected by departmental servers and the centralized order processing on an enterprise server.
4.
OPEN SOLUTION FRAMEWORK
The purpose of creating C/SS models is to provide the classification of the processing style of C/S systems, to provide proven software tools to implement C/S systems in each style, to reduce the total system integration cost, and to construct stable systems with lower cost in a shorter time. For this reason, we developed the Open Solution Framework as C/S system implementation architecture, which is shown in the middle of Figure 9. It forms the kernel model.
Business Model
Implementation
System Model
DM AP
P
D
Applications
Open Solution Framework
Model
Open Software Product Sets
C/SS Model
EIS Model
C/SS Architecture
Business Strategic Planning
Information Solutions Planning
Solutions Implementation
Operation/ Maintenance/ Administration
Figure 9: Flow of C/S system implementation
There are three general processes in the implementation of C/S system that are shown at the bottom of Figure 9. 1. Business strategic planning: information strategy drafting, solution definitions, BPR, project definitions. 2. Information solutions planning: requirements definition, architecture definitions, system basic design.
A Computing Model of Product Lines
13
3. Solutions implementation: detailed design, development, platform and software installation, testing. The Open Solution Framework becomes a guide for the above design (2) and implementation (3) stage. It consists of the enterprise information system model, the C/SS architecture, and the C/SS model and products based on them or services. As open products, we define the open software product sets. These guidelines are closely related to one another. We give only brief descriptions of the EIS model and the C/SS architecture in this paper. Details will be reported separately.
4.1
Enterprise Information System Model
In the Open Solution Framework, the information systems of an enterprise may be classified into business domains, information domains and office support domains from the views of its objectives, roles, and information used. Research Org.
Enterprise Information System Suppliers
Information Office Support
Business
Financial Org.
Business Networking
Allied Companies
Customers Competitors
Figure 10: EIS and its external world
There are business networking domains to support the sharing and cooperation of information within each domain, among domains, and between domains and the external world. As the external world cooperates with an enterprise information system, there are allied companies, suppliers, research organizations, financial organizations, customers, and competitors. We suppose business networking domains will assume more and more
14
Yoshitomi Morisawa
important roles due to the increasing cooperation of the external world. Figure 10 shows these relationships. To implement applications within each domain of an enterprise information system, various computing models will be used together depending on the objectives of the system, its scale, the type of business, etc. Table 2 shows the typical distributed computing models used within each domain. Table 2: EIS model and C/SS model Enterprise Information System Model Business domains Information domains
Office support domains Business networking domains
4.2
Client/Server Solution Models Centralized transaction processing model Distributed transaction processing model Remote data processing model Distributed data processing model Data staging model Centralized messaging model Chained messaging model Chained messaging model Data staging model
Client/Server Solution Architecture
The Client/Server Solution (C/SS) architecture provides the technical architecture for information infrastructure for the execution of a C/S system.
Development Services
Client Production Services
Shared Server Services
Management Services
Applications
Distributed Infrastructure Services
Figure 11: C/SS architecture
The C/SS architecture classifies software into five sets of services such as Development services, Client Production services, Shared Server services, Distributed Infrastructure services and Management services. A service is a
A Computing Model of Product Lines
15
technological building block that is typically implemented in software. Figure 11 illustrates the C/SS architecture service set.
4.3
Open Software Product Sets
In accordance with the C/SS models that indicate execution forms in C/S systems, this section describes the product sets to support the implementation and management of C/S systems, and the connection with other systems.
Centralized Transaction Processing
Distributed Transaction Processing
Remote Data Processing
Distributed Data Processing
Centralized Messaging
Chained Messaging
Data Staging
Data Query
Groupware
Replication Type Data Staging
Data Server
Message Connection
File Transfer Type Data Staging
Transaction Oriented
Figure 12: Basic patterns of implementation
The product sets are classified into seven basic patterns to develop and execute C/S systems corresponding to the seven C/SS models (Figure 12); three basic patterns to manage the C/S systems (Figure 13), and, three basic patterns to connect with other systems (Figure 14). A real C/S system may be combined with these basic patterns and connected with other systems.
Small Scale Management Medium Scale Management Large Scale Management
Figure 13: Basic patterns of management
There is a combination of software which can be recommended in each pattern, and we had about fifty sets in the version 6 of product sets (November 1997). We can not describe everything in this paper; therefore, we introduce some simple combinations for understanding. When we
16
Yoshitomi Morisawa
selected these product sets, we set up the standard selection criteria, evaluated them according to it, and established them. These product sets are periodically revised to reflect latest products.
Internet Connect Open Connect Mainframe Connect
Figure 14: Basic patterns of connection
4.3.1
Transaction Oriented Type
Transaction oriented type, which is used for the imple mentation of Centralized Transaction Processing model and Distributed Transaction Processing model of C/SS models, is divided into server-centric process of application and dialog-centric process between a client and a server. - Server-centric process: The type where the number of transactions is comparatively small, and server process is heavy (e.g., a combination of Unix LINC II and Oracle). - Dialog-centric process: The type where there are a lot of transactions and fast response is required (e.g., a combination of Visual Basic, BEA Tuxedo, and Oracle) 4.3.2
Data Query Type
This type specifies the necessary search conditions, takes data in the form of a spreadsheet from a database of server, analyzes the data, generates report, etc. It is the ad-hoc query type that isn't accompanied by the development of application. Generally it is a non-fixed form process (e.g., a combination of EXCEL, Excellent, and Oracle). 4.3.3
Data Server Type
This type is a combination of middle software and a tool to access business application databases. We divide it into following three types and select software accordingly. Generally it is a fixed form process. - Scale: small. Function: mainly retrieval (e.g., a combination of Access, SQL*NET, and Oracle)
A Computing Model of Product Lines
17
- Scale: medium. Function: retrieval and simple updation (e.g., a combination of VisualBASIC, SQL*NET, and Oracle) - Scale: large. Function: retrieval and updation (e.g., a combination of PowerBuilder, SQL*NET, and Oracle) 4.3.4
Groupware Type
This type is divided into the e-mail type (whic h isn’t accompanied by the development of application), and the information sharing and workflow types (which are accompanied by the development of application). - E-mail type (e.g., Microsoft Exchange) - Information sharing type (e.g., Lotus Notes) - Workflow type (e.g., Staffware) - Document management type (e.g., Interleaf) 4.3.5
Message Connection Type
This type is used for cooperating asynchronous processes in a distributed system (e.g., MQseries). 4.3.6
Replication Type Data Staging
This type does data staging to utilize a replication function. 4.3.7
File Transfer Type Data Staging
This type does data staging to utilize a file transfer function. 4.3.8
Basic Patterns of Management
The product sets of management are divided into three types depending on the number of servers (S) and the number of clients (C), and product sets are determined respectively. - Small scale management type: S = 1-2, C = less than 30, and with client administration and print management. - Medium scale management type: S = 3-10, C = 31-300, and with centralized management. - Large-scale management type: S = more than 11, C = more than 301, and with integrated hierarchical management. 4.3.9
Basic patterns of connection
The product sets of connections are divided into the following three types.
18
Yoshitomi Morisawa
1. Internet connection type: This type sends, collects and exchanges information utilizing the Internet. We utilize free convenient software for this type. 2. Open connection type: TCP/IP connection, file transfer, and the terminal emulation are examples. This type supports connection among multivendor host computers. 3. Mainframe connection type: This type supports connection with mainframes with a high level protocol.
5.
EXPERIENCE IN USING C/SS MODEL UNDER ITIP METHODOLOGY
5.1
System Requirements of S Company
S company is a construction enterprise that manages construction activities from Hokkaido Prefecture to Okinawa Prefecture in Japan as well as overseas. The goal of this project was to develop a new financial affairs system for domestic use in Japan (approximately 2,000 sites). Each site is a temporary work office which is set up at the beginning of a construction project and broken down when construction is completed. Half of these temporary work offices are set up and broken down in a year. To manage these remote sites, 1-3 permanent business offices exist in each prefecture. These offices are organized under branch offices of which there are 14 nationwide. These various offices, together with the head office, accomplish the accounts business function. To take advantage of local availability and pricing, each local work office is responsible for contracting and paying for all materials such as steel frames and fresh concrete, labor costs of steeplejacks and carpenters. Similarly, all accounting information such as orders, order reports, various transfers, etc., which occur in a work office are to input at the local work office, as well.
5.2
Using the C/SS Model
The overall process used in the ITIP methodology to select the recommended C/SS model is as follows. 1. Clarify the data and its administrative organization. 2. Put necessary business processes in order. 3. Describe both a centralized and a distributed data arrangement. Both descriptions are needed to help participants from users’ divisions
A Computing Model of Product Lines
19
understand the proposed solution since they are usually not familiar with computer systems. - Clarify C/SS model of each business process for the centralized data arrangement. - Clarify C/SS model of each business process for the distributed data arrangement. 4. Decide centralized or distributed data arrangement from the points of administration, security, and business requirements. 5. Select simple models after considering its possibilities and stability.
5.3
An Example: New Financial System
The following example illustrates how the C/SS model for the new financial affairs system for S company was derived. We explain only a part of its derivation due to the limited space in this paper. 5.3.1
Data Clarification
The main data and the usage of data within each organization is categorized. Data include entry data, master data, etc. and organization of work offices, business offices, branch offices, the head office, and their relationships. 5.3.2
Business Processes
The following business processes are selected. - Data-entry process. - Branch processes (accounts process of work office, accounts process of branch, monthly balance process). - Inter-branches process (transfer process). - Enterprise process (settlement process). - Supporting processes (master data maintenance, etc.). 5.3.3
Clarify Centralized and Distributed Data Arrangement
The centralized and distributed data arrangements are clarified. For data administration, the arrangements are - Enterprise Data and Enterprise Common Data (various master data) are centralized. - Branch Data are horizontally distributed. - Enterprise Data, Enterprise Common Data and Branch Data are vertically distributed.
20
Yoshitomi Morisawa
- Entry Data are horizontally distributed. - Branch Data and Entry Data are vertically distributed. These data arrangements and the relationships between them are illustrated in Figure 15.
Centralized
Branch Office Business Office Work Office
Vertical Distribution
Head Office
Enterprise Common
Enterprise Data
Branch Data
Entry Data
DataData Branch
Entry Data
Entry Data
Horizontal Distribution
Figure 15: Relationship between data
Table 3 indicates the physical arrangement of these data when they are centralized and distributed. Table 3: Physical data arrangement Centralized Head Office Enterprise Data Branch Office
Business Office Work Office
Enterprise Common Data Entry Data transferred
Distributed Enterprise Data Enterprise Common Data Branch Data Enterprise Common Data (copy) Entry Data transferred
Entry Data
Entry Data Enterprise Common Data (copy)
Using the following premises, we identified the C/SS model for each business process in terms of both a centralized and distributed arrangement. - A data entry terminal in a work office is not established permanently, so it is difficult to connect it always into a network. On the other hand, it is required to provide the availability for an irregular data entry process in a work office. This process is closer to the mobile computing that is included in the Data Staging model.
A Computing Model of Product Lines
21
- We applied the following criteria for selecting Transaction Processing and Request/Reply Processing: Transaction Processing is selected if there is a wide area network (WAN) between a client and a server; Request/Reply Processing is selected if there is not. - A single database would be large enough to accommodate the assumed quantity of data and transactions. Therefore, when data is centralized in the head office, we assume that it is a single database. 5.3.3.1 C/SS Model - Centralized The C/SS model for each business process in a centralized data arrangement is identified as follows. - The data-entry process falls under the Data Staging Model because data is vertically distributed in work offices, business offices and a branch office. The processing style is Delayed Processing for uploading data to the head office. - Branch processes fall under the Centralized Transaction Processing Model. These processes are query processes where a client in a branch office queries data centralized in the head office. The processing style is Transaction Processing because there is a WAN between a branch office and the head office. - Inter-branches process falls under the Centralized Transaction Processing Model. This process is a query process of data related branch offices. Data is centralized in the head office, and the processing style is Transaction Processing. - The enterprise process falls under the Remote Data Processing Model. This process is a query process where a client in the head office queries Enterprise Data centralized in the head office. The processing style is Request/Reply Processing. - Supporting processes fall under the Centralized Transaction Processing Model. These processes are rea-time process for master file maintenance centralized in the head office from branch offices, and the processing style is Transaction Processing. 5.3.3.2 C/SS Model - Distributed The C/SS model for each business process in a distributed data arrangement is identified asa follows. - The data-entry process falls under the Data Staging Model because data is vertically distributed in work offices, business offices and a branch office, and the processing style is Delayed Processing for uploading data to the branch office. - Branch processes fall under the Remote Data Processing Model. These processes are query processes in which a client in a branch office queries
22
Yoshitomi Morisawa
Branch Data centralized in the branch office, and the processing style is Request/Reply Processing. - Inter-branches process falls under the Distributed Transaction Processing Model. This process is a query process that a client in a branch office queries Branch Data horizontally distributed in other branch offices, and the processing style is Distributed Transaction Processing. - The enterprise process falls under the Remote Data Processing Model. This process is a query process that a client in the head office queries Enterprise Data centralized in the head office. The processing style is Request/Reply Processing. Supporting processes are divided into two categories 1. The processes of master file maintenance are query processes of Enterprise Common Data centralized in the head office from branch offices. The processing style is Transaction Processing. Therefore, these processes fall under Centralized Transaction Processing model. 2. The processes of deployment are Delayed Processing for downloading Enterprise Common Data to branch offices, business offices and work offices from the head office. Therefore, data is vertically distributed. These processes fall under the Data Staging Model. 5.3.4
Other Centralized/Distributed Decisions
Because of the following requirements, it was decided that a centralized data arrangement is the best for new financial affairs system. - The new data entry load on operators could be no more than with the current system. - Security is important, including protection against loss or theft in the work place. - Data input from local sites must be checked against master data to ensure integrity. 5.3.5
Model Selection
The enterprise process, which will be used by clients within the head office, may use the Centralized Transaction Processing model and is not restricted to Remote Data Processing model. Therefore, Centralized Transaction Processing model and Data Staging model were selected as infrastructure models for the new financial affairs system.
A Computing Model of Product Lines 5.3.6
23
Analysis Results
Based on this analysis, we proposed a set of recommended software products necessary for each model and listed the necessary hardware configurations in our proposal. Our proposal was selected from the following set of recommended software products from the product sets of each C/SS model, and included administration products. - For the Centralized Transaction Processing model: Visual Basic for a client application, BEA Tuxedo as a transaction monitor, and Oracle for database software on a server, - For the Data Staging model: Oracle Mobile Agents. The following hardware products were selected: - For servers: Sun Ultra Enterprise 4000 and COMPAC PC servers, - For clients: DOS/V PCs and mobile facilities. S company has selected the information infrastructure described in our proposal, and is proceeding towards the application development.
6.
CONCLUSIONS
In this paper, we have explained our framework and model to select a product line and its product set for implementing our customers' distributed processing systems. NUL has been putting the C/SS model to practical use in selecting a combination of products for implementing client/server systems since the announcement of OSFW in January 1996. Since the available products are evolving rapidly, recommended combinations of products are reviewed and revised as the technology progresses. We are also using the C/SS model as a reference model to develop an information infrastructure in our IT consulting business. The responses to this model from our customers and our system engineers have been positive as a reference model to select a combination of products and to support design stage of business applications. However, the OSFW, which contains the C/SS model discussed in this paper, doesn’t cover all application areas and new emerging information technologies. Currently, we are revising OSFW as a framework for the Internet era, updating C/SS model for covering emerging information technology and revising product sets for the model. We will report our new framework and its experiences in other opportunity.
24
Yoshitomi Morisawa
ACKNOWLEDGEMENT OSFW is the fruition of discussion with many colleagues within NUL. The author wishes to acknowledge many colleagues, especially Mr. Hiromichi Iwata and Mr. Haruo Toyama, who have participated in the development from the early stage of this framework, Mr. Hisashi Okada who has applied the framework in the ITIP methodology, and Dr. Koji Torii for reviewing the draft of this paper.
REFERENCES Berson, Alex (1992), Client/Server Architecture, McGraw-Hill. Cassell, James(1994), The Total Cost of Client/Server: A Comprehensive Model, A Gartner Group Conference on the Future of Information Technology Industry (November). IBM (1994), A Guide to OPEN CLIENT/SERVER, Open Enterprise group of IBM Europ in Basingstoke UK, (May). Morisawa, Yoshitom and Iwata, Hiromichi and Toyama, Haruo (1996a), A Proposal of Computing Models for Distributed Processing Systems, IPSJ-SIG Software Engineering, 96-SE-109-3 (May), 17-24, in Japanese. Morisawa, Yoshitom and Iwata, Hiromichi and Toyama, Haruo (1996b), Open Solution Framework for Implementing Client/Server Systems, Unisys Technology Review, Vol.16 No.2 (August), 15-33, in Japanese. Morisawa, Yoshitom and Okada, Hisashi and Iwata, Hiromichi and Toyama, Haruo (1998), A Computing Model for Distributed Processing Systems and Its Application, Proceeding of 1998 Asia Pacific Software Engineering Conference (December), 314-321. Shedletsky, J.J. and Rofrano, J.J. (1993), Application reference design ed for distributed system, IBM Sys.J., Vol.32, No.4.
