Design considerations

for distributed
applications
by J. J. Rofrano, Jr.

Probably the hardest part about developing a A distributed application requires more logic
distributed application is determining where to than just the communications between a work-
start. There are multiple hardware and software
platforms to understand, network traffic station and a back-end server or host. Different
implications, and numerous tools and programming paradigms must be blended and in-
technologies to consider. One question, however, terfaced. One paradigm views the rws as an ex-
transcends the importance of what platform to tension of the host world; the other views the host
pick or what tool to use: that is, how do you as an extension of the rws world. We examine the
design it? This paper represents the results of
two years of work with customers regarding this two approaches in greater detail but, regardless of
question. The paper explores some of the one's perspective, the graphical user interface
implications of working in a distributed found on the present programmable workstations
environment, reviews some rules for data and has an impact on the design of the application.
function placement, and introduces a
methodology for distributed application design.
The mix of skills needed to implement distributed
applications may have an impact on the organi-
zation of current software development depart-
ments. Most end-user's jobs were probably de-
fined by existing computer applications, whereas
new applications should expand the existing
T wo popular terms, cooperative processing
and client/server, are used to describe dis-
tributed applications. These two terms, however,
scope. In fact, if the application does not change
the work habits of people, then the technology is
not being exploited. Many things are to be con-
often mean various things to different people. In sidered in designing the physical connection be-
the context of Systems Application Architecture* tween the portions of the distributed application,
(SAA *), an SAA application is one that runs on an such as scalability, configurability, and perfor-
SAA platform, conforms to Common User Ac- mance.
cess" (CUA*), uses the Common Programming In-
terface (CPI), and is designed for cooperative pro- This paper reviews some of the issues involved in
cessing. 1 Most people understand hardware and understanding the distributed processing envi-
software platforms and what a common program- ronment and designing applications to take ad-
ming interface is. However, the expression "de-
signed for cooperative processing" brings to mind ©Copyright 1992 by International Business Machines Corpo-
ration. Copying in printed form for private use is permitted
a broad definition of an application that can be without payment of royalty provided that (1) each reproduc-
split between a programmable workstation (rws) tion is done without alteration and (2) the Journal reference
and a host. Likewise, the term client/server has and IBM copyright notice are included on the first page. The
been often broadly defined as an application title and abstract, but no other portions, of this paper may be
copied or distributed royalty free without further permission
whose "client" part makes requests from a "serv- by computer-based and other information-service systems.
er" part that resides somewhere in a local area Permission to republish any other portion of this paper must
network (LAN) environment. be obtained from the Editor.

564 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

vantage of it. Allan L. Scherr introduced a matrix eral transparent services, making this environ-
approach to determining where to place applica- ment very attractive to programmers and end
tion function and data in a network." This paper users alike.
is based on his work and introduces a tool called
the object/action matrix, which is built on
Scherr's initial matrix design. We expand on the From a software design perspective, the client is
the one making the request, while the server is the
rules for data and function placement, and review
one who does the actual work to satisfy the re-
a methodology for distributed application design
quest. Most people think of client/server in hard-
using the object/action matrix.
ware terms, with the rws always being the client.
One look at X Windows** confirms that this view
SAA is the example environment, but since this
is flawed. The server is the place the work actu-
methodology is independent of the application de-
ally gets done. For a database request, the server
velopment tools that are used, it will apply to the
is the machine that applies the request to the ac-
Advanced Interactive Executive* (AIX*) and
tual data. For a display request in an X Windows
other environments.
environment, the server is the PWS that executes
the display request on behalf of the host process
Distributed application models that made it.
Since there has been widespread usage of the
terms cooperative processing, distributed pro- For both of these forms of distributed processing,
cessing, and client/server computing, we first de- the work is shared between two or more proces-
fine the terms as they are used throughout this sors. This may be the result of a conscious deci-
paper. sion by the application developer to execute func-
tion on a particular platform, or it may be a
Distributed processing is the distribution of func- transparent system service provided by the un-
tion or resources across two or more intercon- derlying network or operating system. The ob-
nected processors. These processors can be any jective is to extend the domains of applications
combination of mainframe, midrange, or pro- across local area networks (LANs) and wide area
grammable workstation. The distribution may be networks (WANs), and expand the role of both the
transparent or overt. Distributed processing is a traditional host and the programmable worksta-
generic term that includes cooperative processing tion by exploiting the unique capabilities of each.
and client/server computing.
The relationship between distributed parts of an
Cooperative processing is a term that mainframe
application can be either peer-to-peer, call/re-
users created to talk about an application whose
turn, or event-driven. The three communication
functions are divided between a mainframe
models that implement these relationships are:
processor and a programmable workstation
the conversational model, the remote procedure
(rws), It is a "host-centric" view of the world in
call (RPC) model, and the message and queueing
which the rws adds value to the mainframe by
model.
providing a better human interface and perhaps
some additional processing. Cooperative pro-
cessing is a form of distributed processing. The conversational model is one model for dis-
tributed processing where the two application
Client/server computing is a term that personal halves agree on who has the right to send and who
computer (t-c) users created to talk about an ap- will receive data based on established protocols
plication whose functions are divided between a (peer-to-peer). The initiating application usually
programmable workstation and a LAN server. It is starts with the right to send data. When the ini-
a "workstation-centric" view of the world in tiating application has completed sending and
which the LAN server adds value to the worksta- agrees to receive data, the roles are reversed.
tion by carrying out work on its behalf. Some This role reversal continues until processing is
users extend the definition to include enterprise complete and the conversation is terminated.
servers, which are traditional mainframes and This model is implemented on some systems
minicomputers that have now taken on a new through the Advanced Program-to-Program Com-
role. The network operating system provides sev- munications (APPc) interface.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 565

 Remote procedure call is a call/return model Programmable workstation (rws) refers to a Per-
where application functions interact in a request- sonal System/2*- (PS/2*-) class workstation run-
er/server relationship. The requesting program ning Operating System/2* (OS/2*), AIX, or PC-DOS.
makes a request of the server program to provide We assume that the PWS has a graphical user in-
some service. The server program then carries terface such as Presentation Manager", AIXwin-
out the task and completes the process, usually dows *, or Microsoft Windows *". The graphical
by returning some results. Since services can be user interface assists in the distributed goal of
local or remote, this model introduces an element exploiting each processor for what it does best. A
of transparency in which the application can be traditional time-sharing system simply cannot af-
unaware of where the actual service is performed. ford to dedicate the resources necessary to ma-
This model is implemented by the Open Software nipulate the end-user interface like a rws. The
Foundation (OSF) Distributed Computing Envi- rws gives all applications an easy-to-use common
ronment (DCE) remote procedure call application "look and feel" independent of the back-end pro-
programming interface (API), often referred to as cessor.
DCE/RPC. The Transmission Control Protocol/In-
ternet Protocol (TCP/IP) also has an RPC mecha- The PWS can physically be connected to other
nism. computers via a local area network, or be at-
tached to a mini- or mainframe via a wide area
Message and queueing (MQ) is an event-driven network.
model for writing distributed applications. The
communication between functions is performed
by placing a message event on a queue, which is In this paper, the back-end processor is referred
routed to the called function's queue. The mes- to as a host. What makes it a host is its ability to
sage is then taken off the queue and processed. It execute function on an application's behalf and to
is, by default, an asynchronous model but if a share resources with other workstations. This pa-
result is needed, the function called can return a per considers mainframes, minicomputers, and
message, thus simulating a synchronous call. LAN servers all to be hosts when they fit the above
E-Mail is one example of message and queueing. description.
Because of this, some people refer to messaging
as "datagrams." Whether trying to exploit the capabilities of the
rws from host-based applications or trying to ac-
Messaging uses a connectionless paradigm. There cess host data and resources from rws-based ap-
is no knowledge of the underlying transport or plications, the objective is the same: to integrate
topology. The message is sent to the first queue the role of the rws into the enterprise information
along with the destination address and all inter- system.
queue routing is transparent to the calling appli-
cation. In fact, the function being placed on the
queue may not even be running at the time the Most applications will operate in multiple modes.
message is sent. This provides for off-line or batch They do this by sometimes becoming a client to
processing of messages. the OS/2 LAN services to perform a function, while
at other times they may need to use a conversa-
Messaging is widely used in computer-integrated tional model like APPC to get at back-end func-
manufacturing (CIM), where it is appropriate for tions on the server. Even servers may become
clients of other servers in the process of servicing
alerts and the asynchronous starting and stopping
of jobs and machinery. The added advantage of a request.
being connectionless allows the shop floor to be
reconfigured during run time. The application is All distribution is performed by some form of pro-
unaware of the change. The IBM Distributed Au- gram-to-program communications. The question
tomation Edition (DAE) is one implementation of is, does the developer write that communications
this model and is generic enough to be applicable function into the application logic, or provide
for application developers outside of elM. some means of making it transparent to the ap-
plication by either utilizing network/system serv-
Two more terms may require clarification: pro- ices or by writing the developer's own request-
grammable workstation and host. or/server interface?

