Thanks Dennis, Maven's repository's just keep sounding better & better:
source and doc artefacts. This is brilliant, a GUI Service Spec Maven
browser would be sweet too. Leveraging Maven's repository's could
really get River out onto the net.
Chris, Dennis & Greg, your all spot on with the Service-spec.jar, I'd
like to add something to the jar Manifest of these Service Interfaces,
to ensure River loads it into the top level ClassLoader. Any suggestions?
We need some good doc's to really get the message across for these ideas.
Why do you need to annotate the Marshalled Streams with the ServiceID?
It boils down to segregating Security concerns. If we have Several
services that utilise the same proxy CodeSource (from Maven, perhaps for
fail over etc) it is ok to only have one ClassLoader for that proxy
implementation, provided all Servers have the same Principals and only
if static variables don't cause issues.
However if there are proxy's with different Principals and identical
CodeSource, in one JVM, they need to be loaded in separate
ProtectionDomains, hence, they must be loaded into different ClassLoaders.
When you potentially have two ClassLoaders, with identical CodeSource,
how do you choose one to unmarshall the objects? Will the context
ClassLoader always be correct? It might be, you might be right Dennis,
the proxy is given a thread to initiate the communication, we might not
need the ServiceID.
What are your thoughts?
So if you've got a weak hash index cache to lookup proxy ClassLoaders by
ServiceID, you can segregate the proxy's Security Concerns. But at the
same time I also want to make it possible to put several proxy's in the
same ClassLoader if their Principals are identical, for memory efficiency.
Dennis Reedy wrote:
So this is what I'm understanding thus far:
Extend the jar conventions of service construction to include:
Implementation jar: service.jar
Specification jar: service-spec.jar
Download jar: service-dl.jar
(I would love to see the jars also follow the convention of including the
version number as part of the jar name, makes it clearer what is being used.
Not a mandate, just a nicety)
Clients would include direct dependencies on service-spec.jar, including that
jar as part of it's own classpath, and would also be able to provision the
service-dl.jar. The service-dl.jar has a dependency on service-spec.jar (but
not the other way around), as does the service.jar. Note that service-spec.jar
may be project wide (like River) and include service interfaces
(specifications) for multiple services, or it may be service specific.
Provide a ServiceDLEntry (implements ServiceControlled) that includes the DL jar(s) and accompanying message digests for the jar(s) allowing clients to optionally download and install DL jars to avoid expensive http(md) based class loading.
On May 20, 2010, at 324AM, Peter Firmstone wrote:
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.
Why is this important? Why do you need to annotate the marshalled streams with
the serviceID?
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.
Realize that if something like a maven repository is used you can browse
available services as artifacts, which can also include source code, docs, etc
... Also, each of the conventions outlined above would manifest themselves as
follows (as an example lets version 1 of use org.foo.bar.example):
org.foo.bar:example:1.0
org.foo.bar:example:spec:1.0
org.foo.bar:example:dl:1.0
If I want to use the service as a client during development, I declare a dependency on org.foo.bar:example:spec:1.0
