...
Camel makes use of "components" to integrate various services using a terse, domain specific language (DSL) that can be expressed in JAVA, XML, Scala or Groovy. There exists one such component designed to work specifically with a Fedora4 repository. This makes it possible to model Solr indexing in only a few lines of code like so:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
XPathBuilder xpath = new XPathBuilder("/rdf:RDF/rdf:Description/rdf:type[@rdf:resource='http://fedora.info/definitions/v4/rest-api#indexableindexing#indexable']") xpath.namespace("rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#") from("activemq:topic:fedora") .to("fcrepo:localhost:8080/fedora/rest") .filter(xpath) .to("fcrepo:localhost:8080/fedora/rest?accept=application/json&transform=default") .to("http4:localhost:8080/solr/core/update"); |
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<route> <from uri="activemq:topic:fedora"/> <to uri="fcrepo:localhost:8080/fedora/rest"/> <filter> <xpath>/rdf:RDF/rdf:Description/rdf:type[@rdf:resource='http://fedora.info/definitions/v4/rest-api#indexableindexing#indexable']</xpath> <to uri="fcrepo:localhost:8080/fedora/rest?accept=application/json&transform=default"/> <to uri="http4:localhost:8080/solr/core/update"/> </filter> </route> |
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
val xpath = new XPathBuilder("/rdf:RDF/rdf:Description/rdf:type[@rdf:resource='http://fedora.info/definitions/v4/rest-api#indexableindexing#indexable']") xpath.namespace("rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#") "activemq:topic:fedora" ==> { to("fcrepo:localhost:8080/fedora/rest") filter(xpath) { to("fcrepo:localhost:8080/fedora/rest?accept=application/json&transform=default") to("http4:localhost:8080/solr/core/update") } } |
...
If an fcr:transform
program has been installed as mytransform
, you can generate a JSON representation of an object a container and send it to a low-latency, highly available document store, such as Riak. The following route determines if an object a container has been removed or simply added/updated. It then routes the message appropriately to a load-balancer sitting in front of the Riak HTTP endpoint.
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
from("direct:delete") .process(new SparqlDescribeProcessor()) .to("http4:localhost:3030/db/query") .process(new SparqlDeleteProcessor()) .to("http4:localhost:3030/db/update"); from("direct:new") .to("fcrepo:localhost:8080/rest?accept=application/n-triples") .process(new SparqlInsertProcessor()) .to("http4:localhost:3030/db/update"); from("direct:update") .process(new SparqlDescribeProcessor()) .to("http4:localhost:3030/db/query") .process(new SparqlDeleteProcessor()) .to("http4:localhost:3030/db/update") .to("fcrepo:localhost:8080/rest?accept=application/n-triples") .process(new SparqlInsertProcessorSparqlUpdateProcessor()) .to("http4:localhost:3030/db/update"); |
...
The default configuration is fine for locally-deployed listeners, but it can be problematic in a distributed context. For instance, if the listener is restarted while a message is sent to the topic, that message may be missed. Furthermore, if there is a networking hiccup between fedoraFedora's local broker and the remote listener, that too can result in lost messages. Instead, in this case, a queue may be better suited.
...