Hi Alessio,
many thanks for your time and feedback! Some comments inline.
----- Original Message -----
> From: "Alessio Soldano" <[email protected]>
> To: [email protected]
> Sent: Thursday, May 9, 2013 5:39:11 PM
> Subject: Re: WS-Eventing for CXF
>
> 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?
>
You are right, the wrapped delivery thing is not supported at the moment, I
wasn't sure how to do that. AFAIK a service accepting wrapped delivery will
have a different WSDL and/or a different JAX-WS Java interface than a service
accepting unwrapped delivery, right? And because I only always have one
interface available at a time for each event source (and it is made either for
wrapped or unwrapped delivery), I don't know what how to proceed with it.
>
> >> 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.
>
I agree that would be useful. I might implement that perhaps, but maybe in
June, I will have too much other stuff now :) and it will not catch the
deadline of my thesis text anyway :(
>
> >> 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
>
