3. 3
Aiming for Seamless B2B Integration at Web Scale
Buy 100 IBM R50p
power supplies
Data: UNSPSC
B2B Protocol: ebXML
Data: RosettaNet
B2B Protocol: RosettaNet
Data: EDI
B2B Protocol: EDI
Ship to
Africa
Service
Client
4. 4
RPC based Distributed Computing
Network layer
Wire protocol Wire protocol
Client stub Server stub
Client Server
5. 5
CORBA and DCOM build on RPC
• Object oriented distributed computing – RMI
– Objects in one process invoking objects in another process
• Typed interfaces defined using IDL
– Build-time type checking
• Standardised bindings to programming languages
– Java, C, C++, Lisp, Python, Smalltalk
• At least 15 years of research into
– Efficiency, transactionality, reliability, exception handling
6. 6
The Promise of Web Services
web-based SOA as new system design paradigm
7. 7
Web services a step back scientifically
• Re-inventing inferior technology
– No standardised mappings to programming languages
– Not type-safe
– Immature notions of security, transactionality, reliability
– Closer to RPC – no polymorphism or inheritance
• But there are advantages …
– Language and platform independent
– Web standard specifications: URIs, XML, HTTP
– Open and interoperable – scale for the Web
8. 8
Current Situation
• Web services descriptions are structural only
– WSDL, UDDI, XML-Schema, BPEL, WS-*
• Assumption of shared understanding of semantics
– Data, process, protocol, policy, QoS
• Web service usability, usage, and integration needs to be
inspected manually
• Design-time binding of services and requesters
9. 9
Adding formal semantics, we can improve …
• Discovery
– How can a machine interpret a textual UDDI description
• Handling mismatches
– Data, process and protocol
• Composing services
– (Semi-) automatically
• Orchestration
– Execution of complex services defined using Workflow
11. 11
WWW
URI, HTML, HTTP
Semantic Web
RDF, RDF(S), OWL
Dynamic Web Services
UDDI, WSDL, SOAP
Static
Semantic Web
Services
The Vision
Time
12. 12
Conceptual model for Semantic Web Services
Formally describe
required
knowledge base
What a service requester
wants to achieve
Describe services
including the capability
they offer and the
public interface they
provide
Overcome
interoperability
issues for data,
process, protocol
13. 13
Conceptual model for Semantic Web Services
Formally describe
required
knowledge base
What a service requester
wants to achieve
Describe services
including the capability
they offer and the
public interface they
provide
Overcome
interoperability
issues for data,
process, protocol
14. 14
Conceptual model for Semantic Web Services
Formally describe
required
knowledge base
What a service requester
wants to achieve
Describe services
including the capability
they offer and the
public interface they
provide
Overcome
interoperability
issues for data,
process, protocol
15. 15
Conceptual model for Semantic Web Services
Formally describe
required
knowledge base
What a service requester
wants to achieve
Describe services
including the capability
they offer and the
public interface they
provide
Overcome
interoperability
issues for data,
process, protocol
17. 17
WSMO Mediator
uses a Mediation Service via
Source
Component
Source
Component
Target
Component
1 .. n
1
Mediation
Services
- as a Goal
- directly
- optionally incl. Mediation
Mediator structure
18. 18
Mediation – background theory
• Ontology alignment with machine assistance building on
– Schema-mapping approach of DB integration
– Ontology-mapping (MAFRA) and ontology merging (PROMPT)
• Extended with
– With different matching perspectives on ontologies
• Helps for different types of matches and expertise levels
– Top-down and bottom-up approach
• Caters for different scope for ontology alignment
• Better guidance during mapping
19. 19
Mediation – background theory
• Formal model for mapping creation
– Abstract model for flexible grounding to ontology langauge
– ISWC 2006 paper (building on ontology alignment & merging)
• Design-time tool
– Model is mapped to the graphical elements
• Run-time
– Abstract mappings are grounded to WSML
– Automatic execution with WSMX
23. 23
Discovery
• Two aspects
– Finding the services on the Web
– Matching goals with capability descriptions of available services
• We focus on the matching
– What needs to be modelled to make the semantic match
– What kind of middleware is needed
– What algorithms can we use
• Finding services on the Web
– Subset of problem for Semantic Web Search Engines
24. 24
Matt Objective: „book a flight and a
hotel for me for the ICWS 2005.“
Service Registry SWS Discovery
has
searches
VTA
result set includes
Goal definition
Web service discovery
25. 25
Underlying principle
• State-based formalization of services and goals
– Precondition, assumptions, postconditions and effects
• Follow description logics approach of OWL-S
• But stick with more intuitive semantics
– Postconditions, effects represent ‘objects’ the service can deliver
– Preconditions and assumptions represent a ‘contract’ that needs
to be fulfilled before discovery can take place
• Use reasoner to query over combined knowledge base
(capabilities, inputs, additional axioms) to get matches
29. 29
WSMX Architecture
• Execution environment for goal-based invocation of Web services
• Semantic overlay for Web service-based distributed computing
• WSMX interprets a client’s goal to
– Discover matching service (simple or composed)
– Select the best service
– Mediate interoperabilities (data, process, protocol)
– Enact the interoperation between the client and service
• Based on the conceptual model provided by WSMO
• Layered on top of Web service specifications (WSDL, XML, SOAP)
30. 30
WSMX Design Principles
Strong decoupling & Strong mediation
autonomous components with mediators for interoperability
Goal-driven invocation
distinguish interface (= description) from implementation (=program)
+
32. 32
Reasoner
• Mins
– Datalog + Negation + Function
Symbols Reasoner Engine
– Features
• Built-in predicates
• Function symbols
• Stratified negation
• WSML2Reasoner
– Reasoning API
• mapping from WSML to a vendor-neutral rule
representation
– Contains:
• Common API for WSML Reasoners
• Transformations of WSML to tool-specific input data
(query answering or instance retrieval)
• WSML-DL-Reasoner
– Features:
• T-Box reasoning (provided by FaCT++)
• Querying for all concepts
• Querying for the equivalents, for the children, for the
descendants, for the parents and for all ancestors of a
given concept
• Testing the satisfiability of a given concept with
respect to the knowledge base
• Subsumption test of two concepts with respect to the
knowledge base
• Wrapper of WSML-DL to the XML syntax of DL used
in the DIG interface
33. 33
• OASIS Semantic Execution Environment (SEE TC)
– Based on WSMX architecture
– Co-chaired by DERI
– EU, US, Asia co-operation
• W3C member submission
– WSMO, WSML and WSMX
Standardization
34. 34
WSMX – Summary
• Current WS technology insufficient for eCommerce
– Syntactic nature of WSDL, UDDI, XML Schema …
• WSMO provides rich formal descriptions
– Layering on WSDL and XML Schema for compatibility
• WSMX: reference implementation for WSMO
– Discovery, mediation, choreography, orchestration, enactment of WS
• Adopted platform for multiple EU Projects (DIP, SUPER, TripCom,
SWING, ++)
• Standardization through OASIS (and input to W3C)
