river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Hobbs" <tom.ho...@sucfin.com>
Subject Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)
Date Fri, 02 Oct 2009 09:27:53 GMT
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

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

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.



-----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
Instead, I am trying to discover what people think about creating an
structure that could then be used for service deployment into various 
environments.  Clearly, we could provide an archive assembler that used
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
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
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
pieces of a service deployment in particular environments, and solutions
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


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.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message