Dynamic Clients

The great distinction between Web sites and Web applications lies in the use of business logic. In Chapter 2, the discussions of Web applications and their enabling technologies all centered on implementing business logic only on the server. The client browser was a simple, generalized user-interface device that played no role in the execution of business logic. In the history of Web applications, that model didn't last long. When system designers, especially client/server system designers, recognized the potential of the Web as a serious system architecture, they realized that it might be beneficial for client computers to share in the execution of the business logic. The idea was simple, but some problems needed to be solved, including those of deployment and platform independence

An important concept needs to be made clear when discussing dynamic clients and business logic. Business logic comprises the rules and processes that shape the business state of the system. It is field validations and data systems. For example, the computation of shipping charges is covered by business logic, since it involves the rules of the business, as well as those of the postal service. Presentation logic focuses on making the user interface easy for the user. It may accept any data that contributes to the business state of the system, but it is not responsible for it. For example, the use of a date-picker controla user interface widget that pops up a minicalendar for the user to select a date fromdoes not constitute business logic. It is simply a device to capture user input; the device itself doesn't affect the business state of the system, just the data it collects. The use of the date, in computing an age or an expiration period, however, is business logic.

The simplest examples of business logic on the client are field and form validations. For example, a date entry field should never accept the invalid date February 30th, even though it is entirely possible to enter the words in an ordinary text box. Without client-side validation, this value would be submitted with the form to the server and only there be identified as an invalid value. When this happens, the entire form is usually sent back to the user for correction. This number of server trips is expensive because the time it takes for a form to submit itself to the server, receive processing, and get a response is on the order of seconds, not milliseconds.

In a traditional client/server system the date value would probably be checked as it was entered, when it lost focus, or when the form was completed. The validation of the field would be done by the client machine, possibly by the user interface, because the action does not require server resources. Another option for traditional client/server designers is to use a specialized date input control, one that doesn't accept invalid dates.

It is not surprising that the movement to enable dynamic clients was not originally driven by the need to execute business logic on the client. It, like many other aspects of Web development, was driven by the need to enhance the user interface rendered by Web pages. Many Web users, already familiar with computers, sought some of the features found in their client applications: most significantly, a responsive and dynamic user interface. Plain-vanilla Web pages aren't very dynamic and were never intended to be. Therefore, to give Web surfers new reasons to visit sites and to lay the groundwork for serious use of the Web as an application platform, HTML became dynamic.

A number of technologies and mechanisms bring business logic to the client. These technologies can also be used to enhance the user interface. For the most part, they fall into one of two categories: scripted or compiled. All of them share some features.

• They are associated with the Web page and can access and modify its content.
• They are automatically deployed, or downloaded, to the client computer as needed.
• They address specific security concerns.

When minimal business logic needs to be used on the client, scripting is often an easy yet powerful mechanism to use. When truly sophisticated logic needs to run on the client, building Java applets, JavaBeans, or ActiveX controls is probably a better approach because these environments are more structured and powerful. ActiveX, however, is an option only when the client computers are Windows based. In an intranet environment, this could very well be the case, and such an environment could take advantage of the increased performance of natively coded modules.

For most Web applications, the key to the use of business logic on the client, particularly in the context of HTML pages, is that it has access only to the resources on the client. Implementing a business rule on the client that requires access to server resources doesn't make much sense because the rule can be implemented only by making additional page requests to the server.[1] The business logic that is implemented on the client needs to focus on the manipulation of the data in the Web page itself.

[1] It is possible for client-side components to have persistent and asynchronous communications with server-side objects, however; this type of Web architecture is covered in detail in Chapter 7, Defining the Architecture, and doesn't relate to HTML-page business logic.

Client-side enabling technologies can be sophisticated and highly object oriented if done properly. This depth of functionality is important to keep in mind when designing client-side activity. When giving the client a role in the business, it is essential to do so in a way consistent with the rest of the system.

The manipulation of content and function of the user interface in a Web page is the central focus of client-side scripting and dynamic activity. To truly enable business logicor even user interface enhancementsto be useful, they need access to virtually every aspect of the page they work within. The key to enabling dynamic clients lies in the ability to make Web page content accessible to scripts and modules that can be executed on the client and delivered by the Web page. In keeping with the theme of this book, it is important to recognize that the technologies used to bring business logic to the client must be well understood and incorporated into the application model. Just because an element of the application uses JavaScript to perform some simple calculations on the client but the rest of the system relies on distributed C++ objects and CORBA (Common Object Request Broker Architecture) ORBs (object request brokers) doesn't mean that the script isn't important. If it implements a business rule or process, it needs to be included in the model.