Just started to develop a small application in Scala running on a standard enterprise java stack. You can find more details on github: https://github.com/holisticon/ranked.

Today, I’ll post some details on the persistence layer. The idea is to use Scala case classes and JPA as a persistence layer. For simple attributes it looks very cute:

/**
 * Superclass for all persistent entities.
 */
@MappedSuperclass
abstract class PersistentEntity(
  @BeanProperty @(Column @field)(name = "ID")@(Id @field)@(GeneratedValue @field)(strategy = GenerationType.AUTO) id: Long,
  @BeanProperty @(Column @field)(name = "VERSION")@(Version @field) version: Long) {
  def this() = this(-1, -1);
}

/**
 * Represents a player. A player has a name, initial and current ELO ranking.
 */
@Entity
@Table(name = "PLAYER")
case class Player(
  @BeanProperty @(Column @field)(name = "NAME") name: String) extends PersistentEntity {

  def this() = this(null);
}

/**
 * Represents a team. A team contains of et least one player and might have a name.
 */
@Entity
@Table(name = "TEAM")
case class Team(
  @BeanProperty @(Column @field)(name = "NAME") name: String) extends PersistentEntity {

  def this() = this(null);
}

Stay tuned about the development progress.

• Download Eclipse 3.6.1 Classic
• Add the tow following Update Sites to the Update Manager:
  Xpand: http://download.eclipse.org/modeling/m2t/xpand/updates/nightly/
  MWE: http://download.eclipse.org/modeling/emft/mwe/updates/nightly/
• Download the TMF 2.0 M6 Update Site from Eclipse TMF Site and add it as a local update site
• Install all TMF Features from the archive update site
• Restart Eclipse and Enjoy Xtext 2.0!

Thanks to Dennis Huebner for the hints….

One of the interesting aspects of databinding is data validation. The update strategies, responsible for propagation of changes in models or in widgets can be supplied with validators, making sure that the data changes are legal. In the same time the JSR-303 Bean Validation specification focuses on a modern standardized way of data validation. In this post, I combine these subjects and use JSR-303 in JFace Databinding Validators.

One of the core insights of the JSR-303 is the idea of annotation of data validation constraints on data itself. It is indeed a good observation, that validation code strongly relies on the data structure and semantics. To follow this idea consequently, the application developer should care of validation during implementation of business logic as less as possible. A much better idea is to encapsulate the entire validation into domain-specific types. Let me demonstrate it by example, imagine the following class:

public class Customer {
  private String name;
  private String address;
  private String zip;
  private String city;
}

This is perfectly reasonable, but now consider not only the data storage/transport aspects, but also the validation aspects. A standard approach would be to use the following validator logic, in the databinding:

public class CustomerComposite {
[...]
  public void bindValues(Customer model, DataBindingContext dbc) {
    UpdateValueStrategy m2t = new UpdateValueStrategy();
    m2t.setAfterGetValidator(new IValidator() {
      @Override
      public IStatus validate(Object value) {
        String name = (String) value;
        if (name == null || Helper.isRegex(name, "[A-Za-z -]*")) {
          return ValidationStatus.error("Wrong name");
        }
          return ValidationStatus.ok();
        }
      });
    dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(namefield),
      BeanProperties.value(Customer.class, "name").observe(model),
      new UpdateValueStrategy(), m2t);

    m2t = new UpdateValueStrategy();
    m2t.setAfterGetValidator(new IValidator() {
      @Override
      public IStatus validate(Object value) {
        String zipCode = (String) value;
        if (zipCode == null || zipCode.length() > 5 || zipCode.length() < 5 || Helper.isRegex(zipCode, "[0-9]*")) {
          return ValidationStatus.error("Wrong zip code");
        }
          return ValidationStatus.ok();
        }
      });
    dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(zipfield),
      BeanProperties.value(Customer.class, "zip").observe(model),
      new UpdateValueStrategy(), m2t);
  [...]
  }

Pretty much code, and rememeber that JFace Databinding code like this can not be reused in other parts of the application. Let’s put the validation logic on the data declaration in a way how JSR-303 proposes to do this:

public class Customer {
  @NotNull
  @Pattern(regexp = "[A-Za-z -]*")
  private String name;
  private String addressLine;
  @Size(min=1, max=5)
  @Pattern(regexp = "[0-9]*")
  private String zip;
  @NotNull
  @Pattern(regexp = "[A-Za-z -]*")
  private String city;
}

As a next step, let us develop an update strategy factory which create update strategies with embedded Validator for JSR-303 Bean Validation constaints.

public class BeanValidator implements IValidator {
  private ValidatorFactory factory = Validation.buildDefaultValidatorFactory();

  @Override
  public IStatus validate(Object value) {
    Set<ConstraintViolation<Object>> violations = factory.getValidator().validate(value,
      new Class<?>[] { Default.class });
    if (violations.size() > 0) {
      List<IStatus> statusList = new ArrayList<IStatus>();
      for (ConstraintViolation<Object> cv : violations) {
        statusList.add(ValidationStatus.error(cv.getMessage()));
      }
      return new MultiStatus(Activator.PLUGIN_ID, IStatus.ERROR,
        statusList.toArray(new IStatus[statusList.size()]), "Validation errors", null);
    }
    return ValidationStatus.ok();
  }
}

