Business Logic Partitioning

In HTML-based WebObjects applications, all business logic (and the business objects that use that logic) lives on the server. Business objects are never sent to the client (the Web browser). Rather, selected data from those business objects is sent along with HTML user interface data.

In Java Client, however, business objects are sent to the client application for performance reasons. Java Client applications generally access more data than do distributed HTML applications. To limit the number of round trips to the server, copies of the business objects containing the data live on the client.

While this helps performance, it also presents security issues. In Java Client, business objects are Java objects, which can be decompiled and analyzed quite easily. So you never want to send sensitive business objects (objects containing private algorithms or data) to the client.

To control which business objects are sent to the client, you use business logic partitioning. As well as securing business data, business logic partitioning can also improve performance. The key to business logic partitioning is to minimize the amount of data sent from server to client while simultaneously minimizing the number of round trips over the network.

package example.common;

import com.webobjects.eocontrol.*;

public abstract class Foo extends EOGenericRecord {

    public abstract String bar();

}

package example.client;

import com.webobjects.eocontrol.*;

public class Foo extends example.common.Foo {

    public String bar() {

     return (String) invokeRemoteMethod("clientSideRequestBar", null, null);

    }

}

package example.server;

import com.webobjects.eocontrol.*;

public class Foo extends example.common.Foo {

    public String bar() {

        return "secret string";

    }

    public String clientSideRequestBar() {

        return bar();

    }

}

Remote Method Invocations

In Java Client applications, you may want some methods to execute only on the server for both security and performance reasons, such as when the method consumes a lot of system resources. Java Client defines two categories of remote method invocations: those that apply to business logic and those that apply to application logic.

public void calculateRating() {

    invokeRemoteMethod("clientSideRequestCalculateRating", new Class[]          {NSArray.class}, new Object[] {globalIDs});

}

