Semantic Management of Web Services

1. Semantic Management of Web Services Steffen Staab Prague May 19, 2005

2. Hopes • Describe a goal – let the work be done by Semantic Web Services (previously „agents“, „PSMs“,…) • Projects like • EU: DIP, ASG, Ibrow, … • IBM India: see WWW2005 • US: OWL-S

3. Hopes Costs high RPC WS* Management Costs SWS low Granularity of Modelling coarse fine

4. Humbleness in Front of Total Costs Costs SWS high Total Costs RPC WS* Management Costs Modelling Costs low Granularity of Modelling coarse fine

5. Humbleness • What are the most urgent problems? • Where are the largest benefits • Analogy/Pseudoquote from Mohan (Sigmod Record, 2004): Where is this huge need for Semantic Web Services? Better be incremental! „Relational Databases were so successful, because people would have to write 20 times more code if they would not use them. Therefore, people could do things that they were not able to do otherwise, because they would not have been able to write 20 times more code. Therefore, people put up with early relational database mgmt systems, which were unstable, had many problems, etc.“

6. Hope, Humbleness and Hope again… • Web Services • Middleware • They are a huge mess! • Though they have clear conceptual underpinnings, they are complex beasts! • Semantic Technologies can do something for them! • Let‘s backtrack how!

7. Situation AIFB 1999 – not about Web Services Portal3 Semantic Web Service x ... Portal4 Semantic Web External Internal Portal1 Portal2 Knowledge Management App

8. helps Semantic Web Web Services helps • Web Services facilitate application development (in the Semantic Web) • Semantic Web technology is useful for Web Services Contribution of this talk Application Server for the Semantic Web • ASSW facilitates application development in the Semantic Web • Semantic Web technology is used within the ASSW helps Semantic Web ASSW helps

9. Agenda • Application Server • Semantic Web for Application Server • Problem • Ontology • Use Cases • Development Time • Run Time • Ontology Design • Architecture • Implementation • Relationship to MDA • Conclusion • App Server for Semantic Web • Semantic Management of Web Services

10. <web-app> <servlet> <servlet-name>JMXInvokerServlet... <servlet-class>org.jboss....</servlet-class> <init-param> ... </init-param> <load-on-startup>1</load-on-startup> ... <security-constraint> ... </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>HTTP Invoker</realm-name> </login-config> <security-role> <role-name>HttpInvoker</role-name> </security-role> ... ... Dependencies Access Rights Ontology Resources Users web.xml ... application.xml login-config.xml ejb-jar.xml MLETs .htaccess Problem Complexity in Application Servers Multitude of XML-DTDs

11. Component Ontology Schema level Instance level EnterpriseBean MBean instOf Semantic Metadata CustomerEJB Ontology • Ontology is explicit conceptual model • Formalizes properties, relationships and behaviors of components • Aims at conceptualizing „shared“ understanding • Logics-based formal semantics • Axioms • Allows reasoning • Allows conceptual querying

12. Use Cases Development Time • Component dependencies and versioning • Licensing • model development constraints • Capability descriptions • make component capabilities explicit • Semantics of parameters • associate names with ontology • Automatic generation of component and service metadata • beyond java2wsdl ... Recommender- Servlet WebShop- Servlet Lib Lib ... News- Servlet Lib Lib Customer Entity Bean Lib

13. Use Cases Run Time • Access Rights • E.g. indirect permissions • Error handling • Avoid exceptions thrown to the user • Transactional settings • Discover components that do not support transactions • Secure communication • Discover non-encrypting components ... Context Switch Customer WebShop- Servlet Anonymous Customer Entity Bean Admin

14. Ontology Design • Ontology Design • Syntactic vs. Semantic Metadata • Generic vs. Domain Knowledge • Modular Container Semantics of parameters Automatic generation Capability Descriptions Syntactic vs. Semantics Domain Knowledge Implementation details Mapping to source code

15. Application Server Core Services Administration Transaction Manager Inference Engine Security Security Management Component Loader Naming Version Management Architecture Ontology ... web.xml application.xml login-config.xml ejb-jar.xml MLETs .htaccess