public class StrategyFactory {
 public static UpdateValueStrategy getStrategy() {
   UpdateValueStrategy strategy = new UpdateValueStrategy();
   strategy.setAfterConvertValidator(new BeanValidator());
   return strategy;
 }
}

Using the StrategyFactory, the validation code inside of the composite becomes trivial:

public class CustomerComposite {
[...]
  public void bindValues(Customer model, DataBindingContext dbc) {
    dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(namefield),
      BeanProperties.value(Customer.class, "name").observe(model),
      new UpdateValueStrategy(), StrategyFactory.getStrategy());

    dbc.bindValue(WidgetProperties.text(SWT.Modify).observe(zipfield),
     BeanProperties.value(Customer.class, "zip").observe(model),
     new UpdateValueStrategy(), StrategyFactory.getStrategy());
 [...]
}

An important property of the introduced validation approach is the fact, that it can be reused in other application layers (e.G. in service layer, or in data access layer). In other words you can use the same validation logic across the entire application and just remain valid…

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:

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…

Introduction

Creating your own domain-specific textual languages in Xtext is really easy, and the authors in Northern Germany are doing a good job to make it even easier. Once you have a language, you want to process it and this means usually to transform your model into another representation. The facility responsible for this transformation is called generator and consists of a bunch of transformation templates (e.G. XPand) and some code executing them. On some event, the model is read in and the transformations are applied to produce code. Currently, there are two ways of triggering the transformation: you can put the calling infrastructure in a Modeling Workflow Engine file, which is a kind of batch script or you can write a build-participant, which react on the changes in the model. In this article I want to describe my experiences with the builder approach.

Examining initial builder

The base idea behind the builder approach is the fact, that Xtext provides an project builder, which watches for all Xtext resource changes (Xtext-based DSL models) and notifies the so-called XtextBuilderParticipants. These are registered using Eclipse extension point org.eclipse.xtext.builder.participant and implement the IXtextBuilderParticipant interface:

...
public interface IXtextBuilderParticipant {
    void build(IBuildContext context, IProgressMonitor monitor) throws CoreException;
}

public interface IBuildContext {
    IProject getBuiltProject();
    List<IResourceDescription.Delta> getDeltas();
    ResourceSet getResourceSet();
    void needRebuild();
}

In order not to start completely from scratch, let us examine the builder provided in the Domain-Model-Example, delivered with Xtext. In the build method the example builder processes as follows:

• checks that the project is a Java project
• finds the generation folder
• creates an Output
• creates an Outlet and registers it in the Output
• registers a post-processor managing Java imports on the outlet
• creates the Xpand execution context
• registers the Java Beans version of the metamodel
• processes the changes and analyses if the files have to be deleted or not prior re-generation
• for all changed model elements re-generates

Quite a lot of tasks, so there is a good reason, why MWE scripts are used for generation.

Using Project natures

The first improvement I created for the builder is the ability to distinguish DSLs. The problem of triggering all XtextBuildParticipants on the change of any Xtext-based resource is that the entire Workspace gets re-generated. In my scenario, we used three DSLs and a random change caused three builders to run, even if the change has been made in another project of workspace. In order to solve this problem I used the standard Eclipse way to distinguish projects: Project Natures.

The nature I created is used as a marker for the builder and is emtpy:

public class UiNature implements IProjectNature {
	public static final String NATURE_ID = "de.techjava.dsl.uiNature";
	private IProject project;

	public void configure() throws CoreException {
        }

	public void deconfigure() throws CoreException {
	}
	public IProject getProject() {
		return project;
	}
	public void setProject(IProject project) {
		this.project = project;
	}
}

Don’t forget to register it in the plugin.xml:

   <extension point="org.eclipse.core.resources.natures"
         id="de.techjava.dsl.uiNature"
         name="User Interface DSL Project Nature">
      <runtime>
         <run class="de.techjava.dsl.userinterface.builder.UiNature" />
      </runtime>
   </extension>

As the first line in my builder I check the presence of the nature in the current project and stop building if the nature is not present:

if (!context.getBuiltProject().hasNature(UiNature.NATURE_ID)) {
	// skip projects without UI DSL nature
	return;
}

Now, what is missing is the ability to add and remove the nature to/from the project. I liked the way how Xpand/Xtend Natures are configured (using toggle action in configure menu of the project pop-up menu). What you need is a ToggleAction that can be switched on, if the nature is not present and switched off, if the nature is installed.

public class ToggleNatureAction implements IObjectActionDelegate {
	private ISelection selection;
	@SuppressWarnings("unchecked")
	public void run(IAction action) {
		if (selection instanceof IStructuredSelection) {
			for (Iterator it = ((IStructuredSelection) selection).iterator(); it.hasNext();) {
				Object element = it.next();
				IProject project = null;
				if (element instanceof IProject) {
					project = (IProject) element;
				} else if (element instanceof IAdaptable) {
					project = (IProject) ((IAdaptable) element).getAdapter(IProject.class);
				}
				if (project != null) {
					toggleNature(project);
				}
			}
		}
	}

	public void selectionChanged(IAction action, ISelection selection) {
		this.selection = selection;
	}