566 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

The distributed view lithic, hierarchical, "panel-oriented" way of de-
signing applications and move to an overall in-
The role of the rws has often been referred to as terface design that is modular and event-driven. 4
the window to the enterprise. All applications will Event-driven applications place the end user in
be transparently accessed from a common work-
station platform whether they are local, remote,
or distributed. The enterprise network will be-
come less apparent to the end user. Distributed
processing expands the role of the rws to that of
an active participant in the enterprise. Rather The user interface of a
than just being the window into the user's appli- distributed application needs to
cations, it becomes active in the execution of the
user's applications as well (see Figure 1). The end remain highly interactive.
user sees a seamless application with transparent
access to function and data.

Advantages of distributed processing. One of the

primary reasons for implementing distributed control of application flow, not the programmer.
processing is to utilize each processor for its They also give programmers the freedom they
unique capabilities. The resulting application need to place function on various platforms while
should provide a better result than could have maintaining the user interface code at the rws.
been achieved with either the rws or mainframe We discuss these two application designs in more
technology alone. 3 We are already familiar with detail in the next section.
mainframe capabilities. A better understanding of
rws capabilities is needed. Some mainframe end
users may already be familiar with rws capabil- Productivity. Increased productivity and ease-of-
ities, but does the "glass house" programming use of the programmable workstation are some of
department understand it? The user interface of a the advantages distributed processing offers.
distributed application needs to remain highly in- Some people find it easier to interact with a graph-
teractive while the back-end host or server is also ical interface than with the traditional character-
busy processing data. The user does not neces- based interfaces on host systems. An advantage
sarily have to wait for host processing. in some environments is the ability to invoke mul-
tiple copies of an application and run them con-
Multitasking. Some tasks such as a credit check currently. Direct manipulation of screen objects
or customer number search can be done in the will be an advantage in others. For example, in a
background while the user continues to interact data entry application, the re-keying of informa-
with the workstation in the foreground. Other tion can be virtually eliminated, along with the
functions such as accessing insurance rate tables errors re-keying introduces, by using direct ma-
and other "table lookup" functions can be per- nipulation at the field level to move data easily
formed without ever going up to the enterprise from one application to another. Greater input
host by storing the data on a work group LAN integrity may be a by-product of the graphical
server or even at the workstation. This worksta- user interface on the PWS.
tion processing can also be done in the back-
ground because of the multitasking capabilities of Work-load shift. Because we have programmable
most workstation operating systems. Programs intelligence at the workstation, an advantage of
should not be written with the assumption that the distributed processing might be to off-load host
end user is waiting for a transaction to complete. processing. At the same time, the increased in-
Users could very well be working on the next telligence of the PWS can now process transac-
transaction or even working with another part of tions faster than was humanly possible on a non-
the application during wait times. programmable terminal (NPT). The result may be
that the host work load actually increases by ex-
Design changes. In order to design an application ploiting the rws multitasking environment. This
with simultaneously highly interactive front and will depend on application design and whether
back ends, we need to change our current mono- transactions are driven synchronously or asyn-

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 567

 Figure 1 The distributed view

- COMMON PWS FRONT END

- INTEGRATED APPLICATIONS
- DISTRIBUTION IS
TRANSPARENT TO END USER VM ,...-_--1-1.._-'-_--1"'"- ..1----,

MVS

IONS

IONS

IONS

DISTRIBUTED APPLICATIONS

USER'S VIEW

OS/2

NEW APPROACH
TO APPLICATION DESIGN

o - NEW APPLICATION STRUCTURE

- NEW DECISIONS
-NEW SKILLS
-NEW TOOLS

DISTRIBUTED APPLICATIONS
rT~::;:::'::;:5'=j- - - - - - --'-------------'

chronously. There may be a work-load shift, but The addition of a consistent graphical user inter-
not necessarily in the intended direction. face for applications seems most powerful of all
the extended possibilities in distributed process-
Greater connectivity options. The PWS will also ing. The increased user productivity will affect all
provide the ability, in some instances, to continue applications.
processing if a host link fails or to have the option
of working remotely without a host link and batch Distributed application design
upload to the host later. The possibilities are lim-
ited only by our understanding of the capabilities While distributed processing introduces transpar-
of each platform. ent application execution to the end user, the ap-

568 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 2 Application anatomy

APPLICATION FUNCTIONS SHOULD

BE DESIGNED INDEPENDENT
OF WHERETHEYWILL EXECUTE

- USE PORTABLE LANGUAGE

CONSTRUCTS

- USEOBJECT-ORIENTED DESIGN
(Le.,MODULAR/ENCAPSULATED)

- DESIGN FOR REUSE

plication programmer has some conscious deci- discussed in greater detail when we explore func-
sions to make, as outlined in the lower righthand tion placement.
corner of Figure 1. A new approach to application
design is required, along with a new application Having function execute on multiple platforms
structure to support placement of function and raises the problem of how to determine the split
data across multiple platforms. In the past, the point. The easiest solution is not to think in terms
programmer never worried about where to place of split points, but to design the application from
the data or end-user interface or where the code the start with separate functions that will execute
would run-it all ran in the same place. This on an unknown platform (see Figure 2). The plat-
changes in a distributed environment. The devel- form will probably be determined by what the
oper must acquire skills to know when and where function does or what object it must manipulate.
to split application function and must decide on (For example, the manipulated functions include
what platforms to run them. Tools are necessary the data functions on the same platform as the
to help make and execute these design decisions. data, the compute-intensive calculation function
on the processor with a floating-point accelerator,
Ideally, the functions should be placed on the or the end-user interface function on the work-
platform where they perform best or where shar- station.)
ing is desired. The benefits are in reuse of code by
multiple applications, as well as good perfor- The application becomes a collection of self-con-
mance by executing code on the platform it runs tained functions that, when executed in a partic-
best. "Best" is whatever is best for the enter- ular sequence, perform a business process. These
prise; in some instances this means best perfor- same functions executed in another fashion may
mance, in others it means the cheapest platform. perform a completely different process. The abil-
Whatever the goals are, function should be placed ity to reuse functions in multiple applications is
where it will best meet these goals. This topic is very advantageous in today's environment of

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 569

 Figure 3 Assembling the pieces

.t
APPLICATION FUNCTIONS ~IIIIIIIIIIIIIIIIIIIIIIIIII
SHOULD BE PLACED WHERE
THEY EXECUTE BEST

J:::::
r-:---:--..,.....,

?•
o - SOME DECISIONS
ARE OBVIOUS, WHILE
OTHERS ARE NOT

