Posts Tagged ‘ejb’

Now.. C# to EJB over QMF

Posted: June 19, 2009 in geek stuff
Tags: , , , ,

This is a follow up to the earlier post about accessing EJBs from python.. In this post, we will build the CSharp Console and use that to access the EJBs which are running on JBoss. This code was built and tested using Mono on Fedora 10. My hope is that someone can test out the console in a windows proper environment. CSharp to dotnet is pretty hard with all but the most vanilla WS technologies. This post shows how the Qpid Management Framework can bridge that gap.

First.. follow the directions from the earlier post to check out the latest qpid code from apache, and the latest qmf example code from github. I will assume you have the broker running, and that you have tested the python client to see that it is working.

Now, lets build the dotnet qpid code. You will need ant, mono, and nant installed.

cd qpid/qpid/dotnet/client-010
# Read the README.txt file if things go wrong
cd gentool
cd ..

If you are getting a nansty nunit error, do the following before running nant:

export MONO_PATH=/usr/lib/mono/nunit22/

Now, we will build the test code which will use the console to access the Java Server. The example code has 2 versions. One is using the raw QMF Session interface, and is the most similar to the python code. This is located in the qmfExample/cSharpConsole/generic directory. The second has some classes which were generated off of the example schema. This code is located in qmfExample/cSharpConsole/generic. The same logic can be used to generate either one.

cd qmfExample/cSharpConsole/generic
# edit your and set the property qpid.dir
# it is now built, lets run it
export MONO_PATH=$MONO_PATH:[QPID_DIR]/qpid/qpid/dotnet/client-010/bin/mono-2.0/debug/
mono ./bin/QmfExample.exe

And.. Bobs your uncle. Now we have 2 technologies (python and C#) which are historically not friendly to Java, accessing EJBs running on Jboss.


My current project is looking at how to expose Enterprise Java Beans to other technologies. I am most concerned with C#, but any other languages would be cool. We looked at the WS-* standards (and CXF which is a great tool) but the different versions across the vendors provided difficult.

We then looked at QMF, which is an management framework written on top of the QPID messaging fabric. You can learn about QMF here. This post will walk you through an eaxmple of exposing an EJB in jboss over the QMF Bus. Gregory Mostizky is working on a deployer, so this should get easier.. but this is a good enough to criticize.. so I am posting it.

To get started, you will need the gcc tools, ant, and jboss5 installed. Next.. get the code:

# Get the latest QPID Code
svn co
# Get my example Code:
git clone git://

Build the latest qpidd broker and java code

cd trunk/qpid/cpp
./configure --prefix ~/qpidlocal
make install
cp ../java

Once this is done, you should be able to launch the most current qpidd

export LD_LIBRARY_PATH=~/qpidlocal/lib

Now…. build the example code:

cd ~/qmfExample/javaAgent
# Edit the file to point to your local
# installation
ant install

You can now start up jboss, and run the example python script to access the bean

export PYTHONPATH=~/trunk/qpid/python
cd ~/qmfExample/pythonConsole
python ./

Thats all there is. Python is now calling EJBs! Now… lets see how we did it. All the code below is in the qmfExample/javaAgent/src
directory. Lets first look at the Session Bean we created:

package qmf.example.ejb;

import java.util.ArrayList;
import java.util.List;
import javax.ejb.Stateless;
import org.apache.qpid.agent.annotations.QMFHide;
import org.apache.qpid.agent.annotations.QMFObject;
import qmf.example.BaseClass;
import qmf.example.DerivedClass;

@QMFObject(className="ExampleService", packageName="qmf.example.ejb")
public class ServiceClassBean implements ServiceClass

    public BaseClass getBase(String name, String description) {
        BaseClass bc = new BaseClass() ;
        bc.setName(name) ;
        bc.setDescription(description) ;
        return bc ;

    public DerivedClass getDerived(String name, String description, int count) {
        DerivedClass dc = new DerivedClass() ;
        dc.setName(name) ;
        dc.setDescription(description) ;
        dc.setCount(count) ;
        return dc ;        

    public List findMany() {
        ArrayList list= new ArrayList() ;
        list.add(getBase("JarJar", "My Friend")) ;
        list.add(getDerived("Binks", "Not My Friend", 12)) ;
        ArrayList data = new ArrayList() ;
        data.add(11) ;
        data.add("Info") ;
        data.add(getBase("Wotto", "Also My Friend")) ;
        list.get(0).setStuff(data) ;
        return list ;

    public void doHokeyPokey() {
        System.out.println("Turn yourself around") ;

This is pretty normal except for 2 annotations. One, @QMFObject, gives
the name and package to expose. The second, @QMFHide, causes the method
to be ignored. The bean returns 2 classes, a base class and a derived
class. We have annotated the base class so that the marshalling code
knows about the derived class. This is a similar pattern to JAXB:

package qmf.example;

import java.util.ArrayList;

import org.apache.qpid.agent.annotations.QMFSeeAlso;

public class BaseClass

The final magic, is a beans.xml file which tells the JBoss microcontainer to start up the agent. Here is the code for that:

<deployment xmlns="urn:jboss:bean-deployer:2.0">    

	<bean name="QPIDConnection" class="org.apache.qpid.client.AMQConnection">
    <bean name="ServiceBean" class="org.apache.qpid.agent.ManagedEJB">
        <property name="name">ServiceBean</property>
        <property name="className">qmf.example.ejb.ServiceClassBean</property>        
        <property name="jndiLocation">qmfExample/ServiceBean/local</property>

	<bean name="QMFAgent" class="org.apache.qpid.agent.Agent">
		<property name="label">agent</property>
		<property name="sessionTransacted">false</property>
		<property name="connection">
			<inject bean="QPIDConnection" />
		<property name="managedObjects">
			<list elementClass="org.apache.qpid.agent.ManagedObject">
				<inject bean="ServiceBean" />		
		<property name="registeredClasses">
			<list elementClass="java.lang.String">	


As I said earlier, the deployer should make this easier. Specifically.. it will remove the need for the beans file. But.. this will work until the deployer is done.