	public void setActivePart(IAction action, IWorkbenchPart targetPart) {
	}

	/**
	 * Toggles sample nature on a project
	 * @param project to have sample nature added or removed
	 */
	private void toggleNature(IProject project) {
	// implemetation of toggle nature ...
	}
}

In order to make an action to a toggle-action the Eclipse Command Framework, Object Contributions and the Command Core Expressions are needed. The idea is to register two actions as object contributions on the IProject using the org.eclipse.ui.popupMenus extension point and define visibility of those to be complement to each other (if one is visible the other is not) based on the object state, which is the presence of a project nature. The actions used point to the same implementation class but have different labels. The menu path to pop-up menu Project > Configure is org.eclipse.ui.projectConfigure/additions. The visibility is defined based on the objectState:

  <extension point="org.eclipse.ui.popupMenus">
      <objectContribution adaptable="true"
            id="de.techjava.dsl.userinterface.ui.addNature"
            objectClass="org.eclipse.core.resources.IProject">
         <action
               class="de.techjava.dsl.userinterface.ui.action.ToggleNatureAction"
               id="de.techjava.dsl.userinterface.ui.AddNatureAction"
               label="Add User Interface DSL Nature"
               menubarPath="org.eclipse.ui.projectConfigure/additions">
         </action>
         <visibility>
            <not><objectState name="nature" value="de.techjava.dsl.uiNature" /></not>
         </visibility>
      </objectContribution>
      <objectContribution adaptable="true"
            id="de.techjava.dsl.userinterface.ui.removeNature"
            objectClass="org.eclipse.core.resources.IProject">
         <action
               class="de.techjava.dsl.userinterface.ui.action.ToggleNatureAction"
               id="de.techjava.dsl.userinterface.ui.AddNatureAction"
               label="Remove User Interface DSL Nature"
               menubarPath="org.eclipse.ui.projectConfigure/additions">
         </action>
         <visibility>
            <objectState name="nature" value="de.techjava.dsl.uiNature" />
         </visibility>
      </objectContribution>
   </extension>

Please note, that the nature is implemented and registered inside of the generator project and the toggle action is implemented in the UI project. Finally, the code of the toggleNature method, which is the standard code for the project nature installation and removal:

...
	IProjectDescription description = project.getDescription();
	String[] natures = description.getNatureIds();

	// remove the nature
	for (int i = 0; i < natures.length; ++i) {
		// if nature exists
		if (NATURE_ID.equals(natures[i])) {
			// Remove the nature
			String[] newNatures = new String[natures.length - 1];
			System.arraycopy(natures, 0, newNatures, 0, i);
			System.arraycopy(natures, i + 1, newNatures, i, natures.length - i - 1);
			description.setNatureIds(newNatures);
			project.setDescription(description, null);
			return;
		}
	}

	// Add the nature
	String[] newNatures = new String[natures.length + 1];
	System.arraycopy(natures, 0, newNatures, 0, natures.length);
	newNatures[natures.length] = NATURE_ID;
	description.setNatureIds(newNatures);
	project.setDescription(description, null);
...

That’s it, run and right-click on the Project and then go to the Configure Menu (pretty low in the pop-up) and you will see the result:

Parameterizing generator

Domain-specific languages should cover only the real requirements and incorporate the specific decision made in the project. So far the theory, but in fact it is a trade-off and a compromise, what is a part of the language and what is too specific to be covered. The same holds for the generator: on the one hand you want the generator to solve exactly your problem, on the other hand you want to make it generic enough to cover a class of similar problems.

I faced the problem of using the generator for two teams in a big project, where the langage could be reused, but the generation infrastructure need to be slightly modified. For example, the information about the generation target folder, package prefix and the fact which artifact should be generated differred between the teams. In the same time the teams were able to agree on the same language. In order not to develop two generators, I decided to parameterize the generator and the templates.

The Xpand2/Xtend developers provided a way of parameterization of the templates using the so-called Global Variables, using the GLOBALVAR keyword. My favorite way of using it is to create a cached extension for reading the variable:

/*
 * Retrieves the boolean value of the global variable set from outside of the template
 */
cached Boolean generateService() :
    GLOBALVAR generateService == "true"
;

In order to set global variables from the build participant the XPand execution context constructor takes a Map<String, Variable> argument. The nice story about the global variables, that you can provide any objects as values. So the advantage over the usage of MWE workflow with property files read-in during processing is the big flexibility in providing the object-graphs or even statefull objects as global variable values. A good example of usage of global variable is provided in Domain-Example with Java Import Tool:

JavaImportsTool importsTool = new JavaImportsTool();
...
ctx = new XpandExecutionContextImpl(output, null,
    Collections.singletonMap(JavaImportsTool.VAR_NAME,
    new Variable(JavaImportsTool.VAR_NAME,importsTool)),
    null, null);
...

In the same time it is important to be able to load simple properties from file in the generation project. For example you could implement your own ModelProperties container, which reads properties from the file located in the generation project. For example:

public class ModelProperties extends Properties {
	/**
	 * Indicates that no timestamp is available
	 */
	private static final long NO_TIMESTAMP = -1;

	private long lastModified = NO_TIMESTAMP;
	private final IFile propertyFile;
	private final HashMap<String, Variable> globalVars;

