Minutes W3C WS Choreography WG con call held on 25 March 2003, 1pm pst.

SRT: I can tell you what I know and that is all I can tell you, Daniel you and I already had an e-mail exchange. I'm going to put that on the top of the agenda to get that out of the way and then go on to the actual review. Anything else? O.k. Nothing... I shall dive in. Um... as you know... on the face to face when Microsoft showed up at around 10 o'clock it was quite a surprise and we can judge that by the number of chairs and heads that turned around. We did not know until the evening prior that MS was going to show up at Oracle's building, we didn't know until fairly late the evening before. Given that that was the case I had been having a private dialog with Greg Meredith for a considerable time before trying to get him to come to the face to face. I never for one minute thought he would turn up, I got an e-mail that evening saying he would show up and I said that you have to make sure your AC rep confirms and that was Alan Brown who also showed up. I didn't hear anything until they showed up. You may notice in the minutes that I left the room at 10 for 10 minutes to make sure they had the appropriate documentation to be there. I asked Hugo if they had received anything from David Turner (MS AC Rep), they had not. A phone call was made to David Turner to confirm their presence, an e-mail was received confirming their joining the group and I made the intro. Throughout that first day I thought their contribution was very useful and very clear and I felt hat there was a lot of good stuff that they talked about and certainly raised a number of issues with the group and that are continuing issues with the group that are on the agenda. I knew that Greg had to go home and Alan stayed but had to leave mid-way the next day, which he did. I got an e-mail over the weekend when I got back to England where Alan asked for the result of the vote and I said it was not a vote but a straw poll. By Wednesday of the following week I got an e-mail out of the blue from David Turner saying that both Greg and Alan had resigned with no explanation what so ever. Officially that's all I know. There has been much said in the press, I noticed that Daniel offered his words of wisdom to the wider community. There has been a lot of debate in the community about why they left and that is an issue for MS and MS alone to resolve, we can speculate until the cows come home. If they want to come back and sign up for the charter and work with us then our doors are open. That is where we are. The press is having a field day, they turned up, said one thing, which I have completely denied, the focus of the charter is the focus of the charter and has not changed. The focus of the charter is in keeping with all that Greg had said at the face to face and I have made that clear in any press statement and I think that it is. It's not... it's not changing what is there, it's just being clear about what is there and that's it. That's all I can tell you. Any questions? Those of you who were there know exactly what happened.

DA: They did sort of present us with an ultimatum at the meeting, which I thought was odd. The last thing Greg Meredith said is that if you play in this space then we will join you and if you don't then we won't.

??: The thing is that we made no decisions in the meeting.

??: We were certainly leaning toward the space they wanted us to play in

??: We have to assume internal stuff at Microsoft

Jeff: They said two things, you have to play in this space and they can't play in that space and we didn't say we wouldn't play in that space.

SRT: That is correct, the point of that comment was made by Greg Meredith, I responded very shortly or immediately after that and said that the focus of the charter supports the focus that they wish us to have, it was not exclusive of it. Call me old fashioned or call me a politician, I think that is the case. We have not finalized what it means in terms of what external or both mean, we haven't finalized those things. I agree with the comment. We certainly as a group are leaning towards the external without necessarily making clear statements about Turing completeness of externalization or not.

John Dart: I think they did make it fairly clear that they cared not only about the external issue but the Turing complete issue as well.

SRT: That is correct.

Jeff: I suggest we just move on, this is sort of pointless.

SRT: Indeed, it is where it is.

??: The ball is in their court

SRT: Totally in their court

DA: They picked it up and took it home

Jeff: I meant the motivations discussion

SRT: The group has other things to do then discuss Microsoft. Whether it is something they want to support that is their decision to make.

Action Item Review

SRT: There are 3 action items:

ACTION: W3C staff to setup teleconf - DONE

ACTION: Hugo to send choreography definitions to the list

ACTION: write up use cases

SRT: obviously the w3c staff did set up the telecom. There is an action on Hugo to send choreography definitions to the list. Is that a done deal?

Hugo: Yes

SRT: If we can record that as being done. There is an action to write up use cases, the action to write up use cases falls on those who went to the board at the face to face and put up a specific use case. I can say that I haven't actually done it, I have done it but my e-mail is down. I haven't seen any others. Has anyone sent in their use cases?

