Subject: Minutes of the
Meeting started:
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.