	/**
	 * Creates a valid model properties instance
	 *
	 * @param aProject reference to the current project
	 * @param name of the property file
	 * @throws CoreException on errors
	 */
	public ModelProperties(final IProject aProject, String filename) throws CoreException {
		if (aProject == null) {
			ErrorHelper.throwCoreException("project must be not null");
		}
		if (filename == null) {
			ErrorHelper.throwCoreException("filename must be not null");
		}
		this.globalVars = new HashMap<String, Variable>();
		this.propertyFile = (IFile) aProject.findMember(filename);
	}

	public IFile getPropertyFile() {
		return propertyFile;
	}

	/**
	 * Returns the global variables.
	 * @return global variables.
	 */
	public Map<String, Variable> getGlobalVars() {
		updateProperties();
		return globalVars;
	}

	@Override
	public String getProperty(String key) {
		updateProperties();
		return super.getProperty(key);
	}

	/**
	 * Updates the properties and the global variables if the property file has
	 * been modified.
	 */
	public void updateProperties() {
		if (this.propertyFile != null && lastModified != this.propertyFile.getModificationStamp()) {
			loadProperties();
			globalVars.clear();
			for (Map.Entry<Object, Object> entry : entrySet()) {
				final String propertyName = (String) entry.getKey();
				globalVars.put(propertyName, new Variable(propertyName, entry.getValue()));
			}
		}
	}

	/**
	 * Loads the properties from the model file
	 */
	private void loadProperties() {

		try {
			if (propertyFile != null && propertyFile.exists()) {
				super.load(propertyFile.getContents());
				this.lastModified = propertyFile.getModificationStamp();
				handleSpecialProperties();
			}
		} catch (CoreException e) {
			// no model property file isn't a problem but clear the properties:
			super.clear();
			this.lastModified = NO_TIMESTAMP;
		} catch (IOException e) {
			super.clear();
			this.lastModified = NO_TIMESTAMP;
		}
	}

	protected void handleSpecialProperties() {

	}
}

Using this class you can simple initialize the XPandExecutionContext with properties read from the file system. So in build-Method of your Generator put something like:

         ModelProperties structureProperties = new ModelProperties(context.getBuiltProject(), "structure.properties");
         XpandExecutionContextImpl ctx = new XpandExecutionContextImpl(output, null, structureProperties null, null);

Now you can resolve the values from the property files directly from the Templates and Extensions using the built-in GLOBAL VAR feature.

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {

  List<SimpleRelationship<S,T>> relationshipsToAdd;
  List<SimpleRelationship<S,T>> relationshipsToRemove;
  ...
}

class SimpleRelationship<V extends BaseDto<?>, W extends BaseDto<?>> {

  // BaseDto classes are identified by the parameterized Id
  Id<V> left;
  Id<W> right;

  SimpleRelationship(BaseDto<V> one, BaseDto<W> another) {
    left = one.getId();
    right = another.getId();
  }
}

Having this structure, you can model the relationship between two instances of types A and B by an instance of SimpleRelationship<A>. If you want to communicate the creation of a relationship you would put the latter into the relatioshipToAdd list, if you want to model the deletion, you would put it into the relatioshipToRemove list.

Now I it was time to develop methods for access of the relationship lists inside of the ManyToManyDelta:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T> toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.add(toAdd);
  }
  ...
}

You could think that you have a batch update (e.g. an Array or List) of SimpleRelatioship objects you would like to add them by one invocation instead of a series of invocation. e.G:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T>[] toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.addAll(Arrays.asList(toAdd));
  }
  public void add(SimpleRelationship<S, T> toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.add(toAdd);
  }
  ...
}

Using the varargs feature of Java you could also write equivalent:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T>... toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.addAll(Arrays.asList(toAdd));
  }
  ...
}

That would be nice, right? By the way, it is a good idea, to write some client code, during the development of API. This discovers potential problems:

  ...
  A entityA = ...;
  B entityB = ...;
  ManyToManyDelta<A, B> delta = new ManyToManyDelta<A,B>();
  delta.add(new SimpleRelationship<A,B>(entityA, entityB));

Coding this result in a type safety warning: A generic array of SimpleRelationship is created for a varargs parameter. Which reveals a problem in a Java language: you can not create an array of parameterized types. And resulting from this fact, you can not use that as varargs argument.

Packaging

In order to package the RCP I suggest to use feature-based products as described in a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.

Exporting the product

Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory. A prominent error is

Compliance level '1.3' is incompatible with source level '1.6'. A compliance level '1.6' or better is required.

Which actually means that the plug-in classes has not been compiled at all. In order to avoid this error make sure to set the following properties in the build.properties file of the corresponding plug-in:

javacSource=1.3
javacTarget=1.3

Exporting the wrap-feature

After a successful export of the product, just export the top-level feature (the wrap-feature). Make sure to provide the signing information, since JWS requires all resources to be signed. If you are aiming to deliver for different platforms, make sure to define a target platform (Window > Preferences > Plug-in Development > Target Platform) which contains a Delta Pack. A Delta Pack is a set of plug-ins which can be downloaded separately on the Eclipse Homepage. Also, don’t forget to switch over to the Java Web Start tab of the Feature Export Wizard, activate the checkbox “Create JNLP manifest for the JAR archives” and specify the site URL where the resulting JNLP will be located. Make sure all your features has the provider attribute set, since it is used as the “vendor” inside of the JNLP file, which is a mandatory attribute.