growing application backlogs. Using object-ori- on a particular platform should not stop the pro-
ented design is a good way to achieve this goal. grammer from writing the modular, portable code
These functions could even be available as end- that will take advantage of these common serv-
user computing tools. Think about the power of ices as they become available.
end-user tools like spreadsheets hooking into
company functions, like calculating commission Applications then, are broken down into a series
rates using the latest rate tables. of requests to be carried out on some platform.
These requests should be made through an inter-
Platform portability can be attained by using com- face that is common to all platforms and trans-
mon programming interfaces for both languages parent to the application programmer.
and services. This makes both of them portable as
the objects they manipulate move. There is a re- At some point the programmer will want to as-
quirement to have a common way to call these semble these functions (or code modules) into an
functions in all environments, directory services, application (see Figure 3). When it is assembled,
and routers to keep track of where data and func- there will be some placement decisions that will
tion objects reside. The absence of these enablers be obvious, while other placement decisions will

570 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 4 Panel·driven structure

r-, /

ORDER ENTRY
1. LOCATECUSTOMER
2. ENTERAN ORDER
3. OUERYPARTS
4. REVIEWORDERS

~
~
f-1=-l1 T ~
tr <,
--- ---
HARD
COOED

~;::::::::J

not. In general, we want to place those parts of dure that displays its submenu, which calls an-
the application that deal with the end user on the other procedure that displays the data entry
programmable workstation. It is also desirable to screen, and so on. To select a different menu
place those parts of the application that require item, the user must back out of the chain of
host processing or database sharing on a host sys- screens and start down a new path. This is re-
tem where they can run most efficiently. The LAN ferred to as modal operation because the inter-
environment is also a "host." If the database action proceeds in one mode at a time, i.e., the
sharing needs can be satisfied on a LAN server, user may be using the "data entry mode" or "re-
then that becomes the host to the particular ap- port mode" or "electronic mail mode." To look at
plication. Two models for application design are a report as a result of some mail that was re-
discussed next, one of which might be better ceived, the user has to back out of mail mode and
suited for distributed applications. go into report mode. One could argue that a jump
key or fast path can change the status in the menu
Hierarchical application structure. Procedure- tree, but it must be preplanned by the program-
driven or "panel-oriented" applications are hier- mer.
archical by design. They interact with an end user
on a screen-by-screen basis, usually in a hierar- The problem with this design is that user input is
chy of menus (Figure 4). Each procedure within solicited by each menu procedure that is called.
the hierarchy that needs input from the user, ac- Although structured programming and top-down
tively seeks it on its own behalf. The application design procedures have been used, no central
displays a selection menu that may call a proce- point is specified to gather user input. It is very

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 571

 Figure 5 Event-driven application structure

r---

---,
API

PRESENTA· b
TION
SERVICE
--.J
I I
I'\.

~l a
-
L
L--

difficult to write a distributed application with the Event-driven application structure. The applica-
user interface on the rws and compute-intensive tion structure for the event-driven model is quite
data processing on a back-end host or server us- different, as seen in Figure 5. This model breaks
ing this monolithic design. It is also almost im- the modal barriers of the hierarchical design by
possible to take an existing panel-oriented appli- exploiting the graphical user interface and pre-
cation and change it to be distributed. There are senting the user with simultaneous choices that
too many routines that want to get at both the end can be accessed in a modeless fashion. Multiple
user and the data from the same block of code. options are available simultaneously and are rep-
How can these functions be placed on a back-end resented as windows or icons on the screen.
host when they need to prompt for input at the Rather than a function actively seeking input from
PWS? the user as in the hierarchical model, user input is
solicited by a front-end code via the presentation
The answer is to structure the program so that services, and a back-end function reacts to these
application functions have the data passed to user events. This not only enhances usability by
them by a "front-end" procedure. This procedure offering the end user the freedom to work more
collects the data from the user on the function's naturally in a modeless fashion, but it also takes
behalf. The functions then become reactive to in- the burden of program navigation off of the ap-
put instead of actively seeking it. But how is plication programmer. Each function in the code
front-end processing accomplished? Obviously a is atomic and simply performs when called upon.
new structure is needed for distributed applica- This is called an event-driven application struc-
tions. A solution is to write event-driven appli- ture." There is nothing really new about writing
cations. event-driven applications; programmers have

572 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

 most part. In fact, this structure lends itself quite
easily to having icons represented on the desktop
that actually initiate transactions running on a re-
mote host. With the exception of the end-user
interface code, host programmers will be writing
] pretty much the same style code in the same lan-
guages as they do today. They just will not need

00
to solicit input.

This means it will not matter how back-end trans-

- actions get the user input they need to process.
API
They also no longer need to perform simple range
b'
checking or input validation. All this can be done

0
once in the end-user interface code and will no
longer need to be part of each and every trans-
action. This will yield a savings in host program-
mer time and contribute to reuse of code at the

o
workstation. Because of this structure, the same
a'
I--
DATA transaction can process in both real time and

o
batch mode. One of the added values in designing
an application using this technique occurs when a
L.-
communication link goes down. The system al-
lows the user to keep working on the front end
and do a batch and upload when the link comes
back up. The host transactions will not know that
there is no end user at the other end of the line,
because they now react only to input.

Each function should be implemented as a "black

box." Functions are only required to know what
another function does, not necessarily how it
written them to monitor events on manufacturing does it. This is the object-oriented programming
floors for years. The new aspect is using them in concept known as data encapsulation. A function
line-of-business applications to monitor the end that needs access to data should do so via a re-
user! quest to a function that manages all requests for
that data. The controlling function would be
The application code is structured in three sec- passed all the parameters needed for data extract
tions (Figure 5): code that handles the event- or update, perform the function needed, and then
driven graphical user interface, code that per- return the results. In this way one could change
forms line-of-business (LOB) functions on the the physical data access method and the request-
rws, and code that performs line-of-business ing function would not be affected, because it is
functions on the host. The rws-to-host commu- unaware of how the data are physically accessed
nication will probably be somewhere within the (the requesting function has only a logical view).
two line-of-business code sections, but we could
certainly have an interactive interface that com- Alternate views. The capabilities of the program-
municates directly with host code. Ideally, this mable workstation change the manner in which
communication should be as transparent to the one views the computer systems. The move is
application as making a local procedure call. from a view of applications looking out from the
mainframe to drive dumb terminals, to an alter-
As this model is explored further, it is shown that nate view of the intelligent workstations looking
only the end-user interface code really needs to back at and driving a host. This view is opposite
be event-driven. The line-of-business code on the that of most host programmers. The basis for cli-
workstation and on the host can be modal for the ent/server computing is to expand the role to the

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 573

 workstation to include other services in the en- A well-architected interface that allows programs
