river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: [Discuss] Please have a look at the River Container
Date Wed, 19 Feb 2014 01:51:49 GMT
Greg,

FWIW, I agree with you.  I find the lack of relative ease of use is the
number one adoption inhibitor of Jini, now River. Further, the idea of
creating something that is not in the mainstream group thought process will
be greeted with lengthy and detailed rationale for why it's not the way to
go.

I introduce distributed OSGi, Jini/River, and Paremus to developers who
become intrigued and fascinated.  However, the lack of relative simplicity
and reliable,  straightforward methodologies invariably lead to confusion
and drifting away toward classic JEE approaches.

There was a DARPA program called Control of Agent Based Systems (CoABS),
which I believe started in the late 90s.  It basically created an
abstraction over Jini.  It was comparatively much easier than Jini. IMHO,
it's too bad the software wasn't "stanadardized" and released as free and
open source software.  Having said that,  there is a version of it
available on sourceforge called Intelligent Services Layer (ISL). (
http://sourceforge.net/projects/isl-soa/). I'm not sure what,  if any,
license applies. But I thought I would share it with you.

Again, in my opinion, if you have a vision with this technology,  I
recommend you run with it, even if you have to somehow fork or create a new
project.  You will very likely not garner support from others on this group.

If you do move forward with this,  please feel free to add me to any
notification list. I believe the underlying model is sound and useful. So
anything that makes it more easily  adopted is interesting to me.

Thank you!
Sam
On Feb 18, 2014 10:12 AM, "Greg Trasuk" <trasukg@stratuscom.com> wrote:

>
> 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=tgzas
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
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message