1. 1 Bringing Web Principles to Services – Through a Request Oriented Architecture Muhammed J. Al Muhammed David W. Embley Stephen W. Liddle Yuri A. Tijerino Brigham Young University and Kwansei Gakuin University Supported by:

2. 2 Example of A Free-Form Service Request What’s the weather forecast for Springfield, Illinois, between the 9th and 13th?

3. 3 Weather Forecasting Service Access to the National Digital Forecast Database

4. 4 Problems with Web Services Data heterogeneity problem What is the weather forecast for Springfield, Illinois, between the 9th and 13th? Coupling Problem Discover the required service Know how to use Communicate: keep the communication until the service responds

5. 5 Best: invoke services by only specifying your needs The service recognizes constraints And services the request

6. 6 Request Recognition What’s the weather forecast for Springfield, Illinois, between the 9th and 13th?

7. 7 Request Results 92°68°1% 98°56°0% 97°60°0% 89°53°10% 101690% MaximumTemp ChanceOfPrecipMinimumTemp What’s the weather forecast for Springfield, Illinois, between the 9th and 13th?

8. 8 Use the Web principles for communication Consequence: service- requester decoupling  Requesters do not need to know about the web services intricacies But, services must be capable of resolving data heterogeneity WWW Requester Web Service Web-Principled Services Read service requests Return responses

9. 9 Ontology-Based Web Services (OBWSs) Domain ontologies  Object sets (concepts), relationship sets (relations)  Main object (domain) set to specify the service type  Instance semantics (data frames): capture instances of a concept in terms of their external and internal representations. regular expressions, operations that manipulate concept instances, etc. Process ontology  Uses domain ontologies to process requests  Domain independence: coded once and for all

10. 10 Domain Ontologies Request-Ontology Matching User Free-Form Request Publish Requests OBWSs Ontology Feeds Subscriptions OBWSs Propose Services Requestor Select Best Proposal Establish Direct Link Reply to Request Request-Oriented Architecture Broker

11. 11 Requesters unaware of OBWSs Requesters do not have to discover OBWSs: the broker does. The communication links only created when an OBWS returns a response Result: OBWS-Requester decoupling Benefits of Request-Oriented Architecture

12. 12 Example: Applying OBWSs principles to Traditional Web Services

13. 13 From Traditional Web Service to OBWS Requires One-time Manual Mapping of Domain Ontology to Internal Web Service Representation

14. 14 Domain Ontology: Object-Sets (Extensional Concepts) Associated with Data Frames StartDate internal representation: date -- format: yyyy-mm-dd default value: (today) text representation: {monthName}\s+([0]?[1-9] | [12]\d|3[01])(\s*\,)?\s+\d{4} | (the\s+)?([0]?[1-9] | [12]\d|3[01])\s*(th|...)|... toInternalRepresentation(x:string) returns (StartDate) Tomorrow() returns (StartDate) context keywords/phrases: tomorrow|next\s*day |... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} |... NumDays internal representation: integer default value: 1 … Longitude getLongitude(x1:State, x2:City) returns (Longitude)

15. 15 Ontology-Based Constraint Recognition with Data Frames  What’s the weather forecast for Springfield, Illinois, between the 9th and 13th? Simple Object Set Mapping

16. 16 Ontology-Based Constraint Recognition with Data Frames       What’s the weather forecast for Springfield, Illinois, between the 9th and 13th? Simple Object Set Mapping

17. 17 Ontology-Based Constraint Recognition w/ DFs StartDate... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} |...          What’s the weather forecast for Springfield, Illinois, between the 9th and 13th? Complex range mapping

18. 18 Ontology-Based Constraint Recognition w/ DFs StartDate... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} |... Format … Default value: “24 Hourly” …           What’s the weather forecast for Springfield, Illinois, between the 9th and 13th? Use default values when possible

19. 19 Ontology-Based Constraint Recognition w/ DFs StartDate... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} |... Format … Default value: “24 Hourly” …             What’s the weather forecast for Springfield, Illinois, between the 9th and 13th?

20. 20 Result of Ontology-Based Constraint Recognition w/ DFs What’s the weather forecast for Springfield, Illinois, between the 9th and 13th? Knowns Unknowns Converted

21. 21 Result of Ontology-Based Constraint Recognition w/ DFs Given:  Latitude = 38.99,  Longitude = -77.99  StartDate = 2007-7-9,  NumDays = 5  Format = 24h Report:  Precipitation = ?,  MinTemp = ?,  MaxTemp = ? ?probability-of-precipitation ?minimum-temperature ?maximum-temperature 38.99 -77.99 2007-7-9 5 24-hourly

22. 22 Service Selection WS/OBWS 1 WS/OBWS 2 OBWS 1 OBWS x … … Broker (Profile- based Filtering) Complete/Free/XML/(table 4,2), … Partial/Free/Text/List… Complete/Subscription/XML/API… Complete/Advertisement/XML/Table… ?probability-of-precipitation ?minimum-temperature ?maximum-temperature 38.99 -77.99 2007-7-9 5 24-hourly Post Subscribe to Notify Request Browser Filtered Complete/Free/XML/(t able 4,2), … Complete/Ad- based/XML/Table The following web services can answer your query. Please select one: SelectCancelRetry Select

23. 23 Query Results 92°68°1% 98°56°0% 97°60°0% 89°53°10% 101690% MaximumTemp ChanceOfPrecipMinimumTemp What’s the weather forecast for Springfield, Illinois, between the 9th and 13th?

