Like people, real systems suffer from the vicissitudes of a whimsical reality. An architecture built according to the basic precepts discussed thus far would doubtless be flexible, scaleable, and able to handle the desired business functions with panache—but when actually deployed, it would probably fail in some way. Like people, real systems suffer. Your system might freeze at 12:17 AM every Saturday, slow to a crawl during a critical usage period, crash only when the project sponsor's boss logs in, or simply be hit by a power failure during a critical transaction. Above and beyond the dictates of good theoretical system design, systems architectures in the real world must be designed (and constructed) with an eye for the uncertain world of deployment.

Required Characteristics

Distributed systems must possess certain characteristics to function reliably after deployment. Several of these characteristics pertain to maintenance of quality of service, which is essential in the face of unforeseen interruptions in the flow of operations.

• Stability. When one part of a system fails, it can cause other parts of the system to fail. Even if a failed subsystem restarts, it may not be able to initialize itself properly if it depends upon other system elements that have also failed. Thus, the system may thrash as the failure cascades through the system in a chaotic manner. Dependable systems must be stable.

• […]

Any system you build can become a potential target for misuse and attack by either the curious or the malicious. Regardless of the reason for the intruders' invasion, you will want to provide some measures to protect the system. To be realistic, rather than paranoid, your security policy and implementation will depend very much on the nature of your business and its associated risks. For this very reason, security is a term whose meaning changes dependent to whom you are speaking.

As well as security for business reasons, there is also the need for security for social reasons. Most respectable business will want to protect the privacy of their customers; it is difficult to give privacy assurances to potential customers if you have not implemented any security mechanisms. This goes beyond securing a transaction for an online purchase. For example, you may want to run an ethical online business and assure that information collected about your customers will not be used for nefarious marketing purposes.

In this chapter, we will be looking at what it means for a system of distributed objects to be secure. First, we look at what security is and what you need to consider when determining your security policy. Next we will review the salient features of the CORBA security service; this will help you gain an understanding of how the security service works.

A key part of object-oriented software development is mapping design model entities to implementation model classes. Although we are used to thinking of object instances as the primary players in a runtime system, it is in fact the conceptual entities that they embody, not the instances themselves, that are truly important. Objects come and go, but what they represent lives on in the “minds” of clients. For example, a client invocation may require activating a service and instantiating a new object; or a single entity might be represented by objects in multiple processes in a system with load balancing; or a business entity can exist in a persistent data store and then be incarnated as objects in multiple services. Thus, what appears to be a single perpetual entity to clients may not currently exist as a physical runtime object, or may exist as multiple objects.

This difference between conceptual entities and the objects that serve as their vessels lies at the heart of the areas of life cycle and persistence. Questions raised by the entity/object duality that must be applied to every entity include:

• How is the entity identified so that objects know what they are implementing?

• What process or processes should the implementation objects live in?

• Does the entity exist only when an implementation object is created?

• Where and how is an entity's state stored if it exists beyond the implementation object?

• Can an implementation move?

In 1995, the OMG published a COM/CORBA Interworking Request for Propsals (RFP). The RFP was composed of two parts. Part A dealt with interworking between CORBA and the commercially available implementation of COM. Part B dealt with interworking between CORBA and DCOM, which was still in development at that time. The OMG ratified Part A of the COM/CORBA Interworking Specification in 1996 and Part B in 1998. There are currently commercial implementations of Part A.

Our goal in this appendix is take a look at the concepts and considerations put forth in the specification. To begin, we will consider motivations for COM/CORBA integration. Then, we will give a very brief overview of COM. Moving into the meat of our topic, we will discuss a conceptual model for bridging, examine features common to COM and CORBA, and investigate mapping issues. We will look at locating and managing distributed objects from the perspectives of both COM and CORBA. We will conclude by examining COM/CORBA distribution issues.

From Whence We COM

COM evolved from OLE, Object Linking and Embedding, a technology which was developed for the single-user, single-machine environment of Windows 3.1. OLE enabled users to create and manage compound documents, thereby maximizing code reuse within and across applications on the Windows platform. OLE2 was designed to extend the paradigm to the component level. OLE2 interfaces and protocols mediate dynamic component interaction on a desk top.

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.

Meta-information is information about information. Now you have the definition, what does this actually imply for computational systems? There are occasions where you naturally make use of meta-information: the schema of your database, directory services, information about a system's configuration, and so forth. Meta-information in each of these cases allows us to increase the flexibility of the system. For example, if the schema for a database is embedded within your application, then you have negated any possible reuse of the information in the database. Separating the schema from the application allows other applications to make use of the same information.

The more flexible our systems are, the greater the chance of survival they have in the ever-changing environment of the modern computing system. To be flexible, you need to support dynamic discovery and incorporate new services when they become available. The key to providing flexible systems lies in the amount of self-description within the system. Some programming languages support such self-description (a good example is reflection in Java). There is also support for dynamic discovery of objects and meta-information within CORBA. In this chapter we will explore why meta-information provides such flexibility and how existing facilities can provide meta-information.

A lot of work done has been done in the past couple of decades on reflection in object-oriented systems. Reflection is the ability of a system of objects to reason about itself.

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.

