Setting up a development environment for distributed processing does not have to be complex or expensive. Much of the program code written for this book was developed on a single Pentium 200 MMX machine. Additional testing was done by networking it with a Pentium 133 running NT Server. This machine was built from spare parts, and I think that NT and SQL Server probably cost more than the computer. I also used the Java SDK, Borland's JBuilder, and Microsoft Access.

This appendix will describe the two configurations, as well as how to use them to compile and run the program examples. The topics covered will include:

• Development using a single computer

• Development on a network

• Compiling and testing Java and RMI

• Setting up JDBC

Development Using a Single Computer

Experimenting and testing Java, RMI, and JDBC only requires a single computer. Windows 95 and 98 do a good job of multi-tasking, so there is no reason to go through the trial or expense of networking a second computer. Working on a single computer also saves wear and tear on the chairs and carpet moving back and forth between computers.

Figure A-l shows the processes that must be running to make RMI work on a single computer. Before the application server and the applet can communicate, you must have the RMI registry running on top of an Internet server. For you to use JDBC, you must also have the appropriate drivers and database server running. All of these processes take quite a bit of memory, so the more memory in the machine, the better.

Just as the service interface layer connects the application server to user interface programs, the persistent object layer connects the application server to databases, object stores, and other external applications. Once the business objects perform the processes requested by the service interface, the resulting data must be stored for later use. The persistent object layer routes this data to relational databases or other forms of long-term storage.

In the business environment, data is most often stored in relational databases. Although there are other persistence alternatives, such as object database management systems (ODBMS) that directly store and retrieve objects, these are products that are just now starting to move into the mainstream. Relational database is a mature technology that has been refined over 25 years, and business data processing relies heavily on this technology. For the application server to fit into the business environment effectively, the persistence layer must bridge application server objects with the relational data model.

A number of methods can be used to implement persistent objects, and many of these will be explored in this chapter. Depending on the size and scope of the application server project, these methods can range from a simple set of collections, each representing similar business objects, all the way to a comprehensive persistence service that acts as an object broker, handling persistence, life cycle, and directory services for the entire application server.

The persistent object layer forms the foundation of the application server. This layer is responsible for creating, initializing, and storing business objects derived from relational databases or other external applications. It also serves as the object broker for the application server, tracking and locating business objects already in memory. All of these tasks must be done quickly and efficiently to provide fast response time but must also work carefully to maintain the integrity of the data.

When an object is requested, the persistence layer must know how to access the data from a storage medium such as a relational database, then create the requested object from the data. Once the object is created, the new object must be registered into a data structure where it can be quickly located when the same object is requested by another process. The persistence layer must also provide concurrency control and synchronization to ensure that the data remains consistent with the database and other processes and is not corrupted when more than one process attempts to modify the attributes at the same time. The objects must also be synchronized with changes that occur in the database from other external applications so that the database itself is not corrupted.

This chapter will illustrate how to create a simple persistent object layer and discuss the implementation and programming issues involved. Although the Java language and JDBC will be used to illustrate the problems and tradeoffs that must be considered, the implementation could just as easily be done using C++ and ODBC. Java was chosen for its simplicity and brevity, not because it is a superior platform.

Part 2 examines the issues involved in designing an open, scaleable application server architecture. These include requirements analysis, user interface and business object design, persistent storage, and application integration. Emphasis is on user involvement through joint application design teams, use cases analysis, and incremental, iterative development.

Over the past year or so, quite a few software vendors have released packages they call application servers. Inprise, Oracle, BEA, and a number of others all have jumped onto the application server bandwagon, extending their product lines with products that target enterprise computing. So, what exactly is an application server?

This chapter will explore the reasons why application server technology will play an important role in the next generation of enterprise computing. Topics include:

• Two-tiered vs. multi-tiered computing

• Why I chose multi-tiered client/server

• What can an application server do?

• Costs and disadvantages of application servers

• Moving from traditional client/server to n-tier computing

Two-Tiered vs. Multi-Tiered Computing

