Regardless of which edition of xfNetLink you are using, the only way to take advantage of a distributed processing environment is to use modular, encapsulated code that can be distributed independently in a software system. Modular code is contained in an isolated functional unit with a well-defined, published interface (i.e., an argument list). The published interface tells the programmer how to use the code, and all functionality is provided through that interface. In modular code, routines are usually short and perform single tasks. They do not rely on global data to accomplish their tasks. Data is passed via arguments, and global or common data is kept to a minimum.
Design considerations
If you are designing an application from the ground up, it makes sense to think in terms of completely modularizing your entire system right from the start. However, in many cases, the goal is to improve an existing application or to make only part of your application accessible from the web. If this is your goal, the first step is to think about where you most need the benefits of modular programming. What pieces of functionality do you want to make available on an intranet or the web? What routines can you centralize into a utilities library that can be used by many or all of your applications? Do you want to have multiple user interfaces—perhaps a desktop user interface and a web interface?
In a distributed application, processing is divided into three layers:
- User interface processing occurs on the end user’s machine.
- Business logic processing occurs on the server system. When you’re building a system with xfServerPlus and xfNetLink, this is the xfServerPlus machine.
- Database processing occurs on the database server—the machine (or machines) where the data resides.
Some routines control what the user sees (for example, forms, error messages, and prompts) and other routines handle data access, calculations, validations, report generation, and so forth. When you want to display the result of a piece of application logic in the user interface, the user interface logic can call a function that performs the required task and then display the result.
For example, if you wanted to perform a log-in operation in a distributed processing environment, you would probably separate the processing layers as follows:
User interface processing:
- Draw a log-in screen.
- Perform field input.
- Validate field contents and write error messages to the screen.
Business logic processing:
- Validate the username.
- Validate that the password is correct for the specified username.
Database processing:
- Read user information from the database.
You will likely need to modify your Synergy server code before it can work effectively in a distributed environment. Once you identify the areas where modular programming is needed, you can start redesigning the required functionality with your objectives in mind.
- If supporting multiple user interfaces is your priority, the first step is separating the user interface from the application logic.
- If you want to support multiple databases, the first step is separating the file access from the other application logic.
- If you plan to make your application available to customers on the web, you will first need to modularize the system’s application logic so that it can be called remotely from the user’s browser. Another option is to write a few modular routines that perform the functions you want customers to have access to, and then integrate them into your system at a later date.
As with any other significant code modification, you can handle the move to modularity in chunks, slowly moving your system to a more modular state. Keep in mind that you don’t need to modularize all of your code—just what needs to be called remotely.
Guidelines to improving performance and resiliency
- Minimize the number of trips to the server.
- Minimize “expensive” operations, such as starting your xfServerPlus connection.
- Plan for multiple points of failure.
- When determining what to include in your client-side script, keep in mind that client-side scripts can be edited in a web browser or even disabled by the user. Avoid including business logic that you don’t want the user to tweak.
- Favor client-side processing over server-side processing for simple field-level validations that don’t require server-side data.
- Take into account that information must travel back and forth across the wire, especially for web applications. For example, you should limit the number of records displayed on the user’s browser, or display them in reasonably-sized chunks, rather than sending hundreds of records.