David Burdett: .... I want to submit the use cases from WSA from last year, does that need further alteration?

DA: Why don't you submit it and let the group figure it out.

DB: I will send an e-mail saying I am submitting it and providing a link will that suffice?

??: We need to make people write them

KL: Do we need a sign up person to put together an initial draft?

SRT: I think that is a reasonable thing to do. What I would quite like to do is see all those use cases come in and appoint that person next conference call because one of the things that may well happen is that there may be discussion about the use cases in the week they are sent and I would like to get to the discussion as fast as possible and then have somebody try to summarize all of it.

DA: Um... what is our intention for the use cases in terms of working product for the group, are we intending to put the use cases together in a... a.... use case scenario or document or are we intending to incorporate it into a requirements document?

SRT: I think the later. I think we can pick any one of those but currently I don't think that has been decided. Are there any strong opinions?

DA: My own feeling is that they should be part of the requirements document but that is one person's opinion.

SRT: Any other opinions?

KL I have seen that done in other working groups and it seems a good model. It seems to me that is one good way to talk to users to get use cases verified and understood.

DA: The requirements are usually generated from the use cases, they are integral parts of the process. So I think there is a good argument to be made.

SRT: If there are no objections then I propose they form part of the requirements document. If we can get those use cases delivered to the group then I would like to propose that we select someone to own the requirements formally either at the end of this meeting and if not at this meeting then certainly at the next.

DA: If you want to have that aggressive schedule for the requirements we need to roll.

SRT: Are there any issues in sorting out an editor for the requirements document, W3C people? Are there any issues in terms of constitution to decide that at this meeting?

Martin: Editor nomination goes to us and it is up to us to decide who is the appropriate resource.

SRT: Does that sound all right?

Martin: I have some people on the volunteer list and if other people want to submit themselves for consideration please e-mail us.

SRT: We will make the decision at the next week, probably tell people before the next meeting as we don't want to surprise people.

KL: Will we have only one document for use cases and requirements?

SRT: We said there would be one.

KL: The format for the use case document and requirement document are different, I don't know if it is a good idea to combine them together.

??: Could one be an appendix to the other?

KL: You could do it that way.

DA: If you think of the process you go through to generate requirements the normal scenario is to generate use cases and then generate requirements from those use cases and then go back and match requirements to use cases and that way you know your requirements are complete. Based on that thinking my own preference is to have the use cases and requirements as top level items in one document and show the organic link from one to the other.

KL: Make sense, as long as we make the use case and requirements distinguishable it is o.k. with me.

JohnD: I'm not sure that all of the requirements will be directly related to use cases.

DA: Right, the completeness has to go in the other direction, we have to make sure we have enough requirements to cover the use cases not vise versa:

Rich Bonneau: Do we have other examples in the W3C literature we can start with?

KL: For the description WG we have requirements and use case.

DA: The same is true for DOM, web services architecture and three or four.

??: Web Ontology has both use cases and requirements in the same document, indexing between them.

DA: If you look at the TR page, the Ontology group example is a good example, that is the sort of model I would like to see for this group.

??: I was the chair of the Ontology group, thanks.

SRT: I would like to draw this item to a close. Those people who presented use cases at the face to face all know who you are, the onus is on you to write them up and submit those. Those of you who have a burning ambition to be the editor's of the requirements document that at the moment will include the use cases in some form then please submit your request to Martin and myself. O.k.? Unless there are burning issues about this then I would kind of like to move to discussion of internal to external.

JohnD: can I make a request for the mailing list, clearly there has been a lot of traffic lately. I would like to see this focused as much as possible in the phase we are in, namely requirements, I have seen a lot of it veer off into implementation. I'm not saying we can preclude that but can I ask people to keep in the front of their mind if this is a requirement's phase comment or not.

Crowd: Various +1s and hear hears.

SRT: Yaron, did you get that minuted?

YG: Yes

Discussion of Internal vs External

SRT: Any objections? Then that seems the right focus for this whole debate. Unfortunately it says internal versus external and I got beat up because it is not a versus. It is what do we mean between internal and external.

Martin: Apologies from the author of the agenda.

SRT: That's all right I'm the one who started it. so um... does anyone want to take this debate forward?

