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 07:24:11 GMT
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 

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.



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

View raw message