DBMS, June 1996
Remember the Distributed Computing Environment (DCE)? DCE, in my opinion, is the most significant "open systems" standard for client/server computing in a heterogeneous environment. As with other middleware products that provide an infrastructure for client/server, the benefits and products that support DCE aren't as sexy as front-end development tools and therefore don't seem to catch or keep our attention. Some of us may not even remember just what DCE can do. DCE is the plumbing and wiring that enables client/server developers to make diverse platforms appear as a single virtual system. Using a common remote procedure call-based API, DCE removes the developer, at least in part, from the integration nightmare that is heterogeneous client/server computing. DCE is also the cross-platform communication mechanism for numerous object request brokers (ORBs) that continue to make their way into many distributed computing projects. With products such as Transarc Corp.'s Encina TP monitor, DCE becomes an efficient transaction-processing environment as well.
Despite the success of DCE as a proven middleware layer, it's still viewed as a solution for larger systems because of the resource overhead (16MB or more for typical client/server applications) for its runtime environment. Most PC clients with 8MB or less of RAM, for example, simply can't easily support the DCE runtime. Therefore, DCE has found itself off of the potential product list of many client/server development projects. As a result, DCE has been needing to go on a diet.
Today, there are new DCE-enabled products such as DE-Light and its Java-enabled cousin, DE-Light Web Client, both from Transarc. These products bring DCE to Windows and Web browser clients, without the enormous overhead of traditional DCE.
The beauty of DCE is that it provides a comprehensive multivendor network operating system solution for client/server development. DCE lets the client interoperate with one or many servers on any combination of computer platforms. At the heart of DCE's client/server services is a remote procedure call (RPC). This RPC lets developers reach across platforms to obtain all types of application services, including database requests, and transaction and object services. DCE also provides a distributed naming service, a time synchronization service, a distributed file system, and built-in network security.
Currently, you can find DCE on most popular corporate platforms, including mainframe operating systems such as IBM's MVS, and mid-level systems such as VMS, Ultrix, OS/1, ACE, HP-UX, and AIX, as well as PC operating systems including DOS, Windows 3.11, Windows NT, Windows 95, and OS/2.
The DCE RPC works like other synchronous RPCs and is protocol and network independent. DCE provides an interface definition language (IDL) and a compiler that lets developers create applications that use the DCE RPC. The IDL compiler creates portable C programs for both the client and server portions of the applications. The developer compiles the C programs (called stubs) with an RPC runtime library that can locate other servers running DCE, exchange information, and process any errors.
The security and naming services of DCE are its most valuable assets. Using these features, developers can set up an application to authenticate each procedure call dynamically and locate servers while the application executes.
The DCE RPC by itself does not support transactions. However, integration with the DCE-ready Encina TP monitor from Transarc adds transaction services to DCE. Encina provides its own DCE-based transactional RPC (called TRPC) component using a C-based precompiler.
If all of this sounds a bit intimidating, it is. However, DE-Light makes DCE integration on the desktop easier. Because many developers consider DCE a heavyweight process, Transarc calls this lightweight DCE implementation DE-Light. There is a Java-enabled version for Web applications as well.
DE-Light lets lightweight Windows clients run applications that issue DCE RPCs and Encina TRPCs. DE-Light requires only 100KB of RAM, in addition to the RAM required by the application. DE-Light clients connect to a DE-Light gateway existing on a DCE-enabled server, which is set up to process requests on behalf of the client. (See Figure 1, page 26.) The client and gateway communicate using common network protocols such as TCP/IP. The real value of DE-Light is its ability to keep the heavyweight processing requirements of DCE off of the client and on the shared resource of a remote server.
This is true multi-tiered computing, and therefore a complex architecture. To make things clearer, it's helpful to look at how DE-Light processes an application call. First, the PC client's request is sent to a gateway server. The request is from a Windows application that can load the DE-Light DLL file and invoke a DE-Light procedure call. The gateway acts as a forwarding agent on behalf of the client.
Second, the gateway translates the request into an RPC for DCE or a TRPC for Encina, then forwards the call to the appropriate server. After doing this, the gateway receives a response from the application server and returns the response to the client. A typical DE-Light call looks like a standard function call. For example, the call to invoke an RPC to reserve a conference room on behalf of the client may look like this:
drpc.callrpc("interface=conference RPC=reserveroom month day year time")
The DE-Light gateway is actually an RPC interpreter. Unlike traditional DCE, DE-Light-based clients are not linked with stub files. Instead the DE-Light client constructs a string that describes the function to the RPC gateway. The DE-Light client runtime collects any parameters needed by the RPC, creates a network connection to the gateway, and sends the string and parameters to the gateway for execution. The gateway, in turn, dynamically builds the DCE requisition (RPC or TRPC), and thus eliminates the requirement for stubs on the gateway. The gateway makes a call to the application server. When the call is complete, the results and any return parameters are sent back to the DCE client, including data or completion status messages.
If you're thinking "skinny client" three-tier computing, you're on the right track. DE-Light's architecture reduces memory consumption, because the clients are not required to run as a traditional DCE or Encina client. In addition, the DE-Light gateway is designed with a caching scheme that enables a single gateway to support a large number of clients (well over 200, depending on what the client applications are doing).
There is built-in reliability as well. If a DE-Light client loses the connection with the gateway, the client will "failover" to an alternate gateway (if available), and thus provide redundant services required by critical systems.
Building DE-Light applications is just a matter of integrating DE-Light with your Windows client/server development tool of choice that can load and call functions in a DLL. Most client/server development tools support DLLs, including PowerBuilder, Delphi, Visual Basic, and SQLWindows. Developers can call DCE and Encina services from an application without incurring the overhead of full-blown DCE. DE-Light only requires an extra 100KB of memory.
Other tools are available to the DE-Light developer as well, including DE-Light's RPC Query Facility. This tool helps the application find the names and call signatures of all of an application's RPCs that are accessible from a remote DE-Light gateway. This facility verifies that the developer addressed all the necessary information for an RPC call, which avoids failures at the time of execution.
The DE-Light client also contains API support to select among various gateway services, proving user ID and password information, as well as managing transactions that may span several DE-Light-based RPCs. Thus, developers have the ultimate power to invoke more than one single application server at a time, using the logical unit of work domain of the transaction model.
DE-Light also provides a Data Dictionary Facility that lets the application integrate its naming conventions with DE-Light RPC capabilities. This lets developers code using any naming standard that's natural for their application.
If you've been watching the industry, you already know that all things client/server must be Web-enabled as well. DE-Light is no exception. DE-Light Web Client is a Java-based application development environment designed to take all the capabilities of DE-Light to the Web. Like other Java-based development products, DE-Light facilitates the construction of Java applets that can be downloaded and executed using popular Web browsers such as Netscape 2.0.
The DE-Light Web Client is really a version of DE-Light implemented as a set of Java classes in the Java language. DE-Light provides most of the gateway functionality for the applet developers, and both the Web and Windows versions of DE-Light use the same gateways. DE-Light Web Client consists of two software components: a client and a gateway. The DE-Light Web Client consists of several small Java classes that use an API to issue DCE RPC and Encina TRPC to a DE-Light gateway. As with DE-Light for Windows, the DE-Light gateway accepts requests from DE-Light Web Clients and translates the requests into RPCs or TRPCs.
The DE-Light Web Client supports a subset of the DE-Light client API. It can't support all API calls due to the limitation of the Java programming language (that is, limited data type support). A DE-Light Web Client depends on native browser-based features such as SSL (Secure Socket Layer) to provide security.
The applets that run inside the browsers can function as a DE-Light client for Windows. Thus, DE-Light Java applets make requests to a DE-Light gateway. The gateway processes the request and returns the results to the Web client using Java as the interface. (See Figure 2.) In this case, an applet runs inside a browser that resides on a computer anywhere on the Internet, or on an applet that resides locally on a companywide Intranet.
DE-Light Java applets contain a string that defines the RPC for the gateway. When a user invokes an applet, DE-Light parses the string building the RPC arguments. The applets then create a TCP/IP connection to a DE-Light gateway and pass the arguments. The DE-Light gateway builds a true DCE RPC or TRPC, and it makes the call on behalf of the client. Once the call is complete, the results are returned back to the applet.
There are many benefits to using DE-Light Web Client, most of them relating to the efficiency of Java. First, the DE-Light and Encina runtime clients don't have to exist on the client workstation to allow DCE-enabled applications to run. For instance, downloading all the libraries required to create a runtime environment would be impractical. However, Java is well suited to support thin clients and can automatically find and download any applets that are not in cache. No set up or installation is required. Applets are usually under 100KB and can move from Web server to client in just a few seconds. Because applets are stored on a central server, developers can update clients by simply updating an applet in a single location: the Web server.
Finally, individual platforms don't require specific versions of DCE and Encina client runtime libraries. Java-enabled browsers already run on many platforms, and Java and DE-Light Web Client are thus both inherently machine-independent. Java also offers a common look and feel that provides end users with a consistent interface.
It's nice to see a client/server product that actually reduces the number of resources required to run it, and one that supports less powerful systems. Sometimes I think development tool vendors assume that everyone runs Pentium 150s with 32MB of RAM. That's just not the case, and older 386s and 486s are still prevalent in the user community. DCE, in its full runtime implementation, is just too large and resource-intensive to layer on top of today's already resource-intensive client/server development tools. Transarc shows initiative in moving RPC processing out to a remote gateway that allows thinner clients.
However, as a DLL-based development mechanism, DE-Light will not provide a natural integration with your development tools. Developers must learn how to make calls using the DE-Light DLL, and integrate them into native tool environments. Some tools, such as Delphi and PowerBuilder, easily support the integration of DLLs. Many other tools do not. For now, I see DE-Light as a product for organizations in which DCE is already in wide use, and where the organization needs to integrate DCE in new or existing Windows-based applications.
The Web-enabled version of DE-Light brings the powerful world of DCE to the Web. Using this tool, developers can build DCE into any Java applet for distribution locally over a private Web server or over the Internet to remote unknown users. This will enable Java applets to communicate with processes that run on mainframe and mid-level computers, as well as interface with the Encina TP monitor for OLTP database application services. As with DE-Light, DE-Light Web Client is a product that will find its home in organizations that currently use DCE and plan to expand services to the Web.
* Transarc Corp., The Gulf Tower, 707 Grant St., Pittsburgh, PA 15219; 412-338-4400 or fax 412-338-4404; email: sales@transarc.com; http://www.transarc.com.
