Re: EJB, or one rather detailed comment

A fascinating solution came up in connection with the post When should you use EJB?
Pavel Roušar, a.k.a. Totem, brought it up.
With his kind permission, I’m publishing a more detailed description of a solution that caught my interest, and I hope it
interests you too.

Our uKernel isn’t built on a particular technology such as JMS. It’s pure Java code with no dependencies beyond the JRE. The MessagingBroker provides JMS/MQ service, just as it provides any other regular service.

I’d heard about the JBoss microkernel too. I think you linked to that HTML they released. We handle classloading ourselves, though perhaps we can get JMX in as another broker for services that manage the service queues and the microkernel itself.

The uKernel itself does practically nothing. Everything happens in “userspace.” Even permissions work transparently. They don’t require any changes to the uKernel code or implementation in the consumer, although that’s possible.
As for the structure itself, each service, or rather each service request, is mapped to a queue with a service stack, currently using XML configuration. A request then works its way down the queue, and in the end a POJO is returned to the consumer. I tried to keep it abstract, so everything is simply an N-dimensional mapping vector from the set of products to the set of producers.

Beyond being clean, the concept lets you do some neat things, as you’d expect from a microkernel, including transparent load balancing, caching, filtering, and permissions. I provide services. Describe what you want and I’ll get it for you. You don’t need to worry about implementation details or change your code unnecessarily. Just describe it using the protocol and we’ll see. For example, one developer left and we needed to teach his service broker to cache. I just put a caching broker before or after it in the right queue and that was it. That does sound a bit like AOP.

In the bare kernel anyone can do whatever they want, such as register and consume services. The uKernel is clean and simple, but that’s insufficient. So the first ServiceBroker in a queue is a “state filter,” a little iptables of sorts. It lets through only requests from a trusted object, for example, to load or unload a service broker. A signed module is one example. And it’s just one broker among the others.

That’s the basic concept, which I think is sensible and simple. I think the technology worked exceptionally well for a huge portal we were building. The postal service is about to launch it. Other projects are following. The code ends up so structured and readable that coding starts to get rather boring.

It’d be great if you or one of your readers felt like getting involved, or just wanted to exchange a few words. Maybe it might deserve some attention from the ASF later.

Image could not be loaded. Archive image in Re: EJB, or one rather detailed comment, figure 1

↗ Medium