Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)

[Tom Hobbs <to...@sucfin.com>]

I think there is a lot of merit in this idea.  Creating a standard
".jsd" that described where to put which files (and therefore, which
files are needed) would make River service creation and deployment much
simpler.

One of my frustrations is the sprinkling of different discrete files and
bits and bobs that are all required to start up a service.  Of course,
once you're used to what is needed it becomes second nature, but
developing that second nature is a pain.  As is troubleshooting when
your second natures lets you down!

However, defining an archive file structure that describes everything
you need - and presumably ant tasks and the maven equivalents, to
generate and start/stop these things - will make life a whole lot
easier.

Where I work, we have a concept of a grouping of services which can all
be started together, often in the same JVM.  Any given host can run
multiple "service groups".  We developed our own directory structure
which describes where everything goes, new "service groups" then use a
template of that directory structure.  The problem with this, though, is
that the scripts are all OS specific and need constant configuring and
maintaining.  Also, hand rolling a "service group" directory is error
prone (although made simpler with some Bash magic).

If I understand Gregg (do I?) developing a way to package a service or
services could be left to some, River supplied, automated tool.
Starting them then becomes a simple process of;

$ java com.sun.jini.start.ServiceStarter MyService.jsd

Or something.

I also like the idea of making a mechanism of dropping these ".jsd"
files into other container environments.  Dare I say "OSGi"?  And have
them handle the starting/stopping of them.

River is great in that you can do a whole heap of really clever and
amazing things with it.  But speaking as an "app developer" who just
wants to write services that will live solely within his own companies
secure and safe subnet,  River/Jini can be an absolute pain.  

Again, if I understand it right, these ".jsd" files would take away much
of that pain.  Right?

Great idea, Gregg.  In my opinion, this is well worth a Jira of its own
and some serious thought/effort put into it.

Cheers,

Tom



-----Original Message-----
From: Gregg Wonderly [mailto:gregg@wonderly.org] 
Sent: 01 October 2009 20:08
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release

Dennis Reedy wrote:
> Hi Gregg,
> 
> To a certain extent I think having an archive would make sense, but as

> it relates to Maven created service artifacts I am not so sure.

I am not trying to focus this issue on solving anything related to
maven. 
Instead, I am trying to discover what people think about creating an
archive 
structure that could then be used for service deployment into various 
environments.  Clearly, we could provide an archive assembler that used
maven 
for managing the content of what was placed in the archive.

The generation of the archive is one issue.  But, on the other end is
the 
consumption, and that's where I'd like to initially focus the
discussion.  I 
think that if we feel like it is something that the containers and
deployment 
environments could use, and benefit from, than we can talk about
providing such 
archives as a maven component from the river build.

I'd like to discuss deployment issues regarding packaging, managing
various 
pieces of a service deployment in particular environments, and solutions
people 
have put together to see if there really is a place for such a thing, or
if I'm 
just barking up the wrong tree.

Gregg Wonderly

www.sucdenfinancial.com

Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000

Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.

Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.

The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.

This message has been scanned for viruses by Mimecast.

Re: Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)

[Patrick Wright <pd...@gmail.com>]

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