Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of asoldano@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <518BC31F.8060909@redhat.com>
Date: Thu, 09 May 2013 17:39:11 +0200
From: Alessio Soldano <asoldano@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: WS-Eventing for CXF
References: <1639823862.15156742.1362743103061.JavaMail.root@redhat.com>
In-Reply-To: <1639823862.15156742.1362743103061.JavaMail.root@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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