In Chapter 7, we looked briefly at modeling the presentation layer. The primary task during modeling was to document roughly what the user interface of your application should look like and how the user is expected to work through the various screens. You might also have noted some design constraints on your implementation—for example, the presentation layer application might need to run on both Microsoft Windows and Apple Macintosh platforms or the application might need to run over the Internet and use a Web browser interface. These constraints dramatically affect which technologies you use to implement your application.
As we saw in Chapter 1, the Windows DNA architecture supports a wide range of presentation layer types. The two basic categories of presentation layer are native user interfaces and Web-based user interfaces. Native user interfaces rely on user interface services provided by the underlying operating system. On Windows, native user interfaces use the Microsoft Win32 API. Web-based user interfaces are typically based on HTML, which can be rendered on any operating system by a Web browser.
Of course, there are many points between the extremes of pure Win32 applications and pure HTML applications. Win32 applications can host a Web browser Microsoft ActiveX control to gain access to the Internet or to use the Web browser's HTML rendering capabilities. Most Web browsers today support scripting languages so that you can include code within an HTML page that will execute when the page is rendered. Some browsers, such as Microsoft Internet Explorer, let you include ActiveX controls and other COM objects on an HTML page and control the objects using scripting code. Microsoft Internet Explorer 4 and later support the newly emerging Dynamic HTML (DHTML) standard, which lets you dynamically change the contents of a page from scripting code on the client, as well as data-binding, which lets you manipulate persistent data directly on the client.
The presentation layer itself can be distributed. Server-side applications can generate the client-side user interface, which is downloaded to each user's machine at run time. Distributed presentation layers are common for dynamic Web-based applications. For example, ASP uses server-side components and script code to generate Web pages that can be returned to the user machine via HTTP. The Web pages can contain HTML, client-side script code, DHTML, and references to ActiveX controls or other components, just like static Web pages. Since the page is generated at run time, it can be tuned to the capabilities of the user's Web browser. And, of course, the information displayed on the page can be computed by the server-side code.
In the Windows DNA architecture, the entire range of presentation layer types has some common characteristics. The business logic of the application is encapsulated in business layer (middle-tier) components, rather than coded within the presentation layer application. This arrangement makes the business logic easier to reuse if your presentation layer needs to be changed. The presentation layer communicates with the business logic using COM method calls. The presentation layer might also use COM-based ActiveX controls to display the user interface. The same ActiveX controls can be used in native Win32 applications and in Web-based applications running on Windows, so it might even be possible to reuse user interface code between different types of presentation layer applications.
You should consider several factors when choosing the architecture for your presentation layer applications, as listed here:
Let's look at how each of the factors listed above affects your presentation layer architecture.
It is entirely possible that the major decision—native or Web-based—has already been made for you. If one of your application's requirements is that the application must be made available to users over the Internet, a Web-based architecture will almost always be the correct choice. Although you can write native applications that communicate with server-side code over the Internet, when a requirement states that users must be able to access the application over the Internet, most likely the intent is that users must be able to access the application through their Web browsers.
You might also have corporate policies regarding user interfaces for new applications. Many companies are standardizing on Web-based applications because it is easier to teach employees how to access Web pages than how to run multiple native applications. Other companies might have a standard user interface style based on native code applications. This standardization is done to reduce costs. Development costs are reduced by reusing existing code and developer skills. Training costs are reduced because it is easier to teach employees how to use the application. The cost of maintaining the application over time will likely be lowered as well. Thus, if your company has a standard user interface policy, you'll probably know up front whether you need a native or Web-based application.
Firewalls and security policies that might impact communications between user workstations and server-side machines also impact your architecture choices. These issues primarily affect Web-based applications in which users access the application over the Internet. However, the same issues may apply to applications running on a wide area network (WAN).
Server-side machines might be located behind firewalls that permit only certain communications protocols to penetrate the firewalls. User workstations might need to use proxy servers to access remote machines. In these situations, it might be difficult to use DCOM to communicate between the presentation layer and the business layer. Although it is possible to get DCOM to work through a firewall, doing so normally involves modifying the firewall to permit DCOM traffic to pass through. Access through proxy servers presents an additional challenge, since most proxy servers hide user workstation IP addresses. The usual DCOM network protocols need the workstation IP addresses to establish proper communication between the workstation and server machines.
To deal with firewalls and proxy servers, you have four options. First, you can configure the firewall to permit DCOM traffic and the proxy servers to not hide user workstation IP addresses. Normally, this is not a practical solution, since the proxy servers are not likely to be under your control and corporate policy might not permit modifications to the firewall.
Second, you can use the Internet Tunneling TCP/IP protocol for DCOM. This protocol tunnels all DCOM traffic over TCP/IP port 80, which is the TCP/IP port used by HTTP. Most firewalls permit HTTP traffic through the firewall, so the Internet Tunneling TCP/IP protocol avoids the firewall issue. To get through proxy servers, however, the proxy servers must be configured to permit tunneling on port 80. Again, this might not be a practical solution, since the proxy servers are not likely to be under your control.
The Internet Tunneling TCP/IP protocol is included with Microsoft Windows NT 4.0 Service Pack 4 and Microsoft Windows NT 5.0. (Client-side support is also available for Windows 95 and Windows 98.)
Third, you can use the Remote Data Service (RDS). As we saw in Chapter 3, RDS can be used to marshal ADO Recordset objects over DCOM or over HTTP. More generally, RDS can be used to marshal calls over HTTP from client-side code to any server-side business object that exposes an IDispatch interface. This option lets you use the COM programming model but avoids firewall and proxy server issues. You can use this technique from either native or Web-based applications. We'll discuss using RDS to access remote business objects in the section "Using RDS to Access Remote Objects" later in this chapter.
Fourth, you can structure the application so that it doesn't need to make COM calls through a proxy server or firewall. This option normally implies a Web-based application, typically implemented using ASP. The user accesses the application through a Web browser. ASP pages use server-side scripting to create and use business objects and then generate Web pages to return via HTTP to the user's machine. These pages might contain client-side scripts and components, but they would never reference remote COM objects through a firewall. We'll look at how to access business objects from ASP pages in the section "Using ASP" later in this chapter.
In addition to firewall issues, you might have to address security issues. Usually, COM and MTS applications are secured. The caller must be authorized to use a particular component, and each call might need to be authenticated. In Windows NT 4.0, authorization and authentication can be performed only if the caller can provide security credentials from a trusted Windows NT domain. But in Internet scenarios, most users will probably not be part of a trusted Windows NT domain. Essentially, the users are anonymous. If you want to make COM calls from the user workstation to business objects on the server, you will need to configure the server to permit these anonymous users to access your business objects. If this is not acceptable, a distributed presentation layer application that buffers access to your secure business objects through unsecured business objects or ASP pages should be used.
It's important to determine early on which operating systems must be supported by client-side code. If the presentation layer needs to run on Win32 operating systems only, the full range of technologies discussed in this chapter are available to you. If the presentation layer must run on other platforms, you face significant constraints.
First, COM might not be available on one of your target platforms. If it is not available, you can neither use client-side COM objects nor communicate with remote COM objects. Even if COM is available, DCOM might not be available on one of your target platforms. For example, DCOM is not available on Windows 3.1 or Macintosh platforms. On Windows 95, you must install DCOM95 on client machines in order to use DCOM. If DCOM is not available, you will not be able to communicate with remote COM objects. In this case, a distributed presentation layer that uses ASP on the server to generate Web pages for the client will probably be the most suitable architecture.
Second, COM components are normally distributed as platform-specific binary executables. If you want to use client-side COM objects, you need to ensure that the components are available for each of your target platforms. Otherwise, you will need to create special versions of your presentation layer application that don't use those components.
Finally, the user interface or Web browsing services supported on each platform might vary. To work around platform differences for native applications, you can use a platform-neutral user interface framework. To work around platform differences for Web-based applications, you might need to use a restricted subset of HTML and scripting languages. Otherwise, you will need to write platform-specific presentation layer applications.
Even if you need to support only a single operating system, you might be required to support multiple Web browsers. If you are writing a Web-based application, it's important to determine early on what HTML tags, scripting languages, object models, components, and so on are supported by the browsers you need to target. As noted earlier, you'll need to either find a common subset of features supported by all the browsers or write browser-specific presentation layer applications.
The Browser Capabilities component provided with ASP lets you dynamically generate Web pages that use the highest level of functionality the browser is capable of. Using this object, you can find out which browser requested your ASP page and what features the browser supports. Because the Browser Capabilities component determines supported features using an .INI file indexed by the browser's HTTP User Agent string, you can easily customize the .INI file to provide information about any browser features you want.
If you need to support only Internet Explorer 4.0 or later, all the technologies discussed in this chapter are available to you. If you need to support Internet Explorer 3.0, you cannot use DHTML, but you can use RDS if the necessary ADO components are installed on the users' machines. If you need to support other Web browsers, you might not be able to use either client-side or remote COM objects from within Web pages.
If your presentation layer application is a native Win32 application, installing and running COM components on user workstations probably isn't an issue. You'll need to install the Win32 application, of course, but the COM components are just treated as part of the application.
Things are a bit more complicated for Web-based applications. If the browser supports client-side COM components, the components are usually downloaded the first time a user accesses a page that uses the components and are automatically installed on the user's machine. Some users (or the companies they work for) might have concerns about the safety of automatically downloading and installing executable code that will run on client machines. Some users might not allow any components to be downloaded to their machine. If your Web-based application must support this type of user, you probably cannot use any client-side COM components (including ActiveX controls) unless you can guarantee that the components are already installed on the user's machine. Other users will decide on a case-by-case basis whether they want to download and install particular components. In this case, you might choose to use client-side COM components. We'll look at how to make client-side COM components available to user machines in the section "Using Client-Side Components" later in this chapter.
You also need to consider whether user machines will be able to access remote components. We've already looked at some of the issues related to accessing remote components. First, there must be a way for the user machine to make remote COM calls, either using DCOM or using RDS. Second, if you are writing a Web-based application, the browser must support creating and scripting COM objects.
In addition, accessing remote components usually requires installing some code or registry entries on users' machines. If your application uses vtable-binding or early-binding to access COM components, the proxy/stub DLLs or type libraries must be installed on the users' machines. Most applications will also rely on registry information to locate the remote server machine name. Thus, you might face some of the same issues for remote components that you do for client-side components: users might not feel safe using these components. We'll look at how to make remote components available to user machines in the section "Using Business Objects" later in this chapter.
After considering these six factors, you should have a pretty good idea of the overall architecture of your presentation layer application. You should be able to start coding prototype applications to verify the functionality of the user interface, using hard-coded data. You should also verify that the business objects and data objects you have meet the needs of the presentation layer application. If you are missing functionality, modify the components—hopefully before they are deployed so that you don't have to worry about versioning issues. If you are writing a Web-based application, verify that the functionality you need is exposed via the IDispatch interface. Most scripting languages supported by Web browsers support late-binding only through IDispatch. If the functionality you need is exposed on another interface, you'll probably need to modify your components.