Re: [sca-assembly] Issue 36: How is the introspected CT merged/overriddenby CT side file ?

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Bryan,

How is this indicated to the runtime? In the CT side file? Is that an 
extension to the component type schema?

Thanks.

-Anish
--

Bryan Aupperle wrote:
> 
> For both C++ and C we have mechanisms to indicate that a portion of a 
> header file is used to define a CT (e.g. only specific classes in C++ or 
> specific functions in C are used to define a CT). These mechanisms are 
> optional if restrictions are not needed.
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> Master Inventor
> 
> Research Triangle Park,  NC
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com
> 
> 
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
> 09/23/2008 06:06 PM
> 
> 	
> To
> 	OASIS Assembly <sca-assembly@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[sca-assembly] Issue 36: How is the introspected CT merged/overridden 
> by CT side file ?
> 
> 
> 	
> 
> 
> 
> 
> 
> 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
> --
> 
> ---------------------------------------------------------------------
> 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
> 
>