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 11:23:08 GMT
To be fair, my position changed somewhat after Nic's email and some 
further research, it may of course develop further with understanding 
and experimentation.



On 13/02/2017 7:52 PM, Peter wrote:
> 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?

View raw message