December 13, 1999

Printer ready

The Distributed Object Challenge: Status Check
continued...page 2 of 3

Related links:

sidebar: A Brief History Of DLL Hell Java Messaging Ensures Data Delivery

And from our sister publications:

EETimes Components simplify DSP design

Objects on the server create their own share of challenges. Before the Web began to influence traditional IT architectures, client-server configurations generally consisted of clients feeding into an application server that, in turn, communicated with one or more back-end databases. This three-tier (client, application, and data) arrangement became more complex as some of the server tiers were further broken out. The term "n-tier" arose to describe the layout, where "n" was some number greater than two. In practice, however, most n-tier configurations were specialized implementations of the three-tier model.

The Web has complicated this model even more. The client tier now might have two very different components: a regular base of networked client devices, and the clients that enter through the Web server. At large Web sites, the transaction load on the Web server can be so great that the server must be broken up across multiple machines, each of which might have a unique relationship with the application and database servers.

In an environment in which a server can consist of multiple machines at every tier, a distributed-computing architecture is the only solution. The two primary architectures for distributed computing are Corba and Sun's Enterprise JavaBeans.

Some would argue that Microsoft's Component Object Model and Distributed COM are additional candidates, but Greenfeld disagrees. "DCOM may eventually become a server technology of importance," he says, "but right now, it's a desktop technology cobbled together to have the appearance of a server story to tell. Few, if any, large-scale implementations of DCOM exist or even aspire to enterprise-scale, mission-critical operations at this point."

Most developers interviewed for this story are taking a wait-and-see attitude toward DCOM, while almost all have piloted or ran an implementation of Corba or Enterprise JavaBeans.

One of the first compelling management issues for server-side components is deployment of the components themselves. This has become a particular issue in the case of Enterprise JavaBeans, especially as clustered servers become more common. In the recent past, deployment specialists would package Java components into a Java archive that would be deployed on a single server. The components would execute within an Enterprise JavaBeans container, software required on the server for execution.

This relatively simple model has become considerably more complicated during the past year, not only because of the clustering factor, but because Java technology has continued to race ahead. In addition to dealing with Enterprise JavaBeans, application servers are expected to support Java Servlets and JavaServer Pages. Servlets are Java programs that execute on the server; in contrast, Enterprise JavaBeans objects are not full programs but server-based components that a program will invoke. JavaServer Pages let Web pages integrate static and dynamic content.

"Assembling and deploying all this technology just is not easy. It requires very knowledgeable specialists," says Mike McHugh, director of product management at middleware vendor BEA Systems Inc. "Sun has recognized part of the problem in the Java 2 Enterprise Edition. It has included some useful deployment tools." Indeed, the Java archive files have been extended significantly. The new deployment package, called the Enterprise Archive file, contains the usual Java Archive file and a Web Archive file. The Web Archive file can contain Java servlets, JavaServer Pages, and HTML files. Hence, using Enterprise Archive files, a company can combine a collection of all the necessary components and files for a complete Web application into one file.

Deployment on a specific server in a cluster becomes a difficult task, because once an Enterprise JavaBean is tied to a specific server, its portability is destroyed. The idea behind clusters is that any single machine in the cluster should be able to do the same work as any other, and all machines in the cluster should appear to the network as the same machine. Deploying Enterprise JavaBeans without having to put them on duplicate machines and have them work correctly is a challenge that doesn't offer an easy solution. Application servers by companies such as BEA Systems, Bluestone Software, Lotus/IBM, Netscape, and Persistence Software are attacking this problem, and upcoming Java management specifications, such as Sun's Java Management Extensions, may offer a partial solution. "Application servers already can move components to different servers transparently, so it's likely the technology to solve the clustering problem will arrive soon,'' says Craig Roth, a senior analyst with the IT advisory firm Meta Group.

continued...page 3
return to page 1

Back to This Week's Issue
Send Us Your Feedback
Top of the Page

---