OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 36: How is the introspected CT merged/overridden by CT sidefile ?

We allow CT to be introspected as well as specified as a side file.
In the BPEL TC there was a discussion about what happens if there is a 
side file. Does the side file override completely the introspected CT or 
does the side file modify the introspected CT.

I'm starting a thread here, since this discussion really belongs to the 
assembly TC and issue 36 is about this.

First the easy part:

I think most (if not everyone) would agree that a CT side file cannot 
include whatever it wants. It has to be supported by the implementation. 
A side file can only "narrow" what is offered by the introspected CT. By 
"narrow" I mean the same as what is called "projection of the CT as 
scoped by the constrainingType" in the Constraining Type section. So a 
side file cannot:
1) add any new property, service or reference that is not present in the 
2) change an interfaces to include additional methods
3) change a required property to optional
4) expand the cardinality of a reference
5) remove an intent

The trickier part:

If there is a side file specified, should it contain the whole truth or 
only the partial truth? Partial truth here means that the information 
from the introspected CT is "merged" with the information from the side 
file. And "merged" here means unless the side file has something to say 
about the service, reference or property it remains in the merged or 
effective CT unaltered. I.e., a side file can only modify a 
service/reference/property, it cannot remove it from the CT.

There are use cases, where an implementation provides for N services (N 
being large) and you want to constrain the implementation to just a few 
services using a side file.

There are use cases, where an implementation provides for N services (N 
being large) and you want to just tweak a few services (perhaps add 
intends to the services or narrow the interface associated with the 

If side file contains the whole truth then the 1st use case is very easy 
to achieve. The second use case, requires you to list all the N services 
in the side files; painful but still possible.

If the side file contains only the partial truth, the second use case is 
very easy to achieve. The first use case is not possible.

[MikeE: you had suggested on the BPEL call that we can use a 
constrainingType for use case 1 and use the 'partial truth' solution. I 
looked up the assembly spec and that does not work. A constraining type 
when used on an implementation provides the minimum set of things it 
must provide for. An implementation is still allowed to (and it would 
show up in the effect CT of that impl.) have additional services, 
references, properties]

There are two ways out of this:

1) say that the side file, if present and supported by the 
implementation type, contains the whole truth. This makes use case 2 
difficult, though still possible. It does keep the whole thing simple. 
Either you look at the side file and know everything or you have some 
way to introspect the implementation. No merge is ever required.

2) provide a flag on the CT side file to say whether it is the whole 
truth or the partial truth. This makes both use cases easy to achieve. 
But put extra burden on the sca runtime implementations and requires one 
to do a merge if the CT side file asks you to. It is also harder for Joe 
Programmer to figure out the effective CT without tools.

 From a simplicity POV I prefer (1). I suspect that tools will allow you 
to spit out an introspected CT as a side file which you can edit to 
achieve use case 2.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]