river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Codebase service?
Date Sun, 23 May 2010 19:31:07 GMT

On Sat, 2010-05-22 at 17:22, 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?

More like "the dl-jar is only needed when the service uses a smart
proxy".  From my perspective, whether the service has a smart or dumb
proxy is none of the client's business (although I suppose a client
might have a preference that is expressed as a field in the service
template, or as a proxy constraint).  It also is liable to change for
different implementations of the service.  As such, the rule is "The
client develops and compiles against the API jar".

The API jar contains the interface to the service (interface as in
'public interface MyServ {...}', not the proxy implementation) and
possibly any classes that appear as parameters or return values on
service methods.  I say possibly, because in many cases, you might have
platform-type classes that could be used in the service interface (for
instance classes that form part of a domain data model).  Then part of
the contract of the interface would be "xyz classes are available in the
local classpath", and it's the client's responsibility to make that true
in whatever environment the client runs in.

The client should have no a-priori knowledge of the dl-jar or the
implementation jar.  The dl-jar is only published by including it in the
codebase annotation that is published on the marshalled service proxy.

Cheers,

Greg.

-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


Mime
View raw message