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
sca-bpel-1.1-spec-cd01-18proposal.pdf