There are quite a few advantages to traditional two-tiered client/server. The database products are very mature with heavy competition to constantly improve performance and features. Client-side development tools like Microsoft Access, Borland Delphi, and C++ Builder have become so easy to use that much of the code writes itself. Even the networks are easier to install and maintain.

But as most client/server developers soon discover, it is almost too easy. New applications multiply on the server and, with the constantly plunging price of computers, more clients keep coming on board. In no time at all, the server is overloaded. Even after all of the memory slots have been filled, more CPUs have been added, and thousands of dollars have been spent to upgrade the network, the users still complain that response time is too slow.

Up to now, this book has looked at application servers as abstract concepts—first from an architectural view, then from the designer's vantage point. It's almost time to roll up our sleeves and start the real work: translating the abstractions into program code. But before we can start programming, we need to establish a general framework that can hold the service interfaces, business objects, and persistent objects that implement the server. This chapter bridges the discussion between design and programming, describing how to establish this framework.

In addition to the program framework, we must also create an organizational framework that manages and structures the development process. This includes communication channels, programming tools, testing strategies and other administrative details. Although the emphasis of this book is on the technical side of application server development, these topics will also be discussed in this chapter.

This chapter will examine the following topics:

• The application server framework

• Additional application server requirements

• Development strategies

The Application Server Framework

In the previous chapters, we examined each of the different application server layers as separate entities, each having different responsibilities and requirements. This is the advantage of using a layered architecture: each layer can be examined on its own, viewed independently. Business object design can focus on the needs of the application. Service interface design can implement services for the user interface. The persistence layer design can focus on mapping business objects to their representation inside databases or persistent storage. By focusing on a single layer at a time, it is easier to manage the complex requirements of the application server design.

To those outside the application server team, an application server is just a set of services that support the user interface programs. The user interface collects data and then sends it to the application server, where the data is processed. Depending on the result, the application server returns either the requested data or an error message. The user interface programmers do not need to know how the service interface does its job—only that it works according to the specifications.

This is the goal of a good service interface design. The implementation details should be irrelevant to those working with the services. The services are well defined and documented and the results are understood, but only the application server programmers need to know how the results are obtained.

This chapter will examine how the service interfaces are designed, from use case analysis through design specifications. The topics covered will include:

• What is a service interface?

• Design by interface

• More on JAD: developing use cases

• Turning use cases into services

• Building services out of business objects

What Is a Service Interface?

A service interface is more than just a list of function calls specified by the user interface programmers. Each interface should contain a set of standardized services that not only make sense within the context of a single application, but conform to an organization's standard application architecture. This requires each service to conform to standard naming conventions and use consistent parameter-passing and exception-handling protocols. The user interface programmer should be able to take a new service interface and quickly and easily integrate it into an application with a minimum of research and testing.

A service interface is a set of consistent, easy-to-use application services that can be called by user interface programmers to perform the tasks requested by the user. When the post transaction button is clicked, the user interface calls the post transaction service, supplying the relevant data items. The user interface programmers have no need to know how the transaction is posted; they simply need to know how to request the appropriate post transaction service.

Once the data is supplied to the service interface, it is up to the application server programmer to ensure that the necessary business objects are retrieved by the persistent object layer and that methods are called to perform all of the tasks requested by the service interface specification. If the business objects are designed correctly and the persistence layer can correctly retrieve the business objects, programming the service interface should not be a difficult task.

What complicates service interface programming is the additional layers of middleware managing objects distributed over a number of different computers. This restricts the amount of data that can be passed between the client and the service interface, since much of the data must be passed through network connections and be marshaled to meet the requirements of the remote machine's data format. The network also adds a multitude of new exception and error conditions that must be anticipated. As an added restriction, the same service may be executing simultaneously for a large number of different clients, each requesting services for any number of different sets of data.

This chapter will examine these technical requirements and explore some of the programming techniques available to address these challenges.

