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:
646FFD22D57BD14E9E1051EDBEE28D6E05F13B73@uspale20.pal.sap.corp"
type="cite">
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
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:
478F1D81.6060708@oracle.com" type="cite">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
|