river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: federation
Date Tue, 25 Sep 2012 04:11:26 GMT

On Mon, 2012-09-24 at 12:01, Simon IJskes - QCG wrote:
> On 24-09-12 17:02, Greg Trasuk wrote:
> > I had a look at your file.  Personally, I see a more declarative
> > approach in the future, but I always think that its up to the users to
> > lead us onto the right path by using the approach that suits them best.
> > As such, I'd encourage you to code it up and put it out there.  I don't
> > think that we should present any approach as "the one and only way", but
> > one or more "good ways" should establish themselves in time.
> 
> Thanks for your reaction. What i believe you are saying is, that you 
> don't like the approach. 

I'm afraid I've given the wrong impression, due to e-mail's lack of
intonation.  "Don't like" is too strong a phrase.  It's more like the
way I don't like Stilton cheese.  I accept that Stilton is a perfectly
fine cheese, and many people like it a lot, but I wouldn't eat it.  I
happily serve it to guests, however.  Who am I to comment on other
people's taste?

> Could you provide a small code snippet of how 
> you would like to see your declarative approach?

For service definition, I'm thinking something like this (starting from
your DemoServiceImpl class):

@Service(exporter="defaultExport", join="defaultJoin")
@NameEntry("DemoService")
@ServiceInfo(name="DemoService", manufacturer="Apache Software
Foundation",
 	model="demo-101", version="1.0")
public class DemoServiceImpl
    implements DemoService
{

    @Override
    public String hello(String msg)
            throws RemoteException
    {
        return "hello back: " + msg ;
    }
    
}

My thought is that you'd package one or more of these classes in a jar
file (service archive, or ".sar"?) and deploy it to the service
container.  Much like in EJB3, the container would scan the jar file for
deployable services, and export, then register them in the appropriate
join group.  It could continue to use the
"net.jini.config.Configuration" mechanism, or possibly some other config
mechanism.

The surrogate container in "skunk" has allowances for pluggable
deployers in addition to the "service-starter-service" deployer that is
currently in there to support the core services like Reggie, so we'll be
able to experiment with the concept.

The "service-starter-service" deployment mechanism currently in the
container is to create a "service-starter archive, or ".ssar" file that
contains all the application's jars (in 'lib' and 'lib-dl' folders to
support the codebase server, plus the configuration file and a starter
configuration file of the form shown in  
http://svn.apache.org/viewvc/river/jtsk/skunk/surrogate/testfiles/hosted-reggie.properties?view=markup.
 Then you put that archive file into the deployment directory.  Right now it will start the
service when you start the whole container.  The next step is to add hot deployment and undeployment.

Cheers,

Greg.

> I'm not presenting this as the one and only way, it is intended as a 
> catalist for a discussion about the 'simple way' to start working with 
> river. My idea was not to encapsulate away river, but to provide getters 
> for the internals, so that entry (or lazy like me) users, can start with 
> something. I'm not convinced that a entry user will declare him/herself 
> and start to dictate, indicate what we should build.
> 
> Encouraged by your reaction i will add some more code to the template, 
> but coding it up, on my own, to a working example was not my intention, 
> working as a team is much more to my liking. :)
> 
> Gr. Simon
> 
> -- 
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397


Mime
View raw message