Creating the main JNLP

The PDE build will run and create a distribution in the specified directory. Along with the exported JARs in features and plug-ins, the packaging script will generate the JNLP descriptors for every feature. Still, the main JNLP file required for launching the application is missing and has to be provided separately. Here is, how it looks like:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/app/" href="app.jnlp">
    <information>
        <title>application titel</title>
        <vendor>provider</vendor>
        <offline-allowed/>
    </information>

    <security>
        <all-permissions/>
    </security>

    <application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
	<argument>-product</argument>
	<argument>de.techjava.app.webstart.productid</argument>
	<argument>-application</argument>
	<argument>de.techjava.app.webstart.appid</argument>
    </application-desc>

    <resources>
        <j2se version="1.4+" ax-heap-size="128m" />
	<jar href="plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar"/>
	<extension name="wrap feature" href="features/wrap_feature_1.0.0.jnlp" />
	<!-- OSGI setup -->
        <property name="osgi.instance.area" value="@user.home/app"/>
        <property name="osgi.configuration.area" value="@user.home/app"/>
    </resources>
</jnlp>

Important is to specify both, the product id and the applciation id, otherwise you will see the “Application id not found” exception. Of course you can specify additional options as command-line arguments of the launcher itself. I found it useful to be able to let the OSGi running and then connect to it and query for loaded bundles. You can do it by adding the following arguments:

	<argument>-console</argument>
	<argument>1234</argument>
	<argument>-noExit</argument>

This will allow to connect via telnet with running OSGi, even after the application finishes.
This is basically it.

Adam made it in an hour and presented many interesting topics. He started with new subjects introduces in JEE6, like optional local interfaces, cronjob-like Timer Service and other nice goodies. Then he covered new stuff from JEE like REST and CDI (Context and Dependency Injection). Finally, he moved to the best practices, patterns and anti-pattern. As usual, it was quick and precise – Adam answered many questions and gave a good overview of the technology.

After the presentation, JUGHH / Lehmanns offer a glass of sparkling wine for the smaller audience and Adam spoke about the possibility to speak about JavaFX next time. This time I left my camera at home and only had my phone with me, so sorry for the low-resolutioned picture…

About two years ago, I published an article about Exposing the Functionality implemented in Stateless Session Beans (EJB 2.1) using Web Services. J2EE 1.4 times are over and the new version of the Java Enterprise framework, called Java Enterprise Edition 5 (JavaEE 5, or simply JEE) has emerged. In this article the same business scenario is repeated in the new framework.

Requirements

Before we dive into code examples, some software is required. The good news about the software is, that it also evolved over time. Here is what we use:

• Sun’s Java 6 SDK
• JBoss AS 5.1.0 GA for JDK6
• Eclipse Galileo 3.5.1 for JEE development

Some words about the used software. It is important to get the JDK6-compiled version of the JBoss Application Server. There are some issues with running the version compiled with Java 5 on JDK6, since JDK6 has its own JAX-WS implementation which causes problems with JBoss (affected should be all versions of JBoss < 5.2. Currently it seems like version 5.2 will be compiled with JDK6 by default.) If you launch JBoss from Eclipse, make sure to add the -Djava.endorsed.dirs=PATH_TO_JBOSS/jboss-5.1.0.GA/lib/endorsed as a VM argument, if launched from the command line, please add it as an option inside of the run.conf.bat file:

set "JAVA_OPTS=%JAVA_OPTS% -Djava.endorsed.dirs=$JBOSS_HOME/lib/endorsed"

Otherwise you will get the following exception:

java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage

After installation (unpacking) of Eclipse, make sure to configure the JDK (under Preferences > Java > Installed JREs) and the JBoss instance (Preferences > Server > Runtime Environment).

Use Case

In order to demonstrate the technology by example, imagine the following use case. The system under construction is capable of providing measurements of some sensors. The sensors are identified by numbers and can be queried by the user by providing the timespan of measurements. As a result, the systems delivers the set of measurements for the given timespan with one measurement per minute but at most sixty measurements. Every measurement contains the id of sensor from which it has been recorded, the timestamp, the value as a byte array, the measurement unit and finally a flag whether the measurement exceeds the limits or specified alarm values.

Implementation

We start the implementation with the creation of a JEE Session Bean and then expose the functionality using a second Facade bean. In doing so we follow the EJB 3 specification.

Eclipse for Java EE development

The plugins in Eclipse for Java EE provide massive support and foster the development by deep integration withe JEE servers. Instead of a simple Java Project, start with an Enterprise Application Project. Then, create a new EJB Project and add it to the created Enterprise Application Project. In order to deploy the resulting application to the server, right-click on the enterprise project and select Run As > Run on Server .

To check the deployment on the application server, use the JBoss Consoles. These can be accessed via http://localhost:8080/ for the locally installed JBoss. An additional Web Service Console is accessible via http://localhost:8080/jbossws/.

Implementing the Functionality

In order to implement the functionality in a stateless session bean, we start with the creation of the business interface.

/**
 * Defines the sensor manager functionality
 */