terprise. Now the workstation is master and re- to make requests for services and data without
quests services from an upstream server. being involved in how the service functions is
very desirable. These servers may become re-
It is very important to understand how an appli- questors (or clients) to other servers in the pro-
cation developer thinks. Does the developer view cess of servicing the original request. Servers
should not care if the requestor is an end-user
program or another server making a request on
behalf of its client. This style of application in-
terface is the easiest approach for most program-
mers to use.
There are three approaches
to communications If this type of interface does not exist on a de-
velopment platform, it can be built from what is
between distributed available today: RPC on AIX, APPC in SAA, NetBIOS
functions. (local area network basic input/output system) on
a LAN, or TCP/IP, which is available on all SAA and
AIX environments. If the API does exist (remote
data and print services on a LAN), then it should
be used. The objective is not to reinvent the
wheel, but simply to place a layer of code be-
him or herself as a host programmer or a PWS tween the application functions and the underly-
programmer? If the developer asks, "What func- ing communication transport so that the transport
tions should I move down to the workstation?" can change across environments and the applica-
then the developer is probably a host program- tion is not affected.
mer. Workstation programmers are looking at
what function to distribute up to the host. How Redirection. Environments that employ redirec-
the developer thinks will no doubt influence the tion as a distribution means are the most trans-
developer's decisions on where to place function parent. An example is a virtual file on a LAN.
and data. It is well to be aware that there is an Redirection allows the application to access data
alternate view of the world, in which the host as if the data were local when they are actually on
computer is sometimes not the obvious place to a remote server. If the network can absorb the
run the bulk of the application. traffic of multiple single I/Os, then the system will
perform, but this approach does not allow for up-
Distributed design considerations. There are three ward scalability. What if this same application
approaches to communications between distrib- were run outside of the LAN environment where
uted functions. One uses multiple conversations there are no redirection services or where not
based on a program-to-program communications enough bandwidth exists to use those services?
protocol such as APPC. This requires both func- One must be able to take an application that pro-
tions to be executing at the same time in a "syn- cesses 100 transactions per minute today and use
chronous" fashion. Another uses a messaging it in 10 000 transactions-per-minute environments
model, such as a datagram, which requests a ser- tomorrow, without rewriting the application be-
vice. This service mayor may not be running at cause of redirection at rates that can no longer be
the same time the request is made. When the ser- handled by the underlying topology. The designer
vice processes the request, it sends back a reply, must be sensitive to bandwidth considerations
if any, as another message to the original re- when using redirection as a distribution mecha-
questor. This requires a queuing mechanism that nism. A more robust mechanism is to use some
can store messages and ensure their delivery. The form of distributed data service.
third is to design a requestor/server interface to
act as a remote procedure call (RPC) on behalf of Requestor/server. We now examine the building
the application. This design allows calls for a ser- of a requestor/server interface in more detail.
vice similar to local function calls within the ap- From the software design shown in Figure 6 one
plication. It looks like a local procedure call to the can see a server program on the back-end pro-
application, and the distribution is transparent. cessor, which sits and waits for commands from

574 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 6 Example requestor/server interface

A DATA
REQUESTOR SERVER ~

n, REQ(A,p)
- APPC(TP,A,p)
CASE A:
CALLA(p)
- S

CASES:
CALLBO C
APPC(TP,B)
--z.-

ur
CASEC:

•••
-
REa(e,i)
~ APPC(TP,C,I)

OTHER X

~
- X

the requestor program on the rws. This particular The result is a callable interface that keeps the
example uses APPC as its communications proto- communications transparent to the user program.
col. The user should architect personalized com- A programmer writes the APPC code once, and
mands to perform the functions needed and pass everyone else uses that interface. In environ-
the parameters along with the command. The ad- ments where there exists a remote procedure call
vantage is that programmers only have to learn (RPC) interface, such as with TCP/IP, this layer of
the command set that is implemented, not the un- code mayor may not be necessary, depending on
derlying APPC. The APPC could be changed to whether the programmer may want to move the
TCP/IP or RPC and not affect the calling application application to other environments that may not
functions. have TCP/IP available. If so, RPC would be substi-
tuted for APPC and the original interface syntax
left the same.
In the example, a request is being made for func-
tion A to be performed passing a pointer P as a Conversational. If the requestor/server approach
parameter. The requestor code would then take is not appropriate for the given application, then
the data pointed to by P and ship it via APPC to the one may want to implement a simplified verb set
server function. The server code is just a router interface to APPC for programmers to code to (i.e.,
switch that calls the actual function on the host, START, STOP, SEND, RECEIVE, ERROR_CHECK,
passing it the parameters shipped to it by the re- TOGGLE_STATE). This way only a few program-
questor function. When the function is complete, mers have to write the error handling code in APPC
the server code will return the results to the re- and everyone else uses a higher level API to access
questor code via APPC, which would then place it them. Finally, if this does not yield enough func-
back into a data structure so that the application tion for the program the programmers will have to
code could extract it via a pointer. This is how the code at the native APPC level. This is not as de-
Server Requestor Programming Interface (SRPI) sirable because it makes the application "plat-
works on PC-DOS and OS/2 via LV 2 communica- form-specific" and it will not move easily to other
tions instead of APPC. environments.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 575

 Rules for data placement servation then, is to change the way we think
about data sharing.
A common question that developers ask is, "How
do I determine data placement?" The use of dis- Now, consider the following example: An order
tributed data promises access to local data regard- entry application running on one centralized pro-
less of where the data are placed in the network, cessor probably views an order in process (one
but what are the performance implications of ac- being entered into the system) as data that are
cessing data remotely? The following are some shared by the corporation. After all, someone in
simple rules-of-thumb for data placement. another department is probably taking that order
and filling it somewhere else in the enterprise.
Data placement is a function of the following pa- Based on this fact, the data may be thought to be
rameters: shared at the corporate level. Now, consider the
ownership and level of sharing of the data.
• Level of sharing
• Update/access frequency (timeliness) How was order entry performed when a manual
• Security system was employed? Probably a physical paper
• Capacity invoice was thought of as a private piece of work
• Business needs until the clerk actually sent it off to be processed.
Once submitted, the ownership and level of shar-
ing changed based on whose desk it landed on
If other contributing factors for data placement
exist in the enterprise, then these factors should next. Therefore the order can be thought of as a
private piece of work, and thus is private data to
be added to this list as considerations.
the order entry clerk until the order is ready to
submit for processing. So the question is not so
Optimally, data should not be moved. If the plat- much, "Are the data private?" as it is, "Can the
form in use has distributed data services, then this data be thought of as private for that application
may be the easiest way to design the application. function?" If so, that function should treat the
It may not, however, yield the most robust design data as a private entity and work with the data on
or even perform well, unless there is network the rws.
bandwidth to support the data traffic. Networks
with low latency such as LANs are much more Data ownership must be evaluated and it must be
forgiving than WANs. brought down to the personal or work group level
where ever possible. If all the data remain on a
Given the lack of bandwidth to support distrib- central host processor, the processor may not
uted data for a specific application function, for yield optimal performance for distributed data ac-
performance reasons the data should be placed as cess.
close to the user as possible. On the other hand,
the data may be required to be in a central place Update/access frequency. There will be times
for sharing reasons. The key is to find a solution when data really are shared at a corporate level.
that satisfies both requirements. Then to get that data to a lower level, the follow-
ing questions should be addressed:
Level of sharing. The first step is to get the data
placed at the lowest level that meets the applica- • How often are the data accessed?
tion's sharing requirements. If the data are pri- • How much is required?
vate, keep the data at the workstation. Data that • How often are the data updated?
are shared at the department or work group level • How critical is it to have the latest copy of the
should be on departmental or work group sys- data?
tems, usually on either a LAN or midrange system.
Data that are shared throughout the corporation How often are the data accessed? If the data are
should be on a central host processor. This not accessed very often by an application, then a
sounds very simple in theory, but when an ex- remote request can be used to get to the data on
amination is made of the existing applications, it the host. Using some form of distributed data
is easy to think that most data are corporate data. services is the easiest way to access remote data.
That does not help in this equation. The first ob- There still will be times, however, when distrib-

576 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

uted data are not the right solution. If the data are more. At that point, it is well to back up one step
accessed often, or the amount of data requested to set the ultimate timeliness required for that
cannot be accurately determined, distributed data data. If technology allows the delivery of better
may have a serious performance and network im-
pact. If this is the case, the developer might con-
sider downloading the data to a lower level plat-
form.

How much is required? If downloading is chosen,

It is important to keep one's
the next question is how much should be down- focus on the business problem
loaded? If only an extract is needed, then extract that is being solved.
and download only the data needed. If the whole
database is needed, how often is it updated?

How often are the data updated? If the data are

