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.

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.

This the first first in a series of articles focusing on the Swing components that will be released as part of the Java Foundation Classes in JDK 1.2. I'll review the underlying infrastructure for the Swing components, in addition to some of the components Swing has to offer, in my next few installments. This month, after a brief history of the Java Foundation Classes, I'll discuss Swing's implementation of the Model/View/Controller (MVC) architecture.

THE JAVA FOUNDATION CLASSES

In addition to being a vast improvement over its predecessor, the 1.1 AWT lays the foundation for one of the most visible core Java APIs: Foundation Classes (JFC). The JFC consists of the 1.1 (and later) AWT, the Swing components, the 2D API, and the Accessibility API.

HISTORY OF THE JFC

Back in 1995, no one overestimated the impact that Java was about to have on the modern computing world. As a language originally designed for consumer electronic devices, Java was suddenly catapulted into the stratosphere as the language for developing Web software. Over the next couple of years, Java would mature quickly; not only the language but also core packages, such as the AWT.

The original AWT was not designed to be a high powered UI toolkit—instead it was envisioned as providing support for developing simple user interfaces for simple applets. The original AWT was fitted with an inheritance-based event model that did not scale well.

Business application development and deployment using Java has become much more popular in the past year. This is partly because of the redesigned java.awt library in the JDK 1.1, as well as other third-party JDK 1.1-compliant GUI class libraries and IDEs. Developers can now build sophisticated and complex GUI interface front-ends for their applications. As these frontends become heavier, special consideration needs to be given to the deployment strategy used to deploy the client side of a client/server application.

There are several different options available for deploying Java client applications. Some of the options are fairly familiar, while others are not. Even if you understand what options are available, it is not always as obvious which should be used in a given situation. This article reviews options available for client-side deployment of Java applications along with the advantages and disadvantages of each strategy.

TRADITIONAL DEPLOYMENT

In most client/server applications, the deployment options for the client piece of the application is fairly limited. Usually, a client platform and programming language are chosen before development begins and the application is built with the target platform in mind. For example, a telephone invoicing client GUI application could be built using C++ on a Windows NT machine. On completion of the coding for the application, it would have to be manually or remotely installed on every Windows NT client machine that needed to use the application.

Anyone who has ever tried to construct modular, object-oriented user interfaces using the AWT knows how hard it can be. The result can easily end up being difficult to debug, complex to understand and maintain, and certainly not reusable (except by cutting and pasting!). However, huge benefits can be obtained by separating out the user interface from the application code. This has been acknowledged for a long time and the Java Development Kit included the Observer class and the Observable interface to support this. However, with the addition of the delegation event model in the JDK 1.1, the potential for separating the view and control parts of the interface was provided. This allows the separation of the interface from the control elements (i.e., what to do when a user presses a button) and from the application code. Such a separation is often referred to as a model-view-controller architecture (or just as the MVC for short). The MVC originated in Smalltalk, but the concept has been used in many places. This article considers what the MVC is, why it is a good approach to GUI construction, and what features in Java support it. It then describes a GUI application which has been built using the MVC architecture. The source code for this application is provided as an appendix.

The basic synchronization primitives provided in Java are very easy to use, and well-suited to the majority of situations a programmer sees. In many respects they are simpler, easier to use, and less prone to errors than their counterparts in POSIX threads (Pthreads). They do not, however, cover all situations and extending them is not always obvious.

PROVIDING PROTECTION

The first thing that synchronization techniques must provide is a method to ensure that updates to shared data are done in a correct fashion. In particular, many updates comprise several distinct operations and those operations must be done together, atomically. The canonical example is a program that updates your bank account. In Listing 1, it should be obvious that thread number 1 could overwrite the data that thread number 2 had just saved.

The solution to this is to ensure that each of those operations happen atomically. In Java, this is done with a synchronized method (objects with such synchronization are known as monitors). Now the second method will have to wait for the one called first to complete before it can start. The code in Listing 2 will operate correctly.