DA: When you said it wasn't a matter of versus then maybe one place to start is do we all agree that at least the 'quote' external case has to be handled by the WG and that the real question is do we also do internal?

David Burdett: Can we define what we mean by internal and external? I know there has been some discussion on the list.

DA: I think it is really tough, I think it has to be identified by inspection. I know it when I see it.

David Burdett: Can I have a go at suggesting what I see as the main difference, people please do comment.

DB: An internal choreography is one that defines the sequences of processes and message flows in a domain of control where domain of control is a single business where inside of that domain of control you can have complete control over what processing goes on. That is an internal choreography. An external choreography goes beyond domains of controls, like one business to another where no single organization or role has complete control. So if you want to do a B2B then those two business have to coordinate.

Martin: I don't think that was the distinction at all. It all depends on your point of view. Especially on that definition, what may be under your control on one level may be out of your control anyway so it all gets rather recursive.

DB: Any processes you got were made out of sub-process, so long as you can completely encapsulate that process then you can regard that sub-process as being a black box over which you do have control.

Martin: is that black box the internal thing?

DB: It has to do with the ability you have to change things, you might have an atomic lump of software that does request/response but how you compose that together with other processes to do thing...for example.. .insurance companies have a very set way of doing things and choose different sequences by re-arranging black boxes.

Martin: How is that black box different than an organization boundary? You can see one organization...

DB: If that black box falls over you don't have to go to anyone else to re-start it and recover it. If you have to have a system outside of your boundary you have to go to someone else you can't control.

Martin: A black box is a black box, inside or outside.

DB: I disagree...

??: is this orthogonal to the Turing complete issue or not? We are talking about the interface to the black box...

DA: Actually what I think going back to a couple of speakers before me, somebody was pointing out that the boundaries of these domains of control, the idea was that the boundaries of these domains of control don't always align with the organizational boundaries. I don't always know what's going on in some other part of the company but the notion of being able to control a particular domain or not is a reasonable way of defining internal and external even if that wasn't our original conception. We do have to come up with some definition of what it can be and we need to define the control boundaries of what you can modify at well to distinguish these things.

SRT: Jeff, I have you on the queue.

Jeff: I think about this problem a little bit differently which may blur the distinction, one of the things we want to do is compose web services and you have to have an interface contract with enough information to compose them so if I have two or three web services that I want to compose into a new web service it may have to do some computation, it may use information about the contract and it does some computation where is where the Turing complete discussion comes in and it itself produces another contract and if you want to call that contract boundary an internal/external boundary that's fine but in a proper recursive model it is just an issue of view point. You have to do the composition and once you have done the composition then you have a black box that you present to the outside world that someone else can use and they can't get access to that unless they have access some other way to the internals.

DA: Say that contracts can't modify or can't modify anything inside of the black box but can they know something about it?

JM: Um... the only thing they need to know is what the contract is, we can talk about how detailed the contract needs to be but when you the designer design the contract you decide how much of your internal structure you are going to reveal. You are doing to do it in a way that lets the contract language let you do that. The Turing complete argument is that if you need to do some computation then you need to do some computation, you may need to take data from web service one and mess with it and send it to two and three.

DA: So are we talking about how detailed these contracts need to be?

SRT: I've got Frank on the queue as well, I would like to ask him to come on in a second. I want to make sure I fully understand this and summarize this. A contract, themselves, are not executable. They are descriptions. But in order to have recursive composition you may need to do computation and because you may need to do computation the issue then becomes the composed web service itself, it may indeed have a contract that is executable but it may have to do computation and it may fall in the scope of this group. Is that your argument? [Silence....]

Frank: That relates to Mike Champion's question about Turing complete or not... [noise on the line....] I believe that the original question about internal versus external was really about how much of the state of the process needs to be exposed in order to have a choreography between web services. And... specs like BPEL expose quite a lot of the internal state of a process because they try to encode the control flow of the choreography as well as the messages and Microsoft's point of view I believe and not only them is they want to avoid having that kind of logic show up in the choreography and simply have and this is the PI calculus approach, you try to avoid having any logic in the choreography itself, there is no state information in the choreography and you are only talking about what is externally visible, the choreography atomic, the units of interaction, the rendezvous between the different processes.

