Mapping JavaEE and .NET stack components

Recently I started to research how to develop on .NET as I’ve been developing for JavaEE.
First thing that came to my mind as a JavaEE architect was: “Okay, IIS and ASP.NET are some of the presentation tier alternative I have for .NET but what for business tier?” or rephrasing as someone that has
been using JavaEE for a long time: “What would be the .NET EJB?”.
First thing I missed was the concept of the MDB that in .NET stack that seems to be replaced by an MSMQ message trigger.

Another major .NET difference is that even though it seems to have the concept of the VM process (as Java does) it has the concept of a shared library, or the Global Assembly Cache. If you think in terms of Java then you have to either manually replicate the jar or share them using a shared storage and having it on the classpath.

As we are on the classpath subject, .NET and its CLR seems to avoid (and limit it to J#) the concept of a ClassLoader. Although sometimes problematic, the Java concept of the ClassLoader allows very sofisticate scenarios of application composition and also for hot code generation (by the application) at runtime.

I hope this post has helped anyone in the situation as I were before and I also hope it does not sound as a comparison of which platform is better as you might guess that I sincerely know that each one has its applications, strengths and weaknesses.

WebSphere eXtreme Scale 6 book review

Anyone designing a high performance transaction processing system has already needed at least a caching solution for increasing response time on frequently used data. But sometimes these data might become bigger than usual, those are times when you need a sofisticate

WebSphere eXtreme Scale Book

solution, something that can automatically fetch data from a slower storage, offload when not necessary, split its contents between various nodes, …

If you require something like this then you’ll notice that you need a DataGrid solution.

By now you’ll be asking yourself why I am on that subject? Recently I’ve been kindly invited to review a book about IBM WebSphere eXtreme Scale from Packt Publishing.

Apart from this, I work on a project where we were already evaluating WebSphere eXtreme Scale as a replacement for WebSphere DynaCache.

If you are in a hurry and want to have a sneak peak on the book contents, take a look at the sample chapter (Chapter 7: “The DataGrid API”) available for free on Packt Publishing website.

Anatomy of an inbound jca connector

Continuing with the posts about JCA lets now have a look on the specifics of an Inbound JCA connector. As already mentioned in a previous post the term inbound is related to the flow of the call on your application.
The endpointActivation method plays a key role in an Inbound adapter. This is the method that is triggered by the container on each of the Activation Specs you have configured on your Application Server instance. This is also the point where you start your monitoring thread (FooMonitor in our example). Remember that this monitoring object has to have access to a number of key container classes such as MessageEndpointFactory implementation and also WorkManager.
Apart from container objects you’ll certainly need to have the ActivationSpec object passed on the endpointActivation method since it carries on the configuration provided for this activation spec (taking JMS as an example it’d be host, queue, username, …).
Another point to remember is that you’ll need to have a reference to the monitor threads that were activated since on container shutdown it’ll invoke the endpointDeactivation method and you’ll need to retrieve the related monitor thread and stop its execution.

Inbound Connector classes

Too much text lets now have a look on some diagrams:

As you may have already guessed, FooMonitor is the thread that will poll for events and schedule their notifications through the WorkManager. You should never use the monitor thread for the notification since it’ll be blocked during notification denying the sending of other notifications. That’s the reason you should schedule an asynchronous notification using WorkManager.

FooNotification implementation

Skipping to the FooNotification class, its implementation will be something like the following code:

public void run() {
	MessageEndpoint endpoint = null;
	try {
		endpoint =  messageEndpointFactory.createEndpoint(null);
		((FooListener) endpoint).onMessage(msg);
	} catch (Exception ex) {
		logger.error("Error on foo notification" ,ex);
	} finally {
		if (endpoint != null)
			endpoint.release();
	}
}

As already mentioned, that’s the point where the MessageEndpointFactory is used. It provides us proxies for FooMDB classes. Remember to ALWAYS invoke release after using this proxy otherwise your container may run out of proxies since it’ll think you are still using them.
Another aspect not really detailed is the msg parameter on the onMessage method: this one is dependent on your ResourceAdapter – You are the one responsible for defining it (unless you have chosen a regular API like JMS).

Disabling Seam Deployer

This post is only an update to the previous post. Recently I found an even more elegant solution in order to disable seam.deployer. Instead of removing the package from JBoss AS deployers folder we can provide a jboss-scanning.xml file which as documented on JBoss Wiki is able to remove certain files from scanning process.
So, a better (and also less instrusive) workaround is to provide under war/WEB-INF/classes a jboss-scanning.xml file with the following contents:

<scanning xmlns="urn:jboss:scanning:1.0">
  <path name="servlet-1.0.war/WEB-INF/classes">
    <exclude name="seam.properties"/>
  </path>
</scanning>

Seam on JBoss 5.x without Seam Deployer

Recently I started a proof of concept for a new project that will run on JBoss 5.1. The reason for picking JBoss 5.1 instead of the mature 4.2 series was due to its full support for JavaEE 1.5 (4.2 supports only EJB3 spec, no servlet injection, etc) as well as its longer support (4.2 will start an EOL cycle soon).
As soon as I decided to use JBoss 5.x the classloading nightmare started. First of all, Seam uses a kinda strange hack for detecting its components (its scanner class makes use of java.io.File which in turn does not work on newer VFS system released on JBoss 5.x).
Recommendation on Seam forums is to include no Seam file at you EAR/WAR and let Seam deployer do the trick but thiss comes with much obvious limitations:

1. You’ll need a separate packaging for your application on JBoss (this is probably the worst limitation)
2. Seam (and its dependencies) upgrades will involve patching Application Server files

But although recommended you can still deploy a regular Seam application without Seam Deployer. I’ll try to provide a step-by-step guide on how to circumvent this limitation:

First step: remove seam.deployer from $JBOSS_HOME/server/default/deployers (an alternative and less intrusive solution that I just found after writting this post is described over here)
Second step: add all Seam dependencies (jboss-seam-ui.jar, jboss-seam.jar, etc) inside EAR (I sincerely suggest under a lib folder).
Third step: place a jboss-app.xml with the following content on you EAR/META-INF folder

<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE jboss-app
    PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">
<jboss-app>
      <loader-repository>
            myapp.ear=MyAppEar
      </loader-repository>
</jboss-app>

Fourth step: place a jboss-classloading.xml also on EAR/META-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
              name="myapp.ear"
              domain="MyAppEar">
</classloading>

Fifth step: place jboss-seam-int-jbossas.jar from seam.deployer/lib-int into your EAR/lib folder. (this jar contains org.jboss.seam.integration.jbossas.vfs.VFSScanner)
Sixth step: place another jboss-classloading.xml on WAR/WEB-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
              name="mywebapp.war"
              domain="MyWebAppWar">
</classloading>

Seventh step: Place a jboss-web.xml under WAR/WEB-INF with the following contents:

<jboss-web>
	<class-loading java2ClassLoadingCompliance="false">
		<loader-repository>
			mywebapp.war:loader=MyWebApp
			<loader-repository-config>java2ParentDelegation=false
			</loader-repository-config>
		</loader-repository>
	</class-loading>
</jboss-web>

Eighth step: place a seam-deployment.properties anywhere in the classpath (anywhere but before seam jar) with the following contents:

org.jboss.seam.deployment.scanners=org.jboss.seam.integration.jbossas.vfs.VFSScanner

Ninth step: Add all Seam dependencies on MANIFEST.MF file under WAR/META-INF and remember to include jboss-seam-int-jbossas.jar on the classpath.

That’s all you need to avoid having a separate packaging for a Seam enterprise application running on JBoss 5.x (sincerely I guess that you risk having to remove the seam-deployment.properties only). This also makes it easier to replace the JSF implementation on your application.

Accessing a HMC through a SSH tunnel

For sysadmins this might be a rather easy task, but as a HMC end-user I had to search a little bit.
If you never used an IBM server you might be wondering what is an HMC. At first it seems like a notebook in a blade format as you can see on the picture below:

HMC (source: http://www.fz-juelich.de/jsc/index.php?index=1979)

But apart from its similarity to a fancy notebook, its purpose is to allow administration of IBM LPARs (or DLPARs after Power6 arrival).
There you can boot, shutdown, change CPUs and memory for LPARs, etc.
Apart from allowing the administration in loco, it provides a Java based application that can be installed either through a Java Web Start launcher or using an MSI installer.
I’ll try to explain the steps involved in running it using the JNLP Java Web Start launcher.

Setup SSH tunnel and Download JNLP

Open the SSH connection between you and any host on the same network as your HMC (this can even be the HMC itself) and tunnel the following ports from your machine to HMC’s IP.

• 30000 up to 30009
• 9090
• 9960
• 8443
• 443
• 80

Sincerely, I did not check if, strictly speaking, all the ports are necessary but feel free to test them and leave  a comment. These ports were the result of a few searches over the internet.

After setting up the tunnel, point your preferred browser to http://localhost and download the JNLP file at the following link:

HMC html page

I had to edit the codebase property of the JNLP file, but I guess it wont be necessary as I still had to edit the hosts file and add an alias for the machine name (eg.: hmc.my-server.mylocalnetwork).  You’ll end up having codebase as follows:

codebase="http://127.0.0.1/wsmship/codebase"

Edit hosts file

The next step is to edit your hosts file so it will have an extra alias pointing to 127.0.0.1. Copy the host name from the original value of the codebase property.
Then launch the JNLP file with Java Web Start. If you have the mime type correctly associated at your operating system, double click the file and wait for its launch. Sometimes it may complain at the first connection attempt, retry it and it’ll connect successfully. I guess I might still be missing some ports from the 30000~30009 range, since my first attempt was using ports from 30001~30009 and it always complained at the first attempt.

WebSphere Concepts: Cell, Node, Cluster, Server…

Quick post… If you are not familiar with WebSphere at first you might get confused with its concepts: cell, deployment manager, node, node agent, cluster, server, …

First of all, lets start with the concept of a Cell:

A Cell is a virtual unit that is built of a Deployment Manager and one or more nodes. I guess a picture will help making things clearer:

WebSphere Cell

But still there are a few concepts that need to be explained. The next obvious one is the Deployment Manager.

The Deployment Manager is a process (in fact it is an special WebSphere instance) responsible for managing the installation and maintenance of Applications, Connection Pools and other resources related to a J2EE environment. It is also responsible for centralizing user repositories for application and also for WebSphere authentication and authorization.

The Deployment Manager communicates with the Nodes through another special WebSphere process, the Node Agent.

The Node is another virtual unit that is built of a Node Agent and one or more Server instances.

The Node Agent it the process responsible for spawning and killing server processes and also responsible for configuration synchronization between the Deployment Manager and the Node. Extra care must be taken when changing security configurations for the cell, since communication between Deployment Manager and Node Agent is ciphered and secured when security is enabled, Node Agent needs to have configuration fully resynchronized when impacting changes are made to Cell security configuration.

Servers are regular Java process responsible for serving J2EE requests (eg.: serving JSP/JSF pages, serving EJB calls, consuming JMS queues, etc).

And to finish, Clusters are also virtual units that groups Servers so resources added to the Cluster are propagated to every Server that makes up the cluster, this will in fact affect usually more than a single Node instance.

Lets finish this post with another diagram to illustrate all those concepts.

WebSphere Concepts

First impressions of IBM WebSphere MQ Low Latency Messaging

IBM has a rather new platform for messaging. It is called WebSphere MQ Low Latency Messaging (aka WebSphere MQ LLM). It was released on the fourth quarter of 2007 and sincerely it hasn’t much similarities with the well known WebSphere MQ (former MQ Series).

First of all, after installing it you will probably notice that there isn’t a service for starting up. Soon you notice that it is rather a library that provides messaging services. Actually, it is a native library (currently [v2.1] only available for Linux x86, Windows x86 and Solaris Sparc) that comes already with JNI bindings.

To make things even harder, there isn’t much documentation available (and it seems like IBM is still organizing its docs online).

But, IBM claims that it has shown impressive numbers on its benchmarks:

WebSphere MQ Low Latency Messaging has demonstrated very high throughput, one-to-many multicast messaging, which can deliver approximately one million 120-byte messages per second on Ethernet, close to three million 120-byte messages per second on InfiniBand, and more than 8 million smaller messages per second, all on common x86 servers. Testing has also measured very low latency of 30 microseconds for 120 byte messages delivered at 10,000 messages per second on InfiniBand or 61 microseconds on Ethernet (1)

Source: IBM press release

In its Java version, the main classes that you’ll interact when using WMQ LLM are:

• RUMInstance (available through RUMFactory)
• RMMInstance

For instance, RUM stands for Reliable Unicast Messaging and RMM stands for Reliable Multicast Messaging. As you can guess, RUM is used for Queue styled messaging and RMM for Topic styled messaging.

One of its drawbacks is that it still lacks a JMS based Resource Adapter but nothing denies you from rolling your own if you can’t wait for an official adapter from IBM.

I am planning to do some benchmarking against a regular MQ integrated application. As soon as I have the results I’ll post them over here.

WebSphere custom user repository

If you already used JBoss you probably used (or at least knew there is) the DatabaseServerLoginModule. But, if you happen to be using WebSphere things are a little bit different. WebSphere (I guess version 6 onwards) comes with the powerful concept of the federated repository. This feature allows multiples sources for authentication and authorization. The final layout inside WebSphere ressembles an LDAP tree, every Repository is suffixed with an identifier.

But, unfortunately, through the Web Administration interface you are limited to LDAP and the builtin FileBased WIM authentication.

Another thing that makes it even harder is that there isn’t much documentation about these extended repositories.

There is one post from IBM that suggests that there are alternatives:

The information used for the registry lookup is customizable and can be made totally flexible if a custom registry is developed using the WebSphere Application Server custom registry interface.

But still there isn’t a single link from this article that points out how to achieve this. If you get the key words in this phrase and risk a Google search you’d end up finding how to do this on WebSphere 4, that, by the way, was much limitted when compared to what is available on WebSphere 6.

Refining this search a little bit you’ll find what you are looking for, how to do this on WebSphere 6. But you’ll only take this approach if you are willing to roll your own adapter, but be advised that this tutorial won’t cover every steps you need and this is the content of another post. There is a complex interface that needs to be implemented in order to fulfill the requirements of an WebSphere Repository. The complexity is derived from the fact that all method in this interface is based on commonj.sdo.DataObject class and this class maps an XML to a Java Object hierarchy making for now this implementation almost a guessing game since there isn't much public information regarding this interface contract.

But, returning to the original objective of the post that was to guide on how to make WebSphere authenticate users against a database, setup the DBAdapter using the guide that is found on this page. If you want, check the list of WebSphere builtin adapters here.

The last step is to create the tables for the database as described on step 3 of this post. This post in fact describes various possibilities for user repositories available in WebSphere.

JBoss DatabaseServerLoginModule adantages over WebSphere approach are its simplicity and flexibility but on the other hand, WebSphere Federated Repositories present a much more robust approach for handling user databases.

I’ll try to post some tips on how to roll your own Repository in the next few days.

Avoiding method timeouts in EJB Containers using Command Pattern with a JMS Queue

If you ever needed to run a complex processing in EJB that would take for example two minutes you probably have already faced the container time limitation for SessionBean methods.

This timeout (in contrast to what most think) isn’t there only to developer’s life harder. Actually, it is exactly the opposite: it is there to avoid that someone inadvertly implement a code that takes the whole server down (including your beloved application).

But there are times when long running operations are really necessary, for example a cache warmup.

MDBs are an exception

As in our project a few operations would easily violate this limitation we had to research a smart way of circumventing this limitation. During our research we found out this post on /dev/websphere blog. So we already knew that we would end up using a JMS Queue but having one Queue, MDB and so ever for each task would be a mess (not to mention that it was way too much work and not ellegant). So, that was when we came to the conclusion that what we needed was an way of having multiple tasks on top of the same infra-structure.

Command Pattern to the Rescue

We realized that by using an ObjectMessage that carried our Command object we would end up having a single queue that would handle all of our long running tasks. If there is specific context for the task processing we can have it stored in the Command Object (eg.: id of a purchase transaction that needs to be processed, or even the purchase object itself).

Sequence Diagrams for the solution

Let’s have an example, suppose we have a long running cleanup of a database that needs to be run in a timely manner. We would end up having the following flow of method calls:

JOB Submission on Working Queue

Having the Command object implement Runnable interface is a wise idea (to avoid having another interface that is almost a Runnable clone not to mention that future JavaEE Asynch beans will probably be implemented on top of Runnable interface).

The next important part is the JOB execution, which is depicted below:

JOB execution Working MDB

As mentioned on the notes, you need to be aware that the Transactional Context for the MDB MUST be Never, otherwise you’d avoid method timeouts but would still have transaction timeouts.

Another tricky part is splitting the long running task in smaller chunks that can execute under the method timeout.

As stated in the diagram, the LongRunningJOB code inside the run method is called inside the execution context of the MDB which is free from the method timeout limitation.

Signalling JOB return code

If you need to be notified that the JOB has finished its execution you’d need to have either another JOB passed as parameter to this JOB and it’ll be responsible of executing the code that would inform its return status OR have a message sent on a Temporary Queue OR the last option would be to submit a reply in another queue and have a CorrelationID link the request and the response message.