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