I like & get what your saying, I'd like to add something too.
Can we separate the Service Interface from the Smart Proxy? So they're
in separate artefacts /downloadable jar's?
Then the Client depends on the Service Interface artefact, but not the
proxy implementation-dl.jar artefact, leaving the Service to use any
proxy-dl.jar artefact it likes. (Via Entry)
Then the Client chooses the ServiceInterface artefact, which dictates
the Service, while the Service implementation dictates the proxy
artefact, for a total separation of concerns. Both the client and Proxy
then depend on the ServiceInterface-dl.jar artefact, but not each other
directly.
If we don't grant ServiceInterface-dl.jar any permissions whatsoever and
place it in a Parent ClassLoader, then it can be visible to both the
client and the proxy, and the Proxy and the Client will be otherwise
isolated from each other, with their own permissions and avoid any risk
of namespace conflicts.
That probably helps to make more sense of my previous message too.
Once the required classes are in place, after the proxy has been
unmarshalled, the Remote calls marshalled streams can be annotated with
the ServiceID, so the client platform knows which classloaders to use.
The separation of concerns, the Service Interface, from the proxy
implementation, would allow us to provide a runtime dynamic service that
advertises available Service Interfaces, in a GUI browser, including
Javadoc for developers to discover and explore new and different Service
Interfaces as they are created. This might be useful for Groovy script
developers too, I might be getting ahead of myself here.
I'm starting to have a much more positive feeling about this project, we
definitely seem to be making headway.
Cheers,
Peter.
Dennis Reedy wrote:
Why cant the client express a dependency on that associated service's -dl.jar
file(s)?
The client depends on the Service Interface, not the -dl.jar, what you probably
meant was Marshalled Objects depend on the -dl.jar during Unmarshalling.
No, not at all.
The issue one finds when developing services is that you need to have at build and
deployment time the interfaces you require in order to build, test and deploy a
complete application composed of services. Why change this when you move from
development & test to production? Why introduce the frailty of lost codebase
problem when you know a priori what DL jars you need to load classes from in order
for the smart proxies services you have developed use?
We already know what the DL jars are, and what is needed in order to resolve
compile and runtime dependencies. There is nothing to discover (other than the
advertised service(s) of course).
The services that we make available on the network use the artifacts we create
and bundle to publish smart proxies that are resolvable from DL jars. I suggest
that we know what the dependencies are of these services in advance. We need to
in order to develop test cases, to develop the fundamental interactions
required to enable the semantics across services for the applications that we
write.
This is not a matter of class loader hierarchy or Marshalled Objects, its
simply getting the required jars local to the client (or service acting as a
client) such that the client can load those classes locally instead of loading
them via a codebase service. The only reason that we need dynamic class loading
is if the required classes are not resolvable by the class loader. Why not
provision them to make these issues go away?
It doesnt change the smart proxy semantics necessarily, it just changes 'where'
the classes get loaded from. If we can provision the requisite artifacts to the
client, then the classes can be loaded locally.
Yours and Patrick's ideas are good, including the codebase Entry idea, as you
suggest a Service could pre-empt installation of the correct version *-dl.jar
prior to unmarshalling objects. That *-dl.jar could have dependency's it
requires resolved by a frame work too, all prior to any unmarshalling.
Yep, these are known as transitive dependencies. All known based on convention,
and easily navigatable.
