OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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 sidefile?



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
 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, Jan 17, 2008 15:20 PM
To: Anish Karmarkar
Cc: Michael Rowley; OASIS BPEL; Patil, Sanjay; ALEX.YIU@oracle.com
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:
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]