WS-Eventing - sending notification

[artem_spector]

Something is unclear to me after reading the user guide:

1. Notification payload:
The example shows the payload creation via parsing some xml string - is there a better way to do it?

2. The notification endpoint definition:
It should be described by some wsdl?
Should the notification endpoint wsdl and the event source wsdl share the same data type definition of the payload?
Should the notification enpoint port definition be same as the event source port definition?

Thank you,
artem

[palin]

"artem_spector" wrote:
Something is unclear to me after reading the user guide:

1. Notification payload:
The example shows the payload creation via parsing some xml string - is there a better way to do it?

I think you can create that xml string the way you prefer, it doesn't matter how you do it as long as what you get is in compliance with the schema you provided in you wsdl; for example, we create it on the fly using jdom.

"artem_spector" wrote:
2. The notification endpoint definition:
It should be described by some wsdl?
Should the notification endpoint wsdl and the event source wsdl share the same data type definition of the payload?
Should the notification enpoint port definition be same as the event source port definition?

As far as I understood from ws-eventing specs (http://www.w3.org/Submission/WS-Eventing) no specific wsdl is required for the notification endpoint since all you need to know is already written in the eventing wsdl (i.e. sysmon.wsdl in jbossws eventing examples). The notification endpoint has to be able to process a soap message containing an xml in compliance with the data type schema defined in the wsdl, nothing more (see chapter 4 of w3c specifications).

Alessio Soldano
http://www.javalinux.it/blogs

[artem_spector]

Alessio, thank you for your explanation. These exactly are the things which seem strange to me.

"palin" wrote:
I think you can create that xml string the way you prefer, it doesn't matter how you do it as long as what you get is in compliance with the schema you provided in you wsdl; for example, we create it on the fly using jdom.

But wouldn't it be natural to suggest that since the message structure is written in the wsdl, the application sending the notification can use the generated stuff like the endpoint interface, user types etc? This would ensure that the resulting message is compliant to the wsdl. Is JSR-109 client support available for WS-Eventing?

"palin" wrote:
The notification endpoint has to be able to process a soap message containing an xml in compliance with the data type schema defined in the wsdl, nothing more

Again, I would expect that I could write the notification endpoint implementation with the convenience provided by JSR-181 or JSR-109 support. Just a java class with annotation pointing to the event source wsdl, as in the JSR-181 POJO example. Is that possible?

Thanks,
Artem

[palin]

Unfortunately as far as I know/understand what you would like is not provided by jbossws because not described in any specifications (jsr181,jsr109,...)
bye
Alessio Soldano
http://www.javalinux.it/blogs

[heiko.braun]

I see what you are trying to archieve. The way it is designed, things are kept really simple and nofitifcation producer doesn't have a dependency on web services at all.

[artem_spector]

Yes, it is simple. But is it consistent?
Currently my notification producer builds messages which are not validated against the wsdl, and the endpoint accepts the messages without validate them against the wsdl. Moreover, if I'd wish to perform such validation on either side, I have no tools to do that.
So the notification structure defined in the event source wsdl is always ignored. Was it the intention of WS Eventing?

thank you,
artem

[heiko.braun]

No, it is just not implemented ;)
Actually the EventDispatcher should validate the message before dispatching. Feel free to open a JIRA feature request so people can volunteer.

[palin]

Hi Heiko,
I've just taken a look at the code: it seems to me that the patch at the SubscriptionManager's dispatch method could be done, validating the received element against the right notification schema from eventSourceMapping. However I noticed that notification schema is currently always set to null in the JSR109MetaDataBuilder; it seems the wsdl is to be parsed here to get the xml schema of the message... am I right? May be we can help you...

Anyway, artem_spector, you could nevertheless validate the message in your server application, before dispatching it to the jbossws engine, since you're supposed to know the notification schema there, don't you?

Alessio Soldano
http://www.javalinux.it/blogs

[artem_spector]

Yes, I know the notification schema, but aparently it might be different from the instance loaded by the subscription manager. Therefore the "real" validation can be done only by the engine - or by the application if the engine provides an access to that schema (by URI)

thank you,
Artem

[maeste]

Hi artem,
I can't understand what you mean? Specification of ws-eventing doesn't constrain notifications because (specification said) any message MAY be a notification.
But in real world producer and receiver have to constrain the message accepted. And it is an application level know how.
Of course should be convenient if the application engine does it for you, but I can't understand where is the value of that: immagine you (event producer) define a schema for notification and a subscriber implement a different schema. When you will send notifications you will construct the xml according to your schema (the only one you are supposed to know). You are asking the engine to validate notifications according to the receiver schema, but in that case (schema defined by the ws-eventing source != schema implemented by the event sink) it wold (always) fail and throws an exption. You can check the exception, but anyway you can't recover it. Isn't it?

Instead the validation of the producer defined schema could be conveniently made by the engine, but it can be done also at application level as Alessio already said.

[heiko.braun]

I think artems suggestion is perfectly valid. The SubscriptionManager knows about the schema and could actually validate the event messages. At least this was my original intention. But as palin already realized, there's two things to be done:

The MetaDataBuilder needs to extract the schema (there might be a better format than String) and populate the deployment info. This would make the schema available to the event source instance.

In a second step, the message could be validated in SubscriptionManager.dispatch() before handiong off to the background task.

[maeste]

Hi Heiko,
I agree with you and Alessio and me could work on this stuff.
But we need just a clarification: we you thinking to validate against the schema defined in wsdl by the server. Do you agree?
I'm asking about because probably I didn't understand what artem means with: "but aparently it might be different from the instance loaded by the subscription manager".

[maeste]

One more question:
I suppose you are thinking the dispatch method must throw an exception? Spec doesn't define one for this case, have you any prefered name or hirearchy?

If you get some times take a look at my post on design forum because the modifications proposed there could be done in the same patch if you agree (they also are about notification send errors).

[artem_spector]

Just a short clarification from my side.
I mean the wsdl deployed on the server defines the contract between the event source and the event consumer. So yes, the validation should be done against the schema on the server.

[heiko.braun]

Well, let's do it then. I would simply call it DispatchException.