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.

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.

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.

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.