16. KAON SERVER • Prototype of an ontology-based Application Server • Part of KArlsruhe ONtology and Semantic Web Toolsuite(KAON) • Uses KAON ontology language and inference engine • Makes obsolete several description files • Uses JMX/JBossMX • Inference engine as additional MBean • Additionally facilitates development of Semantic Web applications[ACM TOIT 5(2)] http://kaon.semanticweb.org

17. Relationship to MDA • OMG‘s Model Driven Architecture • Separates conceptual from implementation concerns • Not applied for run time aspects so far • Lack of formal semantics • No reasoning capability

18. Agenda • Application Server • Semantic Web for Application Server • App Server for Semantic Web • Semantic Management of Web Services

19. Trust Proof Logic Ontology RDF + RDFS XML + Namespaces Unicode URI Analysis • Megaprogramming • Semantic Web Layer Cake

20. Requirements • Flexible handling of modulesExtensibility, Dependencies, … • Static part of the Semantic WebLanguage Support, Ontology Mapping, … • Dynamic part of the Semantic WebFinding, Accessing, Modifying and Storing of ontologiesTransactions and Rollbacks, Evolution and Versioning, Inferencing and Verification, … • Semantic enhancement of the serverComponent capability descriptions and discovery, Semantic API descriptions, Component classification, automatic generation of semantic web service descriptions, etc. • Common Application Server functionality

21. Requirements in the Architecture Association Managaement Functional Components Design element Requirement Component Loader Interceptors Connectors Registry Kernel x x • Language Support • Semantic Interoperability • Ontology Mapping • Ontology Modularization • Finding, Accessing, Storing • Transactions, Rollbacks • Evolution, Versioning • Inferencing, Verification • Connectivity, Security • Extensibility • Discovery • Dependencies x x x x x x x x x x x x x x x x x x x

22. Design • Flexible handling of modules → Microkernel and component approach Functionality: simple management operations (start, stop, monitor, ...)Modules must be instrumented -> components Microkernel Component . . .

23. Design • Static part of the Semantic Web→ functional components • Dynamic part of the Semantic Web → functional components • Semantic enhancement of the server→ ontological registry with inference capability→ system component • Common Application Server functionality→ Reuse existing Application Server as far as possible

24. Client Surrogate1 Surrogate2 Architecture

25. MBeanServer KAON SERVER MBeans Implementation Java Mgmt Extensions (JMX) JBossMX Implementation Application Server for the Semantic Web Components Kernel Design

26. Starting the Server/Mgmt Console

27. Browsing and querying the registry KAON OIModeler Generic KAON ontology store surrogate

28. Browsing and querying the registry KAON OIModeller for browsing and querying the KAON SERVER‘s registry at run-time

29. OilEd OilEd • OilEd queries registryfor available reasoners • Component ID is fed intoreasoner surrogate • Reasoner surrogate relayscommunication to FaCT Generic RDF surrogate Reasoner surrogate KAON RDF store Sesame FaCT Racer

30. From App Server to Web Services ASSW Cascade

31. Purpose of Web Services • Light-weight • Widely distributed • Heterogeneous platforms helps Semantic Web Web Services • Semantic Web technology is useful for Web Services=Application Server + Wide Distribution + Web Standards

32. Web Services Standards WS* RPC I/O Typing Workflow Security … Plumbing Semantic Web Services Goals Means End Customer Use Chasm of Web Services

33. Web Services Standards WS* Complex by size Complex by heterogeneity No coherent model Inconsistencies Semantic Web Services Too complicated to specify for developers Semantics not powerful enough Semantic Management of Web Services Chasm of Web Services

34. Modelling Cost Considerations Costs SWWS high Total Costs Our target WS* Management Costs Modelling Costs low Granularity of Modelling coarse fine

35. Data Modelling Query Modify Join Services Modelling Query Configure Compose Execute Monitor Data vs Services Analogy

