river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Mon, 24 May 2010 04:42:28 GMT
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?



View raw message