Subject: Re: Starting to modularize legacy
Josh Holtzman wrote:
As a first attempt at decoupling all of the services that are jammed
into legacy, I just pulled the entity package out of /legacy-service
into its own jar. Because it has dependencies on other legacy stuff,
the new jar must include the exceptions, time, and user packages from
According to my analysis, the Entity dependencies are: Site, User,
Time, and Exception. The dependencies on Time are understandable, to
some degree and we could live with that. The exceptions associated with
entity should be defined and bundled with entity, rather than shared.
This greatly reduces cross-service dependencies, as far as exceptions go.
Dependencies on User could be eliminated by returning a User Id string.
This doesn't really reduce the dependency. It just decouples the
services by making the reference more abstact (String vs. User). Still,
it would make it much more modular. Note also the circular definition:
User entends Entity, Entity relies on User. This feels wrong to me.
I also had to change the EntityProducer interface's
syncWithSiteChange(Site site, ChangeType change) to
syncWithSiteChange(String siteId, ChangeType change) to keep the Site
dependency out of the framework.
This is the Site dependency noted above. I have mentioned this to Glenn
in the past and there was some discussion about alternative approaches
at that time. Personally, I think that a reference to Sites at the
Entity level is completely wrong. It totally violates the layering of
services. I think we should consider moving it into the Site Service
(if possible) or consider developing a synchronization service of some
kind. It sholdn't be in Entity at all. That said, your proposed change
reduces coupling. I could live with that.
Many of maven's project.xml files also needed to be edited to add the
new dependency, which I called sakai-legacy-entity.
That would follow.
Perhaps this can be the start of a "framework" layer below legacy?
Entity should be in common, if it is going to be the base construct for
system resources (called Qualifiers in OKI-speak). Common should be the
basis for the new Sakai framework. Kernel is below it, application and
education services above it. Legacy services need to be evaluated on a
case basis to see where they fit.
We can't really move entity into common at this time, though. Not
without making some of the design changes I mentioned above. Nothing in
common should depend on legacy services. Putting it into it's own JAR
is just a holding action until we can separate it's concerns and reduced
service coupling. What is really gained by putting it into it's own
JAR? Can the legacy services be split up by doing that?
If we are considering a new entity that could be in common, we should
give some thought to the mix-in vs. interface extension design
patterns. There are advantages to the current approach, but mix-ins
have a lot to say for themselves, too. To my mind, Entity should
provide very basic capablities that we want all resources to have. It's
pretty close to where it needs to be, I think.
The good news is that this took only about two hours to accomplish,
and Sakai seems to be running happily. I couldn't make a
comprehensive patch for this, since svn wouldn't include any of the
"added" files (svn help anyone?). Let me know if you want to look at
the changes, and I'll zip it up and send it out.
I'm hoping that other minor API tweaks will allow the rest of legacy
to be modularized.
Modularized how? Do you think you can split the legacy services each
into their own JARs? Certainly pulling the legacy tools out is a very
good thing. Does it make sense to discuss what services should be
clustered? Are there services that could be moved to common?
- Mark Norton
This automatic notification message was sent by Sakai Collab
) from the WG: Framework site.
You can modify how you receive notifications at My Workspace > Preferences.