You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2013/05/13 14:28:13 UTC
Re: WS-Eventing for CXF
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
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
Done, thanks.
On 05/18/2013 06:23 PM, Andrei Shakirin wrote:
> Hi Alessio,
>
> Small finding: it seems that folder 'rt/ws/eventing/src/test/java/org/apache/cxf/ws/eventing/base/aux' cannot be checked out under Windows, because it is forbidden folder name.
> I guess it still from DOS time, when AUX was system device driver "Auxiliary device" :)
>
> Could you please refactor "aux" to something different to make Windows users happy?
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Alessio Soldano [mailto:asoldano@redhat.com]
>> Sent: Samstag, 18. Mai 2013 14:27
>> To: dev@cxf.apache.org
>> Cc: Jan Martiška
>> Subject: Re: WS-Eventing for CXF
>>
>>
>> On 05/13/2013 02:28 PM, Alessio Soldano wrote:
>>> 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).
>>
>> I've committed to trunk an initial implementation of the spec which is
>> basically the work by Jan plus some fixes, the main one basically being the
>> wrapped delivery impl as per explanation above.
>>
>> We can now move to reasoning about the ws-event descriptions support; I
>> have a few idea and will be sharing them here next week.
>> I'll likely also go on with few additional cleanup / enhancements.
>>
>> Ref jira: https://issues.apache.org/jira/browse/CXF-5023
>>
>> Cheers
>> Alessio
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
--
Alessio Soldano
Web Service Lead, JBoss
RE: WS-Eventing for CXF
Posted by Andrei Shakirin <as...@talend.com>.
Hi Alessio,
Small finding: it seems that folder 'rt/ws/eventing/src/test/java/org/apache/cxf/ws/eventing/base/aux' cannot be checked out under Windows, because it is forbidden folder name.
I guess it still from DOS time, when AUX was system device driver "Auxiliary device" :)
Could you please refactor "aux" to something different to make Windows users happy?
Regards,
Andrei.
> -----Original Message-----
> From: Alessio Soldano [mailto:asoldano@redhat.com]
> Sent: Samstag, 18. Mai 2013 14:27
> To: dev@cxf.apache.org
> Cc: Jan Martiška
> Subject: Re: WS-Eventing for CXF
>
>
> On 05/13/2013 02:28 PM, Alessio Soldano wrote:
> > 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).
>
> I've committed to trunk an initial implementation of the spec which is
> basically the work by Jan plus some fixes, the main one basically being the
> wrapped delivery impl as per explanation above.
>
> We can now move to reasoning about the ws-event descriptions support; I
> have a few idea and will be sharing them here next week.
> I'll likely also go on with few additional cleanup / enhancements.
>
> Ref jira: https://issues.apache.org/jira/browse/CXF-5023
>
> Cheers
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
On 05/18/2013 02:26 PM, Alessio Soldano wrote:
> We can now move to reasoning about the ws-event descriptions support; I
> have a few idea and will be sharing them here next week.
I didn't really have time yet to work on this, but let me share some
preliminary thoughts here so that they don't get lost (perhaps Jan wants
to read them / match them with his idea).
First of all, I think we need to work on providing a simplified way for
exposing proper ws-eventing metadata in the event source contract. With
aim of going on with the code first approach for the event source
definition, I would propose a @EventSource annotation to be added to the
event source ws endpoint class. That would allow specified the event
sink interface class, which could be used at deploy time for generating
the notification wsdl (A.2 in the spec) to be automatically added into
the EventSource assertion. Additional props could be supported in the
annotation, to set the various things in the assertion (filters,
expiration, etc.).
Btw, the policy info above should also be used for automatically
configuring the event source / subscription manager using the policy
engine (the assertion can be used e.g. to set limits to the supported
subscription expiration, etc.)
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Eventing for CXF
Posted by Daniel Kulp <dk...@apache.org>.
On May 19, 2013, at 10:22 AM, Alessio Soldano <as...@redhat.com> wrote:
> Hi Dan,
> sure, I'll ask Jan to fill out the software grant form, I believe he's
> the IP owner for the patch he's done, being that part of his thesis
> work, but I'll leave him the last word. I assume there's no IP issue for
> my few additions so far over his patch. Btw, is a new JIRA required for
> Jan's patch, or can he use the CXF-5023 one?
Existing JIRA is fine. Really just need a place to stick the patch along with the MD5/SHA1 for it so we can point at it from the grant.
Dan
> Thanks
> Alessio
>
> On 05/18/2013 02:42 PM, Daniel Kulp wrote:
>>
>> Alessio,
>>
>> This is large enough that it likely would require a grant like we just did for the XKMS stuff. Especially since Jan isn't already a committer. Can you have Jan create a JIRA and attach a patch to it.
>>
>> Who owns the IP for this at this point? Is it Jan or RedHat? Whomever it is would need to fill out:
>>
>> http://www.apache.org/licenses/software-grant.txt
>>
>> and send that in. (Exhibit A would just point to the JIRA attachment above and also have the MD5 of the patch).
>>
>> I just want to make sure we do this right and all the i's dotted and such. Thanks!
>>
>> Dan
>>
>>
>> On May 18, 2013, at 8:26 AM, Alessio Soldano <as...@redhat.com> wrote:
>>
>>>
>>> On 05/13/2013 02:28 PM, Alessio Soldano wrote:
>>>> 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).
>>>
>>> I've committed to trunk an initial implementation of the spec which is
>>> basically the work by Jan plus some fixes, the main one basically being
>>> the wrapped delivery impl as per explanation above.
>>>
>>> We can now move to reasoning about the ws-event descriptions support; I
>>> have a few idea and will be sharing them here next week.
>>> I'll likely also go on with few additional cleanup / enhancements.
>>>
>>> Ref jira: https://issues.apache.org/jira/browse/CXF-5023
>>>
>>> Cheers
>>> Alessio
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
Hi Dan,
sure, I'll ask Jan to fill out the software grant form, I believe he's
the IP owner for the patch he's done, being that part of his thesis
work, but I'll leave him the last word. I assume there's no IP issue for
my few additions so far over his patch. Btw, is a new JIRA required for
Jan's patch, or can he use the CXF-5023 one?
Thanks
Alessio
On 05/18/2013 02:42 PM, Daniel Kulp wrote:
>
> Alessio,
>
> This is large enough that it likely would require a grant like we just did for the XKMS stuff. Especially since Jan isn't already a committer. Can you have Jan create a JIRA and attach a patch to it.
>
> Who owns the IP for this at this point? Is it Jan or RedHat? Whomever it is would need to fill out:
>
> http://www.apache.org/licenses/software-grant.txt
>
> and send that in. (Exhibit A would just point to the JIRA attachment above and also have the MD5 of the patch).
>
> I just want to make sure we do this right and all the i's dotted and such. Thanks!
>
> Dan
>
>
> On May 18, 2013, at 8:26 AM, Alessio Soldano <as...@redhat.com> wrote:
>
>>
>> On 05/13/2013 02:28 PM, Alessio Soldano wrote:
>>> 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).
>>
>> I've committed to trunk an initial implementation of the spec which is
>> basically the work by Jan plus some fixes, the main one basically being
>> the wrapped delivery impl as per explanation above.
>>
>> We can now move to reasoning about the ws-event descriptions support; I
>> have a few idea and will be sharing them here next week.
>> I'll likely also go on with few additional cleanup / enhancements.
>>
>> Ref jira: https://issues.apache.org/jira/browse/CXF-5023
>>
>> Cheers
>> Alessio
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Eventing for CXF
Posted by Daniel Kulp <dk...@apache.org>.
Alessio,
This is large enough that it likely would require a grant like we just did for the XKMS stuff. Especially since Jan isn't already a committer. Can you have Jan create a JIRA and attach a patch to it.
Who owns the IP for this at this point? Is it Jan or RedHat? Whomever it is would need to fill out:
http://www.apache.org/licenses/software-grant.txt
and send that in. (Exhibit A would just point to the JIRA attachment above and also have the MD5 of the patch).
I just want to make sure we do this right and all the i's dotted and such. Thanks!
Dan
On May 18, 2013, at 8:26 AM, Alessio Soldano <as...@redhat.com> wrote:
>
> On 05/13/2013 02:28 PM, Alessio Soldano wrote:
>> 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).
>
> I've committed to trunk an initial implementation of the spec which is
> basically the work by Jan plus some fixes, the main one basically being
> the wrapped delivery impl as per explanation above.
>
> We can now move to reasoning about the ws-event descriptions support; I
> have a few idea and will be sharing them here next week.
> I'll likely also go on with few additional cleanup / enhancements.
>
> Ref jira: https://issues.apache.org/jira/browse/CXF-5023
>
> Cheers
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
On 05/13/2013 02:28 PM, Alessio Soldano wrote:
> 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).
I've committed to trunk an initial implementation of the spec which is
basically the work by Jan plus some fixes, the main one basically being
the wrapped delivery impl as per explanation above.
We can now move to reasoning about the ws-event descriptions support; I
have a few idea and will be sharing them here next week.
I'll likely also go on with few additional cleanup / enhancements.
Ref jira: https://issues.apache.org/jira/browse/CXF-5023
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss