river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject OSGi [PREVIOUSLY]Re: Maven Build
Date Wed, 27 Sep 2017 08:59:40 GMT
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
   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.



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
>> 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
>> 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.

View raw message