ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Achieving Inversion of Control with Eclipse RCP
Pages: 1, 2, 3, 4

A Sample Eclipse RCP Application

We now have all the elements to build the application. Our sample application will be used to show the user interesting epigrams and citations, such as the fortune cookies. It will be composed of four plugins:



  • the Service Locator plugin, which contributes the IoC framework
  • the FortuneService plugin, which contributes the service that manages the fortune cookies
  • the FortuneInterface plugin, which publishes the public interfaces needed to access the service
  • the FortuneClient plugin, which contributes the Eclipse application and shows the epigrams formatted into an Eclipse view

The IoC design we adopted keeps the service implementation separated from the client; the service implementation can now be changed or modified, leaving the client unaffected. Figure 2 shows the dependencies between plugins.

The dependencies between plugins
Figure 2. The dependencies between plugins: the ServiceLocator and the interface definition keep the service and the client separated.

As described in the previous sections, the Service Locator will bind together the client and the service in order to show the epigrams to the user. The FortuneInterface only defines the public interface IFortuneCookie, which clients can use to access the cookie message:

public interface IFortuneCookie {
        
        public String getMessage();

}

The FortuneService plugin provides a simple service factory that creates implementations of IFortuneCookie:

public class FortuneServiceFactory 
  implements IServiceFactory {

    public Object getServiceInstance() 
    throws ServiceException {

        return new FortuneCookieImpl();
    }

  // ... omissis ...

}

The factory is registered to the service locator plugin as an Eclipse extension, as described by its plugin.xml descriptor file:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension
  point="com.onjava.servicelocator.servicefactory">
  <serviceFactory
    class="com.onjava.fortuneservice.FortuneServiceFactory"
    id="com.onjava.fortuneservice.FortuneServiceFactory"
    name="Fortune Service Factory"
    resourceClass="com.onjava.fortuneservice.IFortuneCookie"/>
</extension>

</plugin>

Here, the resourceClass attribute defines the class of the services provided by this factory. The described service is used by the Eclipse view defined in the FortuneClient plugin:

@Serviceable
public class View 
  extends ViewPart {

    public static final String ID = 
    "FortuneClient.view";
    
    private IFortuneCookie cookie;

    @Injected(optional=false) 
  public void setDate(IFortuneCookie cookie) {
        this.cookie = cookie;
    }

    public void createPartControl(Composite parent){
        Label l = new Label(parent,SWT.WRAP);
        l.setText("Your fortune cookie is:\n"
      + cookie.getMessage());
    }

    public void setFocus() {}
}

Notice the presence of the Serviceable and Injected annotations to define the dependencies on external services, and the absence of any reference to the code that provides the service. The final result is that createPartControl() is free to use the cookie object with the guarantee that it has been properly initialized. The sample application is shown in Figure 3.

The sample application
Figure 3. The sample application with a fortune cookie retrieved from the service plugin

Conclusion

In this article I have discussed how to merge a powerful programming pattern that simplifies the handling of code dependencies (Inversion of Control) with an emerging technology that speeds up the development of Java client applications (Eclipse RCP). Even if I have not dealt with the many details that affect the problem, I have demonstrated a sample application where services and service clients are decoupled. I have also described how the Eclipse plugin technology can preserve the separation of concerns when developing both clients and services. However, there are lot of interesting elements still to explore, such as the cleanup strategies to use when the services are no longer needed, or the ways to perform unit testing on our client plugins using mock-up services, which I'll leave to the reader.

Resources

Riccardo Govoni has been working since 2003 as a J2EE developer for a financial services company in the northern part of Italy.


Return to ONJava.com.