● Compiling IDL Interfaces for Java Clients ● Writing a Client Applet
● Handling Exceptions
● CGI Programs, Java.net.*, and Java.io.* May Not Be the Best Choices ● Using the Dynamic Invocation Interface and the Interface Repository ● Using Filters
● Some Points About Distributed System Architecture
The combination of Java and CORBA is a very positive development for client/server systems. While CORBA is the leading heterogeneous distributed system standard, Java provides an extremely portable and powerful mechanism for the development of client-side functionality. And, due to the marriage of these two technologies, many client/server applications that were previously cost- prohibitive are now cost-effective. This situation results from the simple fact that Java and CORBA solve technical problems and simplify many aspects of client/server development and deployment. More specifically, Java and CORBA provide standards-based heterogeneous inter-process communication, client-side deployment, flexible decoupling of clients and servers, portable client-side functionality, and abstraction of some of the more time-consuming aspects of programming in general. This chapter highlights and illustrates some of the ways that CORBA enhances the client/server capabilities of Java-based client applications.
Defining IDL Interfaces
Although this is a chapter on writing CORBA-enabled Java clients rather than servers, a few words about the definition of IDL interfaces are appropriate in order to convey the context of CORBA client interoperability. CORBA's Interface Definition Language (IDL) is a declarative language used to define the interfaces that may be called by a client process. The nature of an IDL interface may vary dramatically from one distributed application to the next. IDL interfaces will vary from very coarse and generic to very fine- grained and specific. Where an interface lies in this continuum will likely depend on some variation of the following factors:
● Are the clients and servers being developed independently?
● Will there be many different clients and/or many servers which must cooperate? ● Is the server intended to provide a wide variety of services?
If the answer to any two of the above questions is yes, then look into the possibility of defining your server's interface(s) in a more coarse and generic fashion. This can significantly enhance the extensibility and longevity of your distributed system. As new servers and clients are introduced to your distributed system there will be much less likelihood that existing clients and servers will need to change. An example of a coarse and generic interface is one that has a comparatively small number of IDL interfaces defined, uses some of the more generic IDL types as function parameters (for example, NameValuePairs, any), and has functions that are not specific to the services provided by the server. An example of a rather specific interface is the one following. This IDL interface describes the server functionality invoked by the client applet which forms the basis for the examples in this chapter.
Chapter 17 -- Creating CORBA Clients
Listing 17.1 CHAPT17LISTINGS.TXT-Notebook Server IDL Interface
interface NotebookIF {
typedef sequence<string> stringListType; //resizeable list of strings typedef exception AccessNotAuthorizedExc; // user access denied
typedef exception NoSuchBookExc{string bookName;}; // no such notebook typedef exception NoSuchPageExc{string pageName;}; //no such page //each user must provide a user name and password
short authorizeUser(in string userName, in string password) raises(AccessNotAuthorizedExc);
//the list of existing notebooks is returned
stringListType getBooks(in string userName, in string password) raises(AccessNotAuthorizedExc);
//the list of existing notebook pages is returned stringListType getPages(in string bookName, in string userName, in string password)
raises(AccessNotAuthorizedExc, NoSuchBookExc); //retrieves the contents of a notebook page
string retrievePage(in string bookName, in string pageName, in string userName, in string password) raises(AccessNotAuthorizedExc,
NoSuchPageExc, NoSuchBookExc); //saves the contents of a notebook page short savePage(in string bookName, in string pageName, in string pageContent, in string userName, in string password) raises(AccessNotAuthorizedExc, NoSuchBookExc); }; Note
As a footnote, it has become a popular convention to arrive at the name of the class which implements an IDL interface by taking the name of the interface to be implemented and suffixing it with an abbreviation of the word "implementation." Using the Web-based notebook server as an example, this convention would result in an IDL interface named "Notebook" and an implementation class called "Notebook_impl". While this seems reasonable on the surface, the fact that this is an ORB-centric convention can present a problem as the server evolves through the development process. The problem arises when it becomes necessary to change the classes or services which are ORB-enabled (have IDL interfaces), or when it becomes necessary to alter the way in which classes implement the IDL interfaces. If a service that has not been previously ORB-enabled must become so, it will then be necessary to change the name of the class implementing that service to add the "impl" suffix. Worse yet, a change to the class's file name is also likely. A better
convention is to suffix the name of the IDL interface with characters indicating that it is an
Chapter 17 -- Creating CORBA Clients
interface (such as IF or _if), and apply no suffix to the implementation class. In this example, the IDL interface is then "NotebookIF" while the implementation class name is simply "Notebook". This way, if you wish to support the implementation of the
NotebookIF interface with another, pre-existing class, neither the Notebook class nor the additional implementation classes need have their names changed.
Tip
When defining IDL functions use oneway where possible. CORBA provides the ability to classify IDL functions as oneway (as long as they do not have a return value or user defined exceptions). A oneway function results in a non-blocking call for the client process. The effect is that a client invoking a oneway call will continue processing immediately after the ORB call is made. There is not a wait for the called function to complete. The performance gains on the client side can be significant. There is also less likelihood for deadlock in the event that a server attempts to call back the client as part of its response to call from the client.
The client applet is a simplified Web-based Notebook allowing a user to create, store, retrieve, and display notebooks and notebook pages. The core of the applet is the free form drawing pallet on which the user types or draws whatever information is necessary. All persistent information about the authorized users, notebooks, and the contents of their pages is accessed and stored on the server's host.
The services of the notebook server are invoked by the client applet, depicted in Figure 17.1, using ORB calls from the applet's host back to the server's host. The Java-enabled ORB product used for the examples in this chapter was OrbixWeb. It is important to recognize that OrbixWeb adheres to the security restrictions imposed on Java applets executing within Web browsers by only allowing ORB calls back to the host from which the applet was dynamically downloaded. As a consequence, the Notebook server must reside on the same machine as the Web server. This restriction has architectural ramifications which will be discussed later in the chapter. A side effect of the necessity to select a specific Java-enabled ORB product to create and compile the examples in this chapter is that some of the client-side syntax presented may be specific to the chosen ORB. However, most, if not all, of the points and concepts presented here will apply to all reasonably capable Java-enabled ORBs.
Figure 17.1 : User Interface of the sample Notebook applet.