Hi Alessio, thanks so much for your time and feedback! See my comments inline.
----- Original Message ----- > From: "Alessio Soldano" <[email protected]> > To: [email protected] > Cc: "Jan Martiška" <[email protected]>, [email protected] > Sent: Thursday, March 7, 2013 10:55:39 AM > Subject: Re: WS-Eventing for CXF > > Hi Jan, > I've tried your demo and had a brief look at your code. The overall > feedback is positive, nice work. > This said, I have a couple of questions regarding the implementation > (I'm sorry should I forget about some specification details, haven't > been refreshing my memories on it since quite some time): > > * 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. > 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. > > 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. > * 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 > * 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. > > Hope this is of any use to you. > Cheers > Alessio > > [1] http://www.w3.org/TR/ws-event-descriptions/ > > > On 03/04/2013 10:04 AM, Jan Martiška wrote: > > Hi guys, > > as you might have noticed earlier, I am working on implementing > > WS-Eventing specification for CXF as my master's thesis. > > WS-Eventing introduces a publish-subscribe pattern for web > > services, eg. a client can subscribe on a server in order to > > receive notifications about certain events which occur in some > > information system. It could be used for weather reports, watching > > stock exchange prices, security systems (eg. with motion > > detectors), or just any system which needs to send notifications. > > > > Actually, the implementation is like 90% complete, I'd guess. At > > least from the specification point of view. What I would like to > > is to have someone have a brief look at it, to do some kind of > > review, so I can receive some feedback and do the necessary > > changes before we merge the code into upstream. And if no one was > > willing to dive into the functionality, at least briefly check if > > it complies with CXF coding patterns. Or you can just try and play > > with it, get familiar with a new technology. There is an example > > webapp to show you the basic principles. I know most of you are > > really busy.. But let's give it a try! > > > > - The specification (for reference): > > http://www.w3.org/TR/2011/REC-ws-eventing-20111213/ > > - The code (the branch is jmartisk-devel): > > https://github.com/jmartisk/cxf/tree/jmartisk-devel/rt/ws/eventing > > - Step-by-step documentation [this is the recommended starting > > point!!!]: > > https://dl.dropbox.com/u/6677495/CXF_HTML_DOC/index.html > > - An example web application is included: > > https://github.com/jmartisk/cxf/tree/jmartisk-devel/distribution/src/main/release/samples/ws_eventing > > The (JSP) web application is meant to be simply deployed to a > > tomcat instance (I use it with tomcat 7), then you navigate to it > > with your browser.. And it will allow you to try out some basic > > features of WS-Eventing. > > > > I would be really grateful for any feedback in this, cause I would > > like to have it merged into upstream soon. After that I can > > finally write the main part of the thesis and perhaps receive that > > master's degree in June ;) > > > > Huge thanks to anyone who would offer help of any kind :) Also feel > > free to contact me. > > > > Cheers, > > Jan (from Red Hat) > > > -- > Alessio Soldano > Web Service Lead, JBoss >
