O BJETIVOS E STRATÉGICOS

For security purposes, each function in your NotebookIF IDL interface requires that a user name and password be included as two of the function parameters. But suppose that the need for this information was just an afterthought, and that your original interface definition did not require these parameters for every call. Depending on the number and complexity of the clients dependent on your server, it could be problematic to recode each client applet and the server functions to provide and accept the user name and password with every call. The functionality provided by filters can simplify this problem (not all available ORBs provide filter-type

functionality).

The idea behind filters is that they intercept outgoing and incoming ORB calls at various points in the ORB's request marshalling and unmarshalling process. At each of these interception points, data can be added to or removed from the ORB request. There are various imaginable uses for the utility of filters (encryption, bookkeeping, and so on), but, for your notebook applet and server, the new necessity to verify access on each ORB call can be addressed using a client-side and server-side filter without requiring a change to any preexisting client or server code. What your client-side filter will need to do is piggyback each outgoing ORB call with a user name and password. A server-side filter will then be written to extract them and assess authorization, raising a system exception if authorization does not succeed.

Your Java-enabled ORB supports filtering functionality by enabling the implementation of a user-defined filter class. This class must inherit from the ORB's built-in filter class. The point in the marshalling process where your authorization data is added to the ORB request is dictated by the filter function which you choose to override in the filter class (see Figure 17.3). In the filter class defined in Listing 17.23, the user name and passwords are added to any outgoing ORB request prior to the marshalling and creation of the outgoing request packet. Because the outgoing request object is passed to the filtering functions, the functionality of the

DII::Request class, as described earlier in this chapter, can be used to add the user name and passwords to the outgoing ORB

Chapter 17 -- Creating CORBA Clients

call.

Figure 17.3 : User defined filters enable examination and modification of function parameter values during the marshalling and

unmarshalling of ORB function calls.

Listing 17.23 Implementation of PiggybackFilter Class

import IE.Iona.Orbix2.CORBA.SystemException; import IE.Iona.Orbix2.CORBA.Request;

import java.io.*;

public class PiggybackFilter extends IE.Iona.Orbix2.CORBA.Filter {

public boolean outRequestPreMarshal(Request request) {

try{request.insertString(userName);}

catch(IE.Iona.Orbix2.CORBA.SystemException ex)

{System.out.println("Outgoing filter failure"); return false;} try{request.insertString(password);}

catch(IE.Iona.Orbix2.CORBA.SystemException ex)

{System.out.println("Outgoing filter failure"); return false;} return true;

} };

To register the filter object with the client ORB, the filter's constructor should be called prior to the first ORB call.

Some Points About Distributed System Architecture

When developing a distributed application, one of the early tasks is to settle on an overall software architecture. While this is not a book on distributed system architecture, an exploration of some of the architectural possibilities and how they relate to and can be addressed by the combination of Java and CORBA is appropriate. The architecture of your notebook client and server system, illustrated in Figure 17.4, is straightforward. As a matter of fact, if it were not for the possible use of client- and server-side filters to support authorization and maybe encryption, there could not be a more simplistic Web/Java/CORBA-based architecture.

Figure 17.4 : The two-tier, distributed architecture of your Notebook application supports multiple clients and has collocated Web

server and ORB server processes to adhere to the Java applet client/server connectivity restrictions.

The only potential point of complexity here is the necessity for the notebook server to support multiple concurrent client applets. But this point of complexity is standard issue for any client/server application. The solutions here vary depending on the client's need to support read-write and read-only control over information accessed from the server, or whether a simple first-come/first-served approach will suffice. Of particular note in your notebook system architecture is the collocation of the Web server application and the ORB-based application. Because Java's security model prefers that client applets make network connections only back to the host from which they originated, it may be an architectural necessity to collocate the Web server and the ORB-based application. This does not present a problem for your simple notebook application, but with more sophisticated applications, it may be a problem which must be worked around. (Some ORB vendors have developed client-side Java libraries that work with this aspect of the Java security model to obviate this issue.)

