TechJava» TechJava – Articles on technology

Extending Xtext Build Participants

Simon Zambrovski — Thu, 17 Jun 2010 10:41:21 +0000

You’ve definitely heard about Xtext, the famous text modeling framework, community award winner . We are all looking forward to the new project management wonder: the release of Helios, upcoming on June the 23rd, which will include Xtext 1.0.0. In this article, I want do describe some aspects of integration of Xtext-based languages into IDE.

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 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:

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:

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 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 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();
		this.propertyFile = (IFile) aProject.findMember(filename);
	}

	public IFile getPropertyFile() {
		return propertyFile;
	}

	/**
	 * Returns the global variables.
	 * @return global variables.
	 */
	public Map 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 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.

Parameterized classes, arrays and varargs

Simon Zambrovski — Wed, 02 Jun 2010 14:30:00 +0000

Yesterday, I discovered a funny nuance in Java programming language, which I didn’t know before and decided to share it with you. I was designing an API for transport of changes in relationships between two DTO types. Since I wanted to support batch changes, I created the class for carrying these:

class ManyToManyDelta, T extends BaseDto> {

  List> relationshipsToAdd;
  List> relationshipsToRemove;
  ...
}

class SimpleRelationship, W extends BaseDto> {

  // BaseDto classes are identified by the parameterized Id
  Id left;
  Id right;

