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:[email protected]]
Sent: Monday, December 07, 2009 11:53 AM
To: [email protected]
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.
