Hi Andreas, No offense taken:) I do agree with you entirely. To follow closely to the spec, Muse should be updated to not return a NotifyResponse since the spec and wsdl defines it as a one-way operation as you pointed out.
To get around this bug, I think you can do the following: 1) Subclass the Notifyhandler class and return null from the toXML() method. This class handles the Notify message input/output, and it currently returns a fixed response. 2) Subclass the SimpleNotificationConsumer capability and override the createNotifyHandler(). Return your custom NotifyHandler class instead of the original Muse implementation. 3) In your consumer's muse.xml, specify your custom class in #2 above instead of the original SimpleNotificationConsumer. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 1:22 PM To: [email protected] Subject: Re: Notify returns a SOAP message 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.pd > f > > > > > -----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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
