Designing a distributed application
Before
you begin building an application to run in a distributed computing environment,
you need to design the application. This section provides some general
guidelines for designing a distributed application.
Determine the application requirements
One of the keys to successful application development is designing
what you’re going to build before you begin building it.
The best way to start the design phase is to identify the detailed
requirements that your application must satisfy to meet the needs
of its users.
Use object-oriented techniques
PowerBuilder’s support for distributed computing
is a logical extension of its object-oriented architecture. For
this reason, a PowerBuilder application that uses object-oriented
techniques can be converted to a distributed application with a
minimum of difficulty.
When you’re ready to begin developing a distributed
application, you need to package your business logic in custom class
(nonvisual) user objects. Custom class user objects provide the
foundation for any distributed application. Once you’ve
created your nonvisual objects, you can make the adjustments required for
client applications to access these objects remotely.
Design your objects to run locally
During the early phases of the development cycle, do not design
for the network. At first, distributed objects, like relational
database tables, should be designed with the business requirements
in mind, without regard for physical implementation. Later on, the
design of the objects can be extended to include implementation
details. Designing with a particular network configuration in mind
may limit the amount of flexibility you have later on.
Select remote objects carefully
Any custom class user object can act as a remote object in
a middle-tier server; however, not all nonvisual objects are good
candidates for distributed processing. Since network and server
performance can degrade if too many objects are deployed in remote
servers, you need to be selective about which objects you decide
to make remote.
Consider network latency
Whenever you request services from a remote object, you need
to be aware of network latency issues. Sending data back and forth
over the network inevitably introduces delays in processing throughput.
Therefore, you need to be sure the processing time required to complete
each request is much greater than the latency time introduced by
distributed computing. Otherwise, the use of a remote object may
not be justified.
To minimize delays caused by network operations, try to keep
the number of remote requests to a minimum. For example, avoid putting
remote requests inside a tight loop.
Examples of remote objects
Here are some examples of
business functions that could be handled by remote objects:
- A business reporting
facility - A news feed service
- A bond pricing function for a complex investment
application - Account inquiry functions for a banking application
that provides sensitive information to customers - Centralized processing functions for a hotel registration
system