Java in the Enterprise, part 2 Beyond n-tier: what you really get from Java By Joel Scotkin

August  1998

Joel Scotkin finishes up his Java in the Enterprise series with an explanation of the benefits the Java platform brings to application architects. He says it is enabling a new kind of migratory architecture -- something beyond n-tier -- that is making life a whole lot better for those of us who develop apps. To illustrate his point, he provides a few examples from real life. (1,800 words)

Mail this article to a friend

Last month we examined Java's evolution into an enterprise development environment, and we took a look at some of the new class libraries for building large scale and distributed applications. This month I will focus on the strategic uses of Java, using case studies to delve into some real-world Java applications.

Most of my examples, here, come from personal experience. My company focuses on the financial industry, so the examples will tend to be financially-oriented. However, the concepts and decisions underlying the applications hold true for pretty much any development arena.

An architectural fable
Once upon a time, the world of computers did not look the way it does now. Applications' basic designs have changed considerably, and choosing the right architecture is now critical to the success of your enterprise application. I am going to start with a brief history of how we got to the current set of models, and then take a look at the implication of each model in the context of a Java development effort.

The evolution of application architectures
Standalone Application lives on client
Client/server Database server, client does the thinking
Three-tier Database, business service, client
N-tier Database, many business services, client
Migratory architecture Intelligent agents, distributed calculations, distributed clients

The land of personal computers has migrated through several general architecture models. Early applications were completely standalone. Some applications needed to manipulate data, and to do so they either linked-in a set of database libraries, which let them manipulate local data files, or they actually were databases. As computer networks evolved for basic print and file sharing, people started to think about sharing these database files. Now, this type of file sharing generally worked, but there were some issues -- the main problem being that only one person could access the data file at a time. To make file sharing possible, database libraries evolved into standalone programs that would arbitrate requests over the network. These database servers (Sybase, Oracle, Informix, etcetera) became a big hit. This wave of development, characterized by a standalone database server and a client that did all of the thinking, was known as client/server.

Initially, the servers in a client/server environment were relatively pure -- they took in a request for data, retrieved the data, and sent it back to the client. As people started to write programs with these servers, however, they began to ask the servers to do more and more work -- to the point where much of the business logic actually began to live in the database, in the form of stored procedures.

At this point, two events occurred. First, a strong theoretical basis for good code design emerged. It underscored the practical advantages to designing code in three distinct layers: user interface, reusable business logic, and data sources. Particularly in an object-oriented world, separating these layers (even if the application would eventually be a single executable file) made applications easier to write and much easier to maintain. The second event was the emergence of a class of tools that enabled applications to be distributed across a network. These tools also enabled the physical separation of the user interface from a business logic server or service, along with a distinct database or set of databases. Essentially, this model enabled developers to create custom shared business services, which behaved like the databases in the client/server world. This became known as the three-tier model. As these middle-layer services began to layer upon themselves, the three-tier model expanded to an n-tier -- or multiple tier -- architecture of services communicating to other services: thin clients on the front end, and distributed data sources on the back.

Looking forward, we are starting to see hints of a new migratory architecture. This will be comprised of intelligent agents that will process data where and when it is needed, distributed analytics and calculations, and ubiquitous computing devices.

Enter Java
Java is one of the first languages with native support for three-tier and n-tier models. Much of Java's strength in enterprise development is derived from the ease with which it enables developers to build the newer architectures outlined above. The following examples attempt to build a logical progression, starting with a 2-tier to 3-tier migration, followed by an in-depth look at a Java/CORBA (Common Object Request Broker Architecture) n-tier infrastructure. In the process, we'll touch on everything from thin client distribution to object transports.

Migrating to 3-tier
One of Java's initial selling points was its ability to distribute the client over an intranet or the Internet. Many applications were designed and built specifically to leverage this property, and this model gave Java a considerable amount of early success in the enterprise. For many firms, Java development was their first experience with a 3-tier model.

A common example of Java's value in this scenario starts with a large and complex monolithic client that has a considerable amount of business logic and a complex user interface. The challenge is to migrate the interface to Java, wrap the business logic into a network service, and magically enable clients (both internal and external) to run the tool through their browser.

3-tier migration in the real world
Let's look at a real-world example. The application started out as a heavy pricing tool for various complex financial derivatives. Some types of these derivatives can be priced instantly, but others could take over a minute of solid number crunching on a Sun workstation. Computing a sensitivity analysis, which tries to predict future possibilities using varying sets of initial conditions, could easily require re-running the calculation thousands of times! The GUI (graphical user interface) allowed users to create complex interactions of different types of derivatives. The application was written in C++ and a user interface (UI) toolkit. It was almost 20 megabytes (MB) when compiled.

