Island Hopper News uses two clients: an Internet client for the newspaper's customers, and a client written in Visual Basic to the Win32 Application Programming Interface (API) that the newspaper's employees use to update customer records and invoices. Both clients access the same business-services tier components and use the same database.
In Windows DNA, clients do two things. First, they present information to the user. Second, they communicate user input to the business objects that in turn read and write to the data-services tier. Several factors govern whether to use the Web browser or the Win32 API as the client platform. First of all, a Win32 client is limited to computers running Microsoft Windows NT 4.0, Windows 95, or Windows 98. Win32 client applications with DCOM installed can make Component Object Model (COM) calls directly to the business objects on the business-services tier. This reduces the overhead incurred by the involvement of Internet Information Server and Active Server Pages (ASP) necessary in a Web application.
For the Win32 client, the Island Hopper News developers built a forms-based Visual Basic application. The application's forms move data in two directions. Some forms retrieve user input and pass it to business objects to be written to the database; other forms populate controls from the ADO recordsets returned by business objects. The client takes advantage of Microsoft Transaction Server by holding pointers to objects, rather than re-creating the objects each time they are needed. Object references are stored in the form's global variables.
An Internet client provides greater platform independence for an application than does a Win32 client. Applications can be written to what the Web browser supports rather than to the operating system of the client machine itself. Even so, among the available browsers, as well as among different releases of the same browser, there are significant differences that can affect an application's design. For example, it is only with Microsoft Internet Explorer 4.0 or later that you can expect, along with support for scripting, support for dynamic HTML (DHTML) and full compliance with the COM specification. Even if users' computers support the most fully-featured Web browser, their company might restrict them from downloading executable code onto their machines. In short, the issues for Web development are as complex as for any other application. The MSDN Online Web Workshop at http://msdn.microsoft.com/workshop contains a number of resources to assist you in dealing with these and many other Web development issues.
In almost all Windows DNA applications, the information presented to the user and the controls provided for interaction depend on a number of features that span the user-services and business-services tiers. The Island Hopper News Internet client generates its Web pages using a combination of scripting languages and DHTML, hosted in the ASP environment running on Internet Information Server 4.0. The application sends DHTML and JavaScript from the ASP pages to the client until it encounters VBScript. At this time, the application executes the VBScript and sends the resulting DHTML to the client. There is no direct data access between the Web client and the data-services tier; ASP pages retrieve data using business objects and return it to the client embedded in DHTML.
External customers place classified ads in Island Hopper News using the Internet client. Placing an ad requires conformity with a number of business rules, the most obvious of which have to do with customer billing. However, policies regarding ad length need enforcement as well. Marking the ASP pages as transactional ensures that if an object cannot commit its changes, or fails for some reason, the work of any other objects involved can be rolled back to a consistent state. In transaction processing, the enforcement of this behavior is conforming to the ACID properties. The following ASP directive adds transactional behavior to the application:
<%@ LANGUAGE = "VBSCRIPT" TRANSACTION = REQUIRED %>
Transactions protect the application from user error such as submitting a too lengthy ad, as well as from application failures such as an inability to write to the database. Either charging a customer for an ad that was never placed or placing an ad that was never paid for would present real problems for this hypothetical business. Making applications transaction-enabled may cost more resources, but these expenses can easily be justified by the greater assurance of data integrity.