You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jan Martiška <jm...@redhat.com> on 2013/03/04 10:04:29 UTC
WS-Eventing for CXF
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)
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
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
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 Jan Martiška <jm...@redhat.com>.
Hi Alessio,
many thanks for your time and feedback! Some comments inline.
----- Original Message -----
> From: "Alessio Soldano" <as...@redhat.com>
> To: users@cxf.apache.org
> 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
>
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
Hi Dan,
On 05/09/2013 07:32 PM, Daniel Kulp wrote:
>> 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.
>
> Caveat: I haven't had time to look at this yet…. :-(
;-)
> I see in your concerns that your talking a bit about the WS-Notification stuff. How does this relate at all to the WS-Notification services and API's we already have in CXF?
Currently it's unrelated. To be honest, the WS-Notification and
WS-Eventing from WS-RA specs have some "common" points / concepts, but
they're definitely different specifications.
Are you kind of suggesting to evaluate trying to uniform the two things
or seeing if solutions implemented for the ws-notification services can
be applied to the ws-eventing impl?
Btw, speaking of services, I would likely see the ws-eventing impl
migrated to the "services" area too, similarly to the wsn, wsdd, sts, etc.
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Eventing for CXF
Posted by Daniel Kulp <dk...@apache.org>.
>
> 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.
Caveat: I haven't had time to look at this yet…. :-(
I see in your concerns that your talking a bit about the WS-Notification stuff. How does this relate at all to the WS-Notification services and API's we already have in CXF?
Dan
On May 9, 2013, at 11:39 AM, Alessio Soldano <as...@redhat.com> wrote:
> 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
--
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 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
Re: WS-Eventing for CXF
Posted by Jan Martiška <jm...@redhat.com>.
Hi Alessio,
thanks so much for your time and feedback!
See my comments inline.
----- Original Message -----
> From: "Alessio Soldano" <as...@redhat.com>
> To: dev@cxf.apache.org
> Cc: "Jan Martiška" <jm...@redhat.com>, users@cxf.apache.org
> 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
>
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
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?
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? 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).
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 also see multiple exceptions being logged running the testsuite for
the rt/ws/eventing module, are those expected?
* in the demo, the published wsdl contracts for the event source and
subscription manager have wsdl:import whose location cannot be resolved.
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
Re: WS-Eventing for CXF
Posted by Alessio Soldano <as...@redhat.com>.
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?
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? 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).
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 also see multiple exceptions being logged running the testsuite for
the rt/ws/eventing module, are those expected?
* in the demo, the published wsdl contracts for the event source and
subscription manager have wsdl:import whose location cannot be resolved.
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