Dennis Reedy wrote:
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.
Yes, but I'd like to build a reusable public library of Service API's
for developers to utilise. Who know's some standard interfaces for
commerce etc, might crop up.
Do you think this would be better served as a Subproject? Would anyone
be interested in contributing Service API?
I suppose the thought may frighten some, as there is some benefit in an
attacker not knowing a Service API. Security by obscurity is foolhardy,
if they're determined, they can find it using bytecode analysis, or
reflection.
We can use other measures such as Delayed Unmarshalling, Download
Permission, Authentication, Integrity, Privacy (encryption), Trust and
Isolation (Permissions, ProtectionDomains & ClassLoader vis) to secure
public distributed programmes over untrusted networks.
Regards,
Peter.
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