Dennis Reedy wrote:
On May 27, 2010, at 451AM, Peter Firmstone wrote:
Hi Dennis,
I can live with Compile time only Service API's (not dynamically loaded), as
has been identified, the API is known prior by the application.
I'm sorry for not answering your question directly, I want to make sure I understand you correctly.
By compile time, are you thinking of an environment that only deals with classes that are loaded at JVM start time?
Or, since a client needs to have some a-priori knowledge of what it wants to
discover and use, that means the class(es) are known by the client in advance.
And those classes are included in the classpath of the client. Is that what you
mean by compile time?
The latter.
We should encourage developers to maker their Service API publicly available on
Maven repository's, for others to implement.
Well, it would be for others to 'use'. Typically artifacts are published to
repositories so you can use them. You may be able to obtain the sources, and
depending on the license (or other criteria) of the project create derivative
implementation(s). But in general the issue is not one of creating
implementations, but one of use and inclusion into the systems that you create.
So we can implement any Service API, whether we have the source or not,
confident that it cannot obtain any Permission's, we can guarantee this by
using static immutable ProtectionDomain's for Service API, where Policy checks
are excluded. Is this the best policy? Or should we allow dynamic Permission
grants for ServiceAPI too? We can always relax our policy later, to make it
stricter would risk breaking code if we had to reverse the decision.
Service Implementers produce jar archives for:
Smart Proxy's:
Implementation jar: service.jar (depends on service-api.jar)
API jar: service-api.jar (unless implemented already)
Smart proxy jar: service-proxy.jar (depends on service-api.jar)
The proxy can depend on other jar's too.
Dumb Proxy's:
Implementation jar: service.jar (depends on service-api.jar)
API jar: service-api.jar
Client's must produce the following jar archive, if extending Parameters:
Client Parameter extensions: AnyNameYouLike-param.jar
Why do we need the -param.jar again?
If we have multiple organisations, entities or companies, cooperating
using River, a Services API, might have some parameter classes that are
interfaces or extendible classes. Where a service is used as a means of
exchanging Objects between the two companies, the client developer and
the Service developer are independent parties.
If the client developer wishes to extend some parameter classes, he
would need to make those available for the Service implementation. The
client might initially use some default parameter classes provided by
the Service, but later decide to extend these classes for whatever reason.
It enables the client to extend or change these parameter classes
dynamically.
It's a separation of concerns, an optional package produced by the
client developer.
Cheers,
Peter.