not updated that often, perhaps a snapshot is re- results, fine, but what the user views as timely
quired that is refreshed when the data are re- and what the business demands may be two dif-
freshed. If the data are updated often, and re- ferent things. Keep focusing on the business need
freshing at the same rate of update is not feasible, for current data.
then the question arises as to how critical it is to
have the latest copy. Security. Security is a concern when dealing with
multiple copies and extracts. The obvious rule of
How current are the data? In a personal experi- thumb is that if the platform being extracted does
ence, the author worked with one customer on not meet security requirements, the data must be
the design of an executive information system. In kept on the next upstream host that does meet
this application the data were being used for trend those needs. The classification of data is impor-
analysis. The designers insisted that the execu- tant.
tives needed the latest data. But, how current did
the data really need to be? It is always nice to For example, consider a personnel database. If
have current data, but when comparing quarter- the database contains a field for employee's sal-
to-quarter, or even week-to-week, how much im- ary, which is usually considered confidential, the
pact will last night's data have compared to in- whole database would be labeled confidential.
cluding this morning's data too? For most The rule-of-thumb has always been to classify the
applications that show trends, last night's data are database at the level of the highest element. When
good enough for weekly trends and last week's taking extracts of this personnel database, what is
data may be good enough for quarterly trends. the security level of the extract? To say the entire
We need to think about how timely the data really database is confidential would be excessive. If all
need to be. that is extracted are names and addresses, then
the extract may not be confidential. This implies
If the data are updated often and current access that the developer must assign security at the
to the whole database is needed in real time, then "field" level for databases that are being ex-
there are two options: Either leave the data on the tracted.
host and split the application so that the functions
that manipulate the data execute on the same host Capacity. Capacity is becoming less of an issue
as the data, or re-evaluate the need for current these days. As disk space on PWSs and LANs in-
data and ask these same questions again. creases, there is more we can store for use at the
personal and work group level. The data to place
It is important to keep one's focus on the business at lower levels in a network should be files like
problem that is being solved, not the technical rate tables, schedules, and any type of reference
problem. The end user should be asked to clarify item that does not change too often. These are
the business need for timely data. Can the end generally small enough to fit in a LAN or PWS envi-
user use yesterday's data? Last week's? Last ronment and are read-only items, so there are not
month's? At some point the business process many data synchronization problems to deal
breaks and the business need is not satisfied any- with.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 577

 Figure 7 Function placement methodology cations duplicated at each workstation. Installing
LAN servers is a good way to solve workstation
capacity problems in a workstation-to-main-
frame-only environment.

FOR EACHUNIQUE USEROF THE APPLICATION: Business needs. There may be business needs for
1 DEFINETHEOBJECTS THE USERCAN MANIPULATE
data placement. A company may have a need to
decentralize and want all databases to be man-
2 DEFINE THE ACTIONS ALLOWED ON THOSEOBJECTS aged on a midrange or work group LAN system.
3 CREATEAN OBJECT/ACTION MATRIX Or there may be a policy that all data are to reside
4 SHOWHOWOBJECTS ARE RELATED TO ACTIONSBY
in one location for ease of backup, so centraliza-
PLACING Xs WHERETHEY INTERSECT IN THE MATRIX tion is key. Whatever the need, the business need
must be balanced with what is available via cur-
5 DETERMINE DATAPLACEMENT BASEDON SHARING,
UPDATE, SECURITY, CAPACITY, AND BUSINESS NEED rent technology to satisfy the local data require-
ments. Quite often, the business needs prevail
6 USINGTHE OBJECT/ACTION MATRIX, UNDERSTAND
THE MESSAGE TRAFFICBETWEEN: and data placement will be determined by factors
-THE END USERANDTHE APPLICATION outside of the application. In these cases, trade-
- THE INTERNAL APPLICATION FUNCTIONS
- THE APPLICATION ANDTHE DATA
offs must be made as to where to place the ap-
plication function given the current data place-
7 DETERMINE FUNCTION SPLITBY FINDING THE POINT
WITH THE LOWEST TRAFFIC(NOTE: THIS MAY
ment.
INCLUDE NO SPLITAT ALL BY USINGSOME FORMOF
DISTRIBUTED NETWORK SERVICES)
Determining function placement
8 REPLACE EACHX IN THE OBJECT/ACTION MATRIX
WITHTHE NAMEOF THE PLATFORM ON WHICHTHAT
FUNCTION SHOULD EXECUTE
The general rule for function placement is to keep
the function near the object it manipulates. If the
9 REPEAT PROCESS TO A GREATER LEVELOF 'ACTION'
DETAIL
function manipulates screen objects, it is kept on
the workstation where the display is being done.
If the function manipulates data objects, it is kept
on the node with the data. This can best be shown
by using an application sample, applying the rules
for both data and function placement as previ-
Table 1 Database descriptions ously discussed. A tool called an object/action
matrix is introduced to help determine the best
Database Description platform for function placement. The steps for
determining function placement can be seen in
Customer details Company-wide customer
information Figure 7.
Inventory of parts Warehouse inventory
Price catalog Company-wide prices for parts We now take a set of functions in a sample ap-
Daily orders Current orders in process plication and apply this methodology. The exam-
Pending orders Orders committed but not filled
ple is the order entry function of a parts supplier
warehouse. It is important to note that this ap-
plication may, in fact, perform more than just this
The rule-of-thumb is: if the developer determines one function or be used by more than one user
the best placement for data, only to find that there group. This methodology takes the perspective of
is not enough capacity for the data on that plat- a single user of the application for a particular
form, then the developer must either increase the application function. In the example we are only
capacity on that platform or move the data back concerned with the order entry function. There
to the next up-stream platform that has the ca- may also be an order analysis function or an in-
pacity. In a distributed environment, LANs play ventory function, but the order entry clerk does
an important role to fill the resource sharing role not use it in the process of taking an order. Those
that mainframes now perform. It does not make functions should be addressed as a separate ma-
sense to have 500 workstations directly attached trix. The key is to break the functions down into
to a mainframe, with 500 copies of all the appli- simple steps.

578 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Table 2 Work flow

Step Procedure Name Description of Activity

Get a form CREATE a blank order form (invoice)

2 Take customer details New customer? CREATE information and ADD to customer file
Existing customer? SEARCH customer file, verify information, and UPDATE if necessary

3 Enter parts needed SEARCH catalog file for part

ADD to invoice

4 Check inventory SEARCH inventory file and UPDATE accordingly

5 Check customer credit CHECK total amount of order and any pending order against credit
If OK, process order
If not, cancel or SAVE invoice for later approval

6 Process order ADD invoice to pending order file

These steps should be performed for each user of enter an order into the system can be seen in Ta-
the system. It is very important to take one user's ble 2. In computer terms, getting a form is simply
view at a time. One matrix is made for the order creating a blank order form that will become the
entry clerk and another for the stockroom clerk. invoice. Taking the customer details involves two
Trying to combine several user's views of the bus- options. For a new customer, the clerk creates
iness in one matrix yields too much detail. the information and adds it to the customer file.
For an existing customer, the clerk searches the
For a new system, the first step is to gather re- customer file for information and verifies over the
quirements. For modification of an existing sys- phone that the information is still correct; if not,
tem, however, there may be a tendency to assume the information is updated, if necessary. In both
that the existing application functions are the base cases, this information is added to the invoice.
requirements. This is a dangerous assumption.
Perhaps the existing functions perform as they do
Next the clerk asks the customer for the items to
because of the limits of technology 10 or 20 years be ordered, searches the catalog for the parts and
ago when the application was first written. The
adds them to the invoice. At some point the clerk
developer should take the attitude that he or she
will check the warehouse inventory to make sure
is designing a new system and gather the user's
the parts are available; to process this order the
requirements for existing functions all over again.
clerk will need to update the inventory accord-
When technology poses limitations, we tend to ingly to commit those resources. The clerk will
make the requirements fit the solution. Taking a
also want to check the customer's credit against
new look at the application ensures that the so-
the final invoice amount to be sure the customer
lution will fit the requirements.
is in good standing. The algorithm for this is sim-
ple: Check the total amount ofthe order, plus any
Work flow and data definition. The first thing we
pending orders the customer has not yet been
need to do, as in any application design process,
billed for, against the customer's credit limit. If
is to understand the current business process. In
the credit is good, then process the order; if not
our example, this is the order processing proce-
the clerk may want to save the order details for
dure. The data associated with entering an order
further credit authorization from a manager or
can be found in Table 1. We start with this ex-
supervisor.
ample and decide how we can make use of dis-
tributed processing.
Finally, when the checking is complete, the clerk
In response to a phone call from a customer the processes the order by adding it to the pending
order entry clerk begins the order entry process. order file. Each action in the activity portion of
The steps that the order entry clerk follows to Table 2 is highlighted by using all uppercase let-

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 579

 Figure 8 Object/action matrix