24. 24 Free-form Ontology-Based Web Service Demo www.deg.byu.edu

25. 25 Costs Manual ontology construction Mitigating observations  Not impossibly hard to build by hand  Data-frame library  Form-based construction  Table-based semi-automatic construction

26. 26 Conclusions Ontology-Base Web Services  Resolve data heterogeneity Request-Oriented Architecture  Requester-service decoupling Web-Principled Traditional Web Service  Build ontology to describe the service  Mapping between the ontology and the I\O of the service www.deg.byu.edu

27. 27 Questions ?

28. 28 Identify Constraints (Results in Heterogeneity Resolution) What’s the weather forecast for Springfield, Illinois, between the 21st and 24th? WeatherReport(x 0 ) is for Latitude(getLatitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) is for Longitude(getLongitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) starts on StartDate(NextDate(“21st”))  WeatherReport(x 0 ) is for NumDays(NrDaysBetween(NextDate(“21st”), NextDate(“24th”)))  WeatherReport(x 0 ) has Format(“24 Hourly”)  WeatherReport(x 0 ) produces ReportPeriod(x 1 )  ReportPeriod(x 1 ) has MaximumTemperature(x 2 )  ReportPeriod(x 1 ) has MinimumTemperature(x 3 )  ReportPeriod(x 1 ) has PercentChanceOfPrecipitation(x 4 ) The heart of the problem: constraint recognition Predicate calculus

29. 29 Generate Relational Calculus Query What’s the weather forecast for Springfield, Illinois between the 21st and 24th? { | WeatherReport(x 0 ) is for Latitude(getLatitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) is for Longitude(getLongitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) starts on StartDate(NextDate(“21st”))  WeatherReport(x 0 ) is for NumDays(NrDaysBetween(NextDate(“21st”),  NextDate(“24th”)))  WeatherReport(x 0 ) has Format(“24 Hourly”)  WeatherReport(x 0 ) produces ReportPeriod(x 1 )  ReportPeriod(x 1 ) has MaximumTemperature(x 2 )  ReportPeriod(x 1 ) has MinimumTemperature(x 3 )  ReportPeriod(x 1 ) has PercentChanceOfPrecipitation(x 4 ) } This constraints Variables have Been instantiated We need the values Of these variables So they become part Of the request

30. 30 Why not use a SOA like everyone else? SOA has been particularly successful in abstracting implementation through interfaces, however each interface has its own intricacies and requires manually developed adaptors at the mediator level. One could create ontology mapping at the WSDL envelop level, but this would daunting As a result SOA has been particularly weak in  Providing a functional and universally accepted service registry (UDDI).  Going beyond the enterprise applications into main stream user applications (with some exceptions such as Amazon, Google, etc).

31. 31 Benefits of a ROA vs a SOA for End-User Oriented Services In a ROA Instead of registering, with at the metadata description level using WSDL, a service subscribes to an ontology providing greater flexibility  E.g., still works even if the interface is changed The ROA proposed is more suitable for end-user oriented web services, but can still be used to facilitate communication among disparate and heterogeneous services.  E.g., we use the weather forecast ontology to facilitate communication between geographic coordinates web service and weather forecasting service

32. 32 Process Flow Domain Ontologies Identify constrains User Free-Form Request Publish Requests OBWSs Ontology Feeds Subscriptions OBWSs propose services Requestor Select best proposal Establish direct Link Reply to request Results in Decoupling

33. 33 Publish Request to Ontology Feed Convert RCQ to Ontology Query Convert Ontology Query to DB query Free-form Request Publish query: Known variable values Unknown variable values

34. 34 Receive Service Proposals from OBWS Proposal might include information such as:  Cost of service  Partial services (E.g., Needs data conversion)  Format (E.g., file type, visual format, etc)  Membership  etc

35. 35 Requestor selects best proposal Can use various criteria:  Cost  Familiarity with service  Other personal preferences

36. 36 Broker establishes direct link Once user accepts a service, broker hands off the session information to selected web service(s) with informatin such as Whole request Requestor IP address, user name, session ID, etc

37. 37 OBWS Responds to requestor directly OBWS uses user information to provide the response directly on the user interface Requestor can bookmark WS

38. 38 Ontology-Enabled Request Oriented Architecture Basic Principles behind an ontology-enabled ROA  Provides heterogeneity resolution User does not need to know how the intricacies of interface (e.g., format, data-types, etc)  Provides decoupling between service requesters and services providers No need for service discovery  Service consumer oriented as opposed to service provider oriented But can also support communication between applications  Scalable Services can be added through a subscription to domain-ontology model Multiple services may service a request through a mediator  Personalizable Requesters can personalize their service preferences  Policy oriented Policies determine how requests are matched to services

39. 39 Implementation in a Ontology-Based (Web- Services) Request Oriented Architecture Weather Forecast Ontology Geographic Location Ontology Car Adds Ontology Appointment Ontology Apartment Adds Ontology … NDFD WS OBWS B WS C WS D WS E WS F WS G WS H WS I … Subscription to Ontology Simple Free-Form Request Interface Free-Form Request Constraint Satisfaction Engine Service Broker Service- Request Publisher Map Publish Service- Selector and Filter WS Proposals Services Summary Request WS Proposals Requestor Preferred Selects WS WS Client Connector Selected Service Direct Link