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