Automated Syntactic Mediation for Web Service Integration

Automated Syntactic Mediation for Web Service Integration Martin Szomszor ( [email_address] )

Presentation Outline Contemporary workflow design pattern Using workflow to capture experimentation process Discovery of services using semantics Problem description Syntactic incompatibility Using ontologies for mediation Architecture to support syntactic mediation Mapping Language Overview of mapping mechanics Implementation description Future work Dynamic discovery of Mappings

In Silico Experimentation Computational experimentation Access to resources provided by Web Services Users map experimental process to workflow Tasks are realised by service instances

Service Discovery Users need to find services to fulfill given tasks e.g. Retrieve sequence data Sequence alignment (Blast) There are lots of services ! Interface definitions can be terse, often un-documented and sometimes cryptic Limited semantic value Manual discovery not ideal

Semantic Discovery Support users in the discovery of services according to domain specific terminology Annotate service descriptions with concepts from an ontology (PEDRO annotation tool) Input and output types assigned a semantic type by a reference to an ontology concept Discover services by: Task performed Resources used Input and output semantic types

Use Case Common bioinformatics task: Find sequence data for a given id (accession number) Perform sequence alignment to discover similar sequence data Obtain results Itself a complete workflow, but likely to feature in larger workflows too

Semantically Driven Workflow Design When building workflows, users connect services because they are deemed semantically compatible: Output semantic type equivalent to input semantic type

Syntactic Compatibility However, semantically compatible service interfaces may not be syntactically compatible (i.e. different data formats)

Syntactic Mediation When a mismatch in data formats occurs within a workflow, a translation component is required Current solutions are manual Identify when mismatch occurs Derive conversion requirements Find suitable conversion tool Create new translation components if necessary These conversion components come in a variety of guises Translation Scripts (e.g. XSLT) Bespoke Code (JAVA and PERL) Web Services

Simple solution: Adaptor for each compatible data format O(n 2 ) Poor Scalability Alternative: Introduce intermediate representation O(n) Less effort introducing new formats Data Integration problem Conversion Approaches f c e b d a f c e b d a

Three Layer View Physical Layer Data can be stored in different formats: E.g. binary, text, xml, relational database, etc… Logical Layer Organisation of data elements described by a schema: E.g XML Schema, relational database model Conceptual Layer What the data means (semantics) E.g. Ontology, description logic, Entity Relation Diagram

Intermediate Representation Data integration field has used this solution in similar application domains: TAMBIS Project [Stevens et al 2003] Complex query formulation over diverse bioinformatics information sources SEEK Project [Bowers and Ludascher 2004] An ontology-driven framework for geographic data transformation in scientific workflows Intermediate representation in the form of a conceptual model E.g. Ontology, Description Logic

Architecture Requirements OWL ontologies capture data format structure and semantics: Existing service ontologies [e.g. C. Wroe et al 2003] can be extended with concepts and properties to describe data contents Modular and composable mapping language Mapping overhead reduced when service providers expose multiple operations over single schemas When schemas are combined to form new datasets, existing mappings can be reused

Architecture Requirements Invocation of arbitrary Web Services Grid and WS applications pull resources from multiple providers into a dynamic and volatile environment Must be able to invoke previously unseen services Minimise annotation overhead Reuse existing Semantic Web Service description methods Input and output types are assigned a concept (semantic type)

Mapping XML to OWL Problem can be simplified by assuming a canonical XML representation for OWL concept instances [OWL- XI ] XML serialisations of OWL concepts commonly used However, XML Schemas to validate individuals do not exist To support validation, OWL instance Schemas [OWL- XIS ] are generated from ontologies Concept hierarchies computed Jena + Java Implementation Enables us to view the translation as an XML to XML transformation

Architecture Diagram Service providers describe their Web Service interfaces using WSDL. Data consumed and produced is defined using XML Schema. OWL Ontologies are created to Describe the information contained Within Bioinformatics data structures. Serialisation and Realisation Mappings describe how to transform XML dopcuments to and from [OWL-XI] Semantic Annotations associate each WSDL Message part with a concept from the ontology. [OWL XIS] are generated to validate ontology instances.

Configurable Mediator Input: Source data instance Source schema Realisation Mapping (source format -> ontology) Ontology Definition Serialisation Mapping (ontology -> destination format) Destination Schema Output: Destination data instance Conversion performed via intermediate OWL concept instance

