Publish Subscribe is a generic mechanism by which clients can subscribe for a set of notification types redlated to a domain of content. The repository is responsible to notify the subscriber when events occur for documents within the subscription domain.
I have end points (lets say website nodes) that are interested in content that lives behind a enterprise content service interface. What lives behind that interface is not really important (about 10 different content systems.) What is important is that the endpoints have no idea that behind the interface is 10 systems. All they know is they need content and they go to a single interface for it. Facade.
The mechansim for specifying what they need has to be a single query format. Its up to the facade or the adapors that allow the ten systems to sit behind the facade to interperate, execute and return any results.
I want my web endpoints to be able to subscribe through this fasade for content. The facade would then proxy that subscription to whatever lays behind it through whatever mechanism is appropriate for the systems being hid.
When content that I am interested in (Content that falls within the domain of my targeter based subscription) has been updated, added, removed, ect I would like to my endpoint systems to recieve a notification.
The endpoint system could then make a determination to request the appropriate granularity of data... not at all, the metadata only, just a particular field, or the whole object.
Subscriptions and notifications could be made persistant allowing for the endpoints to loose connectivity for periods of time and to pick up where they left off when reconnected.
This seems like a great model for deployment. It is a part push and part pull. There is no knowedge shared between the endpoints and the systems that serve it. This is a requirement because with many systems fasaded it is impossible for the endpoints to maintain details about actual content provides, and untenable for the 10 content providers to manage the details of pushing content to all of the consuming systems. The contract is formed only in the QUERY itself, and that is a contract between the facade and the endpoint. Possibly passed through but likely translated for systetms X Y and Z
Becaus the endpoint system is subscribing for udates and pulling the contents local when it is notified it has the benifit of
local access times - udates and remote accesses arnt a factor at the view layer.
it can store the contents in whatever way is appropriate for it (encapsulation).
shared nothing approach allows systems to operate while others are failed or out of service for maintentaince.
It looks to me like IECM is considering XQuery or SQL as options. Either seems adaquate to me. We were looking at XQuery (and initially XPATH.)
In addition Targeters seem to be a great mechansim for personalization
I want to set up small apps that act as SLOTS on my website. I want to associate a targeter with these slots. At runtime I'd like to see these queries executed against a local repository (to the web endpoint) and have the results used to populate the slot.
Alfresco is a perfect platform for the publish subscribe mechansim because events live at the heart of the repository. Many of our other systems do not afford this luxury. Events can always be emulated for these systems.
Suggestion from LuisSala: I envision one possible subscription type being an email subscription where matches to a Lucene search are sent to a user during regular user-defined intervals (real-time, hourly, daily, weekly, etc.) Feel free to turn this into a separate project if it doesn't match up.
Decouples the SLA on the central repository and the consumers. The website needs to be able to serve content even when it is not connected to the CMS.
Heavy content calls to CMS are moved to the background. Calls for content from the application happen against a local repository.
Number of calls are reduced because event mechanism eliminates the need for polling.
Only the delta is communicated. Delta is not determined by date, its determined by the presence of the event.
Eliminates the need for the consumer and produces to have intimate knowledge of each others internals, etc.
Scales very effectively as new clients simply subscribe.
It is possible to make subscriptions persistent, but not necessary. Persistent subscriptions would account for delta while client is disconnected. This could be covered without the need for persistent subscriptions by the client passing the appropriate subscription..