river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: OSGi [PREVIOUSLY]Re: Maven Build
Date Wed, 27 Sep 2017 16:54:09 GMT
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 <jini@zeus.net.au> 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.
>>>
>>> ESent from my Samsung device.
>>>
>>>
>

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