private EODistributedObjectStore _distributedObjectStore() {

    EOObjectStore objectStore = EOEditingContext.defaultParentObjectStore();

    if ((objectStore == null) || (!(objectStore instanceof EODistributedObjectStore))) {

        throw new IllegalStateException("Default parent object store needs to be an

          EODistributedObjectStore");

        }

        return (EODistributedObjectStore)objectStore;

}

_distributedObjectStore().invokeRemoteMethodWithKeyPath(<arguments>);

Custom Code in Business Logic

There are a few things you need to know about using custom code in business logic classes. If you write methods that perform computations that require values in the enterprise object, two methods are provided to help you know when to invoke the custom computations: awakeFromClientUpdate and prepareValuesForClient.

The awakeFromClientUpdate method is invoked after the EOGenericRecord subclass on the server receives a notification that all the business objects have been received from the client. If you try to invoke a method from one of the class’s set methods that performs a computation using values of attributes in your business logic, there is no guarantee that the server-side object has received all the values from the client you use in that calculation. However, if you invoke the method with said calculation in awakeFromClientUpdate, you are guaranteed to have all the business data from the client.

The prepareValuesForClient method is invoked in the EOGenericRecord subclass right before the business objects are sent back to the client (it is actually invoked right before the objects are encoded). You can override it to set a value before it is sent to the client if the value is only a client-side class property.

Distribution Layer Objects

The distribution layer’s client-server communication mechanism relies on four objects: com.webobjects.eodistribution.WOJavaClientComponent, com.webobjects.eodistribution.EODistributionContext, com.webobjects.eodistribution.client.EODistributedObjectStore, and com.webobjects.eodistribution.client.EODistributionChannel.

The flow of information works like this: The client editing contexts talk to the EODistributedObjectStore (client side), which uses an EODistributionChannel to transfer objects across the network to the WOJavaClientComponent object, which uses an EODistributionContext to talk to the server-side editing context and to take care of generating responses to client requests. This flow is illustrated in Figure 5-1.

Let’s examine each of these objects.

EODistributedObjectStore is the parent object store for all the editing contexts on the client. It makes the client editing contexts behave like a nested editing context to the server-side editing context. Its function is similar to that of the EODatabaseContext object, which lives on the server.

EODistributionChannel is responsible for sending data from the client to the server (it actually encodes the data).

The WOJavaClientComponent object is the target of the data sent by EODistributionChannel. It forwards data from the client’s EODistributionChannel to the server’s EODistributionContext. It is provided to isolate the application from different deployment environments and also plays a large role in application startup. It is also the object that embeds Java Client in a WebObjects application.You can learn more about application startup by reading the API reference documentation for the distribution layer classes and the application-level classes in the application layer.

EODistributionContext has many functions: It keeps track of the state of the enterprise objects graph; it tracks which objects the client has fetched; and perhaps most importantly, it synchronizes business objects on the client and server applications.

Data Synchronization

The distribution layer is responsible for synchronizing the client and server object stores. The data flow in a Java Client application occurs like this:

1. The user makes a query and the fetch specification is forwarded by the client’s EODistribution layer to the server’s EODistribution layer.

2. The normal WebObjects mechanisms take over, and a SQL call is eventually made to the database server.

3. The database server returns rows of requested data; these rows are mapped to enterprise object instances.

4. The server’s EODistribution layer sends copies of the requested data to the client.

5. The client’s EODistribution layer receives the objects and registers them with the client’s editing context (the data is cached in the client’s object graph).

6. Through the client’s display group and association mechanisms, the user interface is populated.

As users modify the data (or delete or add rows of data), the client’s object graph is updated to reflect the new state. When users request that this data be saved, the changed object graph is pushed to the server. If the business logic on the server validates these changes, the changes are committed to the database.

Synchronization of the client and server’s object graphs occurs automatically: Java Client automatically pushes updates from the server to the client.

Using SSL

The distribution channel in Java Client (EODistributionChannel) distributes data between the client and server applications. By default, Java Client uses HTTP as the transport mechanism (EOHTTPChannel), but you can subclass EOHTTPChannel to provide a custom mechanism such as SSL. Assuming that you’re using Sun’s JSSE SSL classes, you can use the class in Listing 5-1.

Listing 5-1  Subclass EOHTTPChannel to use SSL

package com.mycompany.client;

import java.io.*;

import java.net.*;

import java.security.*;

public class SSLChannel extends com.webobjects.eodistribution.client.EOHTTPChannel {

    static {

        System.setProperty("java.protocol.handler.pkgs",

          "com.sun.net.ssl.internal.www.protocol");

        Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

    }

    public Socket createSocket(String protocol, String hostName, int portNumber) throws          IOException {

        if (!"https".equals(protocol)) {

            return super.createSocket(protocol, hostName, portNumber);

        }

        Socket socket =

           javax.net.ssl.SSLSocketFactory.getDefault().createSocket(hostName, 443);

        socket.setTcpNoDelay(true);

        return(socket);

    }

}

Make sure to add this subclass to the Web Server (client application) target in your project.

After you add this class, you need to add a binding on the server-side distribution layer component to tell the application to use the custom subclass. Add a binding to the JavaClient.wo component called distributionChannelClassName. Its value is the fully qualified name of the distribution layer subclass that uses SSL. Using the subclass in Listing 5-1, this is com.mycompany.client.SSLChannel.

If you’ve already configured your Web server to use SSL, there are no more steps to perform to use SSL in Java Client applications. Unfortunately, configuring a Web server to use SSL, obtaining SSL certificates, and other tasks necessary to implement a secure protocol are rather complicated tasks and are beyond the scope of this document.

However, if you’re deploying on Mac OS X, the included Apache Web server includes the mod_ssl module and documentation for configuring SSL. See file:///Library/Documentation/Services/apache_mod_ssl/ssl_overview.html on a Mac OS X system.

Delegates

Since the Java Client distribution layer is rather complex, it provides a number of delegates you can use to customize its behavior, which saves you from subclassing. You can set delegates for EODistributionContext and EODistributionChannel to

• change the security mechanism for validating remote method invocations

• implement a custom encryption and decryption scheme for data transfer over the network

• control access to business objects

• handle client-side I/O exceptions

• handle server-side exceptions such as validation, null pointer exceptions, and session timeouts

The default delegate of the distribution layer is the application’s Session object. This is set in the EODistributionContext’s constructor and you set custom delegates with the setDelegate method in EODistributionChannel and EODistributionContext, as described in Setting the Delegate. Because the Session object is the default delegate, you can override the methods that are defined in the EODistributionContext.Delegate class in the Session class and they will be found and invoked by the distribution layer automatically.

To secure access to the data sources with which the server-side application communicates, you override methods defined in the class EODistributionContext.Delegate. A common design pattern is to override all the methods in the delegate class to return true only if a user has authenticated. The easiest and most common way to do this is to store the state of a user’s login in the Session object, as is described in Building a Login Window and as shown in the JCDiscussionBoard example project.

Assuming that you store a user’s authenticated state in an instance variable (isAuthenticated) in the Session class, you can use the code in Listing 5-2 to prevent unauthenticated access to the data store. By restricting access to the class description of entities in the application, you restrict access to and editing of all entities in the application.

Listing 5-2  Use a delegate to restrict access to data

public boolean distributionContextShouldAllowAccessToClassDescription(

     EODistributionContext context, EOClassDescription classDescription) {

     return (isAuthenticated());}

Other delegates defined in EODistributionContext.Delegate allow you to control whether editing contexts are allowed to save, whether particular fetch specifications are allowed to be invoked, and whether the target methods of remote method invocations are allowed to be invoked. There are also two methods you can use to encrypt and decrypt data across the wire, though using SSL as the EODistributionChannel protocol is probably a better idea to secure client-server communications. See the API reference for EODistributionContext.Delegate for more details.

Setting the Delegate

To set the distribution context’s delegate, you need to know when the distribution context has been instantiated. You can use the code in Listing 5-3 to listen for the notification that is sent immediately after the distribution context is instantiated and to invoke custom behavior after that event has occurred.

Listing 5-3  Set the distribution context’s delegate

import com.webobjects.foundation.*;

import com.webobjects.appserver.*;

import com.webobjects.eocontrol.*;

import com.webobjects.eodistribution.*;

public class Session extends WOSession {

    public EODistributionContext dContext = null;

    public MyDistributionDelegate myDelegate = null;

    public Session() {

        super();

        myDelegate = new MyDistributionDelegate();

        NSNotificationCenter.defaultCenter().addObserver(this,

            new NSSelector("listenForContext", new Class[] { NSNotification.class } ),

            EODistributionContext.DistributionContextInstantiatedNotification, null);

    }

    public void listenForContext(NSNotification notification) {

        dContext = (EODistributionContext)notification.object();

        dContext.setDelegate(myDelegate);

    }

}

In Session’s constructor in Listing 5-3, the class registers with the default notification center to listen for the EODistributionContext.DistributionContextInstantiatedNotification notification. When that notification is received from the notification center, the method specified with the NSSelector argument (the method named listenForContext, which takes a single NSNotification object as an argument) is invoked. The listenForContext method is passed a reference to the distribution context object on which it invokes setDelegate. It sets the delegate to a custom class called MyDistributionDelegate, which is instantiated in Session’s constructor.

To set the delegate for the distribution channel object, simply replace EODistributionContext in Listing 5-3 with EODistributionChannel.