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: Service API, class visibility, isolation and garbage collection - ClassLoaders
Date Thu, 27 May 2010 20:23:59 GMT
Dennis Reedy wrote:
> On May 27, 2010, at 451AM, Peter Firmstone wrote:
>
>   
>> 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.
>>     
>
> I'm sorry for not answering your question directly, I want to make sure I understand
you correctly. 
>
> By compile time, are you thinking of an environment that only deals with classes that
are loaded at JVM start time? 
>
> Or, since a client needs to have some a-priori knowledge of what it wants to discover
and use, that means the class(es) are known by the client in advance. And those classes are
included in the classpath of the client. Is that what you mean by compile time?
>   

The latter.

>   
>> 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.
>
>   
>> 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
>>
>>     
>
> Why do we need the -param.jar again? 
>   

If we have multiple organisations, entities or companies, cooperating 
using River, a Services API, might have some parameter classes that are 
interfaces or extendible classes.  Where a service is used as a means of 
exchanging Objects between the two companies, the client developer and 
the Service developer are independent parties.

If the client developer wishes to extend some parameter classes, he 
would need to make those available for the Service implementation.  The 
client might initially use some default parameter classes provided by 
the Service, but later decide to extend these classes for whatever reason.

It enables the client to extend or change these parameter classes 
dynamically.

It's a separation of concerns, an optional package produced by the 
client developer.

Cheers,

Peter.

Mime
View raw message