This essay goes quite technical at times but the presented idea is pretty simple.
Java and the J2EE stack seem to be used in large-scale enterprise web solutions. Ruby is an odd hippie programming language that is not so often met (yet!) in this enterprise world. Ruby on Rails does not quite have the native equivalent in Java web development toolpack, and there never will be such. One key fundamental difference in Java and Ruby, is their measure of abstractness. Higher abstraction in some cases help to describe and solve the problem in just a few code blocks. Ruby lets you express ideas outside the micromanagement level - right from the beginning of your introduction to the language.
JRuby helps to break a major technical barrier, making possible to leverage the massive amount of Java libraries that now can be used through the Ruby interpreter. This is a description of a real world scenario where Ruby expression describes and solves the problem quite beautifully.
To understand what is happening next you need to know that an EJB is an Enterprise Java Bean. You can imagine that the Bean is an exporter in Brazil. The Java transaction layer RemoteMethodInvocation is built on top TCP/IP infrastructure. Regular citizen Java clients need to contact their national supplier.
It is quite a bureaucratic process. It takes some knowledge of Java to understand how each object should behave. EJB3 makes this a bit easier but to efficiently use the developer tools will take a long time to learn. This is an example of the Java enterprise business model where you develop on elaborate IDEs and large companies have lots of people doing object-oriented chunks of code. After having that much Java your dreams will become XML configurable for a while..
Ruby has a similar technique, DRb - Distributed Ruby. It is built into the Ruby core language. It provides a way to share data objects over the wire. As we will see, it takes only a few lines, perfectly writable even from the vi editor.
Now, let's inspect the supply chain.
bean_context =
{
'java.naming.factory.initial' => 'com.evermind.server.rmi.RMIInitialContextFactory',
'java.naming.security.principal' => security_principal,
'java.naming.security.credentials' => security_credentials,
'java.naming.provider.url' => provider_url
}
This is the Brazil Bean exporter who has the brew I like. His contact is found by jndi_name from the @context. Home represents my national office who will be creating me this @stub guy who actually does the delivery of my order.
@context = InitialContext.new(bean_context)
@home = @context.lookup(jndi_name)
@stub = @home.create
EJB home is an object that implements the create() method for requesting the remote EJB and returning the stub object that acts as the EJB interface. It acts a bit like a database table model.
Let's say we want to know more of the company..
@stub.companyID
=> "430146"
@stub.companyName
=> "Brazil Bean Provider"
Mmmh. So let's make an order..
@order = @stub.createOrder(uid,"Coffea arabica, 1 kg sample")
=> #<#:0x62ee558f @java_object=BBPServices stateless session>
Ah! It returned an object! One important aspect of the dynamic nature of Ruby (and thus JRuby) is that the callable methods need not be specified beforehand. The method call to the Ruby object is dispatched to the EJB, the return value as well and if possible, JRuby casts it to Ruby native.
@order.items
=> ["Coffea arabica, 1 kg sample"]
This could be usable in Rails, but the architecture should allow dynamic translation of method calls so that the solution would have the most leverage and also to stay clean out of implementation details. Ruby has the sort of inner beauty that is capable of this.
method_missing() is a powerful Ruby kernel method, which has its counterpart in Python and Lisp, possibly other dynamic languages are growing into that direction too. Unless you are not familiar with method_missing(), I will explain it so that when Ruby calls a method on the EjbObject's instance (there is this @stub), and the Ruby object does not find the method, it calls method_missing, and here the call is redirected to the @stub, alas the EJB interface and along the network over TCP/IP. In other words, Ruby does not care what kind of EJB it gets.
This is the core of EjbObject class:
class EjbObject
def context_environment
{
'java.naming.factory.initial' => 'com.evermind.server.rmi.RMIInitialContextFactory',
'java.naming.security.principal' => security_principal,
'java.naming.security.credentials' => security_credentials,
'java.naming.provider.url' => provider_url
}
end
def initialize
@context = InitialContext.new(context_environment)
@home = @context.lookup(jndi_name)
@stub = @home.create
end
def method_missing(method, *args, &block)
@stub.send(method, *args, &block)
end
end
EjbObject is used by subclassing it:
class MyEJB < EjbObject
set_provider_url 'rmi://....'
end
And so, this essentially is the JRuby engine in ejb2rb. The solution wouldn't be complete without the Rails counterpart, ActiveEJB. Conceptually DRb and RMI are very similar.
Ok - even if the code didn't speak to you, think it this way - now JRuby can talk to the remote Java beans, call their methods, and use the return values as other objects that have methods. Some object classes are mapped directly to corresponding Ruby classes, such as Strings, Arrays and Fixnums. The Java-cast beatnik flower child JRuby can talk enterprise jargon. The EJBDispatcher::Instance enables him to open a channel to one EJB for other Ruby VMs that are equally valuable as Ruby implementations but have not developed their Java-fu.
This is how the EJB stub object is shared for DRb clients (the thread is started later by Hydra):
module EJBDispatcher
class Instance
self.config = {
'hostname' => 'localhost',
'port' => '9876',
'class' => 'MyEJB'
}
def initialize
@uri = "druby://%s:%s" % [config['hostname'],config['port']]
DRb.start_service(@uri, Kernel.const_get(config['class']).new)
return DRb.thread
end
end
end
What happens on the Ruby end?
module ActiveEJB
class Entity < DRb::DRbObject
def initialize
uri = 'druby://%s:%i' % [drb_server,drb_port]
super(nil,uri)
end
end
end
ActiveEJB::Entity is used by subclassing it:
class MyEJB < ActiveEJB::Entity
include Singleton
set_drb_server 'localhost'
set_drb_port '9876'
end
So, in the end, you can use this in native MRI Ruby Rails:
profile = MyEJB.getUserProfile(@username, "PDS")
contacts = MyEJB2.getCountryContacts(profile.getAddress().getCountry())
contacts.each do |contact|
...
end
Or something .. usually more or less involving enterprise business logic.. The actual implementation can handle multiple concurrent EJB instances.
But, in the end, if we look at the power and sheer expressfulness of Ruby, I think this is a fine example of it working to solve a real world problem. The source code is available to help rubyists with the leverage this technology may give them trying to survive under the serviance of J2EE.
Oh, yes, the order:
@order.delivery.weight
=> 1.108
BrewerEJB.makeCoffee(
@order.delivery,
:espresso,
:milk => true,
:sugar => false)
