Even before considering a specific technology like JMS, I'd like to spend a little list-traffic with the question of the pattern to be deployed for this purpose, without thinking too much about the protocols involved.
Is a suite of event queues the right choice? Might we do better with something like a whiteboard arrangement in which the repository exposes a simple "register-yourself" service to let external services register as listeners to the repository-internal event exchange without those external services needing to know how or where the events are being constructed? Or perhaps a simple, lightweight event bus with some very basic routing configuration to allow for the addition of external services to event processing? Part of my concern here is the fact that while our discussion of the moment is to external services (e.g. indexing), we could (and I believe we should) expect the core workings of a repository to move towards the same kind of loosely-coupled pattern. High-level storage is a great example of this. I think Chris' question about the form of events is very important. (I'd like to use the word "events" for now, as opposed to "messages", because "messages" seems to me to beg my above question and imply the use of MQ-style technology, whereas "events" is a little more agnostic as to the protocols involved. Admittedly, I'm being picky, and others may not share my perception, but I thought I would raise the point early in conversation.) I'd like to rephrase (slightly) Chris' question in this way; are we interested in exposing the _operation_ of the repository (current JMS function) to a growing suite of external services, or exposing _the evolving state_ (Steve's new-school thinking) of the repository? Can we think of any use cases for exposing streams of operations that can't be supported by exposing streams of state-changes? Off the top of my head, I can't, but it's a subtle question. One possibility that does occur to me; using a modern WS framework (such as we will soon be doing) opens the possibility of exposing the Web services over asynchronous protocols (e.g. JMS). There are (low-priority) Jira issues to just this possibility. Is that kind of service exposure fundamentally different from the kind of event stream we are now discussing? (Which would put it out of the running for a use case that demands the continued exposure of operation-level events.) Or is it in the same category? (Which would keep it in the running for same.) I'm really glad to see this discussion starting up, because I think it's profoundly important for the future architecture of Fedora and in particular, for its viability as part of complex, large integration projects. --- A. Soroka Online Library Environment the University of Virginia Library On Jun 17, 2011, at 8:59 AM, Chris Wilper wrote: >> On 16/06/2011, at 23.26, Benjamin Armintor wrote: >> I think moving FieldSearch, ResourceIndex, and GSearch (among unknown >> others) out of core and into a queue of indexing services is an >> admirable development goal. > > Since GSearch is notified via JMS of Fedora updates, I would consider > it architecturally "ahead of" where we're currently at with the > Resource Index (ignoring FieldSearch for now). My question is, is a > JMS queue the common integration technology that all such external > services should be hooked up to in order to integrate? And can they > call depend on the same kinds of messages? (a message-per method model > as exists today, or a more object-change-oriented model as I think was > suggested by Steve at last week's meeting). ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
