Title: Message
+1. I
think we can add some RFC2119 keywords. For example:
"A service MUST
occur in the componentType of a BPEL process for each partnerLink in the process
which ...."
-----Original Message-----
From: Mike Edwards
[mailto:]
Sent: 31 July 2008
09:37
To: OASIS BPEL
Subject: RE: [sca-bpel] Issue 18
proposal and next week's call
Martin,
This is a good
& thoughtful discussion of the issues here.
I have a perspective on this which may help - and which
is equally applicable to similar situations for other
implementation types.
Instead of regarding the componentType of a BPEL
process as being the output of some "generation process", I
view the componentType as an intrinsic aspect of the
BPEL process itself - once you have the BPEL process in your
hand, you already have the componentType. For me
the componentType is a set of declarative statements relating
to the BPEL process that say what elements in the
componentType arise from features of the BPEL process itself.
Taking this view, the piece of code that
might be run against a particular BPEL process to obtain its
componentType,
- and the timing of
running that code - is completely irrelevant. The componentType is
always there, it is only a question
of
getting at it.
Looking at it this
way:
1. conformance statements can
be limited to simple ones along the lines "SCA runtimes MUST interpret the
componentType
of a BPEL process as
defined in section 2"
2.
statements concerning the componentType itself can be stated as simple facts
or rules:
"A service occurs in the
componentType of a BPEL process for each partnerLink in the process which
- has a sca-bpel:service
annotation
- if a static
analysis of the process determines that it is possible that the first message
for the partner
link will be
received in a <receive> activity, the <onMessage> element of a
<pick> activity or the
<onEvent> element of an event handler
A reference occurs in the componentType of a BPEL
process for each partnerLink in the process which
- has a sca-bpel:reference annotation
- if a static analysis of the process determines that
the first message for the partner link will not be received
in a <receive> activity, the
<onMessage> element of a <pick> activity or the
<onEvent> element of an event
handler"
Tests for
componentType can be derived through the consequences of the componentType -
ie when you have a component
which
uses the BPEL process as an implementation, then the configuration of the
component depends on the componentType
of the implementation. Tests consisting of various component
configurations using a suitable BPEL process should be able to
catch conformance issues.
Yours, Mike.
Strategist
- Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly
TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
Britain.
Phone & FAX: +44-1962-818014 Mobile:
+44-7802-467431
Email:
"Martin Chapman"
<>
29/07/2008 08:34
To
<>
cc
Subject
RE: [sca-bpel] Issue 18 proposal
and next week's call
For sake of convenience I have attached a pdf version of Mike R's
proposal with added line numbers.
Since the call last week I took a
step back to try to understand what we are trying to define,
which would
help me elucidate my concerns about the proposed text. Words like Runtime
and
generation in the same rule make me very nervous. Initially I was
trying to find an alternative to
the word generate that might more
accurately reflect what a runtime has to do, but finding a
substitute is
not easy.
To me the problem starts at the beginning of section 2
(lines 180 thru 197). This text introduces
the concept of a component
type and ends on line 197 by saying "The Component Type MAY be
generated
from a WS-BPEL process definition by introspection." Also line
217 has a similar sentence on
generating a component type
However
nowhere does it state when the component type should be generated, and
Assembly doesn't say
much on this subject.
I have always assumed that
in order to assemble and configure, one needs to know the component type
at
design time prior to any runtime involvement. In this case, one must know the
services and
references of a BPEL implementation in order to do design time
wiring. Whether generated or not,
the rules of section 2.1 should be obeyed
e.g. it would be invalid to define a component type with
a reference, if
the related BPEL activity is a receive. Furthermore, one is also allowed to
define
a component with a BPEL implementation without the need for a
component type, and in this case as
well the rules of 2.1 should be obeyed
IMHO.
Without a common understanding of the use cases we are
supporting, and an understanding of where in
the lifecycle artifacts are
needed, finding the right words in section 2.1 is going to be
tough.
What I think we need to do is define the relationship rules between
BPEL and Assembly, regardless
of whether it's a component or a component
type, and then decide at what point in the lifecycle the
definitions must
be available, whether they can be generated or not, and whether we have to
mandate
what generates them.
I propose we start the discussion on
Thursday by reviewing the use cases we are supporting and any
assumptions
we have, before diving into the wording
details.
Cheers,
Martin.
>
-----Original Message-----
> From: Anish Karmarkar
[mailto:]
> Sent: 25 July 2008 23:00
>
To: OASIS BPEL
> Subject: [sca-bpel] Issue 18 proposal and next week's
call
>
>
> As promised on this week's I'm sending this
email.
>
> Issue 18 proposal from Michael is located at:
>
http://lists.oasis-open.org/archives/sca-bpel/200806/doc00001.doc and
>
was sent in the email at
>
http://lists.oasis-open.org/archives/sca-bpel/200806/msg00002.html
>
> This is the proposal that is called revision 5, but should be really
> called sca-bpel-1.1-spec-cd01-18proposal.doc (or something like
that).
>
> Homework: please read this proposal and send
>
feedback/opinions/changes/alternate proposals by email before next
>
week's call.
>
> We only have one issue to discuss next week and
that is issue
> 18. This
> issue along with Michael's proposal
(and other proposals, if
> any) will
> be included in the agenda
for next week.
>
> After next week's call we'll go into
aestivation for all of
> august. It
> would be nice if we could
resolve issue 18 as it applies to
> section 2.1.
> If we resolve
it for 2.1, we can then assign an AI to the editors to
> take that
forward to the other sections.
>
> Thanks.
>
>
-Anish
> --
>
>
>
---------------------------------------------------------------------
>
To unsubscribe from this mail list, you must leave the OASIS
> TC that
generates this mail. Follow this link to all your
> TCs in OASIS
at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>
oups.php
>
>
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. Follow this link to all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM
United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
