Evolving the IChannelRegistryStore and ChannelRegistryManager APIs

This page covers changes to the ChannelRegistry APIs that are a part of the UP-2047 effort. Drew Masurek kicked off the discussion with a nice writeup posted to up-dev on 2009/05/06:

Hi everyone... for those of you who don't know me, I'm Drew Mazurek, currently working as a programmer for Unicon's Cooperative Development program. I worked for Yale University's Technology & Planning group for four years, and in my time there I was the Yale CAS project lead as well as the author of the official CAS protocol specification.

Some of the work I've done for Unicon on UP-2047 is checked into the 3.1 trunk. Specifically, I created the new Spring-backed JSON groups and categories service (UP-2394), wrote the subflow for the groups selector webflow (UP-2171), and added UP_PERSON_DIR info to the import/export tool (UP-2189).

I've been tasked with working on refactoring the channel registry, and through discussions with my Unicon colleagues, Drew Wills, Jen Bourey, and Gary Thompson, we've come up with the following:

In going where we intend to go with UP-2047, we will soon be hampered by the current uP API for channel publishing and management, which is IChannelRegistryStore + ChannelRegistryManager.

IChannelRegistryStore is basically the 'DAO' for channel registry information. It provides essential CRUD operations over the following types of entities:

• ChannelType
• ChannelDefinition
• ChannelCategory

Besides unit tests, there's only one implementation of IChannelRegistryStore: RDBMChannelRegistryStore. It stores channel info in the database using the following tables:

• UP_CHANNEL (channel entities)
• UP_CHANNEL_PARAM (publishing parameters)
• UP_CHAN_TYPE (channelType entities)

It also uses the GaP API for channel categories.

ChannelRegistryManager provides several static method-based utilities to perform many of these operations in XML format.

For 2047, we expect that these capabilities won't be comprehensive enough to support the features we would like to offer. We will probably want to add new capabilities. In this case, it probably makes sense for us to look at "trading up" the RDBMChannelRegistryStore for a new persistence infrastructure, presumably one based on Spring+JPA+Hibernate, since that's the current sanctioned approach within the community.

Looking at what's there currently, we're thinking it may be sensible to proceed by creating a new implementation of IChannelRegistryStore, such as 'JpaChannelRegistryStore.' There are many, many dependencies on the IChannelRegistryStore type in the codebase; for everything else besides the Portlet Manager we may be able to "leave well enough alone."

The usual JPA pattern in uP involves creating a DAO (more accurately, an interface + a concrete class); this DAO probably should not be the IChannelRegistryStore impl itself.

The DAO interface can and should define more capabilities than those needed for the IChannelRegistryStore impl. Our portlet can interact with the DAO directly to make use of these features.

As always, we welcome the uPortal community's input on this task, and we would like to keep our development as public and transparent as we can. Please forward along any comments you may have in this regard.

Thanks,
Drew