Re: [sca-bpel] Issue 2 - Does the spec allow a componentType sidefile? Some observations

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

I'm not worried about keeping the CT clear of any metadata that directly 
relates to the implementation artifact. The CT file *is* specific to an 
implementation so I don't see a problem with 'labeling' the CT to say 
something BPEL specific or point to the process QName.

What I'm worried about is complexity and portability. For most cases 
locating the bpel file and CT file in the same directory won't be a 
problem. For those cases where it cannot be colocated (for whatever 
reason), I would prefer to see a deterministic way to figure out the 
location of the CT file. Perhaps by specifying the path in the 
sca-contribution.xml file. Allowing the CT file to be located anywhere 
but disallowing > 1 CT files for the same BPEL process, would create a 
rule that won't be enforced by implementations, but will result in very 
different behaviors on different platforms if broken.

 >Anish has also brought up the value of having the component type
 >_override_ information that is in the implementation, and several of
 >us, myself included, thought that this sounds like a valuable
 >capability.

To be clear, I favor having the ability to override *defaults*. Not 
override things like sca-bpel:property or sca-bpel:multiReference. Such 
an override should result in an error.

-Anish
--

Mike Edwards wrote:
> 
> Folks,
> 
> Some comments inline.
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
> Email:  mike_edwards@uk.ibm.com
> 
> 
> *"Michael Rowley" <mrowley@bea.com>*
> 
> 18/01/2008 15:43
> 
> 	
> To
> 	Mike Edwards/UK/IBM@IBMGB, "OASIS BPEL" <sca-bpel@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [sca-bpel] Issue 2 - Does the spec allow a componentType side file? 
> Some observations
> 
> 
> 	
> 
> 
> 
> 
> 
> Mike,
>  
> Regarding your general comment that you believe that component types are 
> should “only be used in rare cases where it is not possible to derive 
> all necessary information through inspection of the implementation 
> artifact”....
>  
> There is interesting difference between BPEL and C++ or pre-annotation 
> Java is that BPEL uses XML for its syntax, and the schema for that XML 
> explicitly allows extensions.  This means that it is always possible to 
> specify all of the information necessary for the component type in the 
> BPEL file.  So, given this, why have component types?  The answer is for 
> specifying default bindings, targets and policies that a developer might 
> not _/want/_ to specify within the BPEL file.  In fact, a different 
> person might be in charge of developing the BPEL process from the person 
> who is developing the “SCA view” of that process.   Or, if not a 
> different person, perhaps a different tool.
>  
> Anish has also brought up the value of having the component type 
> _/override/_ information that is in the implementation, and several of 
> us, myself included, thought that this sounds like a valuable capability.
> 
> *<mje> I'm lukewarm about this capability.  It introduces complexity for 
> little real benefit.  I note that defaults can be overridden in the 
> configuration of a component that uses the*
> *BPEL process as its implementation. </mje>*
>  
> This gives component types a bit of a different flavor from one of just 
> a “necessary evil”.
> 
> *<mje> I don't agree that the functionality that's described is 
> particularly useful - it can be achieved simply in other ways </mje>*
>  
> Now, regarding how you find the implementation that a component type 
> corresponds to – yes, it is possible to do this by the name of the file 
> of the component type.  Personally, I find this awkward.  I think it is 
> bad design for an artifact (the component type) to be fundamentally tied 
> to another artifact (the implementation) and yet for it not to record 
> that fact.  Depending on the location of component type means that 
> whenever you look at a component type, you need to know where it came 
> from in order to make any sense of it.  If you were to copy it into a 
> registry, for example, it would no longer make sense unless you added 
> the information about where it came from.
> 
> *<mje> I can agree with your point about a registry.  My concern is that 
> having to add labels to the componentType files adds overhead.  Perhaps 
> I shouldn't worry so much as I think that the use of componentType files 
> will tend to be rare - I consider that many developers will find it hard 
> enough to stomach composite files let alone another parallel set of XML 
> files. Adding a few extra elements in the BPEL looks trivial by 
> comparison.</mje>*
>  
> In the early days of Java, I worked in a development environment which 
> assumed that the generated .class files would be in the same directory 
> as the .java files (which is the default).  In many cases this is just 
> the wrong organization of files – but the developers of this environment 
> thought that they knew better about what would be “easy”.  They were 
> wrong.  I believe that we should not make the same mistake.
> 
> *<mje> I can see this point.  However, in Java the files are not tied to 
> each other by labels.  They use a convention about filenames.  The 
> location of the files can be varied, and this is typically done by the 
> tooling used to handle the files, such as Eclipse.  Perhaps I can learn 
> to be less worried about the actual location of the files, but the 
> labelling just looks like some overhead to me. </mje>*
>  
> These are my reasons for wanting the approach represented by my motion 
> at the end of the last meeting, although in the interest of compromise, 
> I could imagine supporting a mixed approach, along the lines of what 
> Alex has proposed.
> 
> *<mje> Mixtures may be the worst of all worlds.  Two ways of doing 
> things to understand - plus the need to know which one(s) your runtime 
> and tooling will use.  I think that I'd prefer one approach rather than 
> 2.  Supporting 2 seems like trying to cop-out of making a decision </mje>*
>  
> Michael
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Mike Edwards [mailto:mike_edwards@uk.ibm.com] *
> Sent:* Friday, January 18, 2008 7:03 AM*
> To:* OASIS BPEL*
> Subject:* Re: [sca-bpel] Issue 2 - Does the spec allow a componentType 
> side file? Some observations
>  
> 
> Folks,
> 
> Watching the debate on this issue, I wonder if we are collectively 
> losing sight of the big picture here.
> 
> Let me start by giving my viewpoint, since it will colour the rest of 
> what I have to say.  I take the view that
> componentType files are a necessary evil, only to be used in rare cases 
> where it is not possible to
> derive all the necessary information through introspection of the 
> implementation artifact(s) (Note [1])
> 
> In general, developers do not thank us for creating ever more files for 
> them to deal with and I think
> that SCA in general should try to keep files beyond the implementation 
> artifacts to a necessary minimum.
> 
> 
> - Having said that, I argue that an SCA BPEL runtime should handle 
> things FIRSTLY by introspecting the
> BPEL process document.  I would encourage the idea that IF "pure" BPEL 
> is not sufficient to unambiguously
> define the componentType of the process, then it is valid and useful to 
> add SCA metadata to the process
> to remove the ambiguity.  This I view as a close equivalent to the SCA 
> annotations for a Java class.
> 
> FOR the (hopefully rare) case where there is the need to provide 
> additional componentType metadata
> separately from the BPEL process itself, I argue that we should again 
> keep this as simple as possible.
> 
> - The general design for componentType files (for any type of 
> implementation) currently keeps those files
> clear of any metadata that directly relates to the implementation 
> artifact.  The componentType file that
> relates to a given implementation artifact is handled by filename - it 
> is the filename that is used to establish
> the connection with the implementation artifact.  The location of the 
> file relative to the implementation
> artifact is then left up to the implementation type specification to 
> decide.
> 
> In the debate on this issue, it is clear that there is a desire to move 
> away from this design.  First, there is
> introduction of a concept of a "label" within the componentType file 
> which is used to indicate which
> implementation artifact it relates to.  Secondly, there is a desire to 
> free the location of the componentType
> file, so that it may be in any place within the same contribution as the 
> implementation artifact, but that
> each runtime implementation may choose which location(s) it will scan 
> when looking for componentType
> files.
> 
> - I  note that one effect of these desires is to place implementation 
> specific metadata into the
> componentType file - and I also note that there are other proposals in 
> the BPEL group to put yet more
> metadata specific to BPEL into the componentType files.
> 
> - Examining the "label" concept, it adds a level of extra work, since 
> the label must be added to the
> componentType file and it must point to the appropriate artifact. 
>  However, it does permit the the filename
> of the componentType file to be made independent of the name of the 
> implementation artifact.  It also
> (in principle) allows for multiple <componentType/> declarations in a 
> single file.  I note that this labelling
> could extend to ANY type of implementation artifact, although the 
> details of the labelling would
> necessarily vary  by implementation type.
> 
> - Allowing for variations in the location of the componentType files 
> within a contribution certainly
> affects portability.  A contribution which locates the componentType 
> files in location A may be processed
> correctly by runtime Z, but incorrectly by runtime Y.  Secondly, there 
> is the question of the understanding
> of the developers.  "Skills portability" is perhaps more important than 
> artifact portability.  I suspect
> that developers will find it annoying that the location skips around 
> when they move from runtime Z
> to runtime Y.  This may possibly be masked by tools, but people don't 
> always use tools, especially
> when things go wrong and they start debugging.
> 
> - One aspect I definitely DONT like is the idea that the runtime has to 
> search around the contribution as
> a whole in order to find these componentType files.  They should be in 
> some "well defined" place to
> limit the search space.
> 
> - Another concern is the confusion if BPEL treats its componentType 
> files in a way very differently to
> that for the other implementation types.  It would be best to see a 
> coherent set of changes across all
> implementation types, otherwise developers dealing with mixed assemblies 
> will keep having to
> switch from one way of doing things to another.
> 
> - The latest set of proposals give us "the worst of all worlds" by 
> proposing to allow searching for
> componentType files BOTH by filename and ALSO by label matching.  I 
> don't think that this kind of
> "flexibility" really helps anyone and introduces error cases (filename 
> and label point to different
> BPEL artifacts) - I make a plea for us to make up our minds and have one 
> single consistent
> mechanism.
> 
> OK, so to cut to the chase (sorry I made you read so much to get here) - 
> what do I propose?
> 
> 1) Keep the current mechanism based on location and filename
> 2) Fix the location of the componentType file relative to the BPEL 
> process artifact
> 
> 
> Note:
> 
> [1] I acknowledge that there will be cases such as C++ where even though 
> it may be possible to derive
> all the required information about the implementation artifact, this has 
> to be done at compile & build time
> and that the information so extracted has to be put somewhere by the 
> tools used to do this.  The
> "somewhere" is in fact a componentType file, which as a result is a 
> mandatory element of the handling
> of such implementation artifacts.
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
> Email:  mike_edwards@uk.ibm.com
> 
> ------------------------------------------------------------------------
> 
>  
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
>