river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Codebase service?
Date Thu, 20 May 2010 03:23:28 GMT
> 
> 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.



Mime
View raw message