Re: OSGi [PREVIOUSLY]Re: Maven Build

[Peter]

Yes, I've been thinking about it.

My current thoughts; ServiceUI can be accessed through 
net.jini.lookup.ServiceAttributesAccessor, so you can unmarshall 
ServiceUI objects, without unmarshalling the service itself.   However I 
haven't given much consideration to locating codebases for ServiceUI 
yet, at least not for OSGi.


The reality is that lots of different service implementations might have 
common ServiceUI components.


Sounds like this is an opportune time to start thinking more about it.

It also makes me wonder whether MarshalledInstance could accept a URI 
codebase string, or allow it to be set and retrieved from the current 
codebase annotation byte array.


Cheers,

Peter.

On 28/09/2017 2:30 AM, Gregg Wonderly wrote:

Do you have anything planned around ServiceUI?  I really use ServiceUI as a 
discovery mechanism to find services which export a UI that a user can interact 
with.  What can happen at registration time, besides Entry specification to 
help with codebase where ServiceUI bits are at?  Are you just relying on the 
“service” setup to include all of that detail, or is there something we can do, 
to wrap ServiceUI into the mechanism you are talking about here?

Gregg


On Sep 27, 2017, at 3:59 AM, Peter  wrote:

Some updates on thoughts about OSGi:

  1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
 ServiceDiscoveryManager and ProxyPreparer allow provisioning of
 OSGi bundles for Jini services.
  2. SafeServiceRegistrar lookup results contain only instances of
 java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
 ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
 remarshalls and unmarshalls into their OSGi bundle provisioned
 ClassLoader, prior to retrieving the actual service proxy using
 ServiceProxyAccessor.
  3. As a result different service principals using identical proxy
 codebases, needn't share a ClassLoader, addressing the trust
 domain issue previously alluded to.
  4. There's no current mechanism to allow provisioning of a bundle for
 a Registrar.
  5. Existing discovery providers accept ClassLoader arguments for
 unmarshalling Registrar's.
  6. Existing Multicast responses allow for additional information to
 be appended; a codebase resource for example.
  7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
 don't utilise discovery providers ClassLoader arguments.
  8. Need to allow bundles to be provisioned for lookup services after
 multicast discovery, by exposing discovery provider ClassLoader
 arguments and allowing client to manage provisioning of bundle
 into a ClassLoader, then passing that in during unicast discovery.
  9. Don't break backward compatiblity.

Cheers,

Peter.

On 16/11/2016 4:18 PM, Dawid Loubser wrote:

+1 for OSGi providing the best solution to the class resolution problem,
though I think some work will have to be done around trust, as you say.


On 16/11/2016 02:23, Peter wrote:

The conventional alternatives will remain;  the existing ClassLoader isolation 
and the complexities surrounding multiple copies of the same or different 
versions of the same classes interacting within the same jvm.  Maven will 
present a new alternative of maximum sharing, where different service 
principals will share the same identity.

Clearly, the simplest solution is to avoid code download and only use 
reflection proxy's

An inter process call isn't remote, but there is a question of how a reflection 
proxy should behave when a subprocess is terminated.

UndeclaredThrowableException seems appropriate.

It would plug in via the existing ClassLoading RMIClassLoader provider 
mechanism, it would be a client concern, transparent to the service or server.

The existing behaviour would remain default.

So there can be multiple class resolution options:

1. Existing PrefferedClassProvider.
2. Maven class resolution, where maximum class sharing exists.  This may be 
preferable in situations where there is one domain of trust, eg within one 
corporation or company.  Max performance.
3. Process Isolation.  Interoperation between trusted entities, where code 
version incompatibilities may exist, because of separate development teams and 
administrators.  Each domain of trust has it's own process domain.  Max 
compatibility, but slower.
4. OSGi.

There may be occassions where simpler (because developers don't need to 
understand ClassLoaders), slow, compatible and reliable wins over fast and 
complex or broken.

A subprocess may host numerous proxy's and codebases from one principal trust 
domain (even a later version of River could be provisioned using Maven).  A 
subprocess would exist for each trust domain. So if there are two companies, 
code from each remains isolated and communicates only using common api.  No 
unintended code versioning conflicts.