Pthreads accomplishes the same behavior by using explicit mutex locks. While functionally equivalent, using explicit mutexes suffers from the added complexity of the programmer having to remember which locks to use and to unlock them after use. This is not a big problem, but when writing complex code that has numerous branches and return statements, mistakes do happen (I speak from experience!) and it can be irritating to track down.

Objects are good. Patterns are good. Networks are good.

These statements have almost become IT axioms in the last few years. I'm not going to buck the trend here. Objects are indeed good. Networks and patterns help to make them even better. I'm going to show a relatively easy way to link these three things together.

Well designed object-oriented applications share a common topology (see Riel, A. Object-Oriented Design Heuristics. Addison-Wesley, 1996.) By topology I mean the natural features of an entity and their structural relationships. A well-planned object model will spread out the application logic within a system. Related data and behavior will be kept in logical, isolated units. Structuring applications in this way promotes reuse, facilitates comprehension, and minimizes the effects of change.

One side effect of partitioning a system in this way is the need for these “logical isolated units” to communicate with each other. Using controller classes to organize the communication is not a viable solution because it concentrates the system's intelligence in a single place. How can we share information without cluttering our design?

The Observer pattern (see Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.) provides a possible answer to our question. In the applicability section of the pattern description we find that Observer is a good way to “notify other objects without making assumptions about who these objects are.

The java developers' slogan is “100% Java,” meaning “Don't taint your Java software by incorporating non-Java components.” Yet, Java itself is neither 100% pure object nor 100% pure object-oriented; it is “tainted” with components of the procedural programming paradigm. The Java designers have borrowed many ideas from diverse sources—other object-oriented languages, especially C++ and Smalltalk, design patterns (see Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995), and basic object-oriented design principles—picking and choosing good ideas from each. And they've done a truly fine job. However, at one particular juncture, I believe the language architects made the wrong choice, and that was the decision to incorporate non-object primitive types into the otherwise uniform object-oriented language model.

There are two types of types in Java. By primitive types, I mean elementary variable types such as int, boolean, float, long, short, and so on. These are sometimes referred to as “built-in” types. The other type of type is objects: a variable can be declared to be of type Object or String or any other class. Referring to the two types of types as metatypes, we have primitive and object metatypes (the truth is, the two metatypes are primitive and reference, which includes not only objects, but interfaces and arrays—more on why they are “reference” types later). By incorporating both metatypes, Java is not populated purely with objects.

TheJava Report published its first issue in March 1996. This was a real accomplishment when you consider that it was only on May 23, 1995, that John Gage, director of the Science Office for Sun Microsystems, announced Java to the world at SunWorld. Later in 1995, Sun released the initial Java Development Kit (JDK) and a Java enabled Web Browser called HotJava. The rest is history, as Java is now firmly entrenched in the computing industry. Many of us who saw demonstrations of Java in 1995 knew that it was something new, something different, and something not to be ignored. Those behind the Java Report knew this too, and we have been reporting on Java ever since.

In his first editorial for Java Report, the original Editor-In-Chief, David Fisco, wrote:

Recently, the subject of patterns has become one of the hottest topics in object-oriented development. The most well-known patterns are the design patterns of the Gang of Four (Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994), fundamental implementation patterns that are widely useful in object-oriented implementations. An important part of most OO systems is the domain model—those classes which model the underlying business that the software is supporting. We can see patterns in domain models too, patterns that often recur in surprising places. I will provide a short introduction to some analysis patterns that I have come across.

I'm not going to do this by surveying the field, or discussing theory—patterns don't really lend themselves to that. Rather, I'll show you some examples of patterns and illustrate them with UML diagrams (Fowler, M., UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997) and Java interface declarations.

REPRESENTING QUANTITIES

Imagine you are writing a computerized medical record system for a hospital. You have to record several measurements about your patients, such as their height, weight, and blood-glucose level. You might choose to model this using numeric attributes (see Figure 1 and Listing 1).

This approach is quite common, but may present several problems. One major problem is with using numbers.