Hi all:
For the past little while, I’ve been working on the Apache River Container
(feel free to suggest a better name), which was originally the Surrogate
container.
I haven’t asked for any help or encouraged collaboration so far (although the
project has been in the Apache River repo, so you’ve seen the commit messages),
mainly because I hadn’t crystallized the architecture enough to explain it to
anyone. I find that happens in a new project - you need to flesh out the
concepts before you can talk about them.
That phase of the project is done, I think. It’s time to invite some other
people in.
So, I wonder if I could ask you all to have a look at the container, and
perhaps help finish it off?
The goal of the container was originally to implement the Surrogate
Specification, but it rapidly changed. The new goal is to:
- Create an easily usable deployment environment for Jini/River
services and service consumers (i.e. much simpler to use than the Service
Starter framework - much more like a servlet container).
- Specifically solve our “First Fifteen Minutes” problem.
The container allows “copy and paste” deployment of service modules.
Basically, you package your service into a single archive file that includes
the service’s jars as well as the codebase jars, then copy that archive into
the container’s deployment directory. The container starts up the service in
its own class loader, protected by appropriate Permissions, and publishes the
codebase jars on a local web server. You can deploy multiple applications to a
given startup profile. By default, the container includes starts Reggie and
Mahalo, so it’s a one-stop deployment (obviously in a real SOA you wouldn’t
want the infrastructure services in every container, but it’s handy for
development). It also provides a similar environment to run service consumer
(client) applications - after all, a client might also want to publish service
endpoints, e.g. for notifications.
Obviously, it’s not a released project, so right now you have to build from
source. The source is in Apache’s git repository at
https://git-wip-us.apache.org/repos/asf/river-container.git. If you’re not a
‘git’ user, you can download a snapshot from
https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=snapshot;h=4f7b49be7129170a4a274b7867e2fb5ee0965376;sf=tgz
as a ‘tar.gz' file.
Apache’s git browser doesn’t format the README file (it’s in Markdown), so you
might prefer to read it from my github repo at
https://github.com/trasukg/river-container/blob/master/README.md. It contains
a “First Fifteen Minutes” evaluation guide.
Eventually I’d like to propose this container as an additional deliverable from
the River project. For now, please have a look at it and give feedback,
particularly on the “First Fifteen Minutes” experience.
As far as contributions, I’m hoping that looking at the current state will
generate a wish list, and then we can see who wants to do what. Right now, my
immediate wish list is to have a Maven plugin to do the deployment (I’ve
started work in that direction) and some admin. Later, I’d like to see
integration with the SSL-based JERI endpoints (mainly I think we need to have
the container be aware of the key store), better thread handling (which
requires changes to the jtsk platform, unfortunately), JNDI database
connections, and then an annotation-based service definition model. I’m
looking forward to hearing others’ comments.
By the way, inevitably this container will be compared to Rio and other
containers, and someone will ask “Why didn’t you just use Rio (or ‘startnow',
or Seven, etc)?” What can I say? I had a different itch to scratch. Rio
includes quality-of-service handling that I didn’t need, and I wanted a
container that had a similar deployment model to Tomcat, so I wrote it inside
the Apache River project. People are also encouraged to look at Rio, and if
the Rio group wants to contribute code to River, we should welcome them. I’ve
always thought there’s room for diversity in how we deploy services, although
we probably should encourage a packaging and service-definition standard. I
think we’re all in agreement that we can do better than the Service Starter
framework.
Cheers,
Greg Trasuk