  SimpleRelationship(BaseDto one, BaseDto 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. 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~~, T extends BaseDto> { ... public void add(SimpleRelationship 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, T extends BaseDto> { ... public void add(SimpleRelationship[] toAdd) { if (toAdd == null) { /* react */} this.relatioshipToAdd.addAll(Arrays.asList(toAdd)); } public void add(SimpleRelationship toAdd) { if (toAdd == null) { /* react */} this.relatioshipToAdd.add(toAdd); } ... }
Using the varargs feature of Java you could also write equivalent:

class ManyToManyDelta~~, T extends BaseDto> { ... public void add(SimpleRelationship... 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 delta = new ManyToManyDelta(); delta.add(new SimpleRelationship(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.

Finally, if you want to create convenience methods for one and many items, you have to do it in a old-fashined way, by providing overloaded methods.

JSF 2.0 Reality Check

Simon Zambrovski — Mon, 22 Feb 2010 21:50:42 +0000

Abstract

The JavaServer Faces (JSF) 2.0 is the newest Java presentation technology that is covered in JSR-314 and was publicly released on July 01, 2009. It became a part of the JEE6 standard and can be comfortably used in conjunction with other JEE frameworks, with Spring or just on its own. This article reveals the possible scenarios and shows the required configuration for the usage of JSF 2.0 with EJB 3.1 and with Spring 3.0. It also discusses several auxilary technologies which can be used along with JSF 2.0.

Management Summary

There are many presentation frameworks available, so why JSF 2.0? The short answer is simple: it has an extensible component-oriented presentation layer and event-driven programming model, which both abstract from HTML/JS and leverage the developement. In more detail, the most important features are:

Facelet Support

Validation & Conversion Mechanisms

Resources Support

Templating

Expression Language

Annotation Support

JSF 2.0 makes strong use of the SoC (Separation of Concerns) principle, promoting the MVC (Model View Controller) design pattern. Its declarative view is based on facelets: the view documents can be defined using XHTML. These documents build their own component tree from the core or third-party components. The use of special composition elements allows effective templating. The model or/and the controller are realized using so called backing beans / managed beans. A backing bean is an annotated POJO (Plain Old Java Object). The access from the view to the backing beans is possible using the expression language. The navigation can be influenced directly from the view or from the backing beans, by pointing to the logical names of the pages. JSF offers a flexible validation model, which suports Bean Validation (JSR 303) out of the box.

Presentation with JSF 2.0

This chapter discusses the model of the presentation used in JSF 2.0.

Initial setup

A JSF project is an ordinary Java Web project. The result of it runs inside of a web container, like Tomcat or Jetty. A characteristical descriptor has to contain the servlet definitions/mappings of the JSF servlet and third-party component servlets. Here is an exammple for JSF 2.0 and Prime Faces, an open-source component library.

... com.sun.faces.expressionFactory com.sun.el.ExpressionFactoryImpl Faces Servlet javax.faces.webapp.FacesServlet 1 Resource Servlet org.primefaces.resource.ResourceServlet 1 Faces Servlet *.jsf Resource Servlet /primefaces_resource/* ...

The View

The definition of a JSF presentation is relatevely simple. Just create a simple XHTML document and import the JSF namespaces in the header.

#{msgs.welcomeTitle} ...

Please note, that along with the JSF core components, the PrimeFaces component dataTable is used. At runtime the components will be transformed into the corresponding HTML elements.

The Backing Bean

In the previos example, special strings have been used #{customerProvider.customers} and #{customer.name}. Both of them are expressions specified in the Expression Language. This language allows to address elements known inside the application. The customer.name accesses the property name of the variable defined inside the iteration over the elements delivered from the customerProvider.getCustomers(). The customerProvider is a Java Object that delivers data to the view and is called Backing Bean. A Backing Bean is a serializeable POJO, that is attached to the view. It can be declared using JSF Annotation javax.faces.ManagedBean, using the ManagedBean element of the faces-config.xml or by other mechanisms compatible with the Expression Language resolvers.

@ManagedBean @SessionScope public class CustomerProvider { public List getCustomers() { ... } }

Internationalization

Internationalization is an important requirement for the presentation layer. In the previous example, a special string has been used #{msgs.welcomeTitle} to provide a message. The msgs variable is bound to a resource file, containing the localized messages, so the #{msgs.welcomeTitle} is pointing to the key welcomeTitle inside the property file.

Validation

Input validation is another important requirement for web applications. Especially, the ability to validate parts of the input using technologies like AJAX has to be supported in order to deliver the state-of-the-art technology. JSF fosters numerous different validation approaches. For example:

... ...

Please note, that in the example above, the input of the customer name is mandatory and the minimum length is seven.

Another validation approach is defined in the Bean Validation Standard (JSR 303) and is supported if the components are deployed and available. According to JSR 303, the data container can define format constraints which can be used for purposes of validation. There is a set of predefined constraints available, which can be extended by custom constraints. For example:

public class Customer { @Size(min=2, max=50, message= "Customer name must be at least 2 and at most 50 characters long. ") private String name; // getters and setters ... }

This example shows that the customer name has to be at least two and at most fifty characters long and defines a custom error message which is displayed on violation. Remember the previous section Internationalization? Yes, the validation error message can be localized too, by suppliying EL-expressions instead of the message description:

public class Customer { @Size(min=2, max=50, message= "{customerNameError} ") private String name; // getters and setters ... }

Thus, the value of {customerNameError} (without a #) is a key in the file which must be named ValidationMessages.properties and must be available on classpath.

JSF 2.0 with other frameworks

The use of JSF fosters comfort in implementing the presentation tier. The presentation-tier is usually built on top of the business logic layer. The latter can be implemented using different technolgies.

JSF 2.0 and EJB 3.1

Enterprise Java Beans is a standard way to implement business logic inside JEE applications. The current EJB 3.1 specification fosters the usage of Stateless and Statefull Session Beans for this purpose. Since JEE6-compliant servers support Context and Dependency Injection (CDI) and the EJB and Resource Injection, the session beans can be directly referenced from the backing beans. JSF 2.0 is also a part of the JEE 6, every JEE-compliant server will support JSF out-of-the-box, too.

@ManagedBean public class CustomerProvider { @EJB private CustomerService service; ... }

JSF 2.0 and Spring 3.0

If you don’t want to run a full-blown JEE server, but a web-container only, you have to include some libraries into your application deployment.

JSF 2.0 API and Implementation: e.g. Mojarra 2.0.2 ( mojarra-2.0.2-FCS-binary.zip)

Expression Language 2.2 API and Implementation: el-api-2.2.jar, el-impl-2.2.jar

Content and Dependency Injection (CDI, JSR 330) API and Implementation: javax.inject.zip

Bean Validation (JSR 303) API and Implementation: e.g. Hibernate Validator ( hibernate-validator-4.0.2.GA-dist.zip)

This list will be extended by libraries required to run the Spring framework. In order to activate Spring, the context listeners have to be activated. The application context parameter can be provided as a context parameter.

org.springframework.web.context.ContextLoaderListener org.springframework.web.context.request.RequestContextListener contextConfigLocation /WEB-INF/spring-config.xml

In addition, the Expression Language variable resolvers of JSF should be replaced by those from Spring. This is configured in the faces-config.xml

org.springframework.web.jsf.el.SpringBeanFacesELResolver

In order to enable the Spring’s IoC (Inversion of Control), we need to activate the component scan in the application-context configuration file:

Instead of using JSF for resolving the backing beans, the Spring framework can be used. The backing bean is annotated with the Spring annotation Controller. The controller is a special kind of Spring component, which is used in the presentation layer. The Spring’s way of implementing business logic is to provide Spring services. Spring service has to be annotated with Service annotation.

@Controller @Scope( "session ") public class CustomerProvider implements Serializable { @Inject private CustomerService customerService; ... } @Service @Scope( "singleton ") public class CustomerServiceImpl implements CustomerService { ... }

This is not as elegant as inside the JEE server, but it will work.

References

JSR 303: Bean Validation

JSR 330: Dependency Injection for Java

JSR 330 with Spring (in German)

Mojarra Project

Expression Language API

Expression Language Implementation

Hibernate Validator (JSR 303 Implementation)

AtInject (JSR 330 Implementation)

Exposing Functionality using Web Services and JEE

Simon Zambrovski — Thu, 07 Jan 2010 11:11:22 +0000

Abstract

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 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 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 measurements = new LinkedList(); 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 getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault; } ... @Stateless public class MeasurementProviderFacadeBean implements MeasurementProviderFacade { public List 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 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 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:

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 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} }

EWiTa and ESE 2009

Simon Zambrovski — Tue, 10 Nov 2009 21:24:55 +0000

Even if some time has passed since the events EWiTa 2009 and Eclipse Summit Europe 2009, I would like to share my impressions, since I took part in both events…

EWiTa 2009

EWiTa 2009 stands for Elmshorner Wirtschaftsinfromatiktag, that is German for “Elmshorn Business Information Systems Day”. The event has been organized by Frank Zimmermann, of Nordakademie – a private university in Northern Germany. Even if the event is not an official sequel of the MDSD Today, there were many similarities. The event had two tracks: the process modeling track and the MDSD track. After an excellent keynote from Mathias Weske about the importance of collaboration during the process of (business) modeling I stayed in the business track to listen to the Andrea Grass ( oose GmbH) on the combination of UML and BPMN 2.0. To say the truth, I’m not a big fan of this approach, especially, because the conceptual mismatch of modeling of business behavior and technical behavior. After a coffee break I enjoyed an excellent talk of itemis), reporting about the success story of xText in a big project of Deutsche Börse AG (German Stock Exchange).

After a small lunch, I was listening to two Arcando consultants reporting about their eTicketing project. The strange thing about this talk was that they just made some ads on a standard Microsoft product. After this, I enjoyed an interesting talk on business modeling based on CobIT process. Finally, I switched the track again to MDSD and listend to the an interesting usage of MDSD techniques for generation of DynPro and ABAP code.

In general I enjoyed the event. I think the MDSD track was a little more technical, but the combination was good.

Eclipse Summit Europe 2009

The Eclipse Summit Europe 2009 (ESE 2009) took place on October 27-29 in Ludwigsburg, Germany, it is the European complement to the EclipseCon in the US. In contrast to the spring event in Santa Clara, CA, the ESE is an autumn event in a beautiful baroque town near Stuttgart. The event lasted three days and is a must for Eclipse-related technology people. As usual, the venue was great, the keynotes excellent and the talks interesting. And of course it was the place to meet the committers, evangelists, see them in action, talk to them and discuss the future directions.

Symposium Day

The first day is an arrival day. People arrive during the day, some of them are already there. I was visiting the Modeling Track the whole day and had much fun with Ed Merks, Eike Stepper and Thomas Schindl in the morning. Later, in the Modeling Symposium, Eike showed the eDine RCP based on CDO, UBS envisioned the modeling tool pipeline and so on, and so on. About 10 people showed different technologies on and about modeling. Intersting, unstructured and relaxed. And of course, the first evening is the opportunity to speak with all the Eclipse VIPs and drink a cold beer.

First Day

The main conference day was Wednesday and it started with a great keynote on functional programming held by Don Syme, the father of F#. Suprisingly, the talk was about F#. For some of us, there was not enough functional beauty exposed in the talk, so I scheduled a private session with Don and he told Markus Voelter, Heiko Behrens and me about some interesting F# features.

I took part in the How about I/O session on JPicus. A very interesting tool for tracking I/O problems in Java programs developed by SAP. The Climb The Tower of Babel was about the Eclipse translation project. Intersting is the runtime editor allowing you to translate you runnig application. After a delicios lunch, I enjoyed two modeling talks: Xtext and EMF Query. The itemis team introduced some really new features, which make Xtext in my oppinion to a unique technology. Just to mention few of them: white-space aware parsing, usage of scopes and qualified names, usage of index (construted by a builder) in your own language, separation of markers and annotations in the editor, integration of the generator on-save, declarative quick-fix in your DSL, strings with special meaning, references to java types, and much more… The EMF Query is a project developed by the SAP team, that leverages the index by a query language. The language is a SQL-like DSL for querying the EMF-based models. The infrastructure is very intersting and allows complex scenarios with multiple model providers – very technical, and I believe, very interesting project.

Second Day

After the keynote on the importance of software ecosystems and a deep economical analysis of Eclipse ecosystem, I switched off the track to be able to prepare my talk. I was reporting about the IDE for TLA+ which I was building the last nine month at Microsoft Research, and which will be available soon. The main emphasis of the talk, was not the demo of the IDE, but the exchange of experiences on building one. Especially, I focused on the possible pitfalls and conceptual mismatches of IDEs depending on the integrated language. The slides will be available soon.

At the end, I enjoyed the event very much. I even liked it more than EclipseCon. Modeling still seems to be the most interesting part of Eclipse ecosystem. Technologies like Xtext and CDO gain maturity, new technolgoes like EMF Query are being developed. It was nice to see the people again… As usual, some pictures:

Eclipse renews itself: Galileo has arrived!

HeSoK — Wed, 24 Jun 2009 19:08:47 +0000

Finally, another annual release of Eclipse has arrived: version 3.5 aka Galileo.
Galileo is the release of Eclipse IDE synchronized with packets tuned for the Galileo release. Eclipse IDE has moved on from being a sole and mere development environment to being a rich architecture. Often, this is not visible to the novice user.

Galileo, or the JDT (Java Development Tools) to be more precisely, does not surprise with a load of stunning new features, instead, its a solid continuation of improvements. Concerning the JDT part, it has lost its pace of former days. But Eclipse JDT still is the reliable friend at your side, helping you code. This is a good thing, since Eclipse has been the IDE of choice for many, many Java programmers for a lot of years now and has grown to something like a “standard”. Its usability and reliability are well known and especially the first part has been constantly improved.

Galileo now draws its innovative power from the huge amount of different projects which were developed for it. The amount of tools for modeling is impressive. However it is not surprising, since modeling has become a sport in the past month. Consequently, it is bare logic to improve the tooling capabilities and quality. Galileo is following this path, not only because of Eclipse, but with what is available for it.

Code is poetry!

Eclipse DemoCamp Galileo Hamburg

Simon Zambrovski — Tue, 26 May 2009 23:25:06 +0000

As announced in a previous post the Eclipse Demo Camp Hamburg – Galileo Edition took place in the East Hotel in Hamburg. Organized by Peter and Martin, the event was again an interesting meeting with Eclipse-interested people in a wonderful location. Five presenters introduced Eclipse and OSGi-related topics. Moritz Eysholdt reported about the (Meta)Model Evolutions, he was focusing on during his masters thesis. The interesting part of his solution are two Xtext DSLs for description of the Metamodel changes (EPatch) and model migration algorithms (MetaPatch). Heiko Behrens gave a funny and really good introduction of Xtext and DSLs for not Xtext developers. I really like his examples: these are simple and understanding for everyone. Great job! Marco Mosconi showed some ObjectTeams (black) magic. A very intersting technology using aspect-oriented programming for type-safe framework modifications. Seem to be pretty advanced technology with interesting tooling. Markus Alexander Kuppe had a talk on ECF and RFC 119 and gave some sneak preview of the upcomming features. Finally, I had a short talk on Common Navigator Framework, basically explaining the article posted here and something I documented for Galileo. Here are some visual impressions: my FlickR set and Peter’s.

RCP with multiple application windows

Simon Zambrovski — Wed, 14 Jan 2009 21:25:37 +0000

Eclipse RCP by default promotes the usage of a single application window with multiple views and editors inside. This default can be changed to multi-windowed application. The platform API offers several methods to operate with multiple application windows:

package org.eclipse.ui; ... public interface IWorkbench ... { /** * Retrieves the number of opened windows */ public int getWorkbenchWindowCount(); /** * Retrieves the array of opened windows */ public IWorkbenchWindow[] getWorkbenchWindows(); /** * Openes a new window with given perspective */ public IWorkbenchWindow openWorkbenchWindow(String perspectiveId, IAdaptable input) throws WorkbenchException; /** * Performs a perspective switch in a given window */ public IWorkbenchPage showPerspective(String perspectiveId, IWorkbenchWindow window, IAdaptable input) throws WorkbenchException; ... }

Using this API, opening of new windows seems simple. For example one could define a perspective, that is always opens in a new window.

Closing windows is generally performed by calling close method on the IWorkbenchWindow instance.

package org.eclipse.ui; ... public interface IWorkbenchWindow ... { /** * Closes the window */ public boolean close(); }

Unfortunaly, there is no elegant way to find out which window are you in. A workaround which uses Eclipse internal API works fine for WorkbenchWindow, which is a standard platform implementation of the IWorkbenchWindow interface.

/** * Determines if the window is a root window * @param window a window to be checked * @return true, if the window is considered to be a root window */ public static int getWindowId(IWorkbenchWindow window) { // HACK: note this could change in future if (window != null && window instanceof WorkbenchWindow)) { return ((WorkbenchWindow)window).getNumber(); } return -1; }

The initial application window gets the id 1. The lookup in the implementation reveals that the internal method finds the smalles unused positive number and assigns it to the newly opened window. If you do not want to rely on this algorithm, just hash the newly created windows by they ids.

2nd Workshop on MDSD Today 2008

HeSoK — Thu, 06 Nov 2008 21:11:27 +0000

On October 15th to 17th the Workshop on MDSD Today 2008 took place in the Nordakademie Elmshorn near Hamburg. This workshop was actually the sequel to two different workshops which were led by Frank Zimmermann (Nordakademie) and Simon Zambrovski (TUHH) the year before. For this years event, Peter Friese (Itemis) from Itemis joined the two for organizing the Workshop.

The workshop was divided into three parts: Day 1: Management Day, Day 2: Professional Day (Modeling Projects and Tutorials) and Day 3: Professional Day (Generator Tutorials). (See also MDSD08).

The first day was dominated by excellent key-note speeches given by the EMF lead Ed Merks Ph.D. and SAPs Dr. Axel Uhl. Ed was talking about misconceptions in understanding and applying model driven techniques. Axel on the other hand talked about the challenges that still lay on our way and need to be overcome. He discussed for example the different benefits and drawbacks of using different sorts of DSL (e.g. non-textual / textual) with respect to storing them in repositories, merging and refactoring (i.e. general tool-support). Birger Garbe and Stefan Reichert (both Lufthansa Systems consultants) talked about their experiences in applying MDSD in the field. Chances and riscs were explained and how they managed to overcome those riscs. Thomas Stahl of b+m Informatik gave a talk about how MDSD, BPM and SOA fit together, unfortunately he couldn’t give is planned speech “Experiences of 10 years of MDSD”. As one of the authors of the model-driven software development book and with the experience background he has, this would be have been clearly very interesting. The speech he gave instead was also interesting but took little different directions.

The second day was filled with two different tracks one could attend. One covered contributions coming from the fields of research and the industry. And in the other one Ed Merks gave an intro to the Eclipse Modeling Framework (EMF). After that, Ralf Möller of the Eclipse Foundation talked about innovation networks. The afternoon was filled with a tutorial on how to generate graphical editors using the GMF. The tutorial was given by Robert Wloch who jumped in for Jan Köhnlein (both itemis) who unfortunately got sick.

The third and last day was filled with a tutorial on xText, which was given by Peter Friese and Sven Efftinge (both itemis). Later Arno Haase (independant consultant) tought the audience how to do model-to-model and model-to-code transformations.

Summing up this was a very, very interesting event where the cremé dé la cremé of MDSD gathered and where people had the chance to ask, learn and get to know each other. Not only the speeches and tutorials were very interesting, funny but the overall event had socially a nice friendly touch. Some further pictures can be found in the FlickR gallaery.

The Workshop Proceedings can be obtained at amazon:
Proceedings of the Second Workshop on MDSD Today 2008 (engl.)

Ed Merks new book will be published sometime in the beginning of 2009, here is a link to the “old” (but still good) one:

Eclipse Modeling Framework (engl.)

Also I would like to mention the book by Arno Haase, Markus Völter, Thomas Stahl, Sven Efftinge:

Modellgetriebene Softwareentwicklung ( english version)

OSGi: Why Modularity is Important.

Simon Zambrovski — Wed, 10 Sep 2008 10:16:18 +0000

Yesterday, the OSGi session took place in Hotel East in Hamburg. Peter Kriens, the OSGi evangelist showed a wonderful Zen Presentation on OSGi. I wrote a lot during his talk which happens to me very seldom. Here are the core statements I understood:

The core difference between usual plugin architectures and OSGi is that OSGi concentrates on collaboration of the components.

OSGi delivers a controlled environment, in which the question if a component runs or not can be answered in beforehand.

OSGi bundles use metadata (about versions, dependencies, etc) to predict an error, not discover it in runtime.

OSGi has a very narrow API containing the minimal common part.

OSGi consists of module, life cycle and services layers. The initially developed services layer required smart class loading mechanisms (module layer).

The module layer is desigend to control the class loading machanisms (e.G. structureal class loader hierarchies instead of a linear classpath)

Life cycle layer adds a management API (e.G. inform the others about installation event)

Separation of concerns is promoted by definition of services for different tasks.

Services are used for decoupling of system parts (This is a standard application of service-orientation).

OSGI makes dependencies explicit (private, import, export)

OSGI tries to make the system managable, taking dynamics and lifecycle as fisrst-class citizens

OSGI will be extended to support distribution: the team works on policies, SLAs, etc…

I liked the talk and the way how Peter Kriens addressed the problems of OO. I was confirmed in some ideas about coupling that will be layed out in my thesis. After the presentation we had a delicious meal and wraped up the evening with interesting discussion about pros and contras of OSGi. Peter Friese showed me some remote OSGi staff, he was playing with. The lack of documentation in this area makes it a little difficult, but I hope he will post some news on it. As usual, you can find other pictures in my FlickR gallery.