Minutes of SWSA Telecon of January 6, 2004. Participants: Mike Huhns, Tim Finin, Massimo Paolucci, Mike Dean, Stuart Williams, Mark Burstein MarkB: Let's focus on requirements for service invocation, the process of interpreting a service description and generating a request message. StuartW: This should include read descriptions in order to understanding ALL the possible responses - error messages, warnings, clarifications, etc. Not just generating the message. TimF: Need protocols - association of invocation with protocol, errors, default failure MikeH: From an architecture POV, There can be components associated with this - WSCoord, WSTransaction are looking at these - Middleware to provide the coordination between other services, to do things such as ensure 2-phase commits, for example. Rollback techniques, compensation. SW: Transaction coordinator: Its a role that can be done by third party or not. Has integrity issues of its own - if it crashes, it must preserve state. Need to describe those interaction protocols between the parties. TF: Our opportunity is to show how semantics is attached to the protocol. Annotated with conditions and assertions that contribute to the semantics. SW: There is an interesting thread on the www-sws-ig list - Subject: "Who does what" - The argument between a global perspective and role-based perspective on protocol definition. Global perspectives are hard to represent in distributed frameworks where messages can get lost. A provider/consumer model works better - service provided description of how it wants client to behave in order to complete signifigant task. OSI has layer description diagram (basic reference model from mid-80's). Layer entity with state is driven by layer above , sends messages into layer above and below. Book by Gerald Holtzman - book on elements of a protocol (ref below). Chapter 2 Section 2.2 "Design and Validation of Computer Protocols", Gerard J. Holzmann ISBN 0-13-539925-4 see also http://spinroot.com/gerard/ (MB: I found the book is online at http://spinroot.com/spin/Doc/Book91.html, and can be downloaded by chapter as PDFs.) The five elements of a protocol he identifies are: 1. The SERVICE to be provided by the protocol 2. The ASSUMPTIONS about the environment in which the protocol is executed 3. The VOCABULARY of messages used to implement the protocol 4. The ENCODING (format) of each message in the vocabulary 5. The PROCEDURE rules guarding the consistency of message exchanges MB: What are the layers below the protocols that we want to specify? For example, what does WSDL provide/not provide as far as synchrony, lost messages, etc? How about FIPA? Tim: FIPA assumes reliable transport. SW: What does that mean? What if a message doesn't get thru? Tim: There is a store and forward mechanism that is intended to help deliver on this. Reliability is just assumed. MP: Doesn't IP gives guarantees? SW: IP gives few. Max lifetime of msg is strongest guarantee. (upper bound on how late it can be.) TF: Want guarantee from upper layer of the stack- recevied, well formed, intending to process it. SW: Once you get back to HTTP, you are into a large datagram world. TCP connections go up and DOWN. Sequence of exchanges can occur across multiple connections. Business logic can fail. MB: Even WSA tries to ignore this issue. MP: (Action) I will look for a statement of WSA assumptions. SW: Question rephrased: What assumptions does FIPA make? The way I ameliorate my concerns WRT a protocol is that it is designed for some specific environment, and so hope the protocol designed well for the environment it runs in. Are two msgs that arrive with the same content the same or just two instances? If this is an issue in an environment then the protocol should handle it. Current web service are built on raw HTTP - we can't assume things that aren't there. Chris B. would also bring in the EDI world if he were here. Are they web services? If we assume WSDL - then next layer is sequences of WSDL operations - each has service level and http level responses - Say you obtain and read WSDL doc - do a post w this msg format to this port - at the http level you get 404 not found. What does that mean to you? If you follow a redirection do you tell the client to use the redirected endpoint? MP: WSDL can say the book not there, but does not address a 404 error. TF: Do WSDL faults refer to any external ontologies? MP: No, they are like runtime exceptions w. specific error types. TF: WSDL faults could have failure codes + description of WHY in a language like OWL. That is one way to introduce the semantics. This is attractive from a power POV, but not from current engineering practice. If you get back an error like this you could use it to find a service that could handle it. TF: E.g., I couldn't do this (service request) because you are not a premier member. SW: Assume due dilligence before sending the message, but the possiblity of failing because of some local decisionmaking on the part of the provider needs to be accounted for. Division between informative error msgs and those that affect the way that you recover from the failure. TF: Error/exception msgs could refer to an ontology describing specific refusal exceptions vs open ended exception descriptions. MB: Some clients could use abstractions in this ontology to decide what to do. Could even use subsumption to categorize up to a fixed list of error types. SW: HTTP uses numeric ranges, e.g. "200 class errors, 400 class errors" SOAP uses hierarchical structure for fault descriptions string w. dotted description. MP: These are service level - what about a 404? TF: Maybe we should scetch out an ontology for errors. SW: There are some up in the problem domain - out of stock - vs down in the infrastructure. TF: If we had such an ontology, those would be the ones abstracted out. - msg not delivered. We might want to create one. SW: RSC8226(ref correct?) gives account of all the codes - how I chose to map those to some simplifying abstraction so client doesnt want to deal with most or change recovery behavior (except logging). If you get a msg from an HTTP server, has it had any effect? MB: Ontology to contain a list of stages with semantically different recovery sent, received, interpreted(validated), accepted|refused, acted on, completed (task) SW: The last is not part of msg sending protocol Tim: think of it as a request, then the later stage is included. SW: Holtzman has a tool called SPIN for evaluating protocols. (see book ref above) TF: What hasn't been done - getting it right that frees us from a finite number of response protocols. In KQML/FIPA there was an attempt to do this for agents. We didnt complete it because we didnt have an answer for the ontology issues (no ontology of tasks) SW: We need to distinguish message ontologies vs action ontologies. MB: (later thought) Perhaps PSL helps us here? PI calculus? Maybe combined with model of the communications process?