??: What you are saying right now is the Turing complete or not, if the contract is executable then you have a Turing complete contract language.

Jeff: No, what I wanted, what I was trying to get at is that in my mind one of the focuses of this group is to define a composition model and the language for that composition, for that you require a good description of the contract and the language to do the composition.

Martin: If you have looked at something long enough you can see messages coming in and out and infer decision points and you can tell that if a purchase order under $50,000 goes one way and another goes another way and you can detect these decision points and see this logic. I think the Turing completeness is a bit of red herring, I think we need to say what we need to observe and describe and if it is Turing complete falls out.

Daniel: Well, that and to follow up on Frank's comment as well, I think Martin is entirely correct in that first we need to define the scope of what it is we want to accomplish and the how question such as is it Turing complete will arise as we try to solve technical problems but first let's try to get a handle on scope and give ourselves a good description of what we want to accomplish and then we can worry about Turing completeness.

SRT: Daniel are you finished up?

Daniel: yes and thank you.

John Dart: Yeah, I just wanted to say that I'm not sure that the Turing complete issue is unrelated because once you go to a Turing complete representation of external choreography both the benefit and the problem is that you then might as well go and describe the internal state manipulation also because you have a rich enough model to do that.

Daniel: Right but we want to decide the what and then the how. I think we first want to get a handle on how big the ocean we want to boil and then figure out the boiling mechanism.

JohnD: I'm not trying to drive that, whether internal or external converge depends on the richness of the model.

SRT: Mike? Mike, are you there? I have a Mike on the queue?

??: Mike seems to have dropped from IRC.

SRT: Mike speak or it's David? David I think you scared him off.

David: I just wanted to come back to the differences from the internal/external thing. You look at some interface that has a sequence of messages and how you use it and incorporate it. If you are doing B2B I think the more likely scenario is that you are going to get some standardized choreography that says that this is how we as a business interoperate one with the other so what you want to do is when you decide to do business with a partner you identify what choreography they support and what choreography you support and you say that we both support it and we will use it which means that you have to have a way of defining that choreography and that choreography to exist and that is independent of any implementation and that is different than taking a particular WSDL definition and setting up the sequences, you are solving a different problem that involves agreement and specification of the choreography by an independent 3rd party. So that in a way choreography is actually there and it is a constraint on what you can do inside of your own business for example. Thoughts? Comments?

Daniel: Just to respond to David's comments I would like to counter with a different proposal that slightly modifiers yours David. Instead of trying to identify a set of choreography that all of these business and users of this technology share and then trying to standardize on that set of choreography maybe a better approach would to first adopt your idea on how to define internal and external based on domain of control, I like that and then try to identify in the first pass we identified a common choreography that is defined by the two businesses and then identify a subset of primitives that we can define those choreographies and we define different choreographies and messages and we try to reduce it to a common set of primitiveness, hopefully a small # like 8 and we standardize those primitives and business can take those and build up those pieces.

David: I don't think this group and I know I don't have the expertise to define what business want to do so this group should enable experts in vertical industries to define how they want to do business and use that definition to let them automate and increase the speed with which they can do business.

Daniel: I think we are in violent agreement.

SRT: I'm next on the queue

DB: Can we put up an idiot's guide to IRC?

http://www.w3.org/Project/IRC/

http://www.w3.org/2001/12/zakim-irc-bot.html

SRT: Sure, no problem. What machine are you on?

DB: Windows.

SRT: Lots of windows experts.

SRT: There are two points I want to make, first, PI Calculus, PI Calculus is not just for specification, it could also be viewed as an execution language, it is wider than just specifying a non-executable contract however it could be restricted to do that. The use case I will send in will use PI Calculus to define the observable behavior of a web service over its public state identification so that particular web service may have a # of states that you have that you never get to see and only get to see the results of... Just to make sure that is clear, I hope that my use case that I will submit when I get e-mail will define that more fully.

Jim Hendler: It's a little bit different to something a little earlier but one of our, I guess one of the things I thought this group might do is create a declarative language for defining some of these things. Not just take an existing business process to make it go faster but handing this off to someone else to use it for a different purpose, an example is taking a bunch of things that are known as web services and handing them off as a workflow to run on the grid architecture and I think those are very similar technology and that what you would write down is very similar and I want to develop something that had that flavor.

