river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: River Container (was surrogate container)
Date Fri, 29 Nov 2013 04:21:51 GMT

Comments and questions intertwined…


On Nov 28, 2013, at 5:26 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:

> On Nov 28, 2013, at 244PM, Greg Trasuk <trasukg@stratuscom.com> wrote:
>> On Nov 28, 2013, at 12:59 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>>> On Nov 28, 2013, at 1159AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
>>>> I’m all for bringing Rio in at the same time!  It’s good to have choices.
>>> Perhaps what we should also focus on is to create (or move forward) either a
standard archive (the SAR) or interfaces that define semantics for deployment. That way we
can have multiple
>> Probably a good idea.  The way the river-container (probably needs a new name) is
architected, we can add additional deployers that use alternate semantics or archive formats.
 The first one I did handles services that are designed for ‘com.sun.jini.start’, but
there’s no reason we couldn’t add others.  I’m already thinking about re-implementing
the Harvester-style API.  But even that’s looking pretty dated.  That’s what I mean when
I say it’ll make a nice test bed - for example, I’d really like to be able to do
>> @Service
>> @ServiceAttributes( { @Name(“Hello”) })
>> public class HelloImpl implements Hello {
>> 	public String sayHi(String name) {
>> 		return “Hi there “ + name;
>> 	}
>> }
> FWIW, my experience wrt annotations is while they are great for lifecycle type things,
attributes and other deploy-time things are best left in mutable formats.

Mostly agree.  For instance, I don’t think I’d want to specify invocation constraints
in an annotation.  On the other hand, some attributes, like Name or ServiceInfo seem pretty
static.  I think we’d have to have some way to say “this is a service” in an annotation,
blended with “look in the Configuration object under name XYZ for the details”.  In addition,
what I found with Harvester was that it was very useful to be able to instantiate an object
as a “component” that was available in the application context but wasn’t exported as
a service.

In the container as it stands, the global configuration can be selectively passed in to the
individual services’ configuration as “special” values.  For instance the default discovery
group name is available in a configuration file as $discoveryGroup, but is actually set in
the profile’s ‘config.xml’ file.  That way, services deployed into a profile can easily
inherit the discovery group that is set in the profile (although they don’t have to).

> Looking at supporting a subset of CDI (javax.annotation.PostConstruct, javax.annotation.PreDestroy),
and adding River service semantics (that deal with dynamic service issues; things like PreAdvertise
and PostUnAdvertise) might be a good start with establishing a base set of lifecycle semantics.
Keeping configuration items customizable at runtime is preferable.
I like CDI and Spring-style DI for building the application’s object graph.  I actually
wonder if we could use Apache OpenWebBeans to implement a lot of CDI functionality, then add
in Jini services to it.  For instance, would it make sense to create an InvocationLayer implementation
that did dependency injection and resolved service references before placing the call on the
service implementation?  The problem there becomes “what happens when resolution fails?”
 In an EJB-based CDI instance, resolution failure indicates an application bug (you’re missing
CDI components).  But in a network system, resolution failure is to be expected if a service
is offline, so the application needs to be involved.  It gets much more complicated than EJB,
which is static.  I think you’d have to have a @OnResolutionFailure method, and then somehow
allow the call to proceed or fail based on the results of that method.  You could also have
a proxy that re-tries the resolution, but again I think you can’t abstract failure away
from the application.

> What I would like developers to be able to do is create a River service using either
a multi-module Maven project, an Ant project, or a Gradle project, and choose to deploy the
service using a choice of River service instantiation providers. 
Agreed.  Developers need to have a simple way to create and deploy services and clients. 
I recall reading Dan Creswell’s “How to write a Jini Service” (http://www.jroller.com/dancres/entry/how_to_write_a_jini)
and thinking it reads like satire, even though it is completely accurate.

> We also must have an integrated test-suite that can start River services needed to run
integration tests. We also need to be able to instantiate a service and test it as a River
service, but in a unit test scenario. For the latter I wrote this, the former uses a JUnit
compatible approach (easily integrated with Maven failsafe plugin). 
> I didn't see this in the surrogate project you have 
Let me read that back to make sure I understand.  We need to have a test suite that starts
up the River infrastructure services (like Reggie, Mahalo, Outrigger, etc) in a unique workgroup
so that we can test services.  And we need to instantiate Unit-Under-Test services in that
environment (probably not in the same container), and then also execute a JUnit test that
can lookup the actual service and make calls on the proxy, all inside the Maven integration
test framework.  Do I have that right?

I have to confess that I don’t yet understand how to do integration testing under Maven.
 So any hints are appreciated.

> (btw do we even need to have the surrogate idea any more? Most of the devices in our
world today host JVMs). This is key IMO.

Yeah, the surrogate idea is not a very persuasive use case now. Although I can see one or
two applications for it.  For instance I could picture a surrogate popping up an admin interface
to a cloud-based virtual machine image, so you could use the surrogate to start up processes
or deploy software on the VM.

>> I see it’s Apache licensed.  Ideally we’d have a CCLA in place from all the corporate
> The only two at issue are Sun and GigaSpaces (I am the other 2 :) )
>> but I personally don’t know if that’s required if the contributed code is ASL2.
 We might have to consult more experienced Apache people.
> Anyone on the list care to assist here?
> Thanks
> Dennis

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