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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS BPEL" <sca-bpel@lists.oasis-open.org>
- Date: Mon, 21 Jan 2008 17:26:57 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]