river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)
Date Fri, 02 Oct 2009 10:54:45 GMT
Hi

I also think this is a good direction to go in, and would benefit from
group discussion (and action :)).

Personally, I think it would help if we focused on a handful for
specific, widely-applicable use cases/deployment targets. What I mean
is that for example, in my work environment it's hard to get people to
accept a new type of service container or service container model. But
if I say, this service can be packaged as a WAR, or it's just a Java
app that can be started on its own (e.g. with Java Service Wrapper),
then they will go along with it. I think there is a target "market"
for service-oriented/distributed apps which rely on mainstream Java
container/server technologies. That won't address all of the River
community's interests, but I believe this offers us the opportunity to
extend the community to those who would otherwise be considering
something like the Web Services stack or JEE.

I'm not saying that River as a whole needs to move in that direction,
but that it should driven by a sort of partner community/subproject. I
know from previous discussions on the mailing lists that there are
those that don't want to see Jini be pushed/promoted as just another
alternative to web services and JEE, and I agree that the vision and
capabilities of Jini include much more than that. But it is a market
which I, for example, ended up working in, and so I'd like to promote
that use-case. I also think that the previous community experiments
with one central Jini/JavaSpaces project and any number of external
projects doing their own thing hasn't worked out that well. Most, if
not all of the Jini-based service container/deployment projects are
run by one developer. I think only Rio has a sizable community in that
space. It would be better, IMO, if River had a sub-project for
container deployment, perhaps with a set of standards, e.g. around
annotations, configuration, and allowed/supported different
implementations. There is a lot of useful and usable code in the
various sister projects (Rio, Bantam, Seven, reef, etc.) which we
could use as a starting point.

Off the top of my head, some important goals/features would be
- Deployment to "standard" web containers, basically anything
supporting either basic Java web stack (servlet/JSP) or full JEE; this
would include servers like Tomcat, Glassfish, Jetty, Resin, etc.
Should work out of the box with a "standard" deployment package like a
WAR, EAR or SAR.
- LUS and codebase servers packaged for the same type of deployment
- Optional "simple server" startup outside of a container using Java
Service Wrapper (open source, cross-platform, includes watchdog
process, configurable, etc.) or equivalent
- Annotation-based "lightweight" service declaration--the whole JEE
and web services stacks are moving in this direction
- Automated DL JAR building either at compile time or at runtime
- Utilities (including command-line) to monitor lookup services,
health-check services for reachability, etc.
- Standard JMX beans to monitor and configure services

I'd add that it's important to provide a simple alternative to the
external Jini-specific config files. Something like Mayflower is one
direction to go in (since it integrates with Spring)--note that there
is a dependency injection API that will likely be approved for JDK 7
and which will allow dynamic configuration implemented by e.g. Spring,
Guice or others.

Last point, there has been a sea change in server-side app development
for Java servers in the last few years, driven in part by the success
of Ruby on Rails. All of the standard frameworks and APIs are going in
the direction of annotation-based configuration, convention over
configuration, and lightweight setup. This doesn't just impact the
initial out-of-the-box experience, but also the scenario where your
team decides, "we need to split this out to another service" and need
to do it quickly, e.g. in a matter of days or a couple of weeks, not
of months.

Hope this is all not off-topic for the thread.

Regards
Patrick

Mime
View raw message