Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


"Supply Chain" SOA with SKOS : Page 2

Most organizations have yet to fully realize the SOA vision through current technologies. Remedy this problem by mixing a web-based architecture with RDF and the SKOS metadata languages.

SOA Description and SKOS Entailment with Mulgara
The Mulgara Semantic Store is used for the rest of this article although you could substitute other systems without a lot of effort, as long as they support SKOS entailment. The fundamental choices are to commit to URLs, RDF, and SKOS. You can download Mulgara from the project site. After you have the distribution, simply run:

java -jar dist/mulgara-2.0.5.jar (or whatever the Jar file currently is called when you try)

Mulgara does not support SKOS out of the box, but Paul Gearon—one of the project's main other-worldly forces—has created a rule-based entailment system called Krule that makes it easy to add. He has contributed the rule base used for these examples and will eventually fold them into the Mulgara system. You are free to investigate this rule base but it has already been processed for these examples. There are certainly holes in the SKOS support, but it is surprisingly simple to achieve the functionality used here, and it will be expanded over time. This rlog file is converted to an RDF description of the entailment rules by issuing this command (although you need not do this to run the examples):

java -jar dist/rlog.jar skos.rlog > skos-rules.rdf

After Mulgara is running, point your browser at the web interface:


Author's Note: The following examples do not use SPARQL because the Mulgara web interface does not yet support it. This will change soon, but for now, iTQL, Mulgara's RDF query language, is close enough to SPARQL in terms of functionality that the concepts should still be clear.

From the web ui screen, enter the following commands. First, create four named graphs:

create <devx:services>; create <devx:services-instances>; create <devx:rules>; create <devx:services-ent>;

Click the Submit Query button. You should see evidence of success. Next, load the SKOS taxonomy into a graph to capture the service definitions. You can add new concepts to the taxonomy later if you like, but for now, just use the PrintingServices example by issuing this command via the Mulgara web interface:

load <http://zepheira.com/examples/soa-skos> into <devx:services>;

This encodes the taxonomy as described above. Only the statements explicitly in the SKOS file above appears in this model. For example, there is no direct RDF connection between a PrintingServices and a ColorLaserPrintingService. Simple graph match queries do not yield the desired results.

After you deployed some real services you need to describe them. In this case, categorize three (fake) services by inserting RDF triples into a service instance data graph:

insert <http://server1/print> <devx:category> <http://zepheira.com/examples/soa-skos#ColorLaserPrintingService>
into <devx:services-instances>; insert <http://server2/print> <devx:category> <http://zepheira.com/examples/soa-skos#BWLaserPrintingService>
into <devx:services-instances>; insert <http://server3/print> <devx:category> <http://zepheira.com/examples/soa-skos#PlotterPrintingService>
into <devx:services-instances>;

Here you have described three separate services as being a ColorLaserPrintingService, a BWLaserPrintingService, and a PlotterPrintingService. At this point, you could do straight pattern matches for each of the concrete service instances, but you could not search the service instance model for all PrintingServices. In order to do that, you need to load up the SKOS entailment rules into a graph:

load <http://zepheira.com/examples/skos-rules.rdf> into <devx:rules>;

and apply it to the SKOS taxonomy expressed in the <devx:services> graph:

apply <devx:rules> to <devx:services> <devx:services-ent>;

At this point, the <devx:services-ent> graph should have many more triples in it than the <devx:services> graph. This is because the Krule engine has entailed relationships suggested by, but not expressed, in the hierarchy encoding. Now there is an explicit, bi-directional connection between the different concepts in the taxonomy. Something that is related by the <skos:narrower> predicate is now also related by the <skos:broader> predicate in the opposite direction. Somewhat unintuitively, <skos:broader> and <skos:narrower> are not automatically transitive. The SKOS entailment rules indicate if there is instance data that suggests:

A <skos:broader> B <skos:broader> C, then A <skos:broaderTransitive> C.

This allows the following query to finally solve the desired problem. Given the <devx:service-instances> graph, what deployed services are PrintingServices? Again, these relationships were never explicitly expressed; the Krule engine entailed them. So, the query below asks for all service instances from the instance graph where the named service category is either a PrintingService explicitly or connected to the PrintingService concept through one or more <skos:narrower> relationships:

select $instance from <devx:services-instances> where $instance <devx:category> $service and
( <http://zepheira.com/examples/soa-skos#PrintingService> <skos:narrowerTransitive> $service in
<devx:services-ent> or $service <mulgara:is> <http://zepheira.com/examples/soa-skos#PrintingService>);

The results are all three service instances from above:

http://server1/print http://server2/print http://server3/print

Here's the code to select just the LaserPrintingServices:

select $instance from <devx:services-instances> where $instance <devx:category> $service and ( <http://zepheira.com/examples/soa-skos#LaserPrintingService> <skos:narrowerTransitive> $service in <devx:services-ent> or $service <mulgara:is> <http://zepheira.com/examples/soa-skos#LaserPrintingService>);

Running the preceding code yields two services:

http://server1/print http://server2/print

The successful adoption of a service oriented architecture requires the right balance of deployment infrastructure, metadata description, and query capability. By applying web architectures in the Enterprise you can achieve a flexible, scalable addressing scheme that hides specific backend implementation details behind logical names. After you commit to this kind of information-driven architecture, you need to describe and categorize the kinds of data and services available in this environment. RDF and SKOS provide tremendous capabilities while striking a nice balance of simplicity, expressiveness, and flexibility. If you have more sophisticated modeling needs and ontology engineers at your disposal, throwing OWL into the mix can greatly enrich your descriptive and inferencing capabilities even more.

These technologies enable the kind of lightweight, flexible, scalable, on-demand orchestrations as envisioned by the supply chain SOA metaphor in ways that lower costs and are more efficient than conventional technologies.

Brian Sletten is a liberal arts-educated software engineer with a focus on forward-leaning technologies. He has worked as a system architect, a developer, a mentor and a trainer. He has spoken at conferences around the world and writes about web-oriented technologies for several online publications. His experience has spanned the defense, financial and commercial domains. He has designed and built network matrix switch control systems, online games, 3D simulation/visualization environments, Internet distributed computing platforms, P2P and Semantic Web-based systems. He has a B.S. in Computer Science from the College of William and Mary and currently lives in Fairfax, VA. He is the President of Bosatsu Consulting, Inc., a professional services company focused on web architecture, resource-oriented computing, the Semantic Web, advanced user interfaces, scalable systems, security consulting and other technologies of the late 20th and early 21st Centuries.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date