| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Other Middleware Vendors’ Support for the Internet

All the middleware products described earlier—NCRs, BEAs, and Transarcs—replace the need for HTTP and CGI programs and use Java applets. By doing this, middleware runtime client libraries do not have to be preloaded on the client platform. All the potential user has to have is a Web browser and a Java Virtual Machine (normally embedded in the Web browser) to run an application as though he was connected in the normal way to the application.

The Web browser and JVM can be running on any platform—a PC, workstation, big box, little box, Unix, Windows, or whatever, as long as the Web browser and the JVM will run on that machine. So how does it all work?

The middleware in practice

Users wanting to complete a transaction from the Web first access the Web in the normal way using the Web browser. They find the appropriate page using the address of the page or by browsing until they get to the page they want. The page is then downloaded from the Web server in the normal way.

Figure 12.2 Other middleware support for the Internet

Within this page, however, (unknown to them) is a tag pointing to a Java applet, and when the user asks for the page, the Java applet gets downloaded onto their machine.

This Java applet is rather special. It consists of two parts—a part written by you, contains the application code you want executed, and a part supplied by your middleware supplier, which is a lightweight implementation of the normal middleware they supply—something that will supply basic connectivity for the end user but won’t take an age to download.

The application part of the total client package contains the presentation logic, a link to the middleware Java class, and a small amount of application logic—possibly validation. Once downloaded, the lightweight middleware on the client bypasses the Web server and opens a direct connection to a middleware gateway, which runs on the company’s Web server machine. This is an important point to remember—you have to have the middleware gateway running on your Web server machine for this to work.

Communication between the lightweight Client and the middleware Gateway server is then via TCP/IP, but the protocol used is not HTTP. Instead, a special protocol is used—the middleware vendor’s own internal protocol, adapted for use over the Internet.

The gateway provides access to the fully functioned middleware running on the machine. The middleware client builds a string describing the RPC or other type of call it wants the gateway to execute on its behalf. The gateway then builds a true RPC or other type of call and passes it on to the fully functioned middleware to action. The fully functioned version will then do things like security checking, lookup of the Directory to see where the application requested actually resides, and transaction control.

Any application written on any machine on your network can be accessed. The user may be using a Web browser type interface, but he or she will actually be interacting with a real application accessing its functions in the normal way—no need for CGI or scripts or any other forms of complex access.

All communication is via the Gateway, so the Java class has no need to listen on the network for requests or open a network connection. Furthermore, an individual Java class can be identified uniquely over many different service requests, regardless of whether the network connection is maintained or reestablished each time, so application state can be maintained, even when the network connection is released.

Java and three-tier architectures

Generally speaking, the vendors of these products recommend a three-tier architecture for use with this sort of application. The client invokes the transaction, a business logic server executes the transaction, and accesses data or other processes on behalf of the client.

The Java class’s only function is to invoke a transaction and allow entry of data to support the transaction. As such it has no need to access files on the client or communicate with other applets. The architecture is vastly superior to a two-tier approach (which may actually be infeasible), as the transaction can be executed on a powerful machine with failover capabilities, ensuring that the transaction always completes as intended.

Figure 12.3 Three-tier Internet architecture

If the transaction is controlled directly from the client machine, with two-phase commit, for example, being controlled from the client, any failure of the client could cause problems. As users can be haphazard about the way they handle their machines, they could even turn the machine off before the transaction had completed—a disastrous situation—so three-tier is always to be recommended with Internet use. It also makes the control of security easier, as checks can be delegated to the gateway.

In Summary

The modules that other middleware vendors have built to be used over the Internet provide a useful extension to their normal product range, enabling the same applications and services to be used either from a normal client under Windows, for example, or via Web browsers and the Internet. The important point to emphasize is that the developer has no need to adapt an application for use over the Web as long as he or she can adequately express the functionality of the client in a Java applet. The “business logic server” part of the application and data access portions can remain the same.

The reason vendors such as Transarc, BEA, and NCR chose Java for the client was to obtain portability—their Internet front ends should be able to run on any machine—a network computer, a windows-based computer, a NetPC, and so on. A casual user with any sort of machine (as long as it has the Java Virtual machine running on it) should be able to access the applications the company has on site.

The interface will also be the same for all users—irrespective of the machine they are using (a major advantage with a casual user), and the user interface—the browser interface—is easy to understand and use. The approach also means that all the products can support organizations wanting to support commercial transactions on the Internet using the Web.

Now let us see what Microsoft proposes for support of the Web and the Internet.

Previous | Table of Contents | Next