OBJECTS

ACTIONS
CUSTOMERS INVENTORY PRICE CATALOG DAilY ORDERS PENDING ORDERS
~
CREATE
~ ~
SAVE/RESTORE
~
UPDATE
~ ~ ~
SEARCH
~ ~ ~ ~
ADO
~ ~ ~
CREDIT CHECK
~ ~ ~

ters. This defines all of the actions the order entry would be the order entry clerk's "database view"
clerk performs. of the customer file.

Object/action matrix. Now that the actions that On the left side of the matrix are listed all the
are carried out during the order entry process actions that are allowed on those data objects by
have been defined, and the data files are identi- the clerk. The terminology used for these actions
fied, it is time to understand the interaction be- is not of primary importance. It is best to use
tween the two. By thinking of the data as "ob- colloquial terms that reflect the user's perspec-
jects" and the things done to the data as tive. While it is very easy to get caught up in the
"actions," a matrix can be built to show the in- definition of terms, what is important is that the
teraction between the two. We call this the ob- clerk has logged the action needed.
ject/action matrix (see Figure 8).
Once the matrix is set up, we place an "X" in each
Across the top of this matrix are listed the data box where an action is allowed on an object, to
objects that the order entry clerk is allowed to show a relationship between the two. This serves
manipulate to process an order. These objects are a dual purpose. First, the developer can quickly
defined at the database or file (record) level for see which functions will need to be written. Sec-
simplicity. In reality, objects may have to be de- ond, the developer can see that actions like
fined at the field level. Perhaps the order entry "search" and "update" are used quite often. This
clerk is not allowed to see all the information in is an indication that some code can be reused by
the customer file. In this case the data object making the core of these functions generic enough

580 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

to be used by multiple data objects. This could night. Also there will be updates during the day as
mean a tremendous savings of programmer time new customers call, so it is necessary to keep it
for the project. synchronized with the other order entry depart-
ment LANs throughout the day.
For the first pass, the developer should start with
data objects and broadly defined actions. It is best The next choice is to try to extract a subset of the
not to get too entrenched in detail the first time data. The designer wants to find some subset of
through. This is an iterative process that will be the data that may not change very often. Analyz-
repeated several times, refining the actions to ing the demographics of the customers, the de-
smaller entities until the developer is left with the signer may find that because they are retailers
actual functions (i.e., subroutines) that will be who depend on the warehouse for a steady flow
coded. of parts, 90 percent of the customers are return
business. This means that 90 percent of the time
Current data placement. At some point the de- the calls are from customers within the local re-
veloper must look at data placement. We assume gion. Therefore, an extract can be taken of the
that most companies already have their data de- regional customers from the corporate database
fined. If this is a totally new application, then the down to the LAN server. This subset would not
system designer will have to perform normal data take up as much LAN resource and would take less
modeling before going on. The current data place- time to refresh. For the remaining 10 percent of
ment for the sample corporation is shown in Fig- outside and new customers, the system would use
ure 9. remote data access to the host that contains the
master file.
In the sample, corporate headquarters maintains
its own computer with the master copies of the This is an example of how the solution may ac-
customer details file and price catalog for the en- tually be a combination of data access techniques.
tire company. There are three regional ware- The system assumes a 90 percent hit ratio on the
houses, each having its own host computer that LAN. If a customer calls who is outside the local
has a copy of the corporate customer details and region, the system is willing to take the additional
price catalog, along with its own inventory of communications overhead of distributed data ac-
parts, pending orders, and daily orders that are cess across a WAN to the host database, because
maintained for the warehouse. The host computer this should only be 10 percent of the time. Also,
is the warehouse computer. when a new customer calls, the host is updated
immediately so that other LANs will find them if
they call back twice within the same day (i.e.,
The order entry department is one of several or-
between LAN refreshes).
der entry departments connected to the ware-
house host via a LAN. This LAN also has a file
server attached that is currently unused by the The inventory of parts is shared by the whole
existing application. warehouse and is updated in real time to reflect
the current parts committed to orders and parts
Data placement scenario. It is now time to make remaining. Trying to manage distributed updates
a decision about data placement in our sample. in a real-time system across multiple LANs is not
The options for placement are the warehouse recommended since the developer has to write all
host, work group LAN, or personal rws. We take the synchronization code. It would be easier to
each data file and analyze it using the rules out- keep this file on the host and distribute the ap-
lined earlier in this paper. The results are dis- plication functions to access it so the system
played in Table 3. Following is a discussion of the would have the host integrity that is needed for
data objects. real-time updates at the warehouse level.

The level of sharing for the customer details file Although the price catalog is another file whose
is at the warehouse level so the tendency is to sharing scope is company wide, it is only updated
leave it on the warehouse host. It is updated daily weekly, so we download a copy to the LAN server
and the system may not have the capacity on the and access it via a remote server function or lo-
LAN server to download it and then refresh it each cally from the rws. Since the order entry clerk is

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 581

 Figure 9 Current data placement

- MAINTAINS CORPORATE
HOSTSYSTEM CUSTOMER DETAILS

PRICECATALOG

CUSTOMER DETAILS

PRICECATALOG

INVENTORY OF PARTS

- THEREARE 3 REGIONS
- EACHMAINTAINS ITS OWNHOST PENDING ORDERS

DAILYORDERS

- ONE OF MANYO.E. DEPARTMENTS

- CONNECTED TO HOSTVIA LAN

IIIIIIIIIIIIIIIIIIIIIIIIII
-11111111111111111111111111

::.-----1B IIIII1
IIIII1
TOKEN-RING
LAN

582 ROFRANO IBM SYSTEMS JOURNAL. VOL 31. NO 3. 1992

Table 3 Data sharing vs timeliness

Data Objects Suggested Placement Suggested Access

CUSTOMER DETAILS Extract for warehouse and download to Local access to extract
Shared by company LAN server (access too frequent for Use remote data access for exceptions
Updated daily remote data access)

INVENTORY OF PARTS Maintain on host (extraction and update Split application

Shared by warehouse not feasible)
Updated in real time

PRICE CATALOG Batch download weekly to LAN server Local to LAN server
Shared by company
Updated weekly

DAILY ORDERS Maintain on PWS Local to PWS

Private to order entry clerk
Updated in real time

PENDING ORDERS Maintain on host Batch upload at predetermined intervals

Shared by warehouse
Updated as needed

not allowed to update prices, the database is a livery and a three-day backlog exists, then one
read-only database that should not be a problem, must ask if a batch update at the end of the day
given that the system has the disk capacity on the is really going to cause an impact. In the sample,
LAN server. This is the approach that should be this company's policy is the latter, so the decision
taken for most read-only files like rate tables and is to keep the pending orders file on the host for
other static files. We get them as close to the user sharing reasons, but add to it from the daily or-
as possible for performance and refresh them only ders file on the PWS in batch mode each evening.
as needed.
This is a case where the designer questions cur-
The daily orders file is created on the host and rent practices based on business need. It may
stays just long enough for some authorization pro- have been easy to design the application with
cess before it is appended to the pending orders real-time updates in the past because the appli-
file. The file is currently viewed as data that are cation ran on one system, but was there a busi-
shared at the warehouse level because other ness need for it? The author strongly suggests that
workers need to share the data for authorization designers look at the business requirements and
purposes or to fill the order. As suggested earlier, not rely on how the previous application handled
while the data are in the hands of the order entry a particular problem.
clerk, they can be viewed as private data until
ready for submission. It is for this reason that we New physical layout. Figure 10 shows the new
place the data on the workstation and then add the physical layout of the data placement. The parts
data to the pending orders file at some predeter- inventory file is maintained at the host, as is the
mined interval. pending orders file. Rather than updating the
pending orders in real time, we batch and upload
Since the shipping department needs the pending the updates on a daily basis. A full copy of the
orders file to fill the orders, it is shared at the price catalog is downloaded to the LAN server, as
warehouse level. The developer could also prob- well as a regional extract of the customer details
ably add to it in real time from the daily orders file file. The daily orders are maintained on the PWS
today, but does the business really require real- until they are batched and uploaded to the host.
time access? If the business policy is next-day
shipping, then perhaps this is true, but if the bus- Application function placement. Now that the
iness policy is to allow six-to-eight weeks for de- functions (or actions) that need to be written have

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 583

 been identified and the designer has taken a first All the information for an order is taken over the
