OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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

- 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

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


[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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]