river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: OSGi
Date Thu, 26 Jan 2017 01:30:19 GMT
I also think about adding leasing to the scheme.
If CodeBaseModule can be leased (and the client is capable of handling 
declines of lease renewals) - it would be quite straightforward to 
implement auto-upgrade: the lease for a module "mymodule" ver 1.1 
expires and you have to ask the code server for a new CodeBaseModule - 
which in turn could return a newer patched version of it.


Michał Kłeczek (XPro Sp. z o. o.) wrote:
> So for a client and a service to be able to communicate they must 
> agree on a common set of interchangeable CodeRepositories that would 
> allow them to have a common understanding of names.
> In other words - to be able to work - any party first has to contact a 
> CodeRepository that can authenticate itself as a particular principal. 
> The issue is that to find the CodeRepository one needs to communicate 
> with ServiceRegistrar. And to communicate with ServiceRegistrar you 
> need a CodeRepository!!!. So there needs to be some bootstrapping in 
> place:
> - either ServiceRegistrar and CodeRepository constitute as single entity
> - there is a bootstrap well known CodeRepository (Maven central?) - 
> its implementation is based on a well known URL and its implementation 
> code is shipped with the framework.
> Thanks,
> Michal
> Michał Kłeczek (XPro Sp. z o. o.) wrote:
>> Honestly - since I am fixed ( :-) ) on having mobile code treated as 
>> any other object - I see it something like:
>> interface CodeBaseModule {
>>   ClassLoader createLoader() throws AnyImportantException;
>> }
>> interface CodeRepository {
>>   CodeBaseModule getCodeBaseModule(String name, Version version);
>>   boolean isSameNamespace(CodeRepository other);
>> }
>> class NamedCodeBase {
>>   String name; Version version;
>>   CodeRepository repository;
>>   boolean equals(Object other) { //check name, version and repo }
>> }
>> Now the question is about the implementation of "isSameNamespace". 
>> Since the protocol(s) to access code repository might differ (and 
>> there might be multiple available at the same time), location based 
>> equality won't work (although is the easiest to implement). My rough 
>> idea is for the CodeRepository to be able to authenticate as any of a 
>> set of Principals ( ie. satisfy the ServerMinPrincipal constraint ). 
>> Two CodeRepository instances are interchangeable if intersection of 
>> their principal sets is non-empty.
>> At first I thought about having a global naming scheme - then 
>> cryptographic hash would constitute the part of the name. But that 
>> would make names obscure and difficult to remember and write by hand.
>> So I came up with an idea to abstract it away - according to "all 
>> problems in CS can be solved by introducing another level of 
>> indirection" :)
>> Thanks,
>> Michal
>> Peter wrote:
>>> codebase identity
>>> So River codebase identity is currently any number of space delimited RFC 3986
normalised URI strings.
>>> httpmd uses a location filename and message digest.
>>> But should location be part of identity?  How can you relocate a codebase once
remote objects are deployed?
>>> OSGi and Maven use a name and version to identify a codebase.  
>>> Might we also need codebase signers (if any) to be part of identity?
>>> If no, why not and if yes why?
>>> Regards,
>>> Peter.
>>> Sent from my Samsung device.
>>>    Include original message
>>> ---- Original message ----
>>> From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
>>> Sent: 26/01/2017 08:30:58 am
>>> To:dev@riverapache.org
>>> Subject: Re: OSGi
>>> I haven't been aware of ObjectSpace Voyager. I just briefly looked at it 
>>> and it seems like it is based on Java 1.x (ancient beast) and - as I 
>>> understand it - the issues you describe are mainly caused by having only 
>>> a single class name space (single ClassLoader).
>>> But sending IMHO class bytes in-band is not necessary (nor good).
>>> What is needed is:
>>> 1. Encoding dependency information in codebases (either in-band or by 
>>> providing a downloadable descriptor) so that it is possible to recreate 
>>> proper ClassLoader structure (hierarchy or rather graph - see below) on 
>>> the client.
>>> 2. Provide non-hierarchical class loading to support arbitrary object 
>>> graph deserialization (otherwise there is a problem with "diamond 
>>> shaped" object graphs).
>>> A separate issue is with the definition of codebase identity. I guess 
>>> originally Jini designers wanted to avoid this issue and left it 
>>> undefined... but it is unavoidable :)
>>> Thanks,
>>> Michal
>>> Gregg Wonderly wrote:
>>>>   That’s what I was suggesting.  The code works, but only if you put the
required classes into codebases or class paths.  It’s not a problem with mobile code, it’s
a problem with resolution of objects in mobile code references.  That’s why I mentioned
ObjectSpace Voyager.  It automatically sent/sends class definitions with object graphs to
the remote VM.
>>>>   Gregg
>>>>>   On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.)<michal.kleczek@xpro.biz>
>>>>>   The problem is that we only support (smart) proxies that reference
only objects of classes from their own code base.
>>>>>   We do not support cases when a (smart) proxy wraps a (smart) proxy
of another service (annotated with different codebase).
>>>>>   This precludes several scenarios such as for example "dynamic exporters"
- exporters that are actually smart proxies.
>>>>>   Thanks,
>>>>>   Michal

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message