Vinh,
I don't want to start arguing with you on the correct interpretation of
the textual wording in the spec document. I would rather point to the
WSDL provided with the WS-N 1.3 specification, where the definition of
the "Notify" operation clearly is a "one-way operation" (see WSDL 1.1
spec, section 2.4.1) as follows:
<wsdl:portType name="NotificationConsumer">
<wsdl:operation name="Notify">
<wsdl:input message="wsntw:Notify" />
</wsdl:operation>
</wsdl:portType>
From the WSDL specification, this clearly means that the operation
indeed *is* one-way, which implies neither an output nor a fault message
must be sent back.
Let me try and clarify the issue that Matthias Beil and myself have seen
when sending WS-N notifications from a custom NotificationProducer
implementation based on Metro to a NotificationCosumer implemented using
Muse:
The Glassfish v2/Metro web service client implements the following
logics when calling a one-way endpoint using HTTP(S) transport:
- If the HTTP return code received with the HTTP response is 2xx
(request successfully processed), Metro considers the web service call
to have succeeded.
- If the HTTP return code is within 4xx (client-side error) or 5xx
(server-side error), Metro considers the Web service call to have failed.
The issue with Muse's implementation is that for a WS-N Notify request,
the Axis2/Muse combo returns an HTTP status code of 200 while at the
same time sending back an HTTP response that contains a SOAP message
with a SOAP fault. This means that Metro considers this notification to
have been sent successfully, while in reality, notification processing
at the consumer side has failed: we have suffered a message loss!!!
Basically is not the fact that, in case of an unforeseen error at the
Notification Consumer, the HTTP response sent back by Axis2/Muse
contains a - well, let's say: "unnecessary" (at least) - SOAP message,
the crucial point is that this fault message is sent together with an
HTTP status code of 200 (OK): It is this misleading HTTP response code
that, in our case, causes the loss of notifications in case some
unforeseen exceptions have happened in the Muse NotificationConsumer.
So IMHO, for interoperability with other frameworks, you should
definitely consider to change Muse's default implementation to (at
least) ensure that HTTP status 5xx is returned whenever the
(unnecessary) response message happens to contain a fault...
Best regards,
Andreas
BTW: I am just a professional services field guy working at Sun in
Germany and not directly related to the Sun engineering team that
created Metro. No offense meant ;-)
Vinh Nguyen (vinguye2) schrieb:
Hmm, I wouldn't go as far to say that Muse is non-compliant with WS-N
1.3. Muse's NotificationConsumer does meet the specification for the
Notify message by handling the message properly. Just that it
returns a response to the sender, which is extra behavior on top of
the specification. I'm not sure this means non-compliance.
If you look at the last sentence on p.12 of the specification found
via the link below, it just says that: "No response is expected from
the NotificationConsumer upon receipt of this message."
But it doesn't mean that the consumer can't return a response at all.
In a way, I think returning a response is good because it lets the
sender know that the notification was received successfully by the
consumer. Perhaps Metro should just ignore the response if it knows
an operation doesn't need a response. But then, it still needs to be
smart enough to handle responses like an http 400 error:)
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf
-----Original Message----- From: Beil, Matthias
[mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 12:12 AM
To: [email protected] Subject: AW: Notify returns a SOAP
message
Hi,
it's true that Axis2 doesn't return a response by its own.
As I'm using the Axis2 environment of Muse the incoming request goes
through the in-engine of Axis2. The response returns through the
out-engine. What I did was to add an Axis2 handler to this out flow.
This handler just drops the response. With a bit more logic it would
be possible to filter the returning messages.
But this is not the solution: The problem lies within Muse himself!
The "notify" message is defined as an "out-only" message (see
wsn-ws_base_notification-1.3-spec-os line 363 and the wsdl file).
This means that there is absolutely NO return value expected!!!!
Neither a response, nor any fault message.
But Muse doesn't implement this in this way. The implementation of
Muse always returns a "NotifyResponse" and / or a fault message. But
for the "notify" message, even a fault return is not expected.
So it is Muse who does not comply with the WS-N 1.3 Specification!
Regards, Matthias
--
Andreas Loew
Java Architect
Sun Microsystems (Germany)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
