river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Wright" <pdoubl...@gmail.com>
Subject Re: What will eventually be in River?
Date Wed, 03 Dec 2008 15:56:11 GMT
Hi Gregg

I work with users, not developers, of a Jini container. I thought I'd
put in a word for what's important to us in terms of Jini service
containers. We looked at several when moving to Jini a couple of years
ago, and as I've noted before, settled on Bantam, but I think our
criteria apply regardless of our current choice.

One thing that distinguishes Bantam from other approaches is that
Bantam offers a framework for hosting services, rather than a program
which launches and starts services. That is, we can deploy a
Bantam-based service within any standard Java web container (I believe
you could use other containers to initiate the process, though). Thus
Bantam allows us to package up our services and deploy them, along
with some Bantam libraries, in a container-ized format, if one can put
it that way.

Specific questions about Bantam (or Mayflower, which provides for Jini
configuration via Spring) can go to Tom Cellucci, the project owner. I
apologize in advance if I misrepresent Bantam in any way.

- We favor using a "standard" container, such as a JEE or servlet
container, over a custom one specific to Jini, as there is usually
more documentation, testing, support for the standard containers as
such. That's not a hard-and-fast rule, but it's an advantage for us if
we can deploy services in, say, a WAR file in an unmodified servlet
container such as Tomcat. It's easier to convince our administrators
to accept a "standard" container in the production systems than (yet
another) custom one.

- We found it advantageous if the container could serve as a codebase
for its own services. There may be reasons not to do this, but having
the codebase problem--packaging and deploying JAR files--solved for us
by the Jini service framework was a real boon. Bantam can package
dependent/downloadable classes automatically on startup, and associate
the codebase URL as necessary during export. Generally this means that
if the web container goes down, so does the codebase server, which
seems about right in the simple case.

- Deploy and undeploy of services is, for us, determined by the number
of services in the WAR. We use standard WAR deploy/undeploy tools
available with the web container.

- The granularity, so to speak, of services in a deployment unit (WAR)
is up to us. We can have many service interfaces, or just one, in any
deployment unit.

- Remote deployment can be done with standard WAR deployment tools.

- Remote admin, in our case, is currently handled via JMX. Using the
support for JMX annotations in recent versions of Spring, plus
centralized JMX consoles, makes this very comfortable. We haven't
found a need for service administration above and beyond what we can
currently achieve via JMX.

- We don't have a policy for versioning (live updates to services),
though are planning on it. Unclear that we need any special support
for this from the Jini container, however, and weren't planning on
having any; rather, we'd rely on version information in the service
attributes and our custom service-lookup code on the client.

- Support for Spring-based configuration, replacing the custom Jini
config files, has been important to us, mainly because many of our
other (non-Jini) servers were already relying heavily on Spring, and
we can leverage this know-how across the team. We still use the Jini
configuration file format for our LUS and associated codebase, but not
for our own services.

- Support for auto-discovery of services by the Jini container, at
startup, has proven useful. Within the service classes, we use Java
annotations to declare the service name and some attributes of the
service. Additional configuration which is better off externalized is
handled via Spring. The Jini container locates services in the WAR
automatically at startup, prepares downloadable Jars, exports
services, etc. all based on these annotations and the associated
Spring config. For the service developer, this brings the conceptual
effort of designing a service closer to the conceptual cost of
designing the interface.

Generally speaking, on our team we have a sort of infrastructure
budget. While we spend quite a bit on infrastructure, it doesn't pay
our bills, so we have to choose carefully where to deploy those
resources. Being able to deploy into a standard container using
standard tools (e.g. 'any' servlet container with its tools) reduces
our investment in custom infrastructure. Being able to easily declare
new services for export, for example by breaking up large Java
interfaces, or merging smaller ones, is important to us.

Also, while we expect that the developers who end up writing Jini
services should know the basics of Jini, we also need them to be
problem domain experts, and anything the infrastructure can offer to
reduce the conceptual load of creating, modifying, and extending
services is a plus. Thus, the closer we can get to "just use these
annotations, make sure this is serializable, configure these two or
three beans, etc.", the more those developers can focus on what the
service needs to do, rather than how its launched, hosted, or made
available over the network. Of course we have cases where someone has
to dig deeper into the guts of Jini, but we try to avoid this unless
necessary.

To be honest, Bantam does have some gotchas, in particular related to
how JARs, classes and resources are located within the WAR file. Tom
can clarify the exact reasons, but it's not (in its current state)
without some learning curve.

Personally, I would be glad to see the various projects in this area
(service container, configuration) work on a common solution, possibly
a "low-end" solution for simple cases, and an upgrade path to
"high-end", more complex solutions. In particular, it's worthwhile to
note how much both the Spring libraries (and there are many), along
with annotations, have made some rather dreary tasks like working with
JMX and AOP very simple. JPA is another good example of, for the most
common case, simplifying what used to be a mess of configuration. I
think we in the Jini community can learn from this and apply it to the
Jini landscape. I also feel that given the low activity in many
Jini-related open source projects, it would be worth our while to pool
several projects together into a smaller number of more active
projects.

I hope this is helpful in some way, and I'm glad that you launched the
discussion.

Regards
Patrick

Mime
View raw message