Subject:  Minutes of the June 04, 2004 Abstract BPEL Working Group.

 

Meeting started: 11:00 AM EDT and completed 12:00 AM EDT. Attendance was not taken.

 

 

Phil:       It would be worth creating a summery of what has been created so far. I think we’re doing a fairly good job so far. By keeping people in loop I hope to prevent this group from fragmenting.

 

Diane:    I hope we can have a summery presentation of conclusions reached at these discussions at the f2f. That might help us moving forward. What I am looking for at the f2f is not so much a summary of the meetings but a conclusion on the topic. Or at least a conclusion on parts of the topic.

 

Phil:       I don’t know if we are going to have a conclusion. One of the concerns of this sub-group is that we are looking for definitions from the original authors of Abstract BPEL. Nick in particular would like to see more use cases produced by IBM, Microsoft and the other original authors. Some of us in the sub-group feel unsure of what we can say without further input from the original authors.

 

Diane:    I understand what you are saying and that’s been said before. On the other side of the coin, the original authors made their statements in the spec. Satish wrote a paper right.

 

Phil:       Yes, we reviewed the paper in last week’s minutes. So are we saying Satish’s paper is definitive?

 

Diane:    For Satish certainly, Ivana has now contributed. Where there is silence you can assume there is nothing more to be added.

 

Phil:       So we will put up a trial balloon for a definition of Abstract BPEL and its requirements.

 

Diane:    We can’t just keep waiting.

 

Sally:     99 is a specialization of issue 107.

 

Phil:       Phil presents his action items.

 

Sally:     One of the reasons I am asking about the minutes because I was thinking about this. I am leaning towards Nick’s argument.

 

Nick:      The point I was making to Ivana last week was 2 weeks ago Ivana and Yaron were exchanging mailings about issue 99 and 107. I asked Ivana what is your response to 107.

 

Phil:       The thing that clicked for you was that you realized that 99 was a specialization of 107. 

 

Nick:      It’s not really my position. Resolution of 107 could solve all of these 99’s.  I asked Ivana do you share this view, if not why not? Looks like there is some kind of difference of opinion between BEA, Satish and Yaron at the way they are looking at 107. I’m in between.

 

Tony:      I agree that these two issues are strongly related. I feel Yaron’s position is a negative thing. It basically hides stuff. What Ivana is saying in 99 for an executable process, you have to start a process with a receive or a message coming in but for an abstract process, we should actually positively allow invoke as an initiating event. That’s what I see for 107 it’s a hiding thing, it’s a negative thing, and it doesn’t give you any new information. Whereas Ivana’s solution is a positive thing. It says this starts here we are going to allow invoke to start an abstract process.

 

Nick:      There was a lot of discussion about 107 between Yaron and Satish. The original BPEL authors forgot that in Abstract BPEL, you may have cases where you don have a ?? start that is why issue 99 exists. The point is that if you have a vehicle allows you to not have to worry if you forgot or not forgot something, and makes it flexible, I buy that as a more logical argument and then find that you’ve forgotten something. Opaque gives you this flexibility.

 

Tony:      I think opaque is going to have its usefulness when you are going from an executable process to an abstract process. People are always nervous about just chopping things out and chopping things out and replacing it with opaque may make people happier. But if you are starting from drawings on a whiteboard then you try writing an abstract process, you don’t use opaque at all you just write the abstract process. I think 99 is special and fundamental and is suggesting, that it is suggesting that if I want to use abstract process to define a business protocol between two parties, at the moment I can’t do this with Abstract BPEL.

 

Nick:      I’m sorry, no one is saying issue 99 is not a real. What I am asking you and you’re not answering and Ivana is not answering. With issue 99 today, you can’t do exactly what you described. If I have resolution of issue 107 and I have opaque, can I resolve issue 99?

 

Tony:      No you can’t, because you can’t show how the thing starts. How do you show the sending of the first message? You can show the receipt of the first message but you can’t show the sending of the first message. 99 isn’t one of 199, 299, etc. 99 does have a special quality, when you solve it there are no more of that type of issues to solve.

 

Phil:       Basically this is the same argument we had last week. We’ve got to grab the bull by the horns here. Now we’ve got input from Ivana. I asked her to show us an example would preclude the use of opaque and necessitate her approach. I have not had a chance to see her work or yet. Nick you’ve been eloquently arguing for Yaron. I would like you to write a BPEL XML file showing how opaque could be used to solve Ivana’s problem. If we don’t get this we are going to be arguing in loops. Is that OK with you.

 

Nick:      No that is not OK with me. This is not my issue.

 

