Hi Peter,
> JGDMS uses a new implementation of a subset of the Java Serialization’s
> stream format, with input validation and defenses against malicious data (all
> connections are first authenticated when using secure endpoints). Codebase
> annotations are no longer appended in serialization streams, this feature is
> deprecated but it can still be enabled.
>
How the client knows the code needed to deserialise?
Does it require to have it installed in advance? If so - how?
How is the following scenario handled:
class JavaSpaceEventPublisher implements RemoteEventListener, Serializable {
private final JavaSpace space;
//… publish event in JavaSpace implementation
}
The smart proxy class has dependencies on RemoteEventListener and on JavaSpace.
How do you properly resolve classes in this case?
> This paper documents the problems with this approach:
> https://dl.acm.org/doi/pdf/10.5555/1698139
> <https://dl.acm.org/doi/pdf/10.5555/1698139>
> JGDMS provisions a ClassLoader at each Endpoint, the ClassLoader is solely
> responsible for class resolution, once it has been assigned to the relevant
> ObjectEndpoint. A provider mechanism allows customization.
>
> JGDMS doesn't suffer from codebase annotation loss, nor class resolution
> issues. But it did have to give up some functionality; it cannot resolve
> classes that do not belong to a service proxy or its service api and are not
> resolvable from the Endpoint ClassLoader, if they are not present on the
> remote machine. The solution is to always use a service, for parameters
> passed to a service, if they are not part of the service api, eg the client
> overrides the type of parameter arguments for a service. This means that if
> the parameter is not an interface, you cannot create a service that
> implements it and pass it as an argument. That’s why its still possible, but
> not recommended to use codebase annotations appended to the serialization
> stream. The solution is to create service api that uses only interfaces for
> parameter arguments. For example a remote events and listeners use this
> pattern. To prevent unexpected breakages, either use interfaces, or final
> classes, or both, for service api remote method parameters. Then you won’t
> get into the situation where you need codebase annotations appended in the
> stream.
>
I am not sure I follow but...
What I am trying to achieve is exactly the opposite - place as little
constraints as possible on service implementors and make the whole thing
“magically work” :)
> For example if a service proxy is serialized within a serialization stream,
> it will be replaced by a proxy serializer and it will be assigned its own
> independent stream, with ClassLoader, independent of the stream in which it
> was serialized. This is based on the ObjectEndpoint identity, so it will
> always resolve to the same ClassLoader. Note that ProxyCodebaseSpi can be a
> provider or OSGi service.
>
Does it mean you cannot provide services that don’t have any ObjectEndpoint
(ie. local only)?
This would be IMO unacceptable constraint. For example:
- How do you provide the above mentioned JavaSpaceEventPublisher
- How would you provide a java.sql.DataSource as a service?
> Now the proxy serializer is itself a service (bootstrap proxy), that is
> authenticated when using secure endpoints. You could quite easily add an
> interface to the proxy serializer to return your object annotation.
>
> Note that I use a string, because I also use it in secure multicast discovery
> protocols (typically IPv6), which don't include objects, for authentication
> and provisioning a ClassLoader for a lookup service proxy prior to any Object
> de-serialization.
>
> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
>
> <https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml>
> Summing up to simplify JGDMS and solve some very difficult issues, it had to
> give up:
>
> Support for circular references in serialized object graphs, was dropped.
My solution supports any object graph.
>
> Extensible classes in service api method parameters are not advised.
Yes - this one is tricky although my solution supports that as well (there are
edge cases though).
>
> ProxyTrust - deprecated and replaced with secure authentication and httpmd
> (SHA-256) or signer certificates using ProxySerializer.
Deprecated in my solution as well: code is validated _before_ execution.
> Untrusted machines are not allowed in a djinn, some level of trust is
> required, with authentication and authorisation constraints.
Not necessary in my solution.
In general I think the differences are caused by the different perspective:
I see software distribution (ie. mobile code) as orthogonal to networking.
You see River primarily as networking solution with mobile code dependent on it.
It would be great to be able to merge the ideas and work on common solution.
The question is whether it should be Apache River project…
BTW the name of the software I am working on is CodeSpaces (and yes I am aware
of MS/GitHub product named the same but I came up with it earlier and even
registered a domain net.codespaces for this purpose).
Michal
