Presentation given at the 3rd Internet Technologies and Applications Conference (ITA 09, http://www.ita09.org/), held in Wrexham, North East Wales, UK in september 2009.
1 of 17
More Related Content
Presentation at ITA 2009
1. Integrating semantic web knowledge and Service Oriented Architectures Jes炭s Soto-Carri坦n Elisa Garc鱈a Salvador S叩nchez-Alonso
2. Introduction Although the use of Semantic Web frameworks should be transparent and decoupled integration and interoperability between ontologies and applications are effort and time consuming New architectural models (SOA-ESB) can help us to reach transparent integration and decoupling
3. SOA / ESBs S ervice O riented A rchitectures allow software components to "plug in" to a middleware An E nterprise S ervice B us (ESB) acts as the necessary interoperability scenario JBI (Java Business Integration) standard: Normalized Message Router Binding component Service Engine
4. The problem Ont-Space Java-based software framework providing the services of a semantic learning object repository used in several projects Strong dependencies among other problems
5. Semantic Web frameworks in SOA? Knowledge bases with a sound logic model, and many mature ontologies available would enhance interoperability between components plugged in to an ESB Benefits: Rich semantic knowledge Inference operations
6. The hard work has already been done! OpenCyc hundreds of thousands of terms millions of assertions relating the terms domain: all of human consensus reality Many other mature ontologies
7. What is this presentation about? A service engine prototype that enables ontology query and reasoning capabilities through an ESB A general ontology reasoning connector would provide a normalized interface to semantic facilities GORCON GORSE
8. Semantic Web frameworks Schema API: function set to build and manipulate classes, relationships... Individual API Inference API: allows additional facts to be inferred from existing konwledge Query API
9. State of the art Middleware vendors did not make Semantic Web connectors available yet so We must build our own components using a particular semantic web framework. Disadvantages: Hidden development tasks Strong dependencies Application logic Semantic framework Coupled applications
11. General Ontology Service Engine The GORSE prototype implements sample functionalities Deployable on JBI conformant ESBs Developed using ideas taken from OpenESB SQL eng.
12. GORSE setup Users must set up GORSE with a short set of parameters gorse-settings.xml <connection> <database-url value='jdbc:mysql://localhost:3306/model'/> <knowledge-base value='ontomaps'/> </connection> Other ontology serialized representations can be specified E.g. an OWL file
16. Conclusions SOA provides new scenarios for interoperability of heterogeneous services Our prototype was aimed at showing that any application connected to an ESB can take advantage of the benefits provided by Semantic Web technologies Even legacy systems! Future: add more functionalities to GORSE
17. Closing time Thank you for your attention! Contact us: Development issues: [email_address] General issues: [email_address] Information Engineering research unit: http://www.ieru.org
Editor's Notes
In SOA, component communication is implemented through messages exchange. These messages contain data structured according to fixed structures (schemas), rarely using the flexible knowledge expressions provided by emerging semantic web technologies JBI (Java Business Integration standard) defines 2 types of components: Service engine (components implementing main ESB functionalities such as a BPEL interpreter, data translation or data transformation services) Binding component (Enabling services to deploy over a SOA architecture) NMR (Normalized Message Router): provides a normalized message interchange between ESB plugged components
In SOA, component communication is implemented through messages exchange. These messages contain data structured according to fixed structures (schemas), rarely using the flexible knowledge expressions provided by emerging semantic web technologies JBI (Java Business Integration standard) defines 2 types of components: Service engine (components implementing main ESB functionalities such as a BPEL interpreter, data translation or data transformation services) Binding component (Enabling services to deploy over a SOA architecture) NMR (Normalized Message Router): provides a normalized message interchange between ESB plugged components
However: * Hidden development tasks: as there does not exist a common ontology access provider (similar to ADO or JDBC for data access), each semantic web framework provide their specific application programming interface * Besides, each framework (e.g. Jena, Prot辿g辿-OWL, Sesame or Redland) has been developed with a different programming language, which causes a strong dependency between the application logic and the semantic web framework. Coupled applications: common semantic web functionality implemented into different components. To illustrate this problem, let us think of a software architect that decides changing the underlying semantic web framework in the application, just to discover (to her horror) the huge effort necessary linked to changing most of the code, as it is strongly coupled to the old framework.
Let us suppose that the CICS component receives a set of messages containing a sequence of medical patient records in OWL according to the open electronic health record ontology OEHR. Given that the COBOL language does not support a semantic library, the component cannot perform relevant operations depending on the data, such as checking the consistency of the data or retrieving all the instances of one specific class
General Ontology Service Engine functionalities: - Consistency check: verifies if an ontology is well defined, not including inconsistencies between data types and duplicated entries among other problems. Using this operation, a software component can check the consistency of one or more individuals received. - Instances retrieval: retrieves individuals from the ontology making use of the SPARQL language.
These parameters say how to access to the ontology persistent subsystem WSDL interfaces are automatically generated from this setup file
1) GIS coordination service receives a client request (e.g. all oils on canvas by Velazquez) 2) GIS uses a SOAP class including a SPARQL message to launch a query in GORSE. The proxy SOAP class is created with GORSE WSDL interface. 3) GORSE returns the results in result class internally using a XSD schema 4) GIS service decouples KML data and knowledge information to display the results in Google maps
General Ontology Service Engine functionalities: - Consistency check: verifies if an ontology is well defined, not including inconsistencies between data types and duplicated entries among other problems. Using this operation, a software component can check the consistency of one or more individuals received. - Instances retrieval: retrieves individuals from the ontology making use of the SPARQL language.
KML is a file format used to display geographic data in an Earth browser, such as Google Earth, Google Maps, and Google Maps for mobile. You can create KML files to pinpoint locations, add image overlays, and expose rich data in new ways. KML is an international standard maintained by the Open Geospatial Consortium, Inc. (OGC) .