Channels ▼
RSS

Web Development

Strengthening Service-Oriented Architectures (SOA) with Semantics


Semantic-izing Your SOA

Whereas SOA-izing your semantics brings semantically enriched services to the SOA, semantic-izing your SOA improves the fundamental infrastructure capabilities of SOA. This assists the overall management and composition of the SOA itself. We examine two such additions -- a semantic façade that decouples normal SOA services from a larger, more complex and dynamic SOA service, and a semantic registry that improves on the syntax-oriented offerings by UDDI or other types of implementations.

Semantic Façade SOA Service

A semantic façade offers a method to build robust, complex abstractions from groupings of regular SOA services. The facade might be used to provide high availability by intelligently switching between similar services, align multiple, similar services, or to build complex sequences of services. The semantic façade is made possible by the use of semantic technologies and the inferencing provided by a knowledgebase and associated reasoners. A semantic façade can be used to encode and effect the more efficient use of existing services based on the semantics contained in the façade layer. The capability to semantically unite services aides in managing complexity on all three fronts: service complexity, information complexity, and service management complexity:

Figure 2 contains the standard Façade pattern.

Figure 2: Facade Pattern.

Now the Semantic façade adds a SOA interface layer to interact with both the client and the services (here listed as Package 1 through 3). The doSomething method enables the incorporation of semantics to manage the interactions between client and the services. Figure 3 displays the logical architecture of the Semantic Facade.

Figure 3: Semantic Facade logical architecture.

The Semantic façade brings the power of semantics to orchestrate complex service aggregations.

Semantic Registry SOA Service

Existing registries, and their shortcomings, are the Achilles' heel of today's SOAs. No awareness equals no use, and current implementations of service registries make it all too easy for services to fall through the cracks into oblivion. Of course awareness of services from back channels external to SOA can be used on a one-off basis, but this is not a sustainable solution for building a large, dynamic SOA-based application.

Awareness exists on several levels; syntax, functionality, dependencies, assumptions, and sequences. Syntax awareness provides the technical details to exchange information. Functionality awareness provides the purpose of the exchange. Dependencies and assumptions provide the background to exercise the service successfully. Finally sequence awareness provides the logical steps of multiple processes to achieve a larger goal. UDDI and similar SOA services 9 (even LDAP) provide only basic awareness -- allowing insight into syntax, some keywords that describe functionality possibly linked to a taxonomy, and some ancillary information. This is critical information but clearly they would benefit from some additional, rich knowledge about the service and its relationships to information and other services. Semantics can go beyond a taxonomy to find similar services and partnering services. Semantics can maintain alignment to the services as they evolve. Additionally, the complexity of UDDI has limited its implementation and adoption. Semantics can help in managing the complexity of UDDI while also providing a richer description of the service.

Rich semantics would even allow negotiation of services and advance composition. Areas that would enable the self-formation of a service sequence to serve higher level abstractions. This requires advanced, complex service descriptions in addition to the logic to interface properly.

Awareness can be inherent to SOA, where the SOA itself is aware of services. This awareness can improve management for the SOA services. In this case, SOAs can identify busy and non-busy services, leading to better optimization and improved resource utilization. A semantic registry could also provide governance -- a key enabler of advanced, large-scale SOA implementations. A Semantic Registry need not replace any existing syntax-based registry but rather enrich and strengthen the existing registry through semantics. Several potential semantic standards exist. See OWL-S or SAWSDL to see these standardization attempts at adding semantic information to SOA services.

Summary

The Semantic Web offers a bridge to the larger goals possible for a SOA and the many available networked services. It provides the conceptual abstractions necessary to collapse the various technologies into more useful computing artifacts and concepts. Additionally, it provides software the dynamism to keep pace with changes inherent to large scale computing especially when using decentralized, heterogeneous SOA components.

The flexibility of the Semantic Web can help to move SOA from relatively small, single-enterprise efforts to massive Web-scale systems that leverage both the services and information available through the Internet. It also provides a powerful set of tools for communicating and manipulating application data, structure and constraints, to align with many different perspectives.

We outlined four examples to illustrate methods where semantic gracefully strengthens SOA. The first two focused on the ease to add semantic capabilities to the SOA service portfolio. The remaining two demonstrated ways to improve SOA itself through improved composition and registration. These examples illustrate ways to better manage complexity at the service, information, and management levels. This complexity management expands the scope and reach of a SOA solution. Using a richer representation for data and service descriptions can empower higher levels of the SOA stack to effectively tackle the ever larger and more complex challenges that the future will inevitably bring.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

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.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
Dr. Dobb's TV