36. Knowledge Discovery remains a labor-intensive process! DBMS Implicit Meaning of Data Why? Immediate Meaning of Data What? Logical Schema Physical Data How?

37. Service organisation will remain a labor-intensive process! Web Service MS Semantic Web Services Why? (automatic composition!) „WS-Policy“, …. What? WSDL, BPEL, … TCP/IP How?

38. Conclusion from analogy Modelling and use of Web services by manipulation of individual files is an archaic practice – just like managing data by reading and writing individual files!

39. WS Management Objectives • Separate „What?“ from „How?“ • Leave „Why?“ to the developer (at least for the moment) • Go beyond simple data manipulation into semantic management in order to capture the immediate meaning of Web services

40. Use Cases Who? What for? When? Query type/Service Mgmt Task?

41. Ontologies for an Open World DOLCE Descriptions & Situations Ontology of Plans Core Ontology of Services Service Management Core Ontology Domain ontologies

42. Situation Description played-by S-Description C-Description component satisfies Parameter Functional Role Course D&S alignment to DOLCE Ground entities of DOLCE Descriptive entities of D&S In the following slides we see some modelling excerpts from the different levels…

43. Conceptual disambiguation Wider scope Activity Service Activity Computational Activity Information Object Service Task Task Computational Task Agentive Functional Role Instrumentality Role Service Offering Description Service Activities Description Service Agreement Description Legally Constructed Person Executor Service Requirements Description Input Output Service Assessment Description Computational Input Comp. Output Requestor Provider COS alignment to D&S DOLCE D&S COS Situation Description S-Description Functional Role Course

44. Service Management Description Quality of Service Descrip. ... Information Source ... Policy Description Interface Description Parameter Plan Description Age of Information Parameter Service Management Core Ontology Metadata from: WSDL, WS-policy, performace measurements, reflection Descriptive Concept Set of descriptive concepts and associations Description Association

45. Policy Description Constraint requisite for Parameter User right Task Descriptive Entities anakastic duty towards Object obligation towards (agentive) Functional Role Course of Event (non-agentive) Functional Role played-by sequences played-by valued-by Computational Activity Policy Constraint participant Information Object Perdurant Constraint Value Ground Entities Information Object participant locatedIn Endurant Concrete Constraint Endurant Situation Constraint Value

46. Service Management Description SMD1 Service Management Description SMD2 Interface Description ID1 Interface Description ID2 <BPEL> Operation Op1 Operation Op2 Computational Input CI1 Computational Output CO1 Computational Input CI2 Computational Output CO2 <WSDL> <WSDL>

47. Integration in KAON Server

48. Conclusion on Semantic Middleware • Ontologies provide great practical benefit • Conceptual difference between components and web services are marginal (see Oberle 2005) • Ontologies are no silver bullet! • Problem: provision of semantic metadata -> small is beautiful! -> beautiful is cheap!

49. Thank You! • D. Oberle, A. Eberhart, S. Staab, R. Volz. Developing and Managing Software Components in an ontology-based Application Server. In Proc. Middleware 2004, ACM/IFIP/USENIX International Middleware Conference, Toronto, October 18-22, 2004, LNCS, Springer. • D. Oberle, S. Staab, R. Studer, R. Volz. Supporting Application Development in the Semantic Web. ACM Transactions on Internet Technology, 5(2), 2005. • D. Oberle, S. Lamparter, A. Eberhart, S. Staab. Semantic Management of Web Services. Tech Report (shorter version at Semantic Web Service Week, Innsbruck June 2006). • D. Oberle. Semantic Management of Middleware. Springer 2005/06 http://isweb.uni-koblenz.de/

50. Web services constitute a middleware in order to model distributed applications and let them run on a set of heterogeneous platforms. Unfortunately, the many different Web service standards do not include a formal, let alone a common formal, model, which would allow to give an integrated, consistent view onto all of them. In this talk we sketch how ontologies may be used to integrate metadata about middleware in general and web services, in particular. Thus, we may answer about properties of web services in order to facilitate the life of the system developer and administrator for managing complex, distributed systems.