Skip to content

Archive

Category: Enterprise Systems

meanjs

Mean.js is a new popular Javascript full stack using MongoDB for persistence. To be more precise it incorporates MongoDB, ExpressJS, AngularJS, and Node.js and allows for very fast and light-weight application development. The use of scaffolder Yeoman boosts creation of modules, routes, controller, views and other boilerplate Javascript code. As a result, a Single Page Application can be generated very fast. In addition a a user module with Passport authorization supporting a local and several social backend strategies is included.

In order to leverage the the backend authorization capabilities to be used ineth enterprise environment, I combined it with LDAP authorization backend. Since  passport-ldapauth implements this problem it was natural to use this component. In the following post,  I provide the configuration needed for the implementation, inspired by the author of the module.

continue reading…

During last weeks, some local building contractor was involved in reconstruction of our house and renewing the basement drainage. As a result the new basement drainage has been installed and a new hopper for the sewage pumps has been placed. To be honest, it is a lot of heavy work, performed by the builder including digging, insulating, pounding and other dirty staff – but after all the system works if sewage pump is removing the drainage water. In constrast to the earthworks, where you need much experience and human force, which I don’t have, I took over the plumbing and electrical work on the pumps. In order to have a fail-over system, I installed two pumps, where the second pump is triggered if the first one fails. In order to be able to operate on a short circuit of the first pump, I put the second pump on a separate phase (in Europe, we have three phases power supply, 220V each, shifted by 120° to each other, not like split-phase in US). Having this system installed, you get some periodic work to do: finally you want to make sure by regular testing procedures, that the second pump is operating if the first one has failed. Since I’m lazy and like inventing and constucting stuff more than executing regular test procedures, I decided to implement a monitoring system using some cheap electronic and computer components: Raspberry Pi, Tinkerforge Hardware. continue reading…

Ranked

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.

Google Guice

Abstract

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

Business Delegate, Service Locator and Dependency Injection

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

public interface MyBusinessService extends BaseBusinessService {

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

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

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

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

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

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

public class MyBusinessServiceFacade extends BaseFacade implements MyBusinessService {

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

}

This setup results in a following architecture:

Architecture

Business Delegate Boilerplate

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

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

public class ServiceFacadeModule extends AbstractModule {

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

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

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

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

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

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

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

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

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

Packaging Guice

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

What about mock?

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

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

public class MyBusinessServiceMock implements MyBusinessService {

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

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

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

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

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

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

public class PluginUtility {

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

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

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

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

public class InjectorHolder {
...
	private Injector injector;

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

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

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

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

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

Summary

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

Have Fun…

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. continue reading…

The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.

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.


I just returned from the furious event given by Adam Bien on Real World Java EE Practices. The presentation has been held in Lehmanns Bookstore in Hamburg in co-operation with the JUGHH. It was a full success with no space left in the bookstore. I think, I got the last seat and there were some people standing.

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…