This choice would not prevent or exclude other methods of communication, the 

Re: OSGi [PREVIOUSLY]Re: Maven Build

[Peter]

Yes that's correct.

Sun chose to use the ClassLoader to represent the service's pincipal, 
dynamically granting permission after proxy verification.


So that's what we have available on the call stack to use when 
performing authorisation permission checks:


  1. Client's Principal. (Principal based grant)
  2. ClassLoader (ClassLoader based grant, usually dynamically)
  3. CodeSource's of other modules (CodeSource based grants).

Since we trust the code with Maven (because it's downloaded and verified 
separately), it's probably not appropriate to use a ClassLoader to 
represent the service's principal in the client.


I guess it really depends on the information that needs protection at 
the client and how much risk there is of information leaking to a 
service from the client, and the consequences.  I suspect that for a lot 
of applications where the users belong to one organisation, there 
probably nothing to be done.


It may be as simple as using a DomainCombiner to add a ProtectionDomain 
representing the service's principal (Subject) to the stack, or it may 
not be necessary to do anything at all.Currently Java only relaxes 
permission when injecting all ProtectionDomain's on a Thread's call 
stack with Principals (representing a user Subject), it's effectively 
granting the permissions of the user to all ProtectionDomain's on the 
stack.  Typically in the current scenario, code, although trusted, is 
granted less permission in order to allow a user to be granted permission.


An alternative behaviour would be to append a protection domain 
representing a user (Subject) to an existing call stack, such that the 
resuting permission set is the intersection of all domains (rather than 
the intersection of all code based grants and the addition of user based 
grants).   In this case code can be granted all the permissions it needs 
and users might actually reduce the set of permissions, instead of only 
granting additional permission.


So summing up, I think it's something to be aware of, but depending on 
circumstances probably doesn't require doing anything.


Smart proxy's might share ClassLoaders; making dynamic permission grants 
to ClassLoaders based on the service that has just been authenticated 
(as per current practise), may not be appropriate.


Cheers,

Peter.

On 28/09/2017 2:54 AM, Dennis Reedy wrote:

Hi Peter,

In reading your missive I'm not sure I understand when you say "Maven will
present a new alternative of maximum sharing, where different service
principals will share the same identity.", or "Maven class resolution".

Are you referring to an approach where a service may declare it's codebase
as an artifact that may have transitive dependencies, and that artifact,
when resolved (from perhaps a secure repository) is downloaded onto the
requesting client using Maven's local repository scheme? Then remote code
becomes local code right? If services publish artifacts to (public/trusted)
repositories and follow the approach that published versions are immutable,
then a client would download the code only once, and re-use as necessary.

Or are you thinking of this or something else?

Thanks

Dennis

On Wed, Sep 27, 2017 at 4:59 AM, Peter  wrote:


Some updates on thoughts about OSGi:

   1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
  ServiceDiscoveryManager and ProxyPreparer allow provisioning of
  OSGi bundles for Jini services.
   2. SafeServiceRegistrar lookup results contain only instances of
  java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
  ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
  remarshalls and unmarshalls into their OSGi bundle provisioned
  ClassLoader, prior to retrieving the actual service proxy using
  ServiceProxyAccessor.
   3. As a result different service principals using identical proxy
  codebases, needn't share a ClassLoader, addressing the trust
  domain issue previously alluded to.
   4. There's no current mechanism to allow provisioning of a bundle for
  a Registrar.
   5. Existing discovery providers accept ClassLoader arguments for
  unmarshalling Registrar's.
   6. Existing Multicast responses allow for additional information to
  be appended; a codebase resource for example.
   7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
  don't utilise discovery providers ClassLoader arguments.
   8. Need to allow bundles to be provisioned for lookup services after
  multicast discovery, by exposing discovery provider ClassLoader
  arguments and allowing client to manage provisioning of bundle
  into a ClassLoader, then passing that in during unicast discovery.
   9. Don't break backward compatiblity.

Cheers,

Peter.

On 16/11/2016 4:18 PM, Dawid Loubser wrote:


+1 for OSGi providing the best solution to the class resolution problem,
though I think some work will have to be done around trust, as you say.