look at data placement, the designer can begin to phone, and the capabilities of the PWS are used to
look at where to place those functions in the en- enter it and edit it. When the processing is done,
terprise. Using the object/action matrix, the lo- the new record must be added to the database.
cation of the data objects is added at the top of the Because the system is in a distributed environ-
chart. Now for every "X" made in the matrix, the ment, protection against two people adding the
designer must go back and determine the location same customer at the same time must be ensured.
for that function, based on the message traffic it It is for this reason that the ADD function (the
generates to manipulate its data. Keep in mind actual adding to the database) is placed on the
that almost all of these functions will have a PWS host for execution. This allows the integrity of the
component to trigger them off. What is being de- host system to perform this function. Likewise if
termined here is where the "core" function will there is any updating of the customer's existing
execute. record to be done, this should take place on the
host also to allow record locking or what ever is
needed to ensure integrity. Because a full copy of
the customer database is not available at the LAN
Remember it has been stated that the function server, the SEARCH function must be written for
should be placed close to the object it manipulates both the LAN and host environments.
for good performance, preferably on the same
processor. It is unlikely that anyone will debate The inventory file is a rather simple matter. Since
that any code that interacts with the end user be- we elected to maintain this purely as a host file,
longs on the PWS. The problem is with code that the UPDATE and SEARCH functions are placed on
accesses data. The question is when to use dis- the host with the data. It will be necessary to
tributed services and when to move the applica- architect a way to invoke these host functions
tion function. This can only be determined by un- from the rws later. Remember each of these will
derstanding the amount of traffic caused by a probably have a rws component even though the
transaction and whether the distributed service, core function runs on a host.
line speed, and network bandwidth are sufficient
to handle it. Since tools are not available to mon-
The price catalog is really a read-only file for the
itor the physical traffic caused by transactions, all
order entry function, so the SEARCH function is
this is based on manual calculations using the size
placed to access the catalog on the rws and use
of the data record, communications link, and ap-
the distributed LAN services to access it via file
proximate frequency of access. By using the ma-
redirection or distributed structured query lan-
trix a column at a time, leaving the credit check
guage (SQL). It is possible that many people
function for last, we obtain the results shown in
searching this file at the same time on the LAN
Figure 11.
may cause too much traffic even for NetBIOS. If
this happens, the SEARCH function should run in
the LAN server machine and requests should be
made from the PWS.
The customer file has a regional extract on the
LAN server and a full copy on the warehouse host.
The CREATE function can be written on the PWS to Since the daily orders file is really private data to
take advantage of the graphical user interface and the order entry person until it is ready to be sub-
excellent editing capabilities of the workstation. mitted, all functions that manipulate this file are
Keep in mind that wherever possible the designer placed on the PWS and then the results are batched
will rethink data ownership and scope of sharing and uploaded to the pending orders file. Also,
so the designer can consider a new customer since multiple departments need access to the
record a private work until it is completed and pending orders file at the warehouse level, the
submitted for processing. Also keep in mind that function that manipulates this file resides on the
when the word "create" is used, it is not the in- warehouse host with the database.
tention to conjure up any database definition of
what create means. It simply means to collect the Example: Credit check function. The credit check
information about a new customer that is needed function is left until last for a reason. There are
for the customer file. two possible ways to implement this function, as

584 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 10 New physical layout of data

INVENTORY
CUSTOMER FILE
FILE
(MASTER)

PRICE CATALOG
(MASTER)

PENDING
ORDERS

BATCH

BATCH BATCH
DAILY DAILY WEEKLY
ORDERS

