Re: [sca-bpel] Issue 2 - Does the spec allow a componentType side file? Someobservations

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:  

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