RE: [ws-dd] Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924

Gil,

 

The "wsdl import" problem I raised is not an issue for policy-based
approach like MOAP because it does not use <wsdl:import>. 

My observation is that if the event source wsdl wsdl:import the
notification wsdl, then the tools will recursively retrieve the imported
notification wsdl and generate redundant code (i.e. It generates server
code whereas you only need client side code). 

 

Li  

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, January 27, 2010 2:58 AM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org
Subject: Re: [ws-dd] Re: WS-DD comments on WS-Eventing
WD-ws-eventing-20090924

 

Li,

W/regards to "tools getting confused by inlined Notification WSDLs" I
would note the following:

1.) As proposed by MOAP, Notification WSDLs appear as children of a
parameter of a policy assertion. Evenly only moderately robust tools are
likely to ignore information nested within policy assertions that they
don't (by definition, since we're just inventing this stuff)
"understand" (i.e. know how to process), if only out of laziness.

2.) Any WSDL tool that breaks because there is a nested
<wsdl:definition> does not conform to WSDL-1.1 (as amended by BP)
because WSDL-1.1 (as amended by BP) does not forbid the use of
wsdl:definition as a decedent of an extension element (such as
wsp:Policy/wse:EventSource/wse:FormatName). In other words, the tool is
imposing constraints on the information model of the description that
are not there in the base specs.

3.) Even if you were using a tool that was broken in this respect, it's
not that big of deal to modify a local copy of the WSDL to use a
reference to the Notification WSDL instead of inlining it. i.e. the
workaround is fairly painless

- gp

On 1/26/2010 8:33 AM, Li, Li (Li) wrote: 

 
As described by Antoine, two approaches can provide the linkage between
the port types of event source wsdl and notification wsdl. Regardless
the approach taken, we think the following issues have to be addressed.
 
1) one-way or two-way links
We think one-way link is sufficient since two-way links are more
difficult to maintain.
 
2) direction of the links
Both i) source -> notification and ii) notification -> source links can
represent m-n relations. We think direction i) is more inline with the
model in appendix A where the subscriber knows the event source first.
 
3) no event source port type
It is possible that the event source wsdl has no port type because i) it
has no operations other than ws-e; and ii) ws-e is implicit. In this
case, the event source wsdl has no port types.
If this happens, we may use a dummy empty port type in the event source
wsdl. For example, a wsdl extension approach may look like:
 
<portType name="xyz" eventTypes="list of URL" />
 
The advantage of this approach is that the links exist only between port
types and we avoid the complexity arising from cross-linking ports and
port types as proposed in [2].
 
4) problem with wsdl import
To import notification wsdl into event source wsdl (or vice visa) could
be problematic for code generation by some tools. If the tools cannot
distinguish regular operations from those representing event types, as
they both are inbound, they may generate incorrect and unnecessary code.
Typically, an event source implementation should generate server side
code from the event source wsdl and client side code from the
notification wsdl. If the two wsdl are merged through import, only one
type of code will be generated.
 
To address this issue, we should not import the wsdl files. Instead, the
attributes or the policy assertions should indicate the URL of the wsdl.
 
One way to achieve this using policy is proposed in [2][3]. An example
to use plain URL to locate the port type in a wsdl is:
 
eventType="http://wwww.example.com/myservice.wsdl#port-type-name"
<http://wwww.example.com/myservice.wsdl#port-type-name> 
 
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8198
[2]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/at
t-0012/NotificationWSDL_for_6401-6661_v4_submit.htm
[3]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/00
12.html
 
 
Li