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 15:05:39 GMT
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):

If I want to use the service as a client during development, I declare a dependency on org.foo.bar:example:spec:1.0

View raw message