One of the most striking differences between traditional client/server development and the application server environment is the need to service a large number of users simultaneously. Instead of relying on database servers to manage concurrent access, it is now the responsibility of the application programmer to anticipate these needs, making sure that one user's service request does not interrupt or corrupt another service already running. Because of this added complexity, the programmer must decide when objects can be shared, when separate instances must be created, how to synchronize persistent data between objects, and how to coordinate changes in data when there is a chance that it can be modified by other applications.

Fortunately, you have many tools and techniques available to handle these issues. You can purchase middleware tools to replace some of the functionality that used to be provided by the database server. Most development environments provide tools to manage concurrent access, object brokers can assist in life cycle management, and transaction monitors can support complex application dependencies. There are also techniques that can ease concurrency and life cycle management. Application server implementation is far more complex than traditional client/server development, but with the proper approach, your application framework will be open, robust and ready to grow with your business.

This chapter will examine the following issues:

• The trouble with multiprocessing

• Multiprocessing within the application server

• The class factory model

• Multi-threading

• Synchronizing objects and data

• Transactions

The Trouble with Multiprocessing

Multiprocessing, the ability to service many different users at the same time on the same machine, introduces several new issues that are not often addressed in traditional client/server development.

Part 1 offers an overview of application server architecture, describing its benefits in the business environment and providing an overview of its fundamental technologies including multi-tiered client/server computing, distributed applications and middleware.

According to the vendor literature, it appears that moving to multi-tiered client/server computing is as simple as buying a few products, creating a few Web pages, and writing a little bit of application code. In a recent Microsoft presentation, a company representative created a simple three-tiered application in less than ten minutes (Microsoft, Inc. 1998). He built a Web page with a couple extra lines of VBScript code, displayed about twenty lines of Visual Basic code that was already installed on the transaction server, and then with a few mouse clicks, showed how easy it was to validate a customer number. Too bad the transaction server code only returned “credit OK” if the customer number was 123456789.

Microsoft is not the only vendor using this approach to sell middleware products. Although the vendors make the development process look easy, these products are complex pieces of software. Just learning the programming conventions and protocols can take weeks, while producing industrial-strength code could take months. Tools like the Microsoft Transaction Server can make programming somewhat easier for developers by providing communications protocols and development frameworks, but even the simplest service will take far more than twenty lines of code.

This chapter will examine the application server from an architectural viewpoint and will also examine the major categories of middleware software. Topics will include:

• Overview of the application server architecture

• Middleware—the glue that holds it together

• Middleware categories

• Applying middleware to the application server architecture

• Alternative application server architectures

• Putting it all together

The application server model will be an effective approach for building software in the twenty-first century, but it is only one of many different options available to the business software developer. Mainframe computing is still effective for large corporations, as millions of lines of code still perform their tasks effectively every day. Two-tiered client/server also offers an excellent option for less intensive database applications and there are a host of different Internet technologies available to deliver applications to Web browsers. In addition to existing technologies, the rapid rate of change will continue to bring new computing models that will spawn new software technologies. Just as client/server was a response to desktop computers, and a host of new software technology appeared in response to the Internet, other new technologies will continue to rise and shape the way that we build software.

Looking into the future is a difficult and perilous task. Even the best minds in the industry have trouble seeing beyond the next few years. To see how well others have fared, I got out the book Programmers at Work, published in 1986 (Lammers 1986). The book is a collection of interviews with some of the industry leaders of the time; early Mac developers Jeff Raskin and Andy Hertzfeld, dBase author Wayne Ratliff, VisiCalc designers Dan Bricklin and Bob Frankston, and of course Bill Gates.

What initially drew me to application server technology was the need to support constantly changing, complex business rules. Traditional two-tiered client/server worked well for data intensive applications, but as the processing requirements grew, it became difficult to create and manage large client-based programs that supported these complex requirements. Moving the business logic to centralized application servers simplified both software development and code distribution.

Today's business applications are expected to move far beyond simple data management chores, performing business intelligence and decision support tasks for all levels of the company. Business requirements are also constantly changing, with new products and processes introduced in ever-shorter business cycles. Applications must not only encapsulate existing business logic, but be structured openly to allow quick response when rules change.

