[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 implementation. 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 service). 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. Comments? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]