Java and corba fit together. With Java, you have portability of code and platform independence. With CORBA you add location transparency and an enterprise level object model that allows us to interoperate with a multitude of existing languages and integrated or legacy systems.

One of the most important steps when designing your client applications and applets is how they should bootstrap into the CORBA system. With a good system design, you can make this bootstrapping phase straightforward and avoid any bottlenecks along the way. You need to consider how CORBA servers should distribute CORBA object references so that clients can easily and efficiently find them. Some of your decisions may be made at the relatively early IDL design phase, while others can be implemented as late as when you deploy your clients and servers.

BOOTSTRAPPING A CORBA APPLICATION

A CORBA application only needs to obtain one CORBA Object reference (otherwise known as an Interoperable Object Reference (IOR)) for it to be able to connect to and participate in a CORBA system. From then on, a CORBA client or server should be able to obtain new IORs through normal IDL invocations. Therefore, it is the mechanism by which a client or server obtains this initial object reference that can be vital for a CORBA system's overall accessibility and scalability. The most interoperable and scalable solution to locating CORBA objects is to use the CORBA Naming Service.

Java is becoming important for building real-world, mission-critical applications. Although Java is still not a perfect language, it is becoming more mature every day. We all know the advantages of Java, especially the “write once, run anywhere” approach, but we are also aware of the disadvantages (its performance being the most commonly offered reason for not using Java).

In spite of that, there are many large companies claiming they are developing their crucial business applications in Java. Modern applications are not monolithic programs, they are built of objects. Therefore, developers need a “glue” for bringing all the pieces together and coordinating them into a functional application. Object location independence is an advantage that gives developers the ability to structure the application into multiple tiers.

For building distributed applications in Java it is natural to choose the Remote Method Invocation (RMI), but there is another possibility—the Common Object Request Broker Architecture (CORBA). CORBA is a valuable alternative to RMI. We could describe CORBA as a superset of RMI, although both technologies are not compatible yet. Both CORBA and RMI allow remote method invocation independently of location, however, CORBA is more than just an object request broker. It offers programming language independence and a rich set of object services and common facilities all the way to the business objects.

There are multiple factors that can affect the decision. One of them is certainly the performance.

In the first article of this series, Tim Matthews described how JavaSoft is developing a Java Cryptography Architecture (JCA) and extensions (Java Cryptography Extensions, or JCE). He described their contents and structure in the java.security package, and outlined their uses. In the second installment, I presented some actual code using the base functionality in the JCA. This third article describes programming using the JCE and multiple providers.

After reading this article, you will, I trust, be able to write a program in Java (an application or applet) that can encrypt or decrypt data using DES and create an RSA digital envelope with the extensions package. Beyond the specific example presented here, though, I hope you will understand the JCE model enough to be able to quickly write code for any operation in the package, and to be able to use multiple providers.

Before beginning, however, it is important to note that the security packages are not part of the JDK 1.0.2, only JDK 1.1 and above. Furthermore, there are significant differences between the security packages in JDK 1.1 and 1.2. This article (and the previous) describes features in 1.2. If you have not yet left 1.0.2 behind, now would be a good time to do so. After all, with 1.2, you are not only getting the security packages, you are also getting improved cloning, serialization and many other features.

There is an important change from JDK 1.1 to 1.2, the JCE is in a different package.

The syntax of a programming language tells you what code it is possible to write—what the machine will understand. Style tells you what you ought to write—what the humans reading the code will understand. Code written with a consistent, simple style will be maintainable, robust, and contain fewer bugs. Code written with no regard to style will contain more bugs. It may simply be thrown away and rewritten rather than maintained.

Our two favorite style guides are classics: Strunk and White's The Elements of Style and Kernighan and Plauger's The Elements of Programming Style. These small books work because they are simple—a list of rules, each containing a brief explanation and examples of correct, and sometimes incorrect, use. We followed the same pattern in this book.

This simple treatment—a series of rules—enabled us to keep this book short and easy to understand. The idea is to provide a clear standard to follow, so programmers can spend their time on solving the problems of their customers, instead of worrying about naming conventions and formatting.

Java has quickly evolved into more than a simple-minded language used to create cute animations on the Web. These days, a large number of serious Java developers are building enterprise-critical applications that are being deployed by large companies around the world. Some applications currently being developed on the Java platform range from traditional Spreadsheets and Word Processors to Accounting, Human Resources, and Financial Planning applications. Because these applications are complex and use rapidly evolving Java technology, companies need to employ a vigorous quality assurance program to produce a high-quality and reliable product. Quality assurance and test teams must get involved early in the product development life cycle, creating a sound test plan, and applying an effective test strategy to insure that these enterprise-critical applications provide accurate results and are defect-free. Accuracy is critical for users who apply these results to crucial decisions about their business, their finances, and their enterprise. I present a case-study of how an effective testing strategy, focused on sub-system level automation, was applied to successfully test a critical real-world Java-based financial application.

THE APPLICATION

The application is being developed by a leading financial services company (hereafter referred to as client) and is targeted toward both individual investors and institutional investors, particularly those investors that are interested in managing their finances and retirement plans. Reliable Software Technologies (RST) provided the QA/Test services and the test team (hereafter referred to as the QA/Test team) to the client.