Google Guice

Abstract

Development of Eclipse RCP as a rich client of the multi-tier Java Enterprise application becomes an an interesting alternative to other frontend technologies. An important aspect is the ability to develop and test the frontend independent from the backend. In this article, an approach for testing and de-coupling of server and client development in Eclipse RCP is introduced.

Business Delegate, Service Locator and Dependency Injection

In a Java multi-tier application, the business logic is implemented in form of server-hosted components (EJB, Spring Beans, OSGi Services, etc…). In this example, the EJB Backend is used, but it can be easily replaced with other technologies mentioned previously. A rich client is connected to the server using some remoting technology and contains a local storage for the client-specific state, which allows to build more complex and reactive applications. A common approach to hide the aspects of remote invocations on the client side is the use of Business Delegate enterprise design pattern. My favorite way of implementing it is to define the technology-independent business interface (POJI = Plain Old Java Interface) and implement it on the server side by the server beans and on the client side by the business delegates. This article uses the following business interface as example:

public interface MyBusinessService extends BaseBusinessService {

	/**
	 * Full qualified name of the interface (used for Binding).
	 */
	String IF_FQN = "....MyBusinessService";

	/**
	 * Does something on server.
	 *
	 * @param parameter Parameter of invocation.
	 * @return Result of execution.
	 */
	List<OperationResultDto> doSomeStuff(ParameterDto parameter);
}

The delegates make use of the Service Locator design pattern. Here is an example, how the implementation of the Base Facade can look like, which is a superclass of all business delegates:

public abstract class BaseFacade {
...
	/**
	 * Delegates a call to a stateless session bean on the server.
	 *
	 * @param <T> type business interface
	 * @param iterfaze business interface
	 * @param jndi binding on the server
	 * @return result of invocation
	 */
	public static <T> T delegate(Class<T> iterfaze, String jndi) {
		return Activator.getDefault().getServiceLocator().getStateless(iterfaze, jndi);
	}

	/** ... */
	public static void debug(String message) {...}
}

The ServiceLocator.getStateless() method is hiding the lookup of the remote EJB. Using the BaseFacade, the business delegate looks as following:

public class MyBusinessServiceFacade extends BaseFacade implements MyBusinessService {

	public List<OperationResultDto> doSomeStuff(ParameterDto parameter) {
		debug("entering doSomeStuff(ParameterDto)");
		final List<OperationResultDto> result = delegate(MyBusinessService.class, MyBusinessService.IF_FQN)
				.doSomeStuff(parameter);
		debug("leaving doSomeStuff(ParameterDto)");
		return result;
	}

}

This setup results in a following architecture:

Architecture

Business Delegate Boilerplate

The setup looks good in theory, but in fact it is pretty boring to program on the client side. You can reduce the effort of creating business delegates (in fact I use MDSD techniques and Xtext to generate it), but in every place a service is required, the business delegate is instantiated directly. The approach works, but it just not nice, because you reference the implementation directly.

A common approach to avoid writing the code of direct instantiation is the usage of Dependency Injection frameworks. A very popular one is Google Guice, which is used in this article. The essential idea of Google Guice is to configure the binding between the dependency and its resolution and use Google Guice as a kind of factory to create instances and inject dependencies in it. For the creation of the binding, Guice offers a class AbstractModule to subclass from.

public class ServiceFacadeModule extends AbstractModule {

	/**
	 * @see com.google.inject.AbstractModule#configure()
	 */
	@Override
	protected void configure() {
		bind(MyBusinessService.class).to(MyBusinessServiceFacade.class);
	}
}
...
public class InjectorHolder {
...
	private Injector injector;

	public static void configureInjector(AbstractModule module) {
		InjectorHolder.getInstance().setInjector(Guice.createInjector(module));
	}

	/**
	 * Creates an instance of a class.
	 *
	 * @param <T> type of the class
	 * @param clazz type to create
	 * @return a instance with injected dependencies
	 */
	public static <T> T get(Class<T> clazz) {
		return getInstance().getInjector().getInstance(clazz);
	}
...
}

In order to hide references to Guice classes in client code, the DI can be encapsulated inside of a InjectorHolder, which acts as factory for instances with service references:

/**
 * Class with a reference.
 */
public class DataSource {

	/**
	 * Reference to the service.
	 */
	private MyBusinessService myBusinessService;

	@Inject
	public void setMyBusinessService(MyBusinessService myBusinessService) {
		this.myBusinessService = myBusinessService;
	}
}
/**
 * Client which requires the data source with injected references.
 */
public class MyView {

	/**
	 * Let Google Guice create the instance and inject dependencies.
	 */
	private DataSource source = InjectorHolder.get(DataSource.class);
}

Please note, that the data source is using setter-injection for the service implementations and the InjectorHolder as a factory to create an instance of data source with injected reference.

Packaging Guice

After this short introduction of Guice, it is time to package this 3rd-party library into the Eclipse RCP client. In fact it is all about putting the JARs (guice-2.0.jar, aopalliance-1.0.jar) into some folder inside of the client plug-in and modifying the MANIFEST.MF so that the JARs are on the bundle class-path and the packages are listed as “exported”.

What about mock?