public interface SensorManager
{
	/**
	 * Retrieve sensor data
	 * @param sensorId id of the sensor
	 * @param timespan the measurement period
	 * @return a list of measurements in the given period
	 * @throws SensorManagerException on any kinds of errors
	 */
	public List<Measurement> getSensorData(SensorID sensorId, Timespan timespan) throws SensorManagerException;
}

The POJOs Measurement, SensorID and Timespan are used to show the usage of custom user types:

public class Measurement
{
	private SensorID sensorID;
	private Date timestamp;
	private boolean critical;
	private byte[] value;
	private String unit;
...
// getters and setters
}
....
public class SensorID
{
	private long sensorId;
...
// getters and setters
}

public class Timespan
{
	private Date start;
	private Date end;
...
// getters and setters
}

After the creation of the business interface, let us create the actual Session Bean. The class is annotated with the @javax.ejb.Stateless annotation in order to indicate that the bean is a Stateless Session Bean. Since it implements the business interface (and only it), the container will be able to deduce that the given interface is the Local Business interface: this is just one of many examples of the Configurations by Exception in EJB 3. In order to be able to reference the bean from other beans, we annotate the binding of the local interface to a specific JNDI name using the vendor-specific annotation org.jboss.ejb3.LocalBinding.

@Stateless
@LocalBinding(jndiBinding="de.techjava.sensor/SensorManager")
public class SensorManagerBean implements SensorManager
{
	/** Logging facility */
	protected static Logger LOG = Logger.getLogger(SensorManagerBean.class);
	/** Max number of returned values */
	private static final long MAX_DURATION = 60;

	/**
	 * Implementation of the business method
	 */
	public List<Measurement> getSensorData(SensorID sensorId, Timespan timespan) throws SensorManagerException
	{
		LOG.debug("Entering getSensorData()");
		if (sensorId == null || timespan == null || timespan.getStart() == null || timespan.getStart() == null)
		{
			throw new SensorManagerException("Missing a mandatory parameter, that was null (not set)");
		} else if (!timespan.getStart().before(timespan.getEnd()))
		{
			throw new SensorManagerException("The timespan is defined by the start that should be before end");
		}

		List<Measurement> measurements = new LinkedList<Measurement>();
		for (long i = 0; i < getNumberOfElements(timespan); i++)
		{
			Date date = new Date();
			date.setTime(timespan.getStart().getTime() + i * 1000 * 60);
			if (date.after(timespan.getEnd()))
				break;
			Measurement measurement = createMeasurement(sensorId, date, i);
			measurements.add(measurement);
		}

		LOG.debug("Leaving getSensorData(). Returning " + measurements.size() + " values.");
		return measurements;
	}

	/**
	 * Retrieves the number of measurements in timespan
	 */
	private long getNumberOfElements(Timespan timespan) { ... }

	/**
	 * Creates a measurement instance, a dummy implementation
	 */
	private Measurement createMeasurement(SensorID sensorId, Date timestamp, long number) { ... }
}

Web Service Definition

The quality of the web service interface is an important design consideration. As described in the previous post, in many cases it is a good idea to create it by hand instead of generation by a tool. In this particular case, we create another annotated Stateless Session Bean, which is used as a Facade and contains all Web Service-specific settings. From this Bean we generate the WSDL and then tune it in order to show the capability of the customization. In doing so we try to match the WSDL from the previous example as close as possible.

Firstly, we create the business interface and the bean class, then annotate it and finally add the code delegating the Web Service request to the SensorManager.

public interface MeasurementProviderFacade
{
	public List<Measurement> getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault;
}

...

@Stateless
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	public List<Measurement> getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault
	{
	...
	// implementation code
	}
}

In order to have a Session Bean exposed as a Web Service, the JAX-WS specification defines a set of annotations. The most important two are @javax.jws.WebMethod and @javax.jws.WebService. The @WebService annotation is used to mark the class to be exposed e.G.

@Stateless
@WebService(
	serviceName = "MeasurementProviderService",
	name = "MeasurementProviderPortType",
	portName = "MeasurementProviderPort",
	targetNamespace = "http://www.techjava.de/2010/ws4jee/measurement/"
)
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	@WebMethod(
		operationName="GetSensorDataOperation",
		action="http://www.techjava.de/2010/ws4jee/measurement/GetSensorDataOperation"
	)
	public List<Measurement> getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault { ... }
}

All the attributes of the annotation are optional and their values will be derived from the classname and the name of the business interface. The default target namespace for the service definition is derived from the package name, the annotated class is located in. By default, all public methods of the annotated class will be exposed as WSDL operations, with operation’s name derived from the method name. Using the @WebMethod annotation, the name of the WSDL operation and the SOAP action can be changed.

The careful reader might have observed that the getSensorData-method is throwing an exception. In order to map the exception to a SOAP-Fault, the javax.xml.ws.WebFault class-level annotation can be used. The faultBean attribute is used to provide the full-qulified class name of the exception.

...
@WebFault(
	name="GetSensorDataFault",
	targetNamespace="http://www.techjava.de/2010/ws4jee/measurement/",
	faultBean="de.techjava.sensor.bean.SensorDataOperationFault")
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade { ... }

