A SOA platform with built-in inference capabilities can let companies make runtime decisions based on service capabilities and invocation context where tasks are executed based on pre-defined conditions. On its own, SOA doesn't have this capability, but with the addition of inference, SOA gets the semantic semantic richness it needs to make runtime decisions Semantic integration techniques build context and awareness of the underlying services and data in a metalayer. However, many of these techniques aren't fully mature. Tools like Progress Software's DataXtend Semantic Integrator tackle this problem with a common data model that validates data exchanges.
Semantic integration techniques build context and awareness of the underlying services and data in a metalayer. However, many of these techniques aren't fully mature. Tools like Progress Software's DataXtend Semantic Integrator tackle this problem with a common data model that validates data exchanges.
Semantic integration techniques are based on the idea that it's possible to find patterns in the origin of various pieces of heterogeneous data. Once done, then it's possible to define these patterns using a metamodel, and then connect several metamodels by defining how they relate to one another. One emerging approach to semantic integration is ontology. Ontology is a structured representation of a domain -- by which we mean an area of knowledge like biology or economics -- in terms of classes and interrelationships between the classes that can be defined using the XML-based Web Ontology Language.
Any domain is usually expressed by splitting it into classes, and then expressing relationships among those classes. Ontology-enabled SOA extends this modeling technique by building a layer on top of the services dictionary that contains the ontology mappings of the services domain. The mapping is done during the design phase of building an ontology, then implemented at runtime to find semantic similarity for the service request. Policies are then built that contain logic for finding semantic similarity.
There are four steps in building an ontology-enabled SOA:
Step 1: Analyze The Business Process. A business process typically involves execution of a series of tasks based on some conditions. These conditions may represent intelligent routing decisions requiring semantic power. We define these as "points of variability," or areas where inference capability is required for semantic richness.
There are several variables for each task; and for each variable, there are multiple possible values. Future business needs may mandate additional variables or new values for existing variables (e.g., Physical State = "Gaseous"). Here is where defining an ontology model for these variables enables a vocabulary that can be expanded over time and a nondisruptive way to meet new business needs.
Step 2: Construct The Ontology Model. Ontology is defined in terms concepts and relationships. Ontology concepts are implemented in classes.
Relationships are implemented in terms of "object properties" and "data type properties." A mapping of components of points of variability to elements of ontology can assist in constructing the ontology model:
- Task List: Classes
- Variables List: Class Relationships
- Variables Value: Class Attributes
A sound knowledge of the business is a prerequisite to accurately identifying tasks and points of variability in the business process and ultimately mapping them to ontology elements to create a reusable model. Tools like the open source ontology editor and knowledge-base framework Protege can be used to create the ontology model.
Step 3: Create Context-Sensitive Invoker. Creating the runtime component that consults the ontology and makes dynamic context-sensitive service invocations is the next step. One way to implement this is by using Java-based technologies.
The business process flow can be encapsulated as a linear process in a Business Process Execution Language, or BPEL, block. The runtime component uses ontology mapping to determine the appropriate service end point.
This semantic richness is enabled by defining "policies" and "assertions." Policies operate on the available and published end points to a service and define who's eligible to use the service. Assertions are the ontology mappings of all possible context-sensitive variables. The runtime determination of the end point to invoke is based on the best match between the set of assertions and policies.
Step 4: Web Services. Web services provide the actual business service. They're the "consuming" points, invoked to achieve business functionality. The policy that operates on the Web services is part of the task required to incorporate a new service end point.
Putting It All Together
Semantic integration is being applied across a variety of industries, including financial services and pharmaceuticals, and as ontology-based semantic integration matures, it's likely to be applied broadly, too. A SOA architecture we built uses ontology to enable a typical business domain -- drug discovery. All drug discovery activities need chemical and biological samples, and sample management deals with the way the samples are acquired, registered, stored, and distributed. Our ontology addresses the sample acquisition activity, dynamically invoking appropriate Web services.
The system works like this: A researcher requests samples (Step 1, above). The request triggers a BPEL process (Step 2) in which the business process modeler's BPEL engine passes the request on to a context-sensitive invoker (Step 3). The invoker then interacts with the ontology engine and retrieves the assertions based on the context. The result is the context-sensitive selection of Web services using ontological means (Step 4).
Ontology can be used to enable semantic integration by modeling the business domain process as a workflow, and constructing an ontology model alongside the business process modeling. The classes and relationships of the ontology model are created based on the domain knowledge and the business process.
On the downside, an ontology-based SOA can be complex and difficult to maintain if not implemented correctly. But when it's done right, using ontology to create intelligent software agents is an excellent way to create user-friendly software that helps in decision making and speeds information sharing.