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 legacy.

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.