[~

~
I I I I I I I I I I I I I I I I I I II I I I I I I
~ 111111111111111111111 PRICE CATALOG
(FULL COPY)

.>--""" 111I11

I11111
TOKEN-RING
LAN

CUSTOMER FILE
(REGIONAL EXTRACT)

shown in Figure 12. Since the customer file and that the traffic is too much, this is not a good
the daily orders file are both on the PWS, the func- choice.
tion can run on the rws and access the pending
orders file remotely. If this is not a lot of data, this This is an example of how using some form of
may still be a good idea; but if the data are too remote request works to a point. If the system is
large, or the frequency of credit checks is such in a small company that does not have many

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 585

 Figure 11 Object/action matrix with function placement

OBJECTS
/-:--'"""" ,f~H -, ": I, '.'fjll'l' ,'Ct •• ',., "
DATA
CUSTOMERS INVENTORY PRICECATALOG DAILYORDERS PENDING ORDERS PLACEMENT
(LANSERVER) (HOSTS) (LANSERVER) (PWS) (HOST)
ACTIONS (EXTRACT) (FULLCOPY)
,
~
, , .': '"
" ";';', '
"
' "'e
_" ~t

CREATE PWS PWS

LI
SAVE/RESTORE PWS

UPDATE HOST HOST HOST

SEARCH LAN/HOST HOST PWS/LAN HOST ,

ADD T HOST PWS BATCH

U P.-:-
>
CREDITCHECK '. HOST HOST HOST

BASEDON MESSAGE TRAFFIC CAUSEDBY ACTIONS

pending orders, this method might work fine; but transaction rates and is preferred for this partic-
if we have a large corporation with hundreds of ular type of request.
pending orders, this method might break if the
data coming across the link from a distributed
request are too much to handle. This is not a ro- It is important to only use distributed data in a
bust design. line-of-business application when one can safely
predict or limit the volume of data to be trans-
A better solution is to write the credit check func- mitted from a given request. The network may be
tion to run on the host with the master customer able to absorb a few ad hoc queries, but busi-
file and pending orders file. After all, the only nesses do not want all the order entry people mak-
thing needed from the rws is the customer num- ing voluminous queries all day, every day, for
ber and the amount of the invoice. The only re- every customer invoice.
sponse required is the customer number and an
accept or reject notification. If the credit check
function is run as an synchronous task, the cus- Methodology summary. To summarize, we start
tomer number is not needed because the user is by taking the view of one end user. This may be
waiting for the answer. This also eliminates the the data entry person's view, the analyst's view,
worry of how many data are returned from the or the executive's view, but we hold to that view.
credit search, because this is all contained within We then go back and make a new matrix for each
the host environment (i.e., the size of the results different user of the application, avoiding the
are always predictable). This design will not be temptation to combine all actions and objects for
affected by a growing order backlog or increased all users into one large matrix.

586 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 12 Credit check implementation

IIETHOD1

- ACCESS HOSTDATABASE REMOTELY - SENDCUSTOMER NUMBER AND DOLLAR

VIA REMOTE REQUEST AMOUNT TO APPL HALFON HOST

- PROCESS RECORDS FROMREMOTE - HOSTPROCESSES REQUEST AND

HOSTVIA CODEON PWS RETURNS ACCEPT/ REJECT

PWSAPPLICATION HOSTAPPLICATION

INmALIZE CONVERSATION ACCEPTCONVERSATION

ALLOCATE
CUSTNO, AMOUNT
SENDRECORD RECEtvERECORD

CALLCREDITCHK
CUSTNO, YES/NO
RECEIVE RESULT SENDRESULT

••• •••
DEALLOCATE

First define the objects that the user can manip- Now the designer is ready to analyze and under-
ulate. These should not be restricted to data ob- stand the message traffic between the end user
jects, as in the example. Data objects can also be and the application, application-to-application,
defined at the record or field level if needed. In the and the application and the data. The traffic be-
example they are defined at the database level for tween the application and the data is probably the
simplicity, but in reality some people may not highest. This is why we suggest that the parts of
have access to a whole record. the application be kept close to the objects they
manipulate. If one is manipulating a screen ob-
Once the objects are defined, next define the ac- ject, keep the code on the workstation; if one is
tions allowed on those objects. These can be de- manipulating a data object, keep the code on the
rived from an examination of the work flow, much processor that contains the data. Also, be very
the same as one would do for any application de- careful to understand the size of the results from
velopment. What is important is the next step, a distributed request if distributed access is the
which is to define how the objects and actions are preferred choice. Since the traffic between the
related through the use of an object/action matrix. application functions is probably the lowest, the
designer will want to choose a point within the
application that makes sense to distribute.
At this stage, examine the data placement and see
if the data can be placed as close to the user as Once the matrix is built, the designer must ex-
possible for performance reasons. Remember, plore the possibilities for making the connections.
data placement is primarily a function of sharing.
It is desirable to keep the data at the lowest level Checklist for getting started. A checklist for get-
of sharing possible. Go back to the object/action ting started is shown in Figure 13. First and fore-
matrix once this is done and add the location of most, assemble a team with the proper skills. The
the data under each object heading. core team should consist of three to five of the

IBM SYSTEMS JOURNAL, VOL 31, NO 3. 1992 ROFRANO 587

 Figure 13 Checklist for getting started Having an action bar that controls the pop-up
windows with no code behind them will give the
user a good feeling for how the application will
flow. Since functions will be more atomic in this
object/action environment, you can plug the func-
~
ASSEMBLE TEAM
WITH tions behind the windows later with greater ease
REQUIRED SKILLS than in the old hierarchical model, where the
- CORETEAMOF TECHNICAL PROGRAMMERS (3-5 PEOPLE) function called the user interface rather than the
- FOUR-MONTH LEARNING CURVE reverse.
- OS/2AND GRAPHICAL USERINTERFACE DESIGN
- HOSTBACK-END EXPERIENCE
- APPC1NETWORK
Take one distributed function and code it from
start to finish. Then use it on a "real" network to

~
SELECT
RIGHT
understand the implications of network traffic.
APPLICATION Network traffic is going to change. We used to
- ONETHAT LENDSITSELFTO EXPLOITING CAPABILITIES
think of PWS traffic as infrequent but occurring in
OF THE PWS large chunks. This is because we mostly down-
- DO NOT RECODE AN OLD APPLICATION TO DO THE SAME
FUNCTION
loaded files, worked with them, and uploaded the
- BE INNOVATIVEI results. The trend in distributed processing is to
• USE DIRECTMANIPULATION have a much shorter message duration but with
• ADDGRAPHICS REPRESENTATIONS TO DATA
• EXPLOITMULTITASKING CAPABILITIES OF OS/2 increased message traffic. This can be equally
devastating to a network. It is better to work on
one function and refine it until the calculations for
~
BUILD
A WORKING traffic can be trusted, than to code all functions
PROTOTYPE
first and then find out the network cannot handle
-
-
BUILDAND AGREEON USERINTERFACE FIRST
USE'REAL' FUNCTION ON 'REAL' NETWORK
the result in final test stage.
- SKILLSARE ACQUIRED DURING PROTOTYPE PROCESS
- CODECAN BE USEDIN FINALAPPLICATION
Skills are acquired during the prototyping pro-
cess. Although you may need to recode your first
prototype, most others can be used in the final
application. An object/action application is de-
signed with the user interface (objects) first and
best people available. Allow for a four- to six- function (actions) added later.
month learning curve in the respective areas of
rws, APPC, and host back-end skills.
Conclusion
Next, select an application that lends itself to ex-
ploiting the capabilities of the PWS. It should be When applications are developed that are distrib-
something small enough to manage easily. Do not uted across multiple platforms, there are always
simply recode an old application to do the same tradeoffs to be made. Clearly if one must capital-
function in a distributed manner. No one will see ize on system services that are specific to one
the benefit. Add additional function that exploits platform, the design will suffer if it needs to be
the PWS so people will say, "You can't do that moved to other platforms. Still, distributed pro-
with a nonprogrammable terminal!" Be innova- cessing can be a powerful base for application
tive, use direct manipulation, add graphic repre- design, where the resulting application should
sentations to data that were only shown in tabular provide a better result than could have been
format before. Exploit the multitasking capabili- achieved with either the rws or mainframe tech-
ties of OS/2 so that things like credit checks and nology alone. All this is achievable with today's
table lookups are performed asynchronously and technology.
work goes on in the foreground while back-end
processors operate. Applications can be written to perform well
regardless of the underlying topology. The appli-
Build a working prototype. Because all applica- cation design should provide scalability, accept-
tion function will be driven by the end-user in- able performance, and reconfigurability for future
terface, build and agree on the user interface first. growth in the enterprise. A good application de-

588 ROFRANO IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

sign will work well across a wide range of There he specialized in the support of Personal Computer
usage/loads without change, and execute across a products. In 1986 he became manager of the Information Cen-
ter for the Information Systems and Products group and a year
wide range of configurations. It should also allow later became manager of Customer Services liS at IBM Cor-
flexibility in data placement. porate Headquarters in Purchase, New York. In 1989 he
joined Application Solutions, working in the Cooperative Pro-
While there are considerations today that have to cessing Cluster as a technical planner. He was responsible for
do with bandwidth implications, these can be strategy and plan evaluation of future products that would
enable cooperative processing. During this time Mr. Rofrano
overcome by designing the application to be in- served as IBM's representative to the GUIDE Cooperative
sensitive to network latency by executing func- Processing Project and worked with members of GUIDE,
tions that require high data access of the same SHARE, and numerous other customers on his distributed
platform with the data. design guidelines. Mr. Rofrano received a B.S. in computer
science in 1984 from Mercy College, New York.
As a common remote procedure call becomes
Reprint Order No. G321-5487.
widely available across systems, it will be much
easier to implement distributed applications. In
the mean time, the user can design applications
today to take advantage of tomorrow's technol-
ogy when it arrives.

Acknowledgments
I would like to thank Allan L. Scherr who not only
provided the basis for this work, but from whom
I have learned so much in the time I have worked
for him. I would also like to thank the customers
who worked with me in validating my methodol-
ogy for function placement. Finally I would like
to thank Oliver Simms, IBM United Kingdom
Technical Support, for the use of some of his
charts and figures and for sharing his ideas on the
event-driven application model.
'Trademark or registered trademark of International Business
Machines Corporation.
"Trademark or registered trademark of Microsoft Corpora-
tion.

Cited references
1. SAA Guide for Evaluating Applications, G320-9803, IBM
Corporation; available from IBM branch offices.
2. A. L. Scherr, "SAA Distributed Processing," IBM Sys-
tems Journal 27, No.3, 370-383 (1988).
3. R. N. Manicom, The Mainframe Versus PC Battle, White
Paper, IBM Canada Limited (1990).
4. O. Simms, "The New World," unpublished, IBM UK
Technical Support.

Accepted for publication December 4, 1991.

John J. Rofrano, Jr., IBM Application Solutions, Route 100,

Somers, New York 10589. Mr. Rofrano is currently a senior
programmer on the Application Solutions architecture and
development technical staff and is working on the definition
and implementation of an application services architecture.
He joined IBM in 1984 in the System Products Division in
White Plains, New York, as an information center analyst.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 ROFRANO 589