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.