After the client has the ability to use business delegates it can access the business functionality of the server. In fact this requires that the server is already implemented. In order to decouple the client from the server development, mocks can be used. Mocks are popular in context of Unit tests, but can be used to simulate behavior of server implementation as well. Since mocks should not be delivered into production it is a good idea to put them into a separate mock plug-in, included into the special mock feature. The mock plug-in should export its packages. These should be imported by the main plug-in, instead of defining of a dependency on the mock plug-in directly. The mock feature is included in the product / top-level feature as an optional feature. This specific configuration allows the main plug-in to instantiate classes from the mock plug-in, if this is delivered, but doesn’t produce errors if the mock plug-in is not included into release.

Since the business delegate implementes the business interface, its mock should also do so:

public class MyBusinessServiceMock implements MyBusinessService {

	public List<OperationResultDto> doSomeStuff(ParameterDto parameter) {
		debug("entering doSomeStuff(ParameterDto)");
		final List<OperationResultDto> result = new ArrayList<OperationResultDto>();
		result.add(new OperationResult(parameter.getValue()));
		debug("leaving doSomeStuff(ParameterDto)");
		return result;
	}
...
}

Since the mocks should also be injected by Guice, we define the binding module as well.

public class ServiceMockModule extends AbstractModule {
	protected void configure() {
		bind(MyBusinessService.class).to(MyBusinessServiceMock.class);
	}
}

Finally, we got two implementations and two Guice’s AbstractModule implementation binding them. The last missing piece is the dynamic configuration which allows to switch between them easily. For this purpose we use the extension-point mechanism of Eclipse and define the following extension point (all documentation elements are removed for readability):

<schema targetNamespace="..." xmlns="...">
   <element name="extension">
      ...
      <complexType>
         <sequence><element ref="moduleConfiguration" minOccurs="1" maxOccurs="unbounded"/></sequence>
         <attribute name="point" type="string" use="required"></attribute>
         <attribute name="id" type="string"></attribute>
         <attribute name="name" type="string"></attribute>
      </complexType>
   </element>
   <element name="moduleConfiguration">
      <complexType>
         <attribute name="moduleClassname" type="string" use="required">
            <annotation>
               <appInfo><meta.attribute kind="java" basedOn="com.google.inject.AbstractModule:"/></appInfo>
            </annotation>
         </attribute>
         <attribute name="priority" type="string" use="required"></attribute>
      </complexType>
   </element>
</schema>

Using this definition, the plug-in can extend the main plug-in, by providing moduleConfigurations, which is a class name of the class extending the Guice AbstractModule and the priority. Using the following utility class, the module configurations can be read:

public class PluginUtility {

	public static TreeMap<Integer, AbstractModule> getModuleConfigurations() throws CoreException {
		final TreeMap<Integer, AbstractModule> moduleConfigurations = new TreeMap<Integer, AbstractModule>();
		IExtension[] moduleConfigurationExtensions = Platform.getExtensionRegistry().getExtensionPoint("...id...").getExtensions();
		for (IExtension moduleConfiguration : moduleConfigurationExtensions) {
			for (IConfigurationElement configElement : moduleConfiguration.getConfigurationElements()) {

				AbstractModule module = (AbstractModule) configElement.createExecutableExtension("moduleClassname");
				String priorityAsString = configElement.getAttribute("priority");
				int priority = 0;
				try {
					priority = Integer.parseInt(priorityAsString);
				} catch (NumberFormatException e) {
					throw new CoreException(...);
				}

				moduleConfigurations.put(Integer.valueOf(priority), module);
			}
		}
		return moduleConfigurations;
	}
}

Using this utility, the main plug-in can read in available AbstractModules available in runtime and configure Dependency Injection. Before the usage of InjectorHolder this should be configured. We use higher priority (bigger number) as a reason to select the AbstractModule.

public class InjectorHolder {
...
	private Injector injector;

	public static InjectorHolder getInstance() {
		if (instance == null) {
			instance = new InjectroHolder();
			injector = Guice.createInjector(PluginUtility.getModuleConfigurations().lastEntry().getValue());
		}
		return instance;
	}
...
}

Finally, the two binding modules should use the extension-point. The plug-in containing the business delegates should define the module configuration with a “standard” priority:

   <extension
         point="....ModuleConfiguration" name="ModuleConfiguration">
      <moduleConfiguration
            moduleClassname="....ServiceFacadeModule"
            priority="1">
      </moduleConfiguration>
   </extension>

The mock plugin should define a higher priority, which would win against the business delegate, if included into release.

   <extension
         point="....ModuleConfiguration" name="ModuleConfiguration">
      <moduleConfiguration
            moduleClassname="....ServiceMockModule"
            priority="10">
      </moduleConfiguration>
   </extension>

Summary

In this article, an implementation approach for business delegates and service locator patterns is shown. Usage of Google Guice Dependency Injection framework allows for a flexible resolution of dependency in client code. Since it doesn’t support multiple binding configurations, we introduce a self-defined extension point, which allows to register different DI-Configuration modules and assign different priorities to them. In addition, we use the ability of Eclipse to define and use optional feature, to foster runtime-based configuration. Using different “Run Configurations”, you can start the RCP client with different implementation of your business services. If the mock plug-in is included, its higher priority will win against the business delegates. Therefore the development of the client can be performed using mock objects instead of real business delegates without any additional configuration.

Have Fun…