One Q
inline below ...
From: Michael Rowley
[mailto:]
Sent: Thursday, Jul 31, 2008
7:18 AM
To: 'Mike Edwards'; 'OASIS BPEL'
Subject: RE:
[sca-bpel] Issue 18 proposal and next week's call
I admit that Anish’s
idea of avoiding 2119 MUSTs in the description of the component type is
appealing to me, although it feels a little bit like a
cop-out.
One of the hardest
things for us to deal with is this bit of text from the assembly spec (from
section 4.1):
Component type
information found in the component type file must be compatible with the
equivalent information found from inspection of the implementation. The
component type file can specify partial information, with the remainder being
derived from the implementation.
This means that the
language specs, such as SCA-BPEL, have to describe the part of the component
type that is derived through inspection, but it may not be the actual
component type, since the actual component type will be a combination of the
introspected information and things out of the component type side file.
We really need terms for all three of these: the file, the introspected
information, and the final result. If we have MUSTs regarding the
introspected information, the conformance target (the thing that we test) is
whatever does the inspecting.
<Sanjay> Why don't we
use 'component type information' as the conformance target (similar to
the Assembly spec text quoted
above)? <Sanjay>
Michael
From: Mike
Edwards [mailto:]
Sent: Thursday, July 31, 2008 4:45
AM
To: OASIS BPEL
Subject: Re: [sca-bpel] Issue 18 proposal
and next week's call
Anish,
This is very close to the
thinking I expressed in my previous notes on this issue.
+1
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:
Anish
Karmarkar <>
31/07/2008
01:41
To
Martin Chapman
<>
cc
Subject
Re: [sca-bpel]
Issue 18 proposal and next week's
call
The fact that a
component type as an artifact does not exist for
introspected implementations makes things a little
difficult wrt
conformance
statements.
MikeR in his
previous proposal had 'generator' as a conformance target.
The TC did not like that idea. So
we are stuck with using the targets
specified in the resolution of issue
15.
I noticed that all the
requirement wrt component type are 'MUST's. I'm
wondering if the way to resolve this is to not use RFC 2119
keywords in
the bpel spec when we
talk about component types, but just state them as
facts/assertions. The BPEL spec then would list the rules
(sans 2119
keywords) for the
component type and the actual assertions would be in
the assembly spec. For example we could say in the bpel
spec:
"If a partnerLink
specifies an sca-bpel:reference attribute, then the
component type contains a SCA reference that corresponds to
that
partnerLink. The name of the
reference is the value of the attribute."
The assembly spec would have assertions for SCA runtimes
and SCDL
documents along the
lines of:
The component
configuration in a SCDL DOCUMENT MUST be compatible with
the component type associated
with the component's implementation.
(ignore the specifics of the assembly spec wording, we
don't have to
decide on that
here. That is assembly TC's problem ;-) What is more
important is the concept of having assertions in assembly
spec and rules
in bpel
spec.)
So if there is a SCDL
document that has a component with
<implemenation.bpel ...> in it and the SCDL
configures a reference for
the
component which does not exist in the component type associated with
the BPEL process, a test tool can
point to the SCDL and definitively say
that the SCDL is
non-conformant.
Comments?
-Anish
--
Martin
Chapman wrote:
> 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
---------------------------------------------------------------------
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