SRT: I've got Tony Fletcher next in the queue.

[Tony pointed out that Yaron, your poor scribe, had several times tried to put himself on the queue and never seemed to be called so Tony graciously gave his spot to Yaron so he could speak.]

Yaron: There is a big difference between the type of use case Jeff is talking about and what I thought we were here to work on. Jeff discussed a scenario where one wants to create a new web service by tying together a bunch of existing web services. To do this you not only have to specify a bunch of message choreography but you almost certainly need to also describe logic. Messages from Web Service A will need to be edited in some way before going to Web Service B. So if I understood Jeff's point correctly this means that the group would certainly have to deal with a Turing complete language since the very act of tying together a bunch of web services to create a new web service will in all non-trivial cases require substantial logic.

However we already have solutions for this exact problem today in the form of BPML and BPEL. They already specify how to create a new web service by tying together a bunch of other web services and provide both the messaging passing specifications as well as the choreography and logic needed to glue everything into a single piece.

I thought the purpose of this working group was to define externally visible behavior. To describe the legal message flows between various web services. This is what my customers need. They can already create composite web services today; they don't need any more help there. What they can't do very well is describe the message flows between web services in an interoperable way. This requires a declarative graph. More specifically, they don't want to express their logic. The point was made previously that if one observed a web service for long enough one could reverse engineer it's logic, you could know that a purchase order for above $50,000 went one way and one below goes another. But in practice that isn't true because in practice that behavior changes. A business may decide to change the threshold or even the entire basis of logic. No one outside of the company needs to know about that decision and that logic shouldn't be exposed in the message choreography. Describe the logic behind these choreography is an explicit non-goal, it defeats the purpose of the choreographies. If we wanted to describe the logic we would just use BPEL. So if describing this logic is what the working group is about then let me know and I hope no one will oppose me proposing to the W3C the formation of a separate working group to just focus on the declarative message graph, the global view, the message choreography.

SRT: Can I ask you to... You pretty well described almost a use case in terms of what your customers need and what happens when that changes and I would like to see that written up and sent to the group, I've heard you say it before and I want to get it on record and I think those points are important and I want them on the record. Can we get you to e-mail them in?

Yaron: No problem.

ACTION: Yaron to write up a use case of what he see the choreography group addressing

SRT: Excellent, so we can be very clear what Yaron is saying. Tony it's your turn.

Tony: What I'm going to say is somewhat orthogonal to what people have been saying. I personally and my company has no particular view doesn't care about internal/external, in terms of the model I wanted to challenge the idea of domain of control and get to what I said in the face to face and in e-mail. I think it would be better to think in terms of, phases, phases in which we use things. I think there is a difference of design time and run time. I think at design time you can stand back and say what are the roles I need. I think in terms of domains of control I think in terms of roles, the example I gave is when you have buyers and suppliers and at design time you can say that these are the roles and here are what the roles can do and you define the types. At run time you can actually say well I'm going to play the role of buyer and since you do a late binding of an actual instance of buyer to the role of buyer that is another characteristic. You could get situations where um... to be hypothetical... where you had a buyer in the company that went to an outside distributor for another company and one of the suppliers is the first company again so in principle two of the end points are in the same domain of control and the bit in the middle is in a different domain of control which is why I don't know that it is that helpful to think of domains of control. I think the difference is the choreography view at design time is what roles do I need and what are the interactions with each role and at run time then you focus on nearest neighbors and effectively take each interchange and say what is the contract we have between us, what are the messages, what are the meaning of each message, what needs to happen in regards to those messages and that needs to be a shared understanding between the roles and I think that is what the people advocating the external view are advocating, what they can share and agree. What you do internally, in a roll, you need a way to say what I do internally and how I react to messages come in and messages going out, in my sense an internal view, a single role view and it's a open question, I think they are all valid views and valid things that need to be done. I have no position on which particular piece or pieces of that problem this group takes on.

SRT: I'm going to try and bring this part of the discussion to a close and I want to get through these three speakers on the queue. I want to keep moving on because we are running out of time. Nick I think you're next.

