It's a common programming problem. Lets say, you have feild in two seperate databases, that are both named 'temp', is it legitimate to assume they represent the same quantity and can be integrated together? One might represent temperature and other temporary value. To properly combine these 2 fields, you really need to understand what the data represents.
At NASA and other large entities - both in government and business - integrating heterogeneous data is a challenge, but it's one that must be faced in order to easily share information internally and with outside partners. The integration challenge is one reason why NASA and many organizations are turning to SOA combined with semantic integration. As we know SOA consists of services that offer interoperability capabilities built into the network. While SOA's business-centric approach has sparked enthusism, the challenge is now to build in inference capabilities to make intelligent and dynamic selection of Web services possible. This is where semantic technology - the modelling of an area of knowledge like biology or economics as close to natural language as possible - comes into play.
Semantic technology
A SOA platform with built-in inference capabilities can let companies make runtime decisions based on service capabilites and invocation context where tasks are executed based in pre-defined conditions. On its own, SOA does'nt have this capability, but with the addition of inference, SOA gets the semantic richness it needs to make runtime decisions. Semantic integration techniques build context and awareness of the underlying services and data in a metalayer.
Ontology-Enabled SOA
Semantic integration techiniques 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.
There are 4 steps in building an ontology-enabled SOA:
Step 1 : Analyze the Business Process: In execution of business process, conditions may represent intelligent routing decisions requiring semantic power. We define these as "points of variability", or areas where inference capability is required. Future business needs may mandate additional variables or new values for existing variables. Identify them.
Step 2: Construct the Ontology Model: Ontology is defined in terms of concepts and relationships. Ontology concepts are implemeted in classes. Relationships are implemeted in terms of "object properties" and "data types properties".
Step 3: Create Context-Sensitive Invoker: Creating the runtime component that consults the ontology and makes dynamic context-sensitive service invocations in the next step. The business process flow can be encapsulated as a linear process in a BPEL, block.
Step 4: Web Services: provide the actual business service. They're the "consuming" point, invoked to acheive business functionality. The policy that operates on the Web Services is part of task required to incoporate a new service end point.
Final Word:
Ontology can be used to enable semantic integration by modeling the business domain process as a workflow, and constructing an ontology model along-side the business process modeling. The classes and relationships of the ontology model are created based on the domain knowledge and the business process.
