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:12:59 GMT
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.


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