Chapter 17 -- Creating CORBA Clients

Figure 17.5 is an example of an application architecture which works with, but around, the inability to access only a single host from a Java/ORB-based applet. This architecture is applicable when there is a need for client applets to request the services of multiple ORB- based servers residing on multiple hosts. The primary difference with this architecture is the existence of an application proxy server. This ORB-enabled server is called by all client applets for any server request. The parameters sent with each client request are examined by the application proxy to determine which host and server it should forward the call to. It then forwards the call to the target host and server, returning any output parameters to the originating client.

Figure 17.5 : Distributed architecture with an applications proxy server to indirectly support multi-host applet connectivity while

adhering to the Java applet client/server connectivity restrictions.

There are a few important ramifications of this architecture. As discussed earlier in this chapter, IDL interfaces can be very fine- grained and specific or more coarse and general purpose. The notebook server example has a very specific IDL interface. Because the notebook server is rather simplistic and because the server's client applet is likely to be the only client application, having a less generic interface is not likely to present a problem. In contrast, however, the application proxy server in Figure 17.5 must be able to forward function calls to multiple-target applications and potentially support many different clients. So it is preferable that its IDL interface be very generic and inherently extensible. It would not be good if each introduction of a new target application resulted in the need to significantly change the IDL interface and the implementation code of the application proxy. Given this, the application proxy server, in its simplest form, could have a single function capable of handling a call targeted for any function in any of the target applications. The IDL definition of this function could take the form shown in Listing 17.24.

Listing 17.24 IDL Definition of a Generic Application proxy Function

NVPairListType performOperation(in string targetApp,

in string targetInterface, in string targetFunction,

in NVPairListType inParameters);

Using the proxy function, the client provides the names of the target application (a CORBA-enabled server), IDL interface, and function to indicate where the application proxy should forward the call. Any input and output parameters are provided and returned using a list of name/value pairs. There are several variations on the specific signature of this function, but the intent is always the same: To provide a single generic interface to one or more specific services in support of client/server extensibility.

As you have probably ascertained, an additional ramification of this architecture is the requirement that client applets be able to deal with the generic nature of the application proxy interface. More specifically, each client ORB call requires creation and population of a name/value pair list, and examination of the returned name/value pair list. While this process can be simplified using the various DII and IR facilities of the ORB, it is an unfortunate reality of generic IDL interfaces. The advantages of loose coupling of clients and servers do not come without a price. It is worth pointing out that your application proxy server is just one example of the need to decouple client and servers by defining generic IDL interfaces. This architectural technique is not specific to the marriage of Java applets and CORBA servers. Many existing distributed systems were built on this very paradigm.

There are certainly other architectural possibilities which may provide a more appropriate solution to a given problem. For example, a downfall of both previously described architectures is the lack of scalability in the face of high client demand on the servers. In both cases, there is a single host supporting the throughput demands of all clients, a classic shortcoming of 2-tier client/server architectures. As illustrated in Figure 17.6, one architectural solution is to create a 3-tier architecture by pushing the server's persistent data store to a commonly accessible host and establishing two or more server hosts, each having resident Web-server and ORB-server applications.

Figure 17.6 : A distributed architecture with three tiers and multiple ORB server processes can support greater scalability.

The complexity to manage with this solution is concurrent data access attempts fromthe now multiple ORB servers. However, most of

Chapter 17 -- Creating CORBA Clients

the more capable object and relational database products provide mechanisms to support multiple concurrent clients. The notebook server referred to in this chapter, for example, uses an object-oriented database for its persistent storage mechanism. It is certainly feasible to implement the notebook server such that it utilizes the distribution, transaction, and locking mechanisms provided by the OODBMS to support multiple notebook servers accessing the single persistent store of notebook information.

file:///E|/Java%20Professor/Hacking%20Java%20Professional%20Resource%20Kit/f17-1.gif