RE: [sca-bpel] Action item: SCA BPEL conformance statements and component Type

Title: Message

The 
point I was trying to convey is that SCA Assembly defines the rules of CT files. 
Each c+i is constrained by these rules, but these rules do not have to be 
defined in each c+i.

I 
would certainly agree that if we define rules we use RFC2119, but in this case 
the rules are not defined in our spec. Either you have a valid sca bpel 
description, or you don't; if you do have one you will have a valid introspected 
CT file if you want one. Our job is to write the rules for what constitutes 
valid sca bpel, as constrained by the Assembly rules.

 

Martin.

 

  

  
-----Original Message-----
From: Danny van der 
  Rijn [mailto:] 
Sent: 16 September 2008 
  00:46
To: Martin Chapman
Cc: OASIS BPEL
Subject: 
  Re: [sca-bpel] Action item: SCA BPEL conformance statements and component 
  Type

I mostly like this proposal.  But I can't let it 
  go by without trying to change it :-)

A comment on your point 3.  
  You say:

" The bpel spec or any other impl spec will not 
  contain conformance
statements wrt CT, only 
  rules/assertions."

One of the benefits of using RFC 2119 
  language is that it clearly spells out the difference between explanatory 
  text; text that lays out required implementation rules; and text that lays out 
  optional implementation rules.  If we don't use RFC 2119 in describing 
  the "introspected CT rules" then we need to come up with other language making 
  that distinction.  This could come in many forms, but it needs to be 
  intuitive, and the same across all C&Is.  There's already one such 
  form, and it's RFC 2119.  Personally, I think it's a lot easier to use 
  what's there.

Martin Chapman wrote: 
  00c301c9141d$2dfb2290$ 
    type="cite">

    
Myself and Anish had a chat about conformance targets and 
    component types. Here's a summary 
    and
conclusion.

Martin.
-----

WRT component type (CT) 
    there are three cases:

1) There is no CT side file and there aren't 
    any SCA extensions in the
BPEL process
2) There is no CT side file and 
    there are SCA extensions in the BPEL process
3) There is a CT side 
    file.

In case (1), the default rules that we define for the 
    introspected CT
kick in. The introspected CT is the effective CT.
In 
    case (2), the default rules in conjunction with our extension 
    rules
specify what the effective CT will be.
In case (3), the 
    introspected CT is merged/overridden with/by the side
file to provide the 
    effective CT.

SCA has the following as conformance targets (relevant 
    to issue 18):

a) component type side files
b) composite 
    files
c) SCA runtime

We think we should restrict the conformance 
    statements to these targets
and not create new conformance targets that 
    aren't physical artifacts
that you can point to.

We would like to 
    propose that

1) In the assembly spec we define a term 'effective CT' 
    (or something
like that -- the name isn't important). There is already 
    issue 36 [1]
filed in Assembly TC that is meant to address how the CT 
    side file
relates to introspection (subset/override) and essentially what 
    the
'effective CT' will be. In addressing that issue we can define 
    precisely
how the effective CT is calculated from the side file and 
    the
introspected CT, and we can complete the conformance 
    statements
about the relationships between the conformance targets 
    (comonent type side files,
composite file, and implementations)

2) 
    In the assembly spec, we should have conformance statements that
applies 
    to the SCA runtime which say what the runtime MUST/MUST NOT do
given an 
    effective CT.
For example, it would talk about the fact that all services 
    that are
part of the effective CT must be enabled/deployed/made available 
    by the
runtime.

3) In the bpel spec we should define what the 
    introspected CT/default
rules are. These would be definition/rules. Not 
    conformance statements.
The bpel spec or any other impl spec will not 
    contain conformance
statements wrt CT, only rules/assertions.

4) 
    In the bpel spec we should have conformance statement about the 
    BPEL
process. For example: Both sca:service and sca:reference attributes 
    MUST
NOT be present on the same partnerlink in a SCA BPEL 
    process.
These are the rules to produce a valid introspected CT; violate 
    these rules in your source,
and you have an non-compliant 
    source.

In effect, the implementation specs specify (i) rules for 
    introspection
and extensions and (ii) conformance statements that apply 
    to
implementation sources (such as BPEL process). And assembly 
    spec
specifies (i) how effective CT is calculated and (ii) 
    conformance
statements on SCA runtime wrt what it does with the 
    effecttive CT.

[1] http://www.osoa.org/jira/browse/ASSEMBLY-36

---------------------------------------------------------------------
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