Minutes of SWSA telecon of September 23, 2003 Attendees: Chris Bussler, Michal Zaremba, Massimo Paolucci, Mark Burstein, Tim Finin, Boualem Benetallah -------------------- Started out by looking at Massimo's draft Use Case. MB to MP: What assumptions does the service make? Surely not none? For example, How is the state of a shopping cart to be handled? MP: We semi-automatically re-represented the Amazon WSDL interfaces in DAML-S. Then described usage protocols (as process models), as those were not included. We had a choice between use the datatypes that amazon (WSDL) uses or using OWL ontologies. We built an ontology of books, cds, etc. Then used translation to define the DAML-S grounding using XSLT transformations. This allows communication with Amazon to go both ways. As long as you can find a meaningful mapping you can do both ways fully. MB: Is XSLT really sufficient? For example, DAML/OWL/RDF are not order dependent in the way that XML is, and XSLT relies on this to identify paths thru structures. This means that it is not a good way to map OWL to XML, although it can be used the other way, since OWL as target doesnt care what order the expressions are generated in. MB led discussion point: One of the critical elements of our architecture is the requirement that there be languages and architectural components for mapping/translating from ontological terms to message elements and vice versa. XSLT may be a poor model for this and we need to define this requirement further. MP:At the end, if we had used another mechanism such as BPEL, would we have been able to do the same thing? What was DAML-S added value? Part of the answer is the semantics of processes (outputs and effects) and types (inputs and outputs). MP: Also, we observed that the protocol had a lot of non-deterministic choices/paths (valid sequences of msgs depending on the goals that we had). Not always possible to represent all paths. Choice to reserve a book or browse the DB. How to make this choice? MB: DAML-S better supports (automatic) composition than BPEL? What are the key features that support this? ----------------------- MP: WSA Architecture Summary - (based on last version available on the web.) Organized around 5 models/views: Message oriented model (SOAP like): Service oriented model (Services, choreography, provide/request, ... service semantics only a little) Resources - Web architecture, URIs, basic HTTP actions (GET, PUT), + discovery (?) Policy Model - permissions, obligations, authentication Management Model - Life cycle/ management of set of web services. MP: I expected something that would provice grounding in WSDL, SOAP, BPEL or Chor, etc but there is nothing of this - very abstract. Tried to describe amazon using these concepts - made a lot of compromises. e.g. concept of 'action' - not sure if it corresponds to WSDL operation or DAML-S Process - 3 or 4 ways to assemble messages. includes basic HTTP actions, but also includes discovery. They are at the stage where they have a lot of concepts, and now want to formalize using UML or other mechanisms (MP will be doing OWL). Another problem (also comes up with DAML-S) There should be a crisp distinction between the declaration of the architecture components and what happens at execution time. Message template vs actual msg between two web services (sent at time 1, arrived at time 2, specific content). Life cycle issues - not sure if referring to life cycle of protocol or instance. MB: What is their schedule for published (stable) draft that we might build on or contrast with? MP: Last call sometime first half of next year. Will check. MP: There is a lot of room for ontologies here: all of the policy model maps to the work that Tim is doing at UMBC. Tim: I notice that they have a model of actions in terms of permissions and obligations. MP: They say that a msg, service, should have semantics, but not clear what it means. The discovery process is underspecified so far. Semantics for Management Issues - unclear what the contribution we might make would be. MP: What we should say is that there is a distinction between the semantic representation of the content of the messages and the exact formats that are sent. MB: and we need to say how to go between them. MP: XSLT is convenient because it is described in XML Chris: Another example of order dependence problems: Classifications: if you are a shirt mfg - have many different sizes and colors. Request might have size then color, but the output might be color then size. Problem with XSLT is that you dont know what order the rules are applied. plus all items must be in memory. MB and Tim: DOM model not appropriate for ontology languages. We should state this. - ordering isnt important, information scattered. - the 'right' model is triples. Tim: Plus there is this inference problem that you must inherit things from classes down to individuals. MB gives example. Boalem: Philip Berstein at MSFT - operators for Model Management. Metamodel with concepts and entitites. or UML model to that. Chris: He comes from a DB world. Working on transformations between Relational Models and a little beyond. UML etc. Heuristics for finding mappings by looking at tag names. If both sides use the same ontology then into and out is a no-brainer, but if the ontologies are diffrent then problems are similarly difficult. The reason Amazon is publishing their web services API is that they want to eliminate the generating web pages for users, and become B2B. Amazon uses 160 servers 158 for web page generation, 1 for inventory, 1 for orders. They will be B2B, and have others build web pages using their WSDL interface. Next week? Chris - will try, but not promising. - discussion of B2B Boualem - will work with Fabio - behavior of semantics of web service.