I think (after Michael Rowley convinced me with his
argument on the call) there is no need to standardize the search
order. Instead, we could do the following:
a>
Start with the text: A componentType document for a BPEL process definition can be
found by using either 'QName matching' or 'contribution URI matching' mechanisms.
When a componentType document can not be found by using either of these
mechanisms, the SCA infrastructure MUST implicitly generate a componentType
document based on the introspection of the implementation BPEL process
definition
b> Describe the two
mechanisms of finding componentType
-- Sanjay
From: Alex Yiu [mailto:]
Sent: Thursday, Jan 17, 2008 15:20 PM
To: Anish
Karmarkar
Cc: Michael Rowley; OASIS BPEL; Patil, Sanjay;
Subject: Re: [sca-bpel] Issue 2 - Does the spec
allow a componentType side file?
Hi, all,
Michael Rowley's latest proposal for
Issue 2: written in the SCA-BPEL chat room this morning (together with
Dieter's correction in <implementation.bpel> syntax):
SCA finds the ComponentType for a BPEL process named
"foo:bar" by finding any ComponentType document that has
<implementation.bpel process="foo:bar">, wherever it might be within
the contribution. While the assembly specification allows
<implementation.bpel> to be absent, for SCA BPEL, the component type
MUST include an <implementation.bpel> element.
Michael Rowley wrote earlier in the chat room before his
latest proposal, as describe how to locate a componentType file similar to
Java C&I spec:
If <implementation.bpel> is not present, then
the component type has to have a contribution URI that is identical to the
contribution URI except that the extension has to be changed to
".componentType".
I would still prefer keeping the semantics
of locating a componentType by URI, if a componentType file with a matching
QName is not found.
Here is my attempted to consolidate these two
pieces of text together: (I prefer separating normative text and example
in difference sentences also. And, I would like to describe how to handle
error cases)
SCA Infrastructure MUST find the ComponentType for a BPEL
process (which is identified by a QName) by locating any ComponentType
document that has an <implementation.bpel> refers to the same process
QName, wherever it might be within the contribution. For example, if a
componentType document has an <implementation.bpel process="foo:bar">,
it will be considered a match for a BPEL process identified by "foo:bar"
QName (presumbly the prefix "foo" in both documents are resolved to the same
namespace.). During such a QName-based matching between componentType and
BPEL process, if a non-one-to-one relationship is found (e.g. one-to-many or
many-to-one), SCA Infrastructure SHOULD signal this error to its users.
If a componentType document cannot be found through this QName
matching mechanism, then the SCA infrastructure MUST try to locate the
componentType document by using a contribution URI that is identical to the
contribution URI of the BPEL process except of that the extension has to be
changed to ".componentType". For example, if "file:/scratch/dir1/compositeX/Foo.bpel"
is the contribution URI of a BPEL process, then the contribution URI of a
matching componentType document would be: "file:/scratch/dir1/compositeX/Foo.componentType"
If
a componentType document cannot be found through either QName matching or
contribution URI matching mechanism, SCA infrastructure MUST implicitly
generate a componentType document based on the introspection of the
implementation BPEL process definition.
I am using
"SHOULD" for the error case so far, because I am not sure how other parts of
SCA spec handle user errors.
Any fine tuning of the language is very
welcome.
Thanks!
Regards,
Alex Yiu
Anish
Karmarkar wrote:
Michael Rowley
wrote:
The assembly spec currently says: "The
location of the component type
file depends on the type of the
component implementation: it is
described in the respective client and
implementation model
specification for the implementation type."
In my opinion, the SCA BPEL spec should define _how_ to find a
component
type side file for a BPEL process, rather than _where_ to
find them.
This is based on the fact that we don't typically use
locations to refer
to XML definitions.
<implementation.bpel> and
<implementation.componentType>
both refer to their implementations by
QName, not by a location.
Therefore, I think that we should say that SCA finds the
ComponentType
for a BPEL process named "foo:bar" by finding any
ComponentType document
that has <implementation.bpel
qname="foo:bar">, wherever it might be
within the contribution.
That would mean that the implementation and CT side
file can be decoupled with a potential for many side files to exist for the
same implementation. This would mean that which CT side file gets picked up
depends on the resolution mechanism used by the implementation. This will
give rise to portability problems.
The Java C&I says:
"A
component type can optionally be specified in a side file. The component
type side file is found with the same classloader that loaded the Java
class. The side file must be located in a directory that corresponds to the
namespace of the implementation and have the same name as the Java class,
but with a .componentType extension instead of the .class extension."
Why can't we have a similar rule for BPEL: that it be located in
same directory as the bpel file.
Since we'll be discussing this
issue on the call today, I thought I'll list the subissues that I see within
issue 2:
1) how/where the CT side file is found/located
2)
extend the /componentType/service and componentType/reference syntax to
include partnerlinks (providing the ability to override defaults)
3)
compatibility between CT side file and introspected CT. This is more of an
assembly issue, but we need to agree on how defaults are treated.
4)
Allow the same info to be specified in a side file as well as inlined. This
would require new BPEL extensions for service/refs a la multirefs and
properties.
-Anish
--
<snip/>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
