Gregg Wonderly wrote:
Peter Firmstone wrote:
Dennis Reedy wrote:
On May 20, 2010, at 628PM, Peter Firmstone wrote:
We could call it api, instead of spec, so as not to confuse the
Jini Spec? (We call River an implementation of the Jini
Specifications)
Implementation jar: service.jar
API jar: service-api.jar
Download jar: service-dl.jar
Thinking out loud here, what id the service does not use a smart
proxy? There is no difference between the API jar and the DL jar. Is
the API jar only needed when the service uses a smart proxy?
Yep that's correct.
I'm not sure I understand whether we want isolate just interfaces and
and referenced abstract types, or the impls as well, into the API jar.
I can't see a problem using / creating some simple immutable object
implementations for parameter and return types. It would be advisable
for immutable objects to defensively copy their fields during
unmarshalling, to prevent unmarshalling attacks retaining references to
private internal state. One might also consider providing a Builder
object in the same package with methods to manipulate the Immutable
Object. Similar to String and StringBuilder. One could improve the
package at a later date and retain backward compatibility relatively
easily. If there's a chance that The Parameter Object might evolve
functionality and state over time, then we must remember to design up
front to retain Serialization Compatibility too. Whether the class is
final or not also needs to be considered.
Functional parameter and return types are best represented by Interfaces
and abstract types. Since the Service is also a Dependency Injection
Pattern, we have no constructor, we can return or accept any
implementation we like from the DL Jar, Remote Service or client,
without creating a dependency on implementations.
If we want to pass mutable value objects, we really should use an
interface as there are various types; a remote object is just a proxy
stub locally, it requires an interface. Then there are local mutable
objects, Locally Mutable objects can be broken down into threadsafe and
non threadsafe, if it has to be threadsafe then I'd say it needs to be
represented by an interface as you don't want the complexities of
Synchronization implementations, you might want to change later, finding
their way into your Service API.
It would be ok to include a simple locally mutable parameter/return
object, but the documentation should advise that it requires external
synchronization and it should be defensively copied, just in case a
smart proxy wasn't defensively copying it for you. If the Service used
a simple reflective proxy, then a client could be at risk of unmarshall
attacks retaining a reference to internal state, so mutable parameter
objects should be defensively copied anyway. If you do choose to do
this, then you also must consider implementing Cloneable and considering
the consequences of inheritance too, otherwise how can the client
defensively copy it, if it's a subclass?
I imagine that bad Service API and their implementations won't prove
popular and die by suitable replacement.
It sounds like we are assuming that types referenced by the service
interfaces don't need authorization? I'm worried about that. There
are serializable types in the JDK that do work that might require
authorization aren't there?
Your talking about Java platform classes that tyically require
Permission before access?
If you are, you're right, they don't belong in Service API, unless of
course there are Authentication, Integrity and Privacy Constraints, on
both Client and Service.
Something I've been pondering is whether a new Entry type could be
created to advertise a Service's Method Constraints? (Inspired by
Patricks Codebase Entry and one of Gregg's earlier emails).
If feasible, I wonder if it might be possible to mandate a set of
minimum constraints as part of a Service's API?
Perhaps a nominated place in the Jar where River can find them. Then if
an API Jar has been signed, we can guarantee its integrity, at both the
client and Service?
Anyone else have any ideas or suggestions?
Cheers,
Peter.
