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

[Bryan Aupperle <aupperle@us.ibm.com>]

In C++, there is an attribute on interface.cpp
to indicate which class in a header file defines the interface.  This
attribute is optional, and not needed when the header file only contains
one class.

In C, there is a optional function child
element of interface.c that is used for two purposes.  One is to denote
a function as oneWay or endsConversation, the other is to indicate which
function(s) are part of the interface if there are functions in a header
file that are not part of the interface.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

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/29/2008 05:33 PM

To	Bryan Aupperle/Raleigh/IBM@IBMUS
cc	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Subject	Re: [sca-assembly] Issue 36: How is the introspected CT merged/overridden by CT side file ?

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