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

Reply via email to