river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 09:52:06 GMT
Mic,

I'm attempting to get my head around your proposal:

In the case of JERI, the InvocationHandler is part of the smart proxy's 
serialized state.  A number of smart proxy classes will need to be 
unmarshalled before the UnmarshallingInvocationHandler is deserialized.

The smart proxy contains a reference to a dynamic proxy (which sun 
called the bootstrap proxy) and the dynamic proxy contains a reference 
to your UnmarshallingInvocationHandler.    This means the smart proxy 
must be unmarshalled first.

How do you get access to UnmarshallingInvocationHandler without 
unmarshalling the smart proxy first?

More comments inline below.

On 13/02/2017 6:11 PM, Michał Kłeczek wrote:
> We are talking about the same thing.
>
> We are turning circles, Peter - all of this has been already discussed.
>
> 1. Yes - you need to resolve bundles in advance (in OSGi it is not 
> possible to do otherwise anyway)
Agree.
> 2. You cannot decide upon the bundle chosen by the container to load 
> the proxy class (the container does the resolution)
Disagree, nothing in the client depends on the proxy bundle, there's no 
reason to provision a different version.
> 3. The runtime graph of object places additional constraints on the 
> bundle resolution process (to what is specified in bundles' manifests).
> Since you do not have any way to pass these additional constraints to 
> the container - the case is lost.
Disagree.  The proxy bundle contains a manifest with requirements.  The 
stream has no knowledge of versioning, nor does it need to, there are no 
additional constraints.  If the service proxy dependencies cannot be 
resolved, or it doesn't unmarshall, then it will not be registered with 
the OSGi registry in the client, client code will not discover it and 
the client will have no knowledge of it's existance except for some logging.


>
> Additionally - to explain what I've said before about wrong level of 
> abstraction:
>
> Your general idea is very similar to mine: have a special object 
> (let's call it installer) that will install software prior to proxy 
> unmarshalling.
>
> 1. For some reason unclear to me you want to constrain the way how 
> this "installer object" is passed only via the route of 
> ServiceRegistrar (as attributes)

Disagree, I'm not proposing the service have any control over 
installation at the client, other than the manifest in the proxy bundle, 
nor am I proposing using service attributes, or the use of any existing 
ServiceRegistar methods (see SafeServiceRegistrar link posted earlier).

> But why not:
>
> public interface RemoteEventProducer {
>   void registerListener(SmartProxyInstaller installer, byte[] 
> remoteEventListenerBytes);
> }

I guess you could have a service that installs the proxy bundle that 
way, but how will you know which ClassLoader the deserialize into at the 
client?

>
> I cannot see a difference at all and this is why I say that mixing 
> ServiceRegistrar and ServiceDiscoveryManager
> into it is really mixing levels of abstraction (and does not add 
> anything to the solution).

I'm proposing to use ServiceDiscoveryManager to discover 
SafeServiceRegistrar's, then look up matching services, receive dynamic 
proxy's from each of the matching services (using input validating 
deserialization, a security measure) that allow the ProxyPreparer to 
authenticate each service, get attributes, perform local logical 
attribute comparisons, get the codebase URL string, certificate signers, 
grant permissions, then finally provision the codebase and finally 
retrieve the smart proxy, directly from the dynamic proxy.

Now we could put your UnmarshallingInvocationHandler into the dynamic 
proxy, but then we might be installing a bundle we decide we don't want 
after logical comparisons of attributes.  The InvocationHandler's intent 
is to marshall object arguments, when methods are invocated on the 
dynamic proxy.  The InvocationDispatcher unmarshalls the arguments at 
the remote end and invokes the methods on the Remote object.

So I'm proposing to write some code that performs service discovery 
using the above and registers the successfully matched services with the 
local OSGi service registry.  So the client needn't be concerned with 
the time taken to remotely discover and provision a service, all that 
happens in the background until the services can be made available in 
the OSGi service registry for the client to utilise.

>
> 2. If you allow to pass "installer" to unmarshall proxies - then the 
> next question is - why do you require doing it explicitly in the 
> application code???

That's not what I'm proposing, see above.

Cheers,

Peter.

> THIS is really mixing levels of abstraction. A programmer expects a 
> natural programming model (and will not buy into Jini if it does not 
> offer such):
>
> registerListener(RemoteEventListener listener);
>
> without any additional complexities that should be solved by the 
> infrastructure code.
>
> 3. But the above is easy to solve:
>
> class UnmarshallingInvocationHandler implements InvocationHandler {
>
>   private Object unmarshalledProxy;
>   private SmartProxyInstaller installer;
>
>   writeObject(...) { write out installer and proxy bytes }
>   readObject(...) {read installer then bytes and then unmarshall the 
> proxy}
>
> }
>
> 4. But then the next question is why not put it in the object stream 
> implementation itself???
>
> Thanks,
> Michal
>
>
> Peter wrote:
>> Also see the OSGi Enterprise specification, v6, Chapter 136, page 
>> 691, there's some discussion about the NP-complete nature of 
>> dependency resolution there as well.
>>
>> https://www.osgi.org/developer/downloads/release-6/release-6-download/
>>
>> On 13/02/2017 5:19 PM, Peter wrote:
>>> OSGi Dependency resolution is.
>>>
>>> http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html

>>>
>>>
>>> Which means if we want to support an OSGi environment properly, we 
>>> may need some time to resolve the dependencies for a smart proxy, 
>>> before deserializing the proxy, rather than downloading the proxy 
>>> dynamically during unmarshalling, it's better to delay unmarshalling 
>>> until the dependencies are resolved, so the client isn't impacted by 
>>> delays.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> On 13/02/2017 4:50 PM, Michał Kłeczek wrote:
>>>> Sorry, NP Completness of what?
>>>> I have been the first to mention NP hardness of constraint 
>>>> satisfaction problem
>>>> but I am not sure if this is what you are asking about.
>>>>
>>>> Thanks,
>>>> Michal
>>>>
>>>> Patricia Shanahan wrote:
>>>>> Are you literally claiming NP Completeness, or just using that as 
>>>>> an analogy for really, really difficult?
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


Mime
View raw message