Phil:       We need an example. Diane, I know Yaron is busy but in order to clarify this issue, we need an example to show how opaque can do just as good a job as what Ivana is suggesting.  Does that make sense to you? It seems to make sense to me.

 

Diane:    I understand what you are saying, I don’t know how to make people do things they don’t have time or interest to do. Running a committee like this we can only go with those who are willing to contribute. If they do not contribute and they loose the position they are advocating, that’s life.

 

Satish:   We have the coalition of the willing it seems here. Can I just interject here. Issue 99 is a relatively narrow one. It’s about start activities especially for abstract processes. The opaque issue is much broader.. It has to do with “How do you abstract things? How do you do omissions?” Do you do them simply by omitting things or do you mark the places  omitted? I don’t think we need to treat those as though they are the same or at the same level.

 

 I had a little chat with Yaron yesterday. The argument I made was that if we are going to mark things as omitted as explicit with opaque than we have to assert all omissions are thus marked therefore in an abstract you cannot extend anything except those places that are explicitly marked opaque or you are going to say no no no you can extend anywhere else as well I’m not necessarily saying you can’t . Yaron has the latter position in that he does not believe the opaque markers he proposes are marking all of the omissions. I argued in that case it is worse than the omission because it is misleading. You have the feeling that you have achieved syntactic correctness and have somehow marked the omitted places but in fact you’ve miss leaded people to believe that you have marked them all. Yaron agreed that a little bit of security is better than no security.

 

Nick:      I think I agree with Satish. What I was going to say that the discussion we’ve had Ivana and others than if opaque had the correct semantics, could we use it to solve for 99.

 

Satish:    Anyway you do omission explicit or implicit, 99 doesn’t care.

Frank:   How does that solve the issue of 99 where what you really need to do is to be able to exchange with a partner or who ever the other participants are what the messages are going to be. If I use opaque as a starting activity I’ve effectively hidden what I am expecting to exchange with them.

 

Nick:      Have you seen Ivana’s paper? If you look at the pdf file it can be seen that it is obvious what is to be replaced.

 

Tony:      I’m neutral on opaque.  I don’t see how it is a solution to 99. The test case for me would be a simple use case of the buyer sending a message to sender. You can map the seller all right but how do you model the buyer?

 

Nick:      Tony, if you look at the .pdf, you see Ivana has done a very good job of putting diagrams and everything.

 

Satish:   My understanding of 99 is don’t force me to explicitly show you how a process has started in the abstract case because I may not be able to show you. For example in the Rosetta Net situation, where one party is going to initiate an interaction but the initiation of the instance of the initiating party is itself in invisible because it is done by some private means.

 

Nick:      Exactly, and if you see the write up, you will see that in the first example Ivana has a receive-create instance that today would be considered invalid and in the other case because of the resolution of 99 you don’t need the first receive-create instance. 

 

Tony:      That is Okay for the seller end, what about the buyer end.

 

Nick:      What is exactly the issue 99?

 

Tony:      Allowing invoke to be a start activity, is it not?

 

Nick:      It’s exactly what Satish said a few minutes back, its really allowing you not have receive-create instance as the first thing.

 

Satish:   It’s basically saying that there are sometimes processes that do not have explicit create instance mechanisms.

 

Tony:      So that means we need to allow in an abstract process, that is the first thing you need to see is a send.

 

Satish:   Potentially yes.

 

Nick:      But not necessarily.

 

Tony:      No the other end or the counterparty, needs to start off with a receive.

 

Satish:   But what is the problem you are seeing Tony?

 

Tony:      I thought in current BPEL you are allowed to start with a receive but you are not allowed to have an invoke as the first real activity.

 

Satish:   Correct, and you will not be allowed to do that in executable processes, only in abstract processes, where you are not explicitly defining everything anyway.

 

Alex:      Assume we will have opacity, in the abstract BPEL; basically, the opaque activity will be the starting activity.  After the opaque start activity, there will be an invoke say from the buyer to the seller. The opaque will be the start activity.

 

Tony:      The question is then what did the opaque buy you? It is an artificial thing which we put in because we can not allow a process with an invoke. So to not allow that rule, we said we would put opaque there that could be hiding something which was an allowed start activity.

 

Nick:      I think the main issue is the second point Satish was mentioning what exactly are the semantics of opaque.

 

Alex:      The main advantage of opaque is to simplify, it does not require us to define tons of differentiation between executable and abstract BPEL. It helps to simplify our job. I also helps people who understand executable BPEL to do things in abstract bpel without worrying about tons of exceptions and special cases.  I would also like to follow-up with Satish about a point raised. If opacity is the only extension point, what are the good sides and the bad sides? I am still trying to decide if opacity is a good thing.

 

