cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: WS-Eventing for CXF
Date Mon, 13 May 2013 12:28:13 GMT
Hi Jan,
I'm moving this thread to the dev list, which is probably more suitable
for this discussion now.
I've refreshed my memories of the spec a bit more and thought about the
2 topics below which are related after all.
As far as I understand, the notification message format on the wire is
controlled by the binding as described in Appendix A.1.2, unless a
notification WSDL is provided (Appendix A.2). So, if a notification wsdl
is explicitly set, that is to be used. Otherwise, the rules in A.1.2
apply, both for wrapped and unwrapped delivery. I believe in such cases
the client should basically be implemented using a JAXWS Dispatch (a
JAXB context for building up the notification could be created using the
schema coming within the EventDescriptions/Types element which would be
linked by the EventDescriptions/EventType one). Btw, if no notification
WSDL is provided and wrapped delivery is selected, according to the spec
the client (event sink) must implement the generic WSDL in Appendix D
(which has an operation accepting
{http://www.w3.org/2011/03/ws-evt}EventType as input message and that's
basically a sequence of xsd:any).

Cheers
Alessio

On 05/10/2013 09:33 AM, Jan Martiška wrote:
>> 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
:(
> 
>>


-- 
Alessio Soldano
Web Service Lead, JBoss

Mime
View raw message