Mapping Mechanics <S> <X>foo</X> <X>bar</X> </S> <D> <Y>foo</Y> <Y>bar</Y> </D> Source Document Destination Document m 1 : S/X -> D/Y m 2 : X/$ -> Y/$ Mappings

Mapping Mechanics S X “ foo” S/* S/* xsd:string xsd:string X “ bar” D Y “ foo” D/* D/* xsd:string xsd:string Y “ bar” m 1 : S/X -> D/Y m 2 : X/$ -> Y/$

Example M-Binding <binding xmlns="http://www.ecs.soton.ac.uk/~mns03r/mapping/example" xmlns:sns="http://jaco.ecs.soton.ac.uk/schema/source" xmlns:dns="http://jaco.ecs.soton.ac.uk/schema/destination"> <mapping id= "1" > <source match= "sns:S/sns:X" /> <destination create= "dns:D[join]/dns:Y[branch]" /> </mapping> <mapping id= ”2" > <source match= "sns:X/$" /> <destination create= "dns:Y[join]/$" /> </mapping> </binding>

Bio Example <ddbj:DDBJXML> <ddbj:ACCESSION>AB000059</ddbj:ACCESSION> <ddbj:FEATURES> <ddbj:source> <ddbj:location>1..1755</ddbj:location> <ddbj:qualifiers name="isolate">Som1</ddbj:qualifiers> <ddbj:qualifiers name="lab_host">Felis domesticus</ddbj:qualifiers> </ddbj:source> </ddbj:FEATURES> </ddbj:DDBJXML> <ont:Sequence_Data_Record> <ont:accession_id>AB000059</ont:accession_id> <ont:has_feature> <ont:Feature_Source> <ont:isolate>Som1</ont:isolate> <ont:lab_host>Felis domesticus</ont:lab_host> <ont:location> <ont:Feature_Location> <ont:start>1</ont:start> <ont:end>1755</ont:end> </ont:Feature_Location> </ont:location> </ont:Feature_source> </ont:has_feature> </ont:Sequence_Data_Record> Simple One-to-One Element and literal Many-to-Many Split literal value Predicate evaluation

Example M-Binding <binding xmlns="http://www.ecs.soton.ac.uk/~mns03r/mapping/ddbj-to-ont-mapping" xmlns:sns="http://jaco.ecs.soton.ac.uk/schema/DDBJ" xmlns:dns="http://jaco.ecs.soton.ac.uk/ont/sequencedata"> <mapping id="1"> <source match="sns:DDBJXML/sns:ACCESSION"/> <destination create="dns:Sequence_Data_Record[join]/dns:accession_id[branch]/"/> </mapping> <mapping id=“2”> <source match="sns:ACCESSION/$"/> <destination create="dns:accession_id[join]/$"/> </mapping> <mapping id=”3"> <source match="sns:DDBJXML/sns:FEATURES/sns:source"/> <destination create="dns:Sequence_Data_Record[join]/dns:has_feature[branch]/ dns:Feature_Source[branch]"/> </mapping> <mapping id=”4"> <source match='sns:source/sns:qualifiers[sns:qualifiers/sns:name/$ = "lab_host"]'/> <destination create="dns:Feature_Source[join]/dns:lab-host[branch]"/> <mapping> <source match="sns:qualifiers/$"/> <destination create="dns:lab-host[join]/$"/> </mapping> </mapping> <mapping id=”5"> <source match="sns:location/$^[^.]+"/> <destination create="dns:Location[join]/dns:start[branch]/$"/> </mapping> </binding>

Conclusions Provide infrastructure to support syntactic mediation: OWL Ontologies to capture data format structure and semantics (reuse existing annotations) Mapping Language to describe relationships between XML Schemas and OWL Ontologies Modular and Composable Configurable Mediator to consume mappings and perform document translation Dynamic Web Service Invoker

Future Work Dynamic discovery of Mappings Already implemented using the GRIMOIRES registry and WSDL to describe mapping capabilities [Szomszor, Payne, Moreau 2006] UK All Hands, Nottingham Annotation Tool Mappings are complex and difficult to write by hand Web based annotation tool

Automated Syntactic Mediation for Web Service Integration

More Related Content

What's hot (15)

Viewers also liked (16)

Similar to Automated Syntactic Mediation for Web Service Integration (20)

Recently uploaded (20)

Automated Syntactic Mediation for Web Service Integration

Editor's Notes