We wanted to distribute this program over the Internet. The first step was to migrate it to a 3-tier model. Once we identified the function calls where GUI code interacts with business logic, it was easy to replace them with a distributed transport -- thereby separating the GUI code from the server completely. The method of transport here is important, and may change, depending on whether your application is for the Internet or an intranet. In our case, the GUI needed to go out to clients over the Internet and then communicate back through the client firewall. Because of this, we went with a simple key-value protocol over HTTP. (Today, you might want to do the data wrapping with XML over HTTP). This meant writing some code, in both Java and C++, which could interpret the key-value data, and turn it back into a data object at the other end.

Once the transport piece had been decided, the GUI was completely rebuilt in Java, with functionality identical to its predecessor's. The new GUI also had the advantages of cross-platform execution, modular construction, and network distribution. We stripped the C++ analytics code of all user interface components and wrapped it with a basic network infrastructure, turning it into a daemon or service which would sit on a machine waiting for requests. In fact, because we distributed the server code across a powerful compute farm, the Java client performed calculations many times faster over the Internet than the C++ client running on a traders desktop.

Total time: 3 months.

Total value: hard to calculate, except that this application (along with many others built to the same model) has been extremely well received by the client -- at a fraction of the cost of a redevelopment.

The side effects of these migrations can be as impressive as their main goals. One project team realized that they could build custom front ends using the same server and communications classes, and created a proliferation of targeted applets for related tasks. Another side effect is that the code is much easier to maintain, since the GUI code is unencumbered by business logic, and the server code can evolve as needed. Finally, since all of the calculations are done on the server side, the security risks of distributing proprietary code and data are minimized. If someone decompiles the application, all she will get is code to screen components.

Java and an N-tier design: power and flexibility
A recent project involved the creation of an entirely new infrastructure for a major financial firm. Given a blank sheet of paper, the challenge was to create a global infrastructure that would last them well into the next century, provide for rapid change in business models and technologies, and easily enable developers to both leverage and extend the system. By breaking every major business need into a discrete service, an n-tier architecture allows for maximal business logic reuse and flexibility.

The infrastructure consisted of four major layers. First, there had to be a base level of generic services, such as auditing, permissioning, and real-time, which would provide core services to developers throughout the firm. The second layer would contain business objects, such as representations of financial instruments and reference data. The third layer would consist of application servers for a particular application, such as equities trading, and the fourth layer would be the thin clients for various applications.

By building a set of discrete services, and using CORBA as the glue between services and layers, we created an extremely flexible system which is almost totally independent of the underlying operating systems or user interface APIs. Thin clients can be written or rewritten to best leverage developer knowledge -- having a Visual Basic client talking to a CORBA server written in Java is not a problem. CORBA integrates extremely well into the Java framework, so much so that the 1.2 JDK comes bundled with a reference implementation.

The real power of this model grows as developers leverage the core services into their applications. Essentially, each service integrates into a growing component framework, and new applications can leverage existing services as reusable components -- often by simply dropping a JavaBean representation into their application using a visual editor. Building on top of the CORBA framework makes leveraging other people's code much easier -- and the fact that everything is written in Java makes cross-platform development and deployment extremely easy.

It slices, it dices...
Java is an extremely powerful environment, but it may not be appropriate for every task. HTML and the up-and-coming Extensible Markup Language (XML) are simple and extremely powerful when it comes to distributing static data across a network. Building a basic client/server application without programming is still easier in PowerBuilder than in a Java IDE (integrated development environment). If you need direct access to hardware, or you are writing an operating system from scratch, Java is probably not the tool you want to use today. On the other hand, when it comes to large-scale enterprise development, Java is an extremely powerful platform which has become an easy choice for almost any application.

Resources

• Last month's "Java in the enterprise, part 1" http://www.sunworld.com/sunworldonline/swol-07-1998/swol-07-java.html
• JavaSoft http://java.sun.com
• SunWorld sister publication, JavaWorld http://www.javaworld.com
• A listing of Java-related stories in SunWorld's Site Index http://www.sunworld.com/common/swol-siteindex.html#Java

About the author
Joel Scotkin is president of Random Walk Computing, a New York-based consulting firm that specializes in delivering Java and CORBA solutions to the financial industry. Reach Joel at joel.scotkin@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-08-1998/swol-08-java.html
Last modified: