river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Thu, 20 May 2010 22:04:48 GMT
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 
>
>
>
>   


Mime
View raw message