river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net
Date Thu, 09 Dec 2010 18:39:22 GMT

On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
> Usability is a tough problem we need to solve, I recall Dan Creswell 
> highlighted some relevant issues.    If your looking at all the 
> different down stream projects and want to get their cooperation for 
> some common functionality, we'll need to get some community buy in.  
> These people are probably more aware of the pitfalls and I think we need 
> their insight.
> 
> There's all the different containers too.  Perhaps it's time we have a 
> standardised deployment container?  So users can choose and migrate 
> among any of the downstream projects or our own in house simple version 
> (that supports what you're working on) without lock in.
> 

So, I've been working on a clean-room implementation of the Surrogate
spec.  The work so far (mainly some building blocks) is in Subversion
under jtsk/skunk/surrogate.

I concluded early on that hosting Surrogates was really a subset of
hosting plain old services.  As a result, the emerging architecture is
that of a container that manages the classloaders and codebase servers,
but that has a pluggable deployment architecture that can support
surrogate packages, "starter-style" packages or other deployment units.

To some extent, this container is "Harvester 2.0"; it reflects my unease
with going through and restructuring the Harvester code for Apache
release (I had thought about contributing Harvester, but decided to do
this new surrogate container instead).

I am envisioning a deployer that would support definition of services
using annotations, much like EJB3 supports,  e.g.

public interface HelloInterface {
    public String sayHello(String name) throws IOException;
}

@Service
public HelloService implements HelloInterface {
    public String sayHello(String name) { return "Hi there " + name); }

    /* @Proxy says "Inject my exported proxy here, please!" */
    @Proxy 
    HelloInterface myProxy=null;
}

You would create your services, pack them into a jar file (with an
appropriate manifest) and copy the jar file into the deployment
directory.  The deployer then goes through the jar file looking for
@Service annotations and exports them.

The container will also host (with all the codebase crap handled!)
instances of the River infrastructure services (Reggie, Mahalo,
Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
and management will not be awfully difficult.

The goal, much like Harvester, is one-shot deployment, with a
programming model that will not seem alien to servlet or EJB
programmers.

So, stand by, the container is starting to come together.  Once it's in
a form that can host Reggie and deploy a service or two, I'll let you
know.  At that point, I suppose we'll want a catchy name...

Cheers,

Greg.
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


Mime
View raw message