[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Fw: [bpel-dev] Resolvers [of Roles] and other things ...
|
Hi Michal,
Re "Partner activities have portType set as an optional attribute derived
from the partnerLinkType/Role combination, right?":
IMHO if the editor sets that attribute it should derive it from the
partnerLinkType/Role. But what happens if the portType in the
partnerLinkType/role is changed? Will that update the portType attribute of
the message activity, too? I think not. So there is a need for validation
to check the following:
"[SA00005] If the portType attribute is included for readability, the value
of the portType attribute MUST match the portType value implied by the
combination of the specified partnerLink and the role implicitly specified
by the activity (see also partnerLink description in the next section)."
(see chapter 5.2)
IMHO this includes the case that there are duplicate definitions for the
portType and the partnerLinkType/role refer to the one definition and the
activity to the other. The portTypes do not match in this case.
Re "2) when a partner activity has portType and operation set, that
portType and operation might come from another WSDL (imported by the
partnerLinkType WSDL).":
As said before IMHO for that portType / operation the BPEL needs an own
import. The WSDL import can't be used for resolving the portType /
operation referenced in the BPEL.
Re "So the problem is that "visibility"of portType in one instance is via
the partnerLinkType definition and WSDL imports and in the other case it is
via the BPEL imports.":
Right. IMHO for both cases a separate resolver is needed.
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>
14.08.2006 20:11 Subject
Re: Fw: [bpel-dev] Resolvers [of
Roles] and other things ...
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
Thomas,
Thanks for following up on this one.
I circled with Alex on this one, and it appears that classic argument here
is that:
Partner activities have portType set as an optional attribute derived from
the partnerLinkType/Role combination, right ?
Partner activities have operation set mandatory attribute ... , right ?
The variables can be defined to be of a message type, right ?
So the argument goes ...
1) if a partnerLink is defined of partnerLinkType there must be BPEL
import for the WSDL containing the partnerLinkType. That's the obvious
part.
2) when a partner activity has portType and operation set, that portType
and operation might come from another WSDL (imported by the partnerLinkType
WSDL).
So the problem is that "visibility"of portType in one instance is via the
partnerLinkType definition and WSDL imports and in the other case it is via
the BPEL imports.
So which way is the right way ? Does the mere inclusion of the portType in
the parter activity merits a BPEL include ?
It seems to me that resolving linked entities will have to lead a double
life in the designer code base.
-michal
Thomas Schulze wrote:
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
--
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
