Design

Strengthening Service-Oriented Architectures (SOA) with Semantics

By John Hebeler and Andrew Perez,Lopez, October 20, 2009

SOA-izing Your Semantics

SOA-izing your Semantic Web applications makes them available to the wide, powerful ecosystem established through SOAs. These semantic applications, exposed as standard services allow organizations to bring the benefits of semantics into their enterprise-wide SOA solutions using familiar and compatible SOA interfaces. Consumers of the service need not even be aware that semantic technologies are employed in the implementation of the service. The first example simply embeds the Semantic Web into its service and then communicates with SOA through traditional SOA interfaces. This is certainly not earth-shattering but it is important to point out how this simple integration offers semantic benefits to the SOA world. The second example forms a SPARQL endpoint, an emerging standard, into a standard SOA web service. This opens up a semantic knowledgebase directly to the SOA allowing deep interrogation of the underlying knowledgebase from other semantic services.

The two together help illustrate the value in contributing the power of knowledgebases, reasoners, and dynamic, semantic representations to a SOA. This enables the SOA solution to include semantics at the service level to best accomplish its mission. These examples illustrate techniques to address the challenges of information complexity and service dynamics. The underlying semantics enable rich information expressions and interrogation to meet the challenge of information complexity. The information dynamics inherent to the Semantic Web allow run-time adjustments to the semantic data, its semantic structure and constraints.

Embedded Semantic Web SOA Service

Embedding semantics into a SOA service is straight forward. The service establishes its traditional SOA interface and registration. This exposes, to varying degrees, the value in forming, manipulating, and querying a complex knowledgebase but by maintaining a service layer, the subscribing client need not know anything about the Semantic Web. This provides the benefits of Semantics without adding any complexity to other SOA services.

This example shows two key parts of the embedded semantic service; the service declaration and service implementation that contains the Semantic Web constructs. The latter illustrates the knowledgebase composition. This maintains a complete decoupling between the Semantic Web and the other SOA services.

Our example provides a semantic service that accesses the catalogs of several suppliers. The Semantic Web technologies are ideally suited for such integration. The Semantic Web technologies describe the contents of each vendor's catalog for easy integration. The translation from various data forms to the Semantic Web RDF is often easily done using XSL transformation or some equivalent. RDF, the de-facto language of the Semantic Web, expresses relationships among concepts and allows for the transparent integration of multiple catalogs.

Figure 1: Embedded semantic example.

Figure 1 contains two basic catalogs from two suppliers. The first supplier's vocabulary describes Products, of which some are Books. Products names and prices are described using the hasName and hasPrice predicates, respectively. The second supplier describes Items, of which some are Journals and some are Magazines. Their names and prices are similarly described, but with different predicates: title and pricePerIssue. Finally, Figure 1 shows the simple query service and associated business object to represent a catalog item with a given price.

Using just a few lines of the Web Ontology Language (OWL), you can describe the relationships between the concepts from the first supplier's information model and those from the second supplier's.

The two different suppliers use different vocabularies to encode their catalogs, and the fact that supplier two has the notion of a pricePerIssue suggests that there might be some significant differences between their wares. However, for the purposes of a price check into the catalogs, those differences can be ignored, and the classes and properties above can be thought of as equivalent. Then, using just a few lines of Java code, you can combine the three models -- the data from the two suppliers, and those OWL statements that serve to align the data models:

After the models have been added to the joint model, a query can be written that exclusively uses the vocabulary of the first supplier which will still return results from the second supplier's catalog. This is because the equivalences defined in the OWL above allow a reasoner to infer that all Items from the second supplier's catalog are equally validly referred to as Products, like those from the first supplier's. When executed against the model, the query returns The Cat in the Hat and Where the Sidewalk Ends, but also Dr. Dobb's, because all three cost less than $12.

Rather than use semantic technologies behind the scenes as with the first example, a service could alternatively choose to expose them to other semantic-enabled services. This allows SOA services to work together to form a solution while taking advantage of the semantics.

The Semantic Web community has been interested in the complementary role that semantic technologies can play in SOA systems for some time. The World Wide Web Consortium (W3C)-recommended query language for RDF is called SPARQL, and the community is working towards standard artifacts for easy communication with SPARQL endpoints.

The next example illustrates how easy it is to expose semantic data as a SPARQL endpoint. We modify the previous example to accept arbitrary SPARQL SELECT queries and return the results according to the XML ResultSet schema that the SPARQL protocol uses. Assuming the same scenario as in the first example, exposing the combined catalogs as a SPARQL endpoint can give more visibility into the data by clients that are aware of semantic technologies. Here's an excerpt from the implementation the service class:

The SPARQL protocol specification defines an XML result set format which is returned by this code. This example depends on the Jena Semantic Web Framework, an open source implementation of many of the Semantic Web technologies that has come to be very popular in the Semantic Web community. One of Jena's components is ARQ, an implementation of the SPARQL query language, and ARQ provides the classes for executing queries and for serializing their results into the XML result set format. Below is the WSDL generated for this query service:

Being able to expose new, richer descriptions of data and the inferences that can be produces from them via standard service protocols is a big advantage, and helps to show SOA solutions can be enhanced with a little semantic technology.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!