Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Resolvers [of Roles] and other things ... 
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."

Back to the top