Nick: I want to pick up what Jeff and Yoland [Yaron] and yourself said earlier about observable behavior and composition and Turing completeness. If you think we just have BPEL and that is good enough for the internal implementation then you need a way to expose the interface, so you can describe the operations about what can go in and come out but what is missing when you do that at the end points is something to put things together. I think that is what Jeff was talking about. You need to not just say what the capability is of the end points but how you compose them together. Then the buyer puts in a request and the seller does a receive but the buyer independently exposes an interface saying I want to a purchase and seller wants to do a sell, and later you want to say you can do a cancel or exchange. The composition needs to be expressed, the interfaces needed to be expressed, the observable behavior, what can be done. You need to put these things together, to choose them. The question, what Greg was saying, is what is the expressiveness of the declarative language to describe this composition? Do you need the full power of PI or a subset? That is what it boils down to. Internal/External is just a matter of scooping.

SRT: I would come back on that but I'm conscious, but I recognize I would be doing everyone a disservice. Daniel? Daniel?

Daniel: Sorry, had to un-mute myself. I wanted to point out to the members of the WG on the call who are not on IRC, listen up if you use the signal 41 and the # sign you will be added to the queue even if you aren't on IRC.

SRT: Was that your point then Daniel?

Daniel: Yes

SRT: Thank you. John.

John: I'm a little frustrated at the length of discussion and I hope there is forward motion on this, eventually I would like to see some glossary material addressed in the spec, maybe in the requirements phase, defining what we mean about external is a piece of that. I share the concern about domain of control because I don't want to say that a system has to be outside of the organization to be considered external. I want to get back to what Jeff said, there is a layering in this, even if you have a rich expressive public nature you are necessarily going to have to have opaqueness, it is a necessary part of choreography. I think one of the reasons people have discomfort with a rich external definition is that it brings business rules into the public space which is something you generally try to avoid. I think Yaron was also saying that basically if this definition becomes very complex in effect it becomes opaque because the partners can't parse what the overall behavior of the interaction is going to be and I have some sympathy with that. On the other hand saying that it has to be declarative seems more an implementation issue than a requirements phase activity. That is the end of my comment.

SRT: Thanks John. Jim I've got you on the queue.

Jim: Go ahead.

SRT: Go ahead Jim.

Jim: No, I'm fine.

SRT: I'm going to try and summarize and give a bit of direction. It has been an interesting discussion as ever and it is very difficult to make any clear decision at this point because we don't have enough use cases and enough knowledge to make that decision. All that we said about being requirements led, when we have gathered those requirements, it is really up to those people who think they can do this without doing this Turing complete with those who say there is no other way, it becomes an issue of proof. We are not at a point where we can make that decision right now, I don't believe. I think we are going to have to become more focused on the requirements next week and put this to bed and resurrect this when we have more use cases to put this around.

??: I think the proposal with glossary terms and use cases is exactly right.

SRT: I would like to close off item #4 on the agenda, I'm sure it will come back, it is still an issue.

Discussion of centralized control (hub and spoke) vs Peer-to-peer

SRT: The next point in the discussion is the hub and spoke model, centralized control, in which people put their hands up and said that was orchestration versus peer to peer.

Martin: Can I start this discussion by giving a simple use case. I think this is something that we can explore. The simplest use case there. We did have this notion, I'm trying to avoid orchestration and choreography, we did have a distinction between having a central coordinator for a dialog versus a dialog that is happening peer to peer. The central one for the hub and spoke model we can see clearly in languages like BPEL and peer to peer we can see in BPSS. My use case is very simple, I have a very simple client, it doesn't matter what it does and it wants to invoke a purchase order, send a purchase order, there may be some low level acknowledgements but that isn't important, the purchase order goes over to a manufacturer and the manufacturer acknowledgements the purchase order, three weeks later it sends a message saying it is going to ship the product. One easy way of doing that is a callback type scenario. In the current language we have, which is WSDL, there is no way to describe, to formally describe that as a model. So my hub and spoke, I am a client, I am invoking several things. Peer to peer is a callback. I want to ground the discussion in a simple use case and I will stop there. If that makes any sense at all.

SRT: Any comments on that?

DA: I wanted to comment on that. In your use case, just a question, you said that this is an example of a hub and spoke use case and I'm wondering if, if your description was from the viewpoint of a particular service that wants to talk to other services but I didn't hear you mention any central controller mechanism which is how I envision hub and spoke working. Were you meaning to include the necessity of the central controlling mechanism?