In order to increase the quality of the WSDL further, the method parameters and return type can be annotated with javax.jws.WebParam and javax.jws.WebResult respectively, so the method signature becomes a little unreadable. In order not to copy the long string containing the taget namespace a String constant can be used.

...
	public final static String TYPES = "http://www.techjava.de/2010/ws4jee/measurement/types/";
...
	@WebResult(name="measurement", targetNamespace=TYPES)
	public List<Measurement> getSensorData(
		@WebParam(name="sensor-id", targetNamespace=TYPES) SensorID id,
		@WebParam(name="timespan", targetNamespace=TYPES) Timespan timespan) throws SensorDataOperationFault	{ ... }

Finally, in order to force the marshaller / unmarshaller to map the custom data types (Measurement, SensorID and Timespan) to belong to the same namespace, the JAX-B class-level annotation javax.xml.bind.annotation.XmlType has to be used. By default, the datatypes will be mapped to XML Schema types according to their package name and class name.

@XmlType(namespace = "http://www.techjava.de/2010/ws4jee/measurement/types/", name = "TimeSpan", propOrder = { "start", "end" })
public class Timespan
{
	private Date start;
	private Date end;

If deployed to the JBoss, the resulting WSDL looks as following:

<definitions name='MeasurementProviderService' targetNamespace='http://www.techjava.de/2010/ws4jee/measurement/' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:ns1='http://www.techjava.de/2010/ws4jee/measurement/types/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://www.techjava.de/2010/ws4jee/measurement/' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
 <types>
  <xs:schema targetNamespace='http://www.techjava.de/2010/ws4jee/measurement/types/' version='1.0' xmlns:tns='http://www.techjava.de/2010/ws4jee/measurement/types/' xmlns:xs='http://www.w3.org/2001/XMLSchema'>
   <xs:element name='measurement' type='tns:Measurement'/>
   <xs:element name='sensor-id' type='tns:sensor-id'/>
   <xs:element name='timespan' type='tns:TimeSpan'/>
   <xs:complexType name='sensor-id'>
    <xs:sequence>
     <xs:element name='sensorId' type='xs:long'/>
    </xs:sequence>
   </xs:complexType>
   <xs:complexType name='TimeSpan'>
    <xs:sequence>
     <xs:element minOccurs='0' name='start' type='xs:dateTime'/>
     <xs:element minOccurs='0' name='end' type='xs:dateTime'/>
    </xs:sequence>
   </xs:complexType>
   <xs:complexType name='Measurement'>
    <xs:sequence>
     <xs:element name='critical' type='xs:boolean'/>
     <xs:element minOccurs='0' name='sensorID' type='tns:sensor-id'/>
     <xs:element minOccurs='0' name='timestamp' type='xs:dateTime'/>
     <xs:element minOccurs='0' name='unit' type='xs:string'/>
     <xs:element minOccurs='0' name='value' type='xs:base64Binary'/>
    </xs:sequence>
   </xs:complexType>
  </xs:schema>
  <xs:schema targetNamespace='http://www.techjava.de/2010/ws4jee/measurement/' version='1.0' xmlns:ns1='http://www.techjava.de/2010/ws4jee/measurement/types/' xmlns:tns='http://www.techjava.de/2010/ws4jee/measurement/' xmlns:xs='http://www.w3.org/2001/XMLSchema'>
   <xs:import namespace='http://www.techjava.de/2010/ws4jee/measurement/types/'/>
   <xs:element name='GetSensorDataOperation' type='tns:GetSensorDataOperation'/>
   <xs:element name='GetSensorDataOperationResponse' type='tns:GetSensorDataOperationResponse'/>
   <xs:element name='SensorDataOperationFault' type='tns:SensorDataOperationFault'/>
   <xs:complexType name='GetSensorDataOperation'>
    <xs:sequence>
     <xs:element minOccurs='0' ref='ns1:sensor-id'/>
     <xs:element minOccurs='0' ref='ns1:timespan'/>
    </xs:sequence>
   </xs:complexType>
   <xs:complexType name='GetSensorDataOperationResponse'>
    <xs:sequence>
     <xs:element maxOccurs='unbounded' minOccurs='0' ref='ns1:measurement'/>
    </xs:sequence>
   </xs:complexType>
   <xs:complexType name='SensorDataOperationFault'>
    <xs:sequence>
     <xs:element minOccurs='0' name='message' type='xs:string'/>
    </xs:sequence>
   </xs:complexType>
  </xs:schema>
 </types>
 <message name='MeasurementProviderPortType_GetSensorDataOperation'>
  <part element='tns:GetSensorDataOperation' name='GetSensorDataOperation'></part>
 </message>
 <message name='SensorDataOperationFault'>
  <part element='tns:SensorDataOperationFault' name='SensorDataOperationFault'></part>
 </message>
 <message name='MeasurementProviderPortType_GetSensorDataOperationResponse'>
  <part element='tns:GetSensorDataOperationResponse' name='GetSensorDataOperationResponse'></part>
 </message>
 <portType name='MeasurementProviderPortType'>
  <operation name='GetSensorDataOperation' parameterOrder='GetSensorDataOperation'>
   <input message='tns:MeasurementProviderPortType_GetSensorDataOperation' />
   <output message='tns:MeasurementProviderPortType_GetSensorDataOperationResponse' />
   <fault message='tns:SensorDataOperationFault' name='SensorDataOperationFault' />
  </operation>
 </portType>
 <binding name='MeasurementProviderPortTypeBinding' type='tns:MeasurementProviderPortType'>
  <soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/>
  <operation name='GetSensorDataOperation'>
   <soap:operation soapAction='http://www.techjava.de/2010/ws4jee/measurement//GetSensorDataOperation'/>
   <input><soap:body use='literal'/></input>
   <output><soap:body use='literal'/></output>
   <fault name='SensorDataOperationFault'><soap:fault name='SensorDataOperationFault' use='literal'/></fault>
  </operation>
 </binding>
 <service name='MeasurementProviderService'>
  <port binding='tns:MeasurementProviderPortTypeBinding' name='MeasurementProviderPort'>
   <soap:address location='http://127.0.0.1:8080/de.techjava.ws4ee-de.techjava.ws4ee.sensor/MeasurementProviderFacadeBean'/>
  </port>
 </service>
</definitions>

Please note, that the domain datatypes are mapped to the different namespace as the target namespace of the Web Service.

After some tuning the WSDL, like changing the cardinality of elements (minOccurs = 1, maxOccurs = 1) or adding comments we can let the container use the changed WSDL file instead of generating a new one. In order to do this, let us package the WSDL together with the source code. A good place for it is for example /META-INF/wsdl/, so we can provide a reference to it in an wsdlLocationattribute of the @WebService annotation:

@WebService(
...
        wsdlLocation="META-INF/wsdl/MeasurementProviderService.wsdl"
)

Putting all together

After the creation of the Facade Bean and its exposure as a Web Service, we need to delegate the call to the SensorManagerBean, providing the actual implementation. In order to do so, add a private member of type SensorManager inside of the facade bean and annotate it with the javax.ejb.EJB annotation. The container will intialize the member using Dependency Injection and provide a valid reference which can be simply used inside of the method.

...
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	@EJB(mappedName="de.techjava.sensor/SensorManager")
	private SensorManager sensorManager;

