Designing a distributed application – PB Docs 70

Designing a distributed application

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
  • A news feed service
  • A bond pricing function for a complex investment
  • Account inquiry functions for a banking application
    that provides sensitive information to customers
  • Centralized processing functions for a hotel registration

Document get from Powerbuilder help
Thank you for watching.
Was this article helpful?
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x