Business rule processing takes on a variety of forms, from simple data validation to complex data classifications and business processing logic. Encapsulating these processes in program code that can respond to changing requirements is a challenging task. Often, implementing rule processing around data structures instead of program code enables more flexibility and ease of maintenance. Commercial business rule processors and languages can also make the task easier to manage.

This chapter will examine how to incorporate complex business rules and processing into the application server environment. It will examine what a business rule is, how to implement the rules in program code, where to place the logic within the application architecture, and how to standardize error handling and reporting. Application security will also be examined, both as an application server issue and as a way of illustrating how to implement complex business rules.

The goal of business object design is to create a collection of reusable software objects that model your business. While interface design is a bottom-up approach, used to determine application requirements, business object design is a top-down analysis of the entire business, identifying roles and functions. Business objects are formed by specifying properties and services that reflect the real-world objects they model. As with real-world objects, software objects often combine and collaborate to perform tasks that they cannot perform individually.

Object design requires a global view of the organization, determining not only the needs of the current task, but the functions required for the entire business. Objects must be designed for reuse across both the current application and be ready for use in the next project, even if the project is for another department or a different line of business. Although not a simple task, it is not as difficult as it seems. Business objects mirror people, forms, and other objects that have already been integrated into the business. As such, when the objects simulate these functions, they also fit inside the same business context.

The object designer cannot possibly know all of the business requirements, so designing all functionality from the beginning is an impossible task. Business requirements are constantly changing and today's needs may not be relevant tomorrow. Business objects must be designed as open, dynamic components that can easily be changed without impact on other functions.

You've read everything you can find about middleware, CORBA, transaction monitors, message brokers, enterprise JavaBeans, and other distributed technologies. Now it's time to put them to work. Time to build your company's first multi-tiered application. But where do you start? How do you structure the programs? How do you distribute the code? What about integrating existing applications and databases? This was the problem that I faced as I began working with multi-tiered development. There was plenty of information on the tools and technologies, but little on how to make them work in a business setting.

Application servers and related technologies offer great promise and potential for solving the issues that trouble corporate computing. Problems like scalability, application integration and code reuse. But before we can solve these grand problems, we have to figure out how to use the technology. How do we process orders, ship products, bill customers, approve loan applications and pay insurance claims.

My hope is that this book will offer some guidelines to start you on your way. Instead of focusing on middleware, the emphasis is on the design issues and programming techniques necessary to create an overall business application framework. The approach is user-centric, relying on joint development between developers and business people, using short, iterative design-program-review cycles. Object-oriented development is also stressed using designs illustrated with UML and programming examples written for the Java platform. Although Java and RMI are used, the framework will work with almost any language or distributed object platform.

Part 3 describes tools and processes that can be used to transform the user requirements into working program code. These chapters examine how to implement the business objects and place them into a framework that services the user interface programs.

The promise of Java as a truly distributed software platform is now a step closer to reality. The recent integration of Java archive functionality significantly improves the ability of developers to manage and transfer disbursed data over large networks. Specifically, Java now provides two disparate areas of archiving functionality that address the same issue: an improvement in download time—but through different means. Java Archive files, or JAR files, allow an entire applet's dependency list to be transferred in the form of a single compressed file, while Java's archiving classes provide functionality for the programmatic manipulation of files in various compression formats. Given the benefits of archives in a distributed model, I will detail some of these newly integrated features, as well as demonstrate how archive functionality can improve enterprise applet performance.

JAR FILES

Introduced with the JDK 1.1, Java Archive files provide a vastly improved delivery mechanism for applets. An entire applet's dependency list (all. class files, images, sounds, text, etc.) can now be aggregated into a single compressed file, which can then be transferred over a single HTTP connection. Once downloaded, JDK 1.1-compliant browsers can then seemly decompress and run the applet. The result of this process is a marked decrease in the time it takes to launch an applet, due in part to a reduction of both the bytes transferred and number of dependency-based HTTP transactions.

Java Archive files are based on the popular ZIP archive format as defined by PKWare.