> > This said, unless anybody has concerns, I might possibly try enhancing > what Jan has done and eventually merge it into trunk (only), targetting > the 3.0 release. I believe this is interesting stuff.
Caveat: I haven't had time to look at this yet…. :-( I see in your concerns that your talking a bit about the WS-Notification stuff. How does this relate at all to the WS-Notification services and API's we already have in CXF? Dan On May 9, 2013, at 11:39 AM, Alessio Soldano <[email protected]> wrote: > Hi Jan, > first of all, I'm really sorry for the very late reply. > > On 03/08/2013 12:45 PM, Jan Martiška wrote: >>> * I'm not sure I really grasp the full notification mechanism you >>> implemented; iow, the NotificatorService basically ends up creating >>> EventNotificationTasks, which are expected to send out event >>> notifications. Now, in order for doing that, the interface for the >>> event >>> sink seems to be used, the code goes through the interface methods >>> and >>> selects the first one matching the event parameter. Did I get it >>> right? >> >> Yes, exactly. You need to have exactly one method which takes one argument, >> whose type is equal to the event's type. The reason is that I didn't want to >> force the event-emitting-application to be aware of any event >> identifiers/names/types/whatnot, it will just throw an instance of a >> particular class, and it will be the NotificatorService's responsibility to >> match the event object with a method. > > OK, I see. Sure, the NotificationService there needs a way for building > up valid messages to be sent, so it either needs the java interfaces for > the event sink, or a wsdl... > Btw, on a possibly related topic, I see a TODO in > EventNotificationTask#run() regarding wrapped delivery, is that actually > not supported ATM? > > >>> So basically the server needs to be aware of the interface for the >>> notification endpoint that the client specified. How is that going to >>> happen in the real world? Is there / are you relying on a convention >>> on >>> method names, etc? >> >> Method name doesn't matter in this case, only the type of its parameter. >> >>> Or, look at this from another perspective, let's >>> assume the server decides the contract for notification endpoint >>> methods, given it knows the schema for the event, how is the client >>> supposed to know that? This leads to the next question... >>> >>> * Did you implement the WS-Eventing Metadata support (section 9 of >>> the >>> spec)? Asking as that would allow using WS-EventDescription [1] to >>> advertise event information, by properly mentioning the event schema >>> in >>> the event source wsdl (using EventDescriptions into the EventSource >>> policy assertion, I would avoid requiring/supporting >>> WS-MetadataExchange >>> for this). >> >> I didn't implement WS-Eventing Metadata yet. I might do that if we find it >> necessary and if I have enough time. In the current situation, >> the event source will usually publish a WSDL with the event schema and the >> consumer will grab it, or if the client (event sink) is a java application, >> the developer can somehow obtain the interface's code and use it for the >> event sink directly without using WSDL. > > OK, so just to clarify, you're basically saying that the current > implementation does not offer any specific option for advertising event > information (Appendix A of the spec), right? That's for sure optional > ("MAY"s on the spec in chapter 9), but I would suggest this as valid > enrichment to the current impl for making it better usable in real world > scenarios; implementing the Notification WSDLs approach (A.2 in spec) is > probably the easier approach here, at least on event source side. > With that on client (even sink) side the user is simply supposed to get > the notification wsdl embedded in the ws-eventing policy assertion and > builds the even sink endpoint consuming it. > > >>> Besides from the topic above, I have few minor feedback comments, >>> should >>> you be interested in them: >>> * I see many warnings regarding junit Assert when building the >>> rt/ws/eventing module >> >> I used the old deprecated API, should be fixed now. > > Thanks > >>> * I also see multiple exceptions being logged running the testsuite >>> for >>> the rt/ws/eventing module, are those expected? >> >> Not really expected, but didn't matter. Yes, there was a bit too many of >> them and it might have looked scary. I just fixed it. By the way, >> during the fixing I found out that one test was defective, thanks :D > > Np, will have a new try later anyway. > > >>> * in the demo, the published wsdl contracts for the event source and >>> subscription manager have wsdl:import whose location cannot be >>> resolved. >> >> what exactly do you mean? In my deployment of EventSource I see a >> wsdl:import of >> http://localhost:8080/ws_eventing/services/EventSource?wsdl=EventSourceEndpoint.wsdl >> which is the general Event Source contract imported into a WSDL specific >> for this particular Event Source. And that link, if I open it, works. > > I've just built the demo again and deployed on tomcat7 and I don't see > this problem anymore. Thanks. > > This said, unless anybody has concerns, I might possibly try enhancing > what Jan has done and eventually merge it into trunk (only), targetting > the 3.0 release. I believe this is interesting stuff. > > Cheers > Alessio > > > -- > Alessio Soldano > Web Service Lead, JBoss -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