Re: OSGi [PREVIOUSLY]Re: Maven Build

[Dennis Reedy]

Hi Peter,

In reading your missive I'm not sure I understand when you say "Maven will
present a new alternative of maximum sharing, where different service
principals will share the same identity.", or "Maven class resolution".

Are you referring to an approach where a service may declare it's codebase
as an artifact that may have transitive dependencies, and that artifact,
when resolved (from perhaps a secure repository) is downloaded onto the
requesting client using Maven's local repository scheme? Then remote code
becomes local code right? If services publish artifacts to (public/trusted)
repositories and follow the approach that published versions are immutable,
then a client would download the code only once, and re-use as necessary.

Or are you thinking of this or something else?

Thanks

Dennis

On Wed, Sep 27, 2017 at 4:59 AM, Peter  wrote:

> Some updates on thoughts about OSGi:
>
>   1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
>  ServiceDiscoveryManager and ProxyPreparer allow provisioning of
>  OSGi bundles for Jini services.
>   2. SafeServiceRegistrar lookup results contain only instances of
>  java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
>  ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
>  remarshalls and unmarshalls into their OSGi bundle provisioned
>  ClassLoader, prior to retrieving the actual service proxy using
>  ServiceProxyAccessor.
>   3. As a result different service principals using identical proxy
>  codebases, needn't share a ClassLoader, addressing the trust
>  domain issue previously alluded to.
>   4. There's no current mechanism to allow provisioning of a bundle for
>  a Registrar.
>   5. Existing discovery providers accept ClassLoader arguments for
>  unmarshalling Registrar's.
>   6. Existing Multicast responses allow for additional information to
>  be appended; a codebase resource for example.
>   7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
>  don't utilise discovery providers ClassLoader arguments.
>   8. Need to allow bundles to be provisioned for lookup services after
>  multicast discovery, by exposing discovery provider ClassLoader
>  arguments and allowing client to manage provisioning of bundle
>  into a ClassLoader, then passing that in during unicast discovery.
>   9. Don't break backward compatiblity.
>
> Cheers,
>
> Peter.
>
> On 16/11/2016 4:18 PM, Dawid Loubser wrote:
>
>> +1 for OSGi providing the best solution to the class resolution problem,
>> though I think some work will have to be done around trust, as you say.
>>
>>
>> On 16/11/2016 02:23, Peter wrote:
>>
>>>
>>> The conventional alternatives will remain;  the existing ClassLoader
>>> isolation and the complexities surrounding multiple copies of the same or
>>> different versions of the same classes interacting within the same jvm.
>>> Maven will present a new alternative of maximum sharing, where different
>>> service principals will share the same identity.
>>>
>>> Clearly, the simplest solution is to avoid code download and only use
>>> reflection proxy's
>>>
>>> An inter process call isn't remote, but there is a question of how a
>>> reflection proxy should behave when a subprocess is terminated.
>>>
>>> UndeclaredThrowableException seems appropriate.
>>>
>>> It would plug in via the existing ClassLoading RMIClassLoader provider
>>> mechanism, it would be a client concern, transparent to the service or
>>> server.
>>>
>>> The existing behaviour would remain default.
>>>
>>> So there can be multiple class resolution options:
>>>
>>> 1. Existing PrefferedClassProvider.
>>> 2. Maven class resolution, where maximum class sharing exists.  This may
>>> be preferable in situations where there is one domain of trust, eg within
>>> one corporation or company.  Max performance.
>>> 3. Process Isolation.  Interoperation between trusted entities, where
>>> code version incompatibilities may exist, because of separate development
>>> teams and administrators.  Each domain of trust has it's own process
>>> domain.  Max compatibility, but slower.
>>> 4. OSGi.
>>>
>>> There may be occassions where simpler (because developers don't need to
>>> understand ClassLoaders), slow, compatible and reliable wins over fast and
>>> complex or broken.
>>>
>>> A subprocess may host numerous proxy's and codebases from one principal
>>> trust domain (even a later version of River could be provisioned using
>>> Maven).  A subprocess would exist for each trust domain. So if there are
>>> two companies, code from each remains isolated and communicates only using
>>> common api.  No unintended code versioning conflicts.
>>>
>>> This choice would not prevent or exclude other methods of communication,
>>> the service, even if isolated within it's own process will still
>>> communicate remotely over the network using JERI, JSON etc.  This is
>>> orthogonal to and independant of 