Phil:       I have two comments: We need to address other issues. My second comment is “One thing Yaron said to you yesterday was that I could use opaque sometimes but don’t have to always use it when I leave things out.” This appears to be a hybrid. It appears to me that if you are going to leave things out you should always use opaque. Then a person knows you are leaving things out purposefully.   If we use a hybrid, we are not gaining a little protection but I would consider we have lot less protection because we are now leaving it up to the reader to decide if we purposefully left things out. My feeling is if you are going to bite the worm you must eat the whole hook.

 

Satish:   I was going to address that. Look at things from two points of view. Going back to what Alex said about tons of special rules.  What you are really saying is, “I don’t want to complicate the schema.” In other words it’s about the syntactic differences. The other aspect, when viewed from the perspective of Rosetta-Net, I’m saying this is a Buyer’s abstract process, do you feel comfortable saying these are the only places you can extend, and these are the only places where you can insert private behavior? The answer is no. Therefore you cannot say opaque is the only places where extensions can happen unless you put opaque everywhere?

 

Phil:       I feel that when an abstract BPEL process leaves the developer, it should be complete. If you don’t do that, you are left with the same issue of trying to second guess the developer about his intentionality relative to what was left out.

 

Satish:   The person writing an abstract process is NOT a developer.  The person defining the public behavior of a buyer or seller is not developing the buyer’s process at all. They are simply saying from the seller’s point of view the buyer public of visible behavior must have these features or characteristics.  They are saying nothing about the buyer’s process in an executable sense. Thus it is not possible for the Rosetta-Net standards committee to say the buyer’s process needs to be completed at these points because they do not know who the buyer is or what they do. Therefore they need to have extensions everywhere; therefore you would have to place explicit opaque everywhere or you have to go back to Yaron’s argument which is about syntactic completeness which gets you to the hybrid place which you don’t like.

 

Nick:      That’s why the black, white and grey aspects of opaque needs to be discussed.

 

Phil:       There are still two issues I’d like to raise. First, is John here? If so, we would like to discuss your abstract BPEL use case. The question I have for the group, does anyone have any questions for John relative to the use case provided or the BPEL written?  No response… I have a comment. There should be some real non-functional requirements associated with the procedural section of the use case.

 

John:      I’ll take a wack at it.

 

Phil:       I guess if there are no other issues, the meeting is over. The action items assigned already should still be addressed.

 

Tony:      I think one of the things we could do is make a few brief statements of what abstract processes are or can do. I gave a few example in the mail I sent. Should discuss this as a group and achieve agreement. Then we can see if there are a lot of differences.

 

Phil:       You did raise an interesting point. Last week I asked for a list of must-haves. I was wondering if it would be appropriate if we could go around and have each of us define a list of requirements. We can come up with own use cases without waiting for the original authors.

 

Nick:      If Ivana could elaborate on her use case that would be appreciated. What Ivana failed to say why what was missing is important to us.

 

Sally:     I wouldn’t want to list requirements in real-time. I need to think about them before I give them.

 

Phil:       Please provide your requirements before the face-to-face.

 

Diane:    I would like this group to put a stake in the ground. 

 

Phil:       Sally, can I count on you for some help?

 

Sally:     Yes.

 

Nick:      Why not have the people who created the issues get 10 minutes to describe their issues? 

 

Diane:    I was hoping we could have summery statements relative to these issues from this group. We cannot boil the ocean. We need to put our best foot forward. Abstract BPEL will be a normative part of the F2F meeting.

 

Phil:       I think we are making progress. From Satish’s perspective, it seems 99 and 107 may be addressed by the hybrid approach.

 

Diane:    We may not get consensus.

 

Nick:      Do you think it may not be realistic to expect to solve all of these problems by the f2f?

 

Diane:    We will dedicate a good chunk of time to abstract bpel.  If you can articulate different models for abstract bpel, that would be great.

 

Tony:      You don’t want to force a vote too early. We should come up with bullet points for how we can use abstract processes/bpel.  That will help us to focus on the issues.

 

Phil:       One of the big issues has been just understanding what abstract bpel is. 

 

Diane:    Will the context change as we progress?

 

Nick:      Oracle has committees where we ask them “what are your priorities?” All coming back have be on executable BPEL. When we ask about Abstract BPEL, they don’t get it.  Maybe abstract bpel is premature and we should drop it out. Because, I feel we do not want to take this extreme position, we are trying to gain a deep understanding about it. Maybe we should take it out of the spec and leave it for the next release.

 

Diane:    We need to be careful about over engineering and boiling the ocean.

 

Phil:       I agree with you. I think we will be getting something out for the f2f. We need something concrete to look at and discuss. The action items that we have been dragging around will be addressed.

 

 

End of meeting for today. Call next Friday.