Martin: I was just being very general, a client doing a single interaction with a server is a degenerate case. It could be invoking other servers as well.

DA: The reason I'm asking about this is that I think it is an important point in terms of what we are trying to do. Do we assume we have a hub and spoke architecture that requires central control or a peer to peer that doesn't include a central controller? My thinking is that whatever we come up with should allow either of those architectures to be constructed and that it should not require one or the other. End of comment.

SRT: Jim, have you gone? Jim Hendler you are still on the queue? I think you are gone. Martin, I have a question for you about your use case. You said you had a client who sent the purchase order and the manufacturer spoke to the shipper and at some point the shipper responded back to the client. Is the shipper the hub?

Martin: I was saying the original client is the control, it does the initiation and wants the end result where as the manufacturer offers to sell goods.

SRT: So the shipper has no knowledge of the client other than through the request?

Martin: Correct

SRT: The client in effect passes a token that represents some way of communicating with it to the manufacturer who then passes it on to the shipper who can then use it to talk back to the client. Nick, question to you, if you are still on the line, does that sound like passing channels in PI? If you're there Nick? I think Nick may have gone. O.k. never mind, it is just a clarification, when we get that written up I would be interested in understanding the formal semantics of that and it is not dissimilar to the case that Frank McCabe put up that includes channel passing too. That would be a really interesting case and would be a simple degenerate case and I would love to come back on that and I'm sure other people will too.

??: So this is just a foretaste of the type of use case we expect to be seeing in the next week or two.

??: Is there anyone who thinks we should only focus on one?

DA: That's what I read in the notes.

SRT: Anyone think we should just do one of them?

??: I think it's too soon

JohnD: I heard a number of people talking about BPSS as a model, it is a centralized model and does not have a participant-oreintated model. So who is next on the queue? Who is 206-524?

Yaron: I am. I had a couple of points to make. I need to correct a mistake I've heard made several times about BPEL, BPEL does composition. In BPEL you can define a process and then you can glue it together explicitly to other processes. So you can fully describe a composition with BPEL. Second, I believe that spoke and hub is just a subset of Peer to Peer. That is, spoke and hub is a degenerate case of Peer to Peer. Third, BEA has published on its website (http://dev2dev.bea.com/technologies/webservices/WS-CallBack-0_9.jsp) a specification for how to do the callback scenario previously described. It also explains why WSDL can't handle this very well and shows the pain we had to go through to make it work over WSDL.

SRT: Can you post it?

Yaron: Sure, I'll send a link.

SRT: P11 is you Tony. If no one else claims it, it is your spot.

Tony: I don't understand, in this particular context I don't really understand hub and spoke in that I would have thought that each role/entity whatever they are would be autonomous, maybe not completely but to a large extent, they would act as independent autonomous machines, exchanging messages with each other and invoking each other and therefore could always be viewed as peer to peer.

Martin: Let me clarify, I'm talking about is it one document talking about a single person going out to all of these places or a document in which both sides have to agree, dictate both sides of behavior. That's what I'm saying.

Tony: oh, o.k. that is very different. In that case I think at design time you could have a single description that laid out all the different roles that needed to interact and at run time, yes, you would basically, one of the things you can do, this is the BPSS type model, is that basically you have a single description of which you are doing your part.

SRT: Tony, I would like to draw this to a close, you have one minute left. MY apologies to Peter and Nick who are on the queue, I don't think we can accommodate you in that minute. When the use case comes out you should model it in the way you describe for those people who think hub and spoke are a degenerate case of peer to peer.

AOB

SRT: We have barely a minute left. Is there any other business we need to cover?

??: Do you want to summarize the action items.

SRT: Yes

??: We talked about people publishing their use cases, call for an editor by next week, I heard Marc endorse the creation of a glossary and I would like to understand how we move forward with someone owning a glossary.

SRT: I would like to put the glossary onto the agenda for the next meeting in order to resolve how we will deal with that work. It has been raised but there are other issues that are bound to be more important so let's hold it for a week and make sure it appears for next week. Any other business? O.k. its 10:30 (gmt), time to close up shop. It has been most enjoyable, I look forward to it next week. Those of you who have use cases please publish them as soon as you can.