Re: OSGi [PREVIOUSLY]Re: Maven Build

[Gregg Wonderly]

Do you have anything planned around ServiceUI?  I really use ServiceUI as a 
discovery mechanism to find services which export a UI that a user can interact 
with.  What can happen at registration time, besides Entry specification to 
help with codebase where ServiceUI bits are at?  Are you just relying on the 
“service” setup to include all of that detail, or is there something we can do, 
to wrap ServiceUI into the mechanism you are talking about here?

Gregg

> On Sep 27, 2017, at 3:59 AM, Peter  wrote:
> 
> Some updates on thoughts about OSGi:
> 
>  1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
> ServiceDiscoveryManager and ProxyPreparer allow provisioning of
> OSGi bundles for Jini services.
>  2. SafeServiceRegistrar lookup results contain only instances of
> java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
> ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
> remarshalls and unmarshalls into their OSGi bundle provisioned
> ClassLoader, prior to retrieving the actual service proxy using
> ServiceProxyAccessor.
>  3. As a result different service principals using identical proxy
> codebases, needn't share a ClassLoader, addressing the trust
> domain issue previously alluded to.
>  4. There's no current mechanism to allow provisioning of a bundle for
> a Registrar.
>  5. Existing discovery providers accept ClassLoader arguments for
> unmarshalling Registrar's.
>  6. Existing Multicast responses allow for additional information to
> be appended; a codebase resource for example.
>  7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
> don't utilise discovery providers ClassLoader arguments.
>  8. Need to allow bundles to be provisioned for lookup services after
> multicast discovery, by exposing discovery provider ClassLoader
> arguments and allowing client to manage provisioning of bundle
> into a ClassLoader, then passing that in during unicast discovery.
>  9. Don't break backward compatiblity.
> 
> Cheers,
> 
> Peter.
> 
> On 16/11/2016 4:18 PM, Dawid Loubser wrote:
>> +1 for OSGi providing the best solution to the class resolution problem,
>> though I think some work will have to be done around trust, as you say.
>> 
>> 
>> On 16/11/2016 02:23, Peter wrote:
>>> 
>>> The conventional alternatives will remain;  the existing ClassLoader 
>>> isolation and the complexities surrounding multiple copies of the same or 
>>> different versions of the same classes interacting within the same jvm.  
>>> Maven will present a new alternative of maximum sharing, where different 
>>> service principals will share the same identity.
>>> 
>>> Clearly, the simplest solution is to avoid code download and only use 
>>> reflection proxy's
>>> 
>>> An inter process call isn't remote, but there is a question of how a 
>>> reflection proxy should behave when a subprocess is terminated.
>>> 
>>> UndeclaredThrowableException seems appropriate.
>>> 
>>> It would plug in via the existing ClassLoading RMIClassLoader provider 
>>> mechanism, it would be a client concern, transparent to the service or 
>>> server.
>>> 
>>> The existing behaviour would remain default.
>>> 
>>> So there can be multiple class resolution options:
>>> 
>>> 1. Existing PrefferedClassProvider.
>>> 2. Maven class resolution, where maximum class sharing exists.  This may be 
>>> preferable in situations where there is one domain of trust, eg within one 
>>> corporation or company.  Max performance.
>>> 3. Process Isolation.  Interoperation between trusted entities, where code 
>>> version incompatibilities may exist, because of separate development teams 
>>> and administrators.  Each domain of trust has it's own process domain.  Max 
>>> compatibility, but slower.
>>> 4. OSGi.
>>> 
>>> There may be occassions where simpler (because developers don't need to 
>>> understand ClassLoaders), slow, compatible and reliable wins over fast and 
>>> complex or broken.
>>> 
>>> A subprocess may host numerous proxy's and codebases from one principal 
>>> trust domain (even a later version of River could be provisioned using 
>>> Maven).  A subprocess would exist for each trust domain. So if there are 
>>> two companies, code from each remains isolated and communicates only using 
>>> common api.  No unintended code versioning conflicts.
>>> 
>>> This choice would not prevent or exclude other methods of communication, 
>>> the service, even if isolated within it's own process will still 
>>> communicate remotely over the network using JERI, JSON etc.  This is 
>>> orthogonal to and independant of remote communication protocols.
>>> 
>>> OSGi would of course be an alternative option, if one wished to execute 
>>> incompatible versions of libraries etc within one process, but different 
>>> trust domains will have a shared identity, again this may not matter 
>>> depending on the use case.
>>> 
>>> Cheers,
>>> 
>>> Peter.
>>> 

