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.
Michael
From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
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: mike_edwards@uk.ibm.com
Anish Karmarkar
<Anish.Karmarkar@oracle.com>
31/07/2008 01:41
|
To
|
Martin Chapman <martin.chapman@oracle.com>
|
cc
|
sca-bpel@lists.oasis-open.org
|
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:Anish.Karmarkar@oracle.com]
>> 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