Yes. I think we should add a statement to point out the
error case.
-- Sanjay
From: Alex Yiu [mailto:]
Sent: Thursday, Jan 17, 2008 16:40 PM
To: Patil,
Sanjay
Cc: Anish Karmarkar; Michael Rowley; OASIS BPEL;
Subject: Re: [sca-bpel] Issue 2 - Does the spec
allow a componentType side file?
Hi, Sanjay,
Just to clarify:
Do you mean if there
are two componentType documents that are matched (one by URI, or the other by
QName), we will treat that as an error
case?
Thanks!
Regards,
Alex Yiu
Patil, Sanjay
wrote:
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
