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: Need for jsk-dl.jar
Date Thu, 06 Jan 2011 00:03:24 GMT
Dennis Reedy wrote:
> On Jan 5, 2011, at 342AM, Dan Creswell wrote:
>   
>>> Key to the modularization was to remove reliance on classdepandjar. I see
>>> this as a positive, I'm not sure sure others do. IMO, it really simplifies
>>> the project to not rely on classdepandjar, and have modules that produce a
>>> single jar. If you all feel very strongly about having classdepandjar AND a
>>> modularized project, I still doable, it will just take more work to put
>>> classdepandjar back into the mix.
>>>
>>>
>>>       
>> Well, I'm no fan of classdepandjar but removing it is build hassle for me.
>> Hassle is no big deal so long as I have a clear path forward. What can you
>> do in terms of putting together an example or doc that shows how the
>> "typical" Jini service would be built from now on (not sure Blitz is typical
>> but there you go)?
>>     
>
> The approach I'd give to a developer that is starting a project that will result in a
River service is a little different from taking an existing well established & thought
out technology such as Blitz. With Blitz, we're looking at a refactoring. So with that in
mind I thought I'd give myself an hour, and grabbed the Blitz source and took an hour to 'modularize'
it. After looking at the distribution I decided to break out the project into the following
modules, with each module producing a single jar, with inter-project dependencies
>
> blitz-\
>        | - blitz-stats
>        | - blitz-proxy
>        | - blitz-service
>        | - blitz-ui
>
> The relationship between the modules was planned to be as follows:
>
> blitz-proxy depends on blitz-stats
> blitz-service depends on blitz-proxy
> blitz-ui depends on blitz-proxy
>
> (There are other transitive deps including Jini and Sleepycat across the stack but I
will only mention those as a ref for now)
>
> I added gradle build scripts and was making progress but ran into issues with the blitz-stats
module (containing org.dancres.blitz.stats classes), because by itself that package has deps
on other Blitz classes, including SpaceImpl, Lifecycle, LifecycleRegistry, Logging, ConfigurationFactory
(etc...), and I didnt want to bring all of this into blitz-stats, since blitz-proxy depends
on it. So, since I gave myself an hour and simply didnt know (well kinda knew) if the decisions
I would make would break everything, so I stopped. If you'd like maybe we can talk about this
offline, be glad to share what I did if interested.
>
> So much for that experiment. However ...
>
> The general approach is to organize a 'service' project as a multi-module project, with
each module representing  the basic architectural element of a distributed service. Breaking
this down we have the service's API, the service's proxy and the service's implementation
(referenced doc http://www.rio-project.org/conventions.html)
>
> Given a service project with the name of hello, the service project is composed of the
following modules:
>
> • hello-api
> The hello-api module contains all the classes (interfaces and other classes) that is
needed to communicate with the service
>
> • hello-proxy
> The hello-proxy module (optional), depends on the hello-api module, and provides smart
proxy support
>
> • hello-service
> The hello-service module, depends on the hello-api module (or hello-proxy module if used)
provides the backend service implementation.
>
> • hello-rule
> The hello-rule module (optional), depends on the hello-api module and provides support
for rules associated with the service.
>
> • hello-ui
> The hello-ui module (optional), depends on the hello-api module and provides support
for a service user interface.
>
> What I have found is I give greater thought as to what needs to go where, and what the
consequences are to adding classes (and that class's dependencies (and transitive dependencies))
to a module. With the multi-module structure we can focus on the creation of services as a
tuple of api, proxy and implementation. I find it more constructive to have the components
broken out that produce one jar, write test cases for each module, and then write integration
test cases that incorporate all aspects of the service working together.
>
> In addition, the products of the rproject are easier understood from a user's point of
view. They follow a convention. For example, its easy to answer the question of what jar to
include if I want to use a service, you would use (from above) hello-api-<version>.jar.
>
> Note that the structure (approach) has been used with Maven, but as previously pointed
out Gradle is also a very (very) good candidate. Gradle itself uses Ivy for dependency resolution,
but the important thing is you can deploy your service artifacts to a Maven repository where
they can be easily included by other service developers for use. 
>
> I would like to think that we can take this approach to modularize River. FWIW, I think
River is an 'easier' candidate than Blitz, and for what thats worth for my own project Rio
[1]. River's codebase is already organized in such a way that is amenable to this model. The
service packages are all fairly self contained, they have deps to classes found in the platform
and into the application developers toolkit (jsk-lib). 
>
> Regards
>
> Dennis
>
> [1]  Rio is also built using classdepandjar, and I am going to be doing this sort of
refactoring for Rio over the next few months.
>   

I'd like to add that there are several strategies for evolving a Service 
API in a compatible manner for already deployed services.


For new additional api functionality eg:

    gday-api depends on hello-api.

    Create a new service implementation and proxy:
    gday-proxy depends on gday-api
    gday-service depends on gday-proxy

    This new Service can now serve existing clients using the hello
    service as well as clients that say G'day (Australian Hello).

Create a completely new Service api:

    hej-api does not depend on hello-api

    Create a new service implementation and proxy:
    hej-proxy depends on hej-api
    hej-service depends on hej-proxy

    Create a new translation service implementation and proxy, that
    implements hello-api that wraps and translates hej-api services for
    existing deployed clients.  (Hej - a Sweedish hello).


Changing a deployed Service API in an incompatible manner should be 
strongly discouraged. Any changes to a deployed Service API must take 
into account the following:

   1. Serialization compatiblity.
   2. The impact of additional non transient fields or public methods to
      classes.
   3. Addition of methods in an interface will break existing deployed
      services, when clients using the new api are deployed.


Cheers,

Peter.


Mime
View raw message