SWSA Minutes of 11/11/03 ("transcribed" from memory - please fill in anything I missed - Mark) Attending: Chris Bussler, Michal, Tim Finin, Stuart Williams, Massimo Paolucci, Mike Huhns, Mike Dean, MarkBurstein, Naso (Anatas) Kiryakov Editor Note: Frank McCabe of Fujitsu has agreed to join the committee (WELCOME!) Unfortunately, the telecon time is awkward for him (West Coast). Another reason to periodically have a later telecon. Frank is (the/one of the?) editor of the WSA document. His input should help us to make a clear layering on top of WSA. At the F2F, Norm Sadeh of CMU also joined the group. His focus is on Privacy and Confidentiality issues esp. for Ubiquitous Computing. He has volunteered to do a use case as well. Carole Goble is on travel this week. She has a student working on a Grid Use Case. Michal is working on a RosettaNet case. Tim F. is making progress on a Ubiquitous Computing Use Case. We began by discussing the message Mark sent out containing the functional areas descriptions now posted at http://www.daml.org/services/swsa/sws-functions.html (pointed to by the revised top level index page at http://www.daml.org/services/swsa) Please review and comment. This draft contains some slight shifts in the area of matchmaking and discovery (added service selection as a separate function - the act of the client chosing among a given set of candidates. It includes a confused description of orchestration vs choreography. We need to understand better what the distinctions we need to make here are (and how they are motivated from an architectural perspective). Chris: In RosettaNet, distinction between ack msgs (confirmation of prior msg receipt) vs temporal relations between PO and reply/confirmation that order will be filled (which is also acknowledged). Mark: We need to make a distinction between messages at the infrastructure layer (hopefully addressed within the WSA architecture stack) that relate to confirmation of receipt, etc. and those that carry semantic content (like order confirmation which impliy future effects (delivery, status message, etc) We should be concerned with the latter, and address the former by reference to the supporting stack. We discussed n-way conversation examples: Chris: client sends request to service (say, Amazon) for a used book which is forwarded to the actuall seller. email response is from the seller. MikeH: who do you talk to if you want to cancel? Chris: Amazon because the seller doesnt have a cancelation interface. Mark: But the architecture should support the latter - that is, the published process model might include the fact that Amazon's reply might say "your book is now being ordered from Seller" and that an optional cancelation protocol is henceforth available as part of this transaction by sending a message to Seller of the correct type. Chris: We need to support purely two-way conversations as well as the n-way. Mark: question is: do we need a different language for this? A different class of protocols? different architectural supports? Which distinctions do we want to make? Chris: Different architectures support async vs synchronous messaging. Sometimes clients are also made to be (web) servers in order to support asynch msgs. WSDL 2.0 may be moving to support these models, which BPEL requires. Indeed, there is sometimes a need for the clients/agents to describe the messages they can SEND as well as those they can RECEIVE. This may be part of what WSDL 2.0 covers. Stuart pointed out that the WSDL 2.0 draft docs are not at http://www.w3.org/2002/ws/desc/ One of these docs, the message patterns doc at http://www.w3.org/TR/wsdl20-patterns contains a number of potential patterns involving (robust/non) in-only, out-only, in-out and out-in. (We need to understand who is the client and who the server in each case in order to interpret IN vs OUT). These are all the 2-party possibilities. (MB: I THINK that in-only is a description of an acceptable incoming message to an agent, and OUT-only is one that it might send (asynchronously). We should all review these documents soon. Mark: One way to handle n-way is to make explicit the sender and receiver in the semantic model of a message. This was part of the meta-data that the FIPA agent communications language supported, along with such things as conversation tokens (in-reply-to). BPEL has a different model for conversation tokens. In principle, in a A -> B -> C -> A message pattern, Agent A could be aware that a message to B may result in a future message from C, recognized by the "FROM" and conversation-token metadata if A's message to B also resulted in a reply from B that included the token (or it was generated by A in the original outgoing message). Mark: We should review the set of metadata in the FIPA message protocol, and see how it maps onto WSDL, BPEL, and what the semantic import is. We need to establish requirements for what semantic elements are passed "up the stack" from WSDL message layer to semantic characterizations of messages in a meaning language. Tim: I will do a review of these elements. Next week: WE NEED TO HAVE SOME DRAFT USE CASES READY FOR REVIEW.