Hi Michal,
I've found an additional paragraph in section 6.1 talking about that
problem:
"The extensibility mechanism of WSDL 1.1 is used to define
<partnerLinkType> as a new definition type to be placed as an immediate
child element of a <wsdl:definitions> element. This allows reuse of the
WSDL target namespace specification and its import mechanism to import
portType definitions. The <partnerLinkType> definition can be a separate
artifact independent of either service's WSDL document. Alternatively, the
<partnerLinkType> definition can be placed within the WSDL document
defining the portTypes from which the different roles are defined."
IMHO the one sentence "... and its import mechanism to import portType
definitions." indicates that the BPEL imports should not be used to resolve
the portType of the role.
Additionally consider that each artefact must be valid by itself. If a WSDL
can only be valid when used in the context of a special BPEL process this
wouldn't be true any longer.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
----- Forwarded by Thomas Schulze/Germany/IBM on 14.08.2006 13:26 -----
Thomas
Schulze/Germany/I
BM To
"BPEL Designer project developer
11.08.2006 13:10 discussions."
<bpel-dev@xxxxxxxxxxx>
cc
Alex Yiu <alex.yiu@xxxxxxxxxx>,
"BPEL Designer project developer
discussions."
<bpel-dev@xxxxxxxxxxx>,
bpel-dev-bounces@xxxxxxxxxxx
Subject
Re: [bpel-dev] Resolvers [of Roles]
and other things ...(Document link:
Thomas Schulze)
Hi Michal,
I'm sorry for the delay.
I'm mainly referring to chapter 5.4 Document Linking (as you point it out
below):
"... However, documents (or namespaces) imported by an imported document
(or namespace) MUST NOT be transitively imported by the WS-BPEL processor.
In particular, this means that if an external item is used by a WS-BPEL
process, then a document (or namespace) that defines that item MUST be
directly imported by the process; observe however that this requirement
does not limit the ability of the imported document itself to import other
documents or namespaces. The following example clarifies some of the issues
related to the lack of transitivity of imports.
Assume a document D1 defines a type called d1:Type. However, d1:Type's
definition could depend on another type called d2:Type which is defined in
document D2. D1 could include an import for D2 thus making d2:Type's
definition available for use within the definition of d1:Type. If a WS-BPEL
process refers to d1:Type it must import document D1. By importing D1 the
WS-BPEL process can legally refer to d1:Type. But the WS-BPEL process could
not refer to d2:Type even though D1 imports D2. This is because
transitivity of import is not supported by WS-BPEL. Note, however, that D1
can still import D2 and d1:Type can still use d2:Type in its definition. In
order to allow the WS-BPEL process to refer to d2:Type it would be
necessary for the WS-BPEL process to directly import document D2."
What does the second paragraph mean? IMHO it means the process can contain
a variable referencing d1:Type but not a variable referencing d2:Type. If
the process wants to declare a variable referencing d2:Type the process
must import D2. If D2 is not imported, it still can be used in d1:Type.
Carried forward to your scenario it's the same when the process only
references the partnerLinkType in a partnerLink, but the process itself
does not reference the portType or an operation from that portType. If the
process needs to reference the portType or an operation from that portType
the process must import the second WSDL, too.
Observe that the said only applies to the stuff contained in a .bpel file.
The partnerLinkType is not contained in a .bpel file it's located in a
.wsdl file. IMO for partnerLinkTypes only the WSDL imports are interesting,
means if the partnerLinkType refers to a portType outside of the current
WSDL artefact, the WSDL artefact containing the portType must be imported.
This means for your example:
WSDL-A (does not define portType ns1:Port)
....
<plnk:partnerLinkType name="P1">
<plnk:role name="requester" portType="ns1:Port"/>
</plnk>
....
WSDL-B
...
<wsdl:portType name="Port">
....
</wsdl>
Case 1: WSDL-A does not import WSDL-B and both WSDL-A and WSDL-B are
imported by the bpel process.
Can partnerLinkType be resolved then?
The bpel process can resolve the partnerLinkType because WSDL-A is imported
in the process. In case the process references the portType from WSDL-B it
can be resolved, too, because WSDL-B is imported in the process. But the
portType referenced in the partnerLinkType can't be resolved because WSDL-B
is not imported into WSDL-A.
Case 2: WSDL-A imports WSDL-B. Only WSDL-A is imported by the bpel
process.
Can partnerLinkType be resovled then ? WSDL-A is linked to WSDL-B by an
import, but imports are not supposed to be followed, right ?
The bpel process can resolve the partnerLinkType because WSDL-A is imported
in the process. The portType referenced in the partnerLinkType can be
resolved in this case, too, because WSDL-A imports WSDL-B. But if the
process references the portType or an operation from that portType, that
references can't be resolved, because the WSDL-B is not imported in the
process.
Hope this helps.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
bpel-dev-bounces@xxxxxxxxxxx, Alex
Yiu <alex.yiu@xxxxxxxxxx>
02.08.2006 23:38 Subject
Re: [bpel-dev] Resolvers [of Roles]
and other things ...
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
Hey Thomas,
Read below ...
Thomas Schulze wrote:
Hi Michal,
IMHO there shouldn't be a problem, but it might be that I have not get
your
point correctly. So please let me know if this is the case.
I think the BPEL must import both WSDLs and the WSDL containing the
partnerLinkType (WSDL1) must import the WSDL containing the portType
(WSDL2). The resolution mechanism resolving the portType referenced in
the
role must only consider the import in that WSDL and must not consider the
imports in the BPEL.
And where is this stated ? Is this stated someplace in the
partnerLinkType semantics ?
The BPEL must import WSDL1 because the partnerLinkType is referenced from
a
partnerLink. And it must import WSDL2 if the partnerLink is used in one
of
the message constructs. This construct MAY reference the portType but it
MUST reference the operation.
Agreed.
So, when the user models the partnerLink and partnerLinkType this must
create an import in the BPEL to WSDL1 and an import in the WSDL1 to
WSDL2.
When the user creates the message activity this must create an import in
the BPEL to WSDL2.
Agreed. But ...
I think we should not introduce such a switch. IMHO this would result in
a
process which is not BPEL 2.0 compliant.
This just seems like the counterintuitive thing to do (not do follow the
imports) or for that matter having the tool unfold them anyway to
include them in the BPEL imports. Just sounds like the wrong decision to
me, and I thought we could have switch for that.
http://www.oasis-open.org/apps/group_public/download.php/18714/wsbpel-specification-draft-May17.htm
The section on imports talks about imports not being transitive. They
specifically not talk about WSDLs and partner links in that case but
about XSD types.
(This is the section about document linking).
If what you are saying below is right, then WSDL imports and XSD imports
have different semantics on resolution (you MUST not resolve types by
following imports, yet you MAY resolve port type on partner link types
that way). Is that the right way to go ?
By having a several XSD imports of the same namespace you are creating a
"type" system for that namespace. From a resolution perspective, if a
variable has type T1 that type can reside in any of the imported XSD
files (so you search the bpel imports here but not any of the xsd
imports inside those xsds).
Isn't the same true for PortType of a PartnerLinkType ? (that it can be
defined in any WSDL imported by the BPEL processes, not necessarily by
the imported/included WSDL of the WSDL where the partnerLinkType is
defined ? The port type is just a QName ...
By way of example:
WSDL-A (does not define portType ns1:Port)
....
<plnk:partnerLinkType name="P1">
<plnk:role name="requester" portType="ns1:Port"/>
</plnk>
....
WSDL-B
...
<wsdl:portType name="Port">
....
</wsdl>
Case 1: WSDL-A does not import WSDL-B and both WSDL-A and WSDL-B are
imported by the bpel process.
Can partnerLinkType be resolved then ?
Case 2: WSDL-A imports WSDL-B. Only WSDL-A is imported by the bpel process.
Can partnerLinkType be resovled then ? WSDL-A is linked to WSDL-B by an
import, but imports are not supposed to be followed, right ?
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Michal
Chmielewski
<michal.chmielews
To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org
cc
Subject
02.08.2006 04:14 [bpel-dev] Resolvers [of Roles]
and
other things ...
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
I have stumbled on this today and want to make sure that we are straight
on this:
1) When it comes to resolving Role for example (when you have to find a
PortType for it), it is perfectly reasonable that the port type be not
in the same WSDL (and hence definition) as the partner link. It may be
in an imported WSDL, as an example. So the resolve code ought to
consider this ...
2) .... however, in BPEL 2.0, it is mandated that the import of every
WSDL and XSD be present in the BPEL source file and that transitive
importing or searching not be be done when resolving objects ...
3) .. and doing 2.0 by the book the resolution would have to follow the
bpel:imports from the BPEL file anyway.
which is kind annoying. Our BPEL spec guy here says this is the most
annoying thing about 2.0 BPEL.
So, I wanted to make sure that we make this behavior switchable: on/off.
And in addition, object resolution ought to follow the bpel imports path.
Now clearly, there is an ordering here, so shell we assume that ...
1) bpel imports are done first
2) then wsdl/xsd imports if switched on ?
Any comments welcome.
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
