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.
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) .