OpenJDK Loom proposal - has relevance to distributed systems

[Peter]

cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

OSGi [PREVIOUSLY]Re: Maven Build

[Peter]

Some updates on thoughts about OSGi:

  1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
 ServiceDiscoveryManager and ProxyPreparer allow provisioning of
 OSGi bundles for Jini services.
  2. SafeServiceRegistrar lookup results contain only instances of
 java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
 ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
 remarshalls and unmarshalls into their OSGi bundle provisioned
 ClassLoader, prior to retrieving the actual service proxy using
 ServiceProxyAccessor.
  3. As a result different service principals using identical proxy
 codebases, needn't share a ClassLoader, addressing the trust
 domain issue previously alluded to.
  4. There's no current mechanism to allow provisioning of a bundle for
 a Registrar.
  5. Existing discovery providers accept ClassLoader arguments for
 unmarshalling Registrar's.
  6. Existing Multicast responses allow for additional information to
 be appended; a codebase resource for example.
  7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
 don't utilise discovery providers ClassLoader arguments.
  8. Need to allow bundles to be provisioned for lookup services after
 multicast discovery, by exposing discovery provider ClassLoader
 arguments and allowing client to manage provisioning of bundle
 into a ClassLoader, then passing that in during unicast discovery.
  9. Don't break backward compatiblity.

Cheers,

Peter.

On 16/11/2016 4:18 PM, Dawid Loubser wrote:

+1 for OSGi providing the best solution to the class resolution problem,
though I think some work will have to be done around trust, as you say.


On 16/11/2016 02:23, Peter wrote:


The conventional alternatives will remain;  the existing ClassLoader isolation 
and the complexities surrounding multiple copies of the same or different 
versions of the same classes interacting within the same jvm.  Maven will 
present a new alternative of maximum sharing, where different service 
principals will share the same identity.

Clearly, the simplest solution is to avoid code download and only use 
reflection proxy's

An inter process call isn't remote, but there is a question of how a reflection 
proxy should behave when a subprocess is terminated.

UndeclaredThrowableException seems appropriate.

It would plug in via the existing ClassLoading RMIClassLoader provider 
mechanism, it would be a client concern, transparent to the service or server.

The existing behaviour would remain default.

So there can be multiple class resolution options:

1. Existing PrefferedClassProvider.
2. Maven class resolution, where maximum class sharing exists.  This may be 
preferable in situations where there is one domain of trust, eg within one 
corporation or company.  Max performance.
3. Process Isolation.  Interoperation between trusted entities, where code 
version incompatibilities may exist, because of separate development teams and 
administrators.  Each domain of trust has it's own process domain.  Max 
compatibility, but slower.
4. OSGi.

There may be occassions where simpler (because developers don't need to 
understand ClassLoaders), slow, compatible and reliable wins over fast and 
complex or broken.

A subprocess may host numerous proxy's and codebases from one principal trust 
domain (even a later version of River could be provisioned using Maven).  A 
subprocess would exist for each trust domain. So if there are two companies, 
code from each remains isolated and communicates only using common api.  No 
unintended code versioning conflicts.

This choice would not prevent or exclude other methods of communication, the 
service, even if isolated within it's own process will still communicate 
remotely over the network using JERI, JSON etc.  This is orthogonal to and 
independant of remote communication protocols.

OSGi would of course be an alternative option, if one wished to execute 
incompatible versions of libraries etc within one process, but different trust 
domains will have a shared identity, again this may not matter depending on the 
use case.

Cheers,

Peter.

ESent from my Samsung device.