river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Distributed ExecutorService
Date Tue, 08 Dec 2009 02:51:27 GMT
Thanks Shay,

Sweet documentation, spot on, thanks for the links.  I wonder if there's 
any chance of some of this moving upstream into River?
Looks like Gregg's got some code too.

Gregg,

Including the Permissions into the bundle simplifies installation / 
security setup and reduces duplication, it means that you can specify 
how much you want to trust the bundle signer, who might also sign other 
bundles you utilise, the signer might be another company that you 
cooperate with.

There's a tool that does analyse code for the required security 
permissions, I can't remember it's name and where it is, it might even 
be associated with Jini, or it could be OSGi related, I'll have a poke 
around later & see if I can't find it.

What I like about OSGi's security model, is that it is dynamic, it 
allows granting and revoking (allow and deny) of permissions (makes me 
feel like I've been pursuing a duplicate effort!). River currently only 
has dynamic grants, I think the ability to revoke a permission is 
important for services that become disconnected to be able to revoke 
permissions prior to reverifying a proxy.

For a more thorough explanation of OSGi's Security Model, see the newly 
released 4.2 OSGi core spec, chapters 2, 9 and 10.

Patrick,

Thanks for the link, sounds like you've got some first hand experience.  
N.B. I agree that this is a perfect match for Javaspaces, judging by the 
Gigaspaces implementation, it's damn good.  However it might also be 
useful at a lower level, since Javaspaces depends on Jini / River, 
perhaps it wouldn't be too much hassle to have a Javaspace layer built 
on a lower level Jini / River implementation?  But then it's probably 
too early to tell.

Cheers,

Peter.



Cheers,

Peter.

Shay Hassidim wrote:
> It would be great if the group will take a look on GigaSpaces
> ExecutorService as a reference: 
> http://www.gigaspaces.com/wiki/display/XAP7/Task+Execution+over+the+Spac
> e
> http://www.gigaspaces.com/wiki/display/XAP7/Executor+Based+Remoting
>
> Shay
>
> -----Original Message-----
> From: Gregg Wonderly [mailto:gregg@wonderly.org] 
> Sent: Monday, December 07, 2009 11:53 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Distributed ExecutorService
>
> This is the service model that I envisioned for the work I did to put
> executors 
> into a javaspace like environment with my http://griddle.dev.java.net
> project.
>
> I've always wanted to have to conversation about importing permissions,
> but to 
> some degree we've already done that.
>
> o  The granting of permissions to a specific codebase URL already
> exists.
> o  With HTTPMD, we can guarantee that the content of the jar hasn't
> changed
>     and thus the permissions we are granting are to be used by software
> which
>     we know the behavior of.
> o  With DynamicPolicyProvider and the
> com.sun.jini.start.ServiceDescriptor
>     implementations, you can derive a dynamic "service" environment with
> some
>     appropriate changes to com.sun.jini.start.ServiceStarter to include
> the
>     convehence of whatever policy and configuration you want to use.
>
> I've used com.sun.jini.start.ServiceStarter and a derivative of my 
> http://startnow.dev.java.net projects org.wonderly.url.vhttp.Handler 
> StreamHandler implementation to create a dynamically downloading and
> caching for 
> offline execution client runtime environment.
>
> I think we have lots of bits and pieces that can work together, and the
> OSGi 
> bundle mechanism might be a standard way to package into a jar, what
> permissions 
> are actually required.
>
> In the real world, many people still seem to have no stamina for
> building an 
> exact policy, and instead, look at the software they are running as
> either 
> trusted or not-trusted in totality, and use AllPermission as the gating
> permission.
>
> If we were to work on providing a "complete" permission convehence
> mechanism, 
> would that be useful if there still are not adequate tools for 
> discovering/knowing exactly what permissions are required?
>
> Gregg Wonderly
>
> Peter Firmstone wrote:
>   
>> I've had a few thoughts about the whole "move the code to the data" 
>> concept (or "Move the code to the Service node") for some time, 
>> considering it a low priority, I have kept quiet about it, until 
>> recently when the topic came up during a recent email discussion.
>>
>> Current Practise for River applications is to move code and data
>>     
> around 
>   
>> together in the form of marshalled objects.  Two particular groups of 
>> Objects are of interest, those that are process or code intensive
>>     
> where 
>   
>> methods process and create returned results and data intensive objects
>>     
>
>   
>> where there is little to be done in the way of processing, where minor
>>     
>
>   
>> copy / transformations are performed on existing state.
>>
>> I think that the River platform addresses these Object groups quite 
>> effectively when the processing is known at compile time or when the 
>> service requirements are clear.  However there are Occasions when it 
>> would be less network intensive or simpler to submit  the distributed 
>> equivalent of a  ScheduledTask or Runnable to consume an existing data
>>     
>
>   
>> intensive service at the origin of that service and make the desired 
>> result available via a temporary service or some other mechanism or 
>> protocol.  In cases where particular class files and libraries
>>     
> required 
>   
>> to perform processing are available at the service node, but
>>     
> unavailable 
>   
>> at the client due to a legacy java environment, no ability to load 
>> remote class files, or a constrained memory environment that cannot 
>> provide enough memory space for the processing required.  The result
>>     
> of 
>   
>> the uploaded runnable class file can be transformed into a locally 
>> available or compatible class file.
>>
>> The Runnable uploaded code might be uploaded to the service node, by
>>     
> the 
>   
>> client or a third party mediator.  Any suggestions for what the 
>> mechanism should be would also be useful. I'm thinking that a signed 
>> OSGi bundle containing a set of permissions would be a good model to 
>> start from, considering that OSGi already has many of the Security 
>> mechanisms that would make such a thing possible.
>>
>> In essence the DistributedScheduledTask is a remote piece of client
>>     
> code 
>   
>> that is executed in the service node.  I'm wondering just what should
>>     
> a 
>   
>> DistributedExecutorService provide, if anyone else has had thoughts 
>> similar to mine.
>>
>> For instance, a Reporting Node in a cluster might send out the same 
>> DistributedScheduledTask to all available services of a particular
>>     
> type 
>   
>> to perform some intensive data processing or filtering remotely at
>>     
> each 
>   
>> node and retrieve the results from each after processing.  The
>>     
> Reporting 
>   
>> Node might have changing reporting requirements similar to performing 
>> queries for instance.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>>
>>
>>
>>     
>
>
>   


Mime
View raw message