Designing the System Structure › Choose a Client/Server Style › Distributed Processing › When to Use Distributed Processing

When to Use Distributed Processing

Every factor involves a delicate balance between network load, server processing load and server database access that can be altered by locating parts of the logic on either the client or the server.

Distributed processing offers the ability to vary the location of logic and data between client and server to arrive at an acceptable compromise. CA Gen allows such design changes to be made swiftly and with a minimum of effort.

You need to test the effect of the design decisions about locating logic to ensure that the delivered application performs as required.

Use distributed processing when the following factors are true:

• Transaction rates for the application are high—Where transaction rates are high, the processing load on the server can be minimized by locating as much processing as possible to the client. Since every user has an individual workstation, the effect of high transaction rates is dispersed.
• Data volumes are high—The aim here is often to minimize network traffic.

  If a transaction involves retrieving many items of data and manipulating them by some algorithm before selecting a small amount of data, then such manipulation should be located on the server rather than the client if possible.

• The user community is geographically dispersed—Wide Area Networks (WANs) are typically between towns [as compared with Local Area Networks (LANs) within one building or complex] and tend to be much slower than LANs. Therefore, minimizing network traffic may become an important design consideration. In this case distribute the logic so as to minimize the data flow between client and server.
• Integrity and security are critical—Any one server module can be accessed in principle not by just one but by many different client applications. If integrity and security are to be maintained, every usage must be “safe.” If the server module exposes data as in the remote data style, each client application must implement the identical high quality logic to ensure safety. This can be very challenging organizationally.

  However, if the server module is built using distributed processing, the safety logic (integrity and security) and indeed any other common business rules can be located on the server with the data. Access to the data is then allowed only through the server logic.

  Client applications should also ensure integrity and security. But with the recommended approach, there is no reliance on the same high quality and identical logic in multiple client applications.

• Most enterprise—shared databases are best catered for by the distributed process style, for which the remote data style is not usually appropriate.
• Multiple legacy screens need to be associated with one GUI window—The distributed processing style lends itself very nicely to this interworking. Legacy and Current systems residing on hosts or servers contain some logic. Further new logic to support user tasks can be located on the client application that accesses these older modules.