	/**
	 * Simple delegate to the business method of the sensor manager
	 */
	@WebMethod(
			operationName="GetSensorDataOperation",
			action=TNS + "/GetSensorDataOperation"
	)
	public @WebResult(name="measurement", targetNamespace=TYPES) List<Measurement> getSensorData(
			@WebParam(name="sensor-id", targetNamespace=TYPES) SensorID id,
			@WebParam(name="timespan", targetNamespace=TYPES) Timespan timespan) throws SensorDataOperationFault
	{
		try
		{
			return sensorManager.getSensorData(id, timespan);
		} catch (SensorManagerException e)
		{
			throw new SensorDataOperationFault("Error accessing the Sensor Manager: " + e.getMessage() + "");
		}
	}
}

Here is the call in Web Service Explorer:

Outline

In this article we showed how to expose the functionality implemented in an EJB 3 Session Bean using Web Service Technology. In fact, the creation of a FacadeBean was not required since one could annotate the SensorManager-Bean directly, but we separated the implementation Bean from the exposing Bean to make it easier to understand. Even if we didn’t match the WSDL from the J2EE 1.4 example exactly, we came very close. Merely some message-related datatypes have different names. In this example we used the Document/Literal/Wrapped style of Web Services in order to gain maximum interoperability. Even though the creation of the Web Service is a simple task using the annotations. The number of tools and dependencies has dramataically reduced since J2EE 1.4 and the development became less error-prone. Together with other EJB3 improvements it makes the JEE framework suitable for development in the context of enterprise distributed systems.

References and Resources

The example source code is available for download ( ws4jee.zip). Just import the projects from the archive into Eclipse Worskspace. Make sure to set up the JRE and JBoss Server instance for the projecst to work.

• [2008,techreport] bibtex
  E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, and K. Haase, "The Java EE 5 Tutorial," 2008.
  @techreport{JAVAEE,
  author = {Eric Jendrock and Jennifer Ball and Debbie Carson and Ian Evans and Scott Fordin and Kim Haase},
  title = {The Java EE 5 Tutorial},
  url = {http://java.sun.com/javaee/5/docs/tutorial/doc/},
  month = {Oct},
  year = {2008}
}
• [2007,book] bibtex
  O. Ihns, D. Harbeck, S. M. Heldt, H. Koschek, R. Schl�r, J. Ehm, and C. Sahling, EJB 3 professionell. Grundlagen- und Expertenwissen zu Enterprise JavaBeans 3 fr Einsteiger, Umsteiger und Fortgeschrittene , publisher DPunkt Verlag, , 2007.
  @Book{IHNS_2003,
  author = {Oliver Ihns and Dierk Harbeck and Stefan M. Heldt and Holger Koschek and Roman Schlömmer and Jo Ehm and Carsten Sahling},
  title = {EJB 3 professionell. Grundlagen- und Expertenwissen zu Enterprise JavaBeans 3 für Einsteiger, Umsteiger und Fortgeschrittene },
  publisher {DPunkt Verlag},
  year = {2007},
  month = {Jul},
  url = {Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, Holger Koschek, Roman Schlömmer, Jo Ehm, Carsten Sahling}
}