WS-Addressing metadata/WSDL compliance

[Tammo van Lessen <tv...@gmail.com>]

Hi guys,

I'd like to discuss the usage and compliance of Axis2 with
WS-Addressing, since I think there is some potential for improvements. I
started already with Deepal but we decided to move the discussion to
this list since I think its of broader interest.

It is basically about two things, standard conformance as well as better
support for an automated configuration of consumers and providers w.r.t
DO_ASYNC and/or useSeparateListener(true).

Let me first start with my understanding of the status quo:

I understand that WS-Addressing is quite well supported by Axis2 with an
AddressingBasedDispatcher and the addressing.mar. What is currently only
rudimentarily implemented is the support of metadata that indicates
whether and how WS-Addressing should be used. On the spec side, there
are two specs available, the WS-Addressing WSDL binding [1] and the
WS-Addressing 1.0 Metadata [2]. Both define basically the same with
different renderings, the first is defined in terms of WSDL extensions,
the second in terms of policy assertions. They basically provide two
flags: "usingAddressing" defines whether WS-Addressing can, must or must
not be used. "Anonymous" defines, whether an anonymous reply-to EPR
can ('optional'), must ('required') or must not ('prohibited') be used.
The composable WS-* model most probably recommends the second standards,
which is already a REC whereas [1] is only a CR.

If I'm not mistaken, Axis2 currently only supports the usingAddressing
element as the WSDL extension as described in [1]. I'm not entirely sure
if it is just parsed and serialized or whether it also engages or
configures the addressing module. What is not implemented is the
anonymous element (AXIS2-948) and the policy variant (AXIS2-5022).

This is basically my first request: I think that standard specs should
be implemented in an "all-or-nothing" fashion, so if wsaw:usingAddresing
is supported it should also support wsaw:Anonymous, regardless whether
this spec is superseded by the policy assertion variant. For a framework
I think "the more the merrier" is the right approach as there are other
frameworks out there that may make use of the deprecated spec. JAXWS-RI
for instance supports both.

My second point is about the interplay between the Anonymous element and
the dual channel implementation provided by Axis. If I understand it
correctly, Axis supports the dual channel invocation out of the box and
I consider this a great feature, however I think it is a bit cumbersome
that this has to be explicitly enabled via useSeparateListener(true) on
the client side and setting the DO_ASYNC property/parameter on the
provider side. I think this can be configured automatically via the
Anonymous element (i.e. setting it to 'prohibited') in the WSDL (or this
element could be written to the WSDL if dual channel transport is
enabled). I think Deepal recently committed a changeset that tweaked the
provider part to be smart enough to respond on a separate channel when a
non-anonymous Reply-To EPR was present in the request headers. To be
compliant with the spec, this should IMO only work if the Anonymous
element is not set to 'required', so it should be constrained
accordingly. In turn, when the element is set to 'prohibited', it should
always respond via a second channel and throw and exception if an
anonymous EPR has been sent in the request.

Likewise the client (or the code generator) should be able to reflect
the presence and values of the anonymous element in the WSDL.

IMO, this will make it way easier to automatically configure client and
services and will also make this awesome feature more accessible for
users (because it is declarative).

>From an implementation point of view, I think a) the kernel should be
made aware of anonymous/non-anonymous reply-to addresses, should capture
that flag in the description of services and operations and should
validate WS-A headers against these settings and b) there should be
serializers and deserializers for these settings for both, [1] and [2].

So far from my side, I think we're talking about a valuable feature so I
hope the mail is not too long to get some attention :)

Remains the question: WDYT? ;)

Best,
  Tammo


[1] http://www.w3.org/TR/ws-addr-wsdl/
[2] http://www.w3.org/TR/ws-addr-metadata/

-- 
Tammo van Lessen - http://www.taval.de

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: WS-Addressing metadata/WSDL compliance

[Deepal jayasinghe <de...@gmail.com>]

On 9/28/2011 12:25 PM, Tammo van Lessen wrote:
> My second point is about the interplay between the Anonymous element and
> the dual channel implementation provided by Axis. If I understand it
> correctly, Axis supports the dual channel invocation out of the box and
> I consider this a great feature, however I think it is a bit cumbersome
> that this has to be explicitly enabled via useSeparateListener(true) on
> the client side and setting the DO_ASYNC property/parameter on the
> provider side. I think this can be configured automatically via the
> Anonymous element (i.e. setting it to 'prohibited') in the WSDL (or this
> element could be written to the WSDL if dual channel transport is
> enabled). I think Deepal recently committed a changeset that tweaked the
> provider part to be smart enough to respond on a separate channel when a
> non-anonymous Reply-To EPR was present in the request headers. To be
> compliant with the spec, this should IMO only work if the Anonymous
> element is not set to 'required', so it should be constrained
> accordingly. In turn, when the element is set to 'prohibited', it should
> always respond via a second channel and throw and exception if an
> anonymous EPR has been sent in the request.
IMO, use of dual channels is entirely up to the user, he can decide
whether to invoke the service in sync or async manner. Same service
should be able to invoke both in sync and async manner, in fact Axis2
support that. However I see a very interesting point here. That is, if
the service author knows that the service invocation takes time (higher
than common HTTP connection timeout), then he can enforce invocation
model through WSDL.
>
> Likewise the client (or the code generator) should be able to reflect
> the presence and values of the anonymous element in the WSDL.
>
> IMO, this will make it way easier to automatically configure client and
> services and will also make this awesome feature more accessible for
> users (because it is declarative).
+1.
>
> >From an implementation point of view, I think a) the kernel should be
> made aware of anonymous/non-anonymous reply-to addresses, should capture
> that flag in the description of services and operations and should
> validate WS-A headers against these settings and b) there should be
> serializers and deserializers for these settings for both, [1] and [2].
+1
>
> So far from my side, I think we're talking about a valuable feature so I
> hope the mail is not too long to get some attention :)
>
> Remains the question: WDYT? ;)
I agree this is an important thing that we need to address, specially
fix the addressing related issues and then reflect rest to the code
generation.

Deepal
>
> Best,
>   Tammo
>
>
> [1] http://www.w3.org/TR/ws-addr-wsdl/
> [2] http://www.w3.org/TR/ws-addr-metadata/
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org