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.
We should encourage developers to maker their Service API publicly
available on Maven repository's, for others to implement.
Does anyone have any recommendations for ClassLoader structure or how to
set it up, based on the following information?
1. Public Service API, we've assumed cannot be trusted.
2. Service API must be in a Parent ClassLoader relative to Client's,
Service Proxy's and Implementation's, so the Service API's
ProtectionDomain can be removed from the stack when the proxy or
the client need to make a SecurityManager sm.checkPermission()?
While the Service API is on the call stack with no Permission's,
the Permissions of proxy's, service implementation's or client's
cannot be elevated.
3. It isn't safe to remove the Service API's ProtectionDomain from
the stack if your classes are visible to that Service API,
otherwise it could gain Permissions.
4. The service API must not see our implementations, so it cannot
take advantage of the fact that we remove it's ProtectionDomain
from our security checks in child ClassLoaders.
5. This also means that if we implement an interface that requires a
security check and the Service API can see that interface, the
Service API must not be removed from the stack during
checkPermission(). The higher up the ClassLoader tree the Service
API is, the better, there's less to worry about.
6. For ClassLoader domains visible to the Service API, the Service
API ProtectionDomain cannot be removed from the stack.
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
If we want to provide a publicly available Service, we can publish these
artefacts on Maven's repository and anyone can use it.
My apologies to the list for sending the last message 4 times! Poor
mobile reception was the culprit.
Cheers,
Peter.
Dennis Reedy wrote:
On May 26, 2010, at 609PM, Peter Firmstone wrote:
Dennis Reedy wrote:
Peter,
No worries. Although I think there is still a misunderstanding on how the class loader structure works,
Ok, I think I see it now, your ClassLoader structure represents your container.
Containers are free to come and go in Rio during the life of the application?
No, services are. BTW, this is a very similar structure to what ServiceStarter
produces, the big difference is the addition of the common class loader that
contains platform jars that are basically immutable, and not counted on to be
changing during the lifecycle of the JVM.
