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