> > 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.
