Minutes of SWSA Telecon of January 20, 2004 Participants: Chris Bussler, Massimo Paolucci, Mike Dean, Mark Burstein, Frank McCabe, Tim Finin, Enrico Motta Mark will check on dates for F2F, tentatively being discussed for just before WWW which is 17-22 May. DAML PI tentatively on 24-26th May in NYC. Probably going to be using Bell Labs for the SWSI F2F. Mark: Let's take advantage of the presence of Frank McCabe to discuss the relationship between our effort and that of WSA committee. Frank McCabe: WSA is an interoperability architecture - a framework in which specs will fit. 4 models: messaging, services, policy, resources We identify key concepts and relationships among these concepts. Using "MIND MAPS"(I think that is what he said. Frank?) Soap and WSDL are not complete overlays to this abstract architecture. The architecture is above the messaging layer. it assumes messages are delivered. "I strongly recommend ignoring reliability, issues of plumbing. Assume that you have a message - what should you do with it." I have developed (but not discussed in WSA) a Trust model and institutional framework (enactment, rights, authority) model for their architecture WSA has not (yet) addressed these issues. The attitude is that we're not telling you how to build agents, how things get delivered. There is nothing at the level of speech acts. FM: (ACTION) I've given briefings like "WS Architecture in 7 pictures" that I will update and send around. Our goal is to paint a broad picture in a minimal way. "World scale integration" Because as a W3C activity we need to relate to the web generally. We've had arguments about whether REST is the right approach. FM: I proposed a policy framework - enthusiastic uptake. Message model - lot of pain. W3C is reconsidering WSA group - charter ends at end of January. Final Note will be produced around that time. Our focus is Interoperability - says there should be headers, but leaves the details to SOAP and other specs. It is not our job go provide those details. Choreography, Orchestration, Security, ... not part of the architecture. We are never going to tell you how to build a web service. At a world scale, we cannot tell people how to build their systems. They have often already built them. They have their own goals, requirements. We don't want to provide obstacles. SAP, BEA will sell you a system to meet your goals. Then you have to figure out how to work with the rest of the world. If we tell you what to expect in order to inoperate. There are 2 competing standards for reliability. Neither are part of WSA, but should fit in. Most people start off thinking in terms of a bit of software receiving a message. That model is not right. There are many fingers in the pie of a message. If you think of it as a letter that is passed around from person to person that may be closer to right. Intermediaries for encryption, decription, etc. What is the relationship between the original and the encrypted message? Same or not? 'Message + mods' processed by more than one agent. Closer to blackboard systems than messaging - suggests a different kind of architecture - what I call document centric middleware. So our thinking has evolved away from agents sending and receiving messages to a more subtle view. Next week is the last official WSA face to face meeting. Not sure if it will continue after that. About 10 people actively working on it. Hope that there will be an OWL version of the architecture - as a set of concepts and relationships. Massimo, Katia and Bijan are working on it. Mark: We can use the WSA doc as a source of terminology. Frank: and a source of inspiration - for an approach to achieving interoperability - there are many different ways - we hope it will maximize the investment over the long haul. We are trying to avoid having the whole world shifting away from under our feet by being to specific in our recommendations. My personal goal is genuine interoperability across ownership boundaries. Three questions: What are we talking about? What are we trying to do? Who are we? (institutional framework - authority, etc) Reliability (messaging) Transactional Integrity (transactions) Trust The latter are are three levels of 'reliability' We've done our job to say that there are these layers and there is a hole that needs to be filled. Tactically, you should assume that other people will be looking at at least messaging and transaction reliability. But even if they were not, they are of sufficient technical importance that someone will come up with it. Strongly recommend SWSA pay attention to core compentencies. If it takes three years to do policy spec and you spend them doing reliability - then someone else will have done it and we will not have worked on policies. MB: Even if we assume that Reliability of Messaging, Transactional Integrity can have process failures. FM: A good part of the TI vocabulary is failure recovery. FM: PI calculus describes a process. If you want to handle errors, then you get a very reliabile but complex graph. On the other hand, if you took a PI calc approach to just the desirable states - then you can avoid a lot of the complexity - just say what will be true when you do get there. FM: A header is really an independently specified component of a message. The body is not the only content. Many people have stakes in how various parts are specified. Headers are bits that different stakeholders undertand and own. Next week: back to usual time.