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.

 

This gives component types a bit of a
different flavor from one of just a “necessary evil”.

 

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.

 

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.

 

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.

 

Michael

 

From: Mike
Edwards [mailto:] 

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:  

 

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