You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gege <ge...@gmail.com> on 2012/11/11 13:38:47 UTC
Asynchronous
Hi,
I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
HTTP.
I want network callflows to be as simple as possible (no callbacks, plain
simple request/answer) and i want to be resources-efficient because some
requests might be long (and i'll have long-polling for events).
So, I need to have asynchronous implementations (in java) of both client
and servers.
Here is where i stand:
SOAP (jax-ws) :
- asynchronous client : OK (wsimport + binding.xml)
- asynchronous server : not supported yet by CXF (AsyncProvider is
specified in jax-ws 2.2, it's not the most simple to implement (handle the
XML myself...) but it should be able to do the job, might be supported in
jax-ws-ri by sun).
REST (jax-rs) :
- asynchronous client (cxf-wadl2java) : ? i did find anything about
asynchronous client and I really hope someone can give me a pointer
- asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
that i'll post once i've tested a bit more
For now, I feel like there are some pieces missing.
Of course i could implement a REST client myself, but i feel it's a waste.
There are libraries and utilities everywhere and what I want to do seems
pretty much in the scope of jax-rs and jax-ws).
Thanks in advance.
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
OK, I misunderstood. Thanks for the clarification !
2012/11/23 Sergey Beryozkin <sb...@gmail.com>:
> On 23/11/12 15:55, Gege wrote:
>>
>> Thanks a lot.
>> Event if i don't use a RS asynchronous client right now. It might
>> prove usefull to switch from WS to RS.
>
>
> I just think it can be a useful feature to let users to select which methods
> will be handled at the code gen time, it won't imply that they'd need to
> switch from WS if they also have WS frontends or that they have to use async
> clients - will work Ok with browser based clients too or sync coded clients,
>
> I only now see that you actually were more interested in the async clients
> :-) - this new option will help on the server only, to get the code
> generator facilitating the support for async clients @UseAsyncMethod would
> have to supported, not there yet
>
> Thanks, Sergey
>
>
>>
>> 2012/11/23 Sergey Beryozkin<sb...@gmail.com>:
>>>
>>> On 12/11/12 14:19, Sergey Beryozkin wrote:
>>>>
>>>>
>>>> On 11/11/12 12:38, Gege wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
>>>>> over
>>>>> HTTP.
>>>>>
>>>>> I want network callflows to be as simple as possible (no callbacks,
>>>>> plain
>>>>> simple request/answer) and i want to be resources-efficient because
>>>>> some
>>>>> requests might be long (and i'll have long-polling for events).
>>>>>
>>>>> So, I need to have asynchronous implementations (in java) of both
>>>>> client
>>>>> and servers.
>>>>>
>>>>> Here is where i stand:
>>>>>
>>>>> SOAP (jax-ws) :
>>>>> - asynchronous client : OK (wsimport + binding.xml)
>>>>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>>>>> specified in jax-ws 2.2, it's not the most simple to implement (handle
>>>>> the
>>>>> XML myself...) but it should be able to do the job, might be supported
>>>>> in
>>>>> jax-ws-ri by sun).
>>>>>
>>>>> REST (jax-rs) :
>>>>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>>>>> asynchronous client and I really hope someone can give me a pointer
>>>>
>>>>
>>>>
>>>> I guess we can extend cxf-wadl2java to get "@Suspended AsyncResponse"
>>>> added to the generated signature if a current method id is listed,
>>>> example, "-async getIt", where "getIt" is the name or id of some
>>>> specific WADL method element. I'll think about it...
>>>>
>>>
>>> The code generator has been updated on the trunk to support "-async"
>>> option,
>>> for example, '-async get,addBook' where 'get' will match all WADL methods
>>> with name "GET", and 'addBook' - a specific method with id attribute
>>> 'addBook'
>>>
>>> "-managedAsync" option for supporting "@UseAsyncMethod" style will be
>>> added
>>> later...
>>>
>>> Sergey
>>>
>>>
>>>> However, that will only help with preparing the server code, the proxy
>>>> based client code will not be able to run in the async mode itself, it
>>>> is only possible to use WebClient for the client code itself to run
>>>> asynchronously.
>>>>
>>>> thanks, Sergey
>>>>
>>>>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
>>>>> fixes
>>>>> that i'll post once i've tested a bit more
>>>>>
>>>>> For now, I feel like there are some pieces missing.
>>>>> Of course i could implement a REST client myself, but i feel it's a
>>>>> waste.
>>>>> There are libraries and utilities everywhere and what I want to do
>>>>> seems
>>>>> pretty much in the scope of jax-rs and jax-ws).
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com
>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: Asynchronous
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 23/11/12 15:55, Gege wrote:
> Thanks a lot.
> Event if i don't use a RS asynchronous client right now. It might
> prove usefull to switch from WS to RS.
I just think it can be a useful feature to let users to select which
methods will be handled at the code gen time, it won't imply that they'd
need to switch from WS if they also have WS frontends or that they have
to use async clients - will work Ok with browser based clients too or
sync coded clients,
I only now see that you actually were more interested in the async
clients :-) - this new option will help on the server only, to get the
code generator facilitating the support for async clients
@UseAsyncMethod would have to supported, not there yet
Thanks, Sergey
>
> 2012/11/23 Sergey Beryozkin<sb...@gmail.com>:
>> On 12/11/12 14:19, Sergey Beryozkin wrote:
>>>
>>> On 11/11/12 12:38, Gege wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
>>>> over
>>>> HTTP.
>>>>
>>>> I want network callflows to be as simple as possible (no callbacks, plain
>>>> simple request/answer) and i want to be resources-efficient because some
>>>> requests might be long (and i'll have long-polling for events).
>>>>
>>>> So, I need to have asynchronous implementations (in java) of both client
>>>> and servers.
>>>>
>>>> Here is where i stand:
>>>>
>>>> SOAP (jax-ws) :
>>>> - asynchronous client : OK (wsimport + binding.xml)
>>>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>>>> specified in jax-ws 2.2, it's not the most simple to implement (handle
>>>> the
>>>> XML myself...) but it should be able to do the job, might be supported in
>>>> jax-ws-ri by sun).
>>>>
>>>> REST (jax-rs) :
>>>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>>>> asynchronous client and I really hope someone can give me a pointer
>>>
>>>
>>> I guess we can extend cxf-wadl2java to get "@Suspended AsyncResponse"
>>> added to the generated signature if a current method id is listed,
>>> example, "-async getIt", where "getIt" is the name or id of some
>>> specific WADL method element. I'll think about it...
>>>
>>
>> The code generator has been updated on the trunk to support "-async" option,
>> for example, '-async get,addBook' where 'get' will match all WADL methods
>> with name "GET", and 'addBook' - a specific method with id attribute
>> 'addBook'
>>
>> "-managedAsync" option for supporting "@UseAsyncMethod" style will be added
>> later...
>>
>> Sergey
>>
>>
>>> However, that will only help with preparing the server code, the proxy
>>> based client code will not be able to run in the async mode itself, it
>>> is only possible to use WebClient for the client code itself to run
>>> asynchronously.
>>>
>>> thanks, Sergey
>>>
>>>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
>>>> fixes
>>>> that i'll post once i've tested a bit more
>>>>
>>>> For now, I feel like there are some pieces missing.
>>>> Of course i could implement a REST client myself, but i feel it's a
>>>> waste.
>>>> There are libraries and utilities everywhere and what I want to do seems
>>>> pretty much in the scope of jax-rs and jax-ws).
>>>>
>>>> Thanks in advance.
>>>>
>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
Thanks a lot.
Event if i don't use a RS asynchronous client right now. It might
prove usefull to switch from WS to RS.
2012/11/23 Sergey Beryozkin <sb...@gmail.com>:
> On 12/11/12 14:19, Sergey Beryozkin wrote:
>>
>> On 11/11/12 12:38, Gege wrote:
>>>
>>> Hi,
>>>
>>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
>>> over
>>> HTTP.
>>>
>>> I want network callflows to be as simple as possible (no callbacks, plain
>>> simple request/answer) and i want to be resources-efficient because some
>>> requests might be long (and i'll have long-polling for events).
>>>
>>> So, I need to have asynchronous implementations (in java) of both client
>>> and servers.
>>>
>>> Here is where i stand:
>>>
>>> SOAP (jax-ws) :
>>> - asynchronous client : OK (wsimport + binding.xml)
>>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>>> specified in jax-ws 2.2, it's not the most simple to implement (handle
>>> the
>>> XML myself...) but it should be able to do the job, might be supported in
>>> jax-ws-ri by sun).
>>>
>>> REST (jax-rs) :
>>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>>> asynchronous client and I really hope someone can give me a pointer
>>
>>
>> I guess we can extend cxf-wadl2java to get "@Suspended AsyncResponse"
>> added to the generated signature if a current method id is listed,
>> example, "-async getIt", where "getIt" is the name or id of some
>> specific WADL method element. I'll think about it...
>>
>
> The code generator has been updated on the trunk to support "-async" option,
> for example, '-async get,addBook' where 'get' will match all WADL methods
> with name "GET", and 'addBook' - a specific method with id attribute
> 'addBook'
>
> "-managedAsync" option for supporting "@UseAsyncMethod" style will be added
> later...
>
> Sergey
>
>
>> However, that will only help with preparing the server code, the proxy
>> based client code will not be able to run in the async mode itself, it
>> is only possible to use WebClient for the client code itself to run
>> asynchronously.
>>
>> thanks, Sergey
>>
>>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
>>> fixes
>>> that i'll post once i've tested a bit more
>>>
>>> For now, I feel like there are some pieces missing.
>>> Of course i could implement a REST client myself, but i feel it's a
>>> waste.
>>> There are libraries and utilities everywhere and what I want to do seems
>>> pretty much in the scope of jax-rs and jax-ws).
>>>
>>> Thanks in advance.
>>>
>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: Asynchronous
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 12/11/12 14:19, Sergey Beryozkin wrote:
> On 11/11/12 12:38, Gege wrote:
>> Hi,
>>
>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
>> over
>> HTTP.
>>
>> I want network callflows to be as simple as possible (no callbacks, plain
>> simple request/answer) and i want to be resources-efficient because some
>> requests might be long (and i'll have long-polling for events).
>>
>> So, I need to have asynchronous implementations (in java) of both client
>> and servers.
>>
>> Here is where i stand:
>>
>> SOAP (jax-ws) :
>> - asynchronous client : OK (wsimport + binding.xml)
>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>> specified in jax-ws 2.2, it's not the most simple to implement (handle
>> the
>> XML myself...) but it should be able to do the job, might be supported in
>> jax-ws-ri by sun).
>>
>> REST (jax-rs) :
>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>> asynchronous client and I really hope someone can give me a pointer
>
> I guess we can extend cxf-wadl2java to get "@Suspended AsyncResponse"
> added to the generated signature if a current method id is listed,
> example, "-async getIt", where "getIt" is the name or id of some
> specific WADL method element. I'll think about it...
>
The code generator has been updated on the trunk to support "-async"
option, for example, '-async get,addBook' where 'get' will match all
WADL methods with name "GET", and 'addBook' - a specific method with id
attribute 'addBook'
"-managedAsync" option for supporting "@UseAsyncMethod" style will be
added later...
Sergey
> However, that will only help with preparing the server code, the proxy
> based client code will not be able to run in the async mode itself, it
> is only possible to use WebClient for the client code itself to run
> asynchronously.
>
> thanks, Sergey
>
>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
>> fixes
>> that i'll post once i've tested a bit more
>>
>> For now, I feel like there are some pieces missing.
>> Of course i could implement a REST client myself, but i feel it's a
>> waste.
>> There are libraries and utilities everywhere and what I want to do seems
>> pretty much in the scope of jax-rs and jax-ws).
>>
>> Thanks in advance.
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Asynchronous
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 11/11/12 12:38, Gege wrote:
> Hi,
>
> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
> HTTP.
>
> I want network callflows to be as simple as possible (no callbacks, plain
> simple request/answer) and i want to be resources-efficient because some
> requests might be long (and i'll have long-polling for events).
>
> So, I need to have asynchronous implementations (in java) of both client
> and servers.
>
> Here is where i stand:
>
> SOAP (jax-ws) :
> - asynchronous client : OK (wsimport + binding.xml)
> - asynchronous server : not supported yet by CXF (AsyncProvider is
> specified in jax-ws 2.2, it's not the most simple to implement (handle the
> XML myself...) but it should be able to do the job, might be supported in
> jax-ws-ri by sun).
>
> REST (jax-rs) :
> - asynchronous client (cxf-wadl2java) : ? i did find anything about
> asynchronous client and I really hope someone can give me a pointer
I guess we can extend cxf-wadl2java to get "@Suspended AsyncResponse"
added to the generated signature if a current method id is listed,
example, "-async getIt", where "getIt" is the name or id of some
specific WADL method element. I'll think about it...
However, that will only help with preparing the server code, the proxy
based client code will not be able to run in the async mode itself, it
is only possible to use WebClient for the client code itself to run
asynchronously.
thanks, Sergey
> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
> that i'll post once i've tested a bit more
>
> For now, I feel like there are some pieces missing.
> Of course i could implement a REST client myself, but i feel it's a waste.
> There are libraries and utilities everywhere and what I want to do seems
> pretty much in the scope of jax-rs and jax-ws).
>
> Thanks in advance.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
Yes, no prob.
I'll just have to find a nice tool to edit the wsdl.
Or just do another java-first project in order to generate a wsdl from
code, then import it the asynchronous app ;-)
I hope the asynchronous WS server will be soon normalized the same way as
the jax-rs asynchronous server (quite easy to use)
Yes, i'm lazy.
Another question : does CXF's @WebServiceProvider supports the asynchronous
invoke ?
2012/11/12 Freeman Fang <fr...@gmail.com>
> Hi,
>
> Actually it's no such limitation that you must use wsdl first way with
> async, you can write class like GreetMeSometimeResponse yourself, though
> it's a little bit hard and error prone, and yeah we recommend the wsdl
> first way.
>
> Freeman
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-11-12, at 下午4:59, Gege wrote:
>
> > Thanks !
> >
> > Just to be sure, since the callback is of type
> > AsyncHandler<GreetMeSometimeResponse>, does that mean that the webservice
> > must be created from WSDL, and not from Java ?
> >
> > That would be logical : i did not fount the @UseAsyncMethod anywhere. So
> i
> > started to code something on top of async @WebServiceProvider, do myself
> je
> > jaxb glue, and i was going to do some mapping between @WebServiceProvider
> > and methods of a class. I had the same requirement that the WS must be
> > created from WSDL.
> >
> > I guess CXF already did it for me. Good ! :-)
> >
> >
> > 2012/11/12 Freeman Fang <fr...@gmail.com>
> >
> >> Hi,
> >>
> >> FYI, for the jaxws server side asynchronous, since CXF 2.6.x, you can
> use
> >> @UseAsyncMethod which will leverage CXF Continuations API underlying,
> take
> >> a look at jaxws_async sample(especially the README.txt which explain the
> >> Server Side Asynchronous models) shipped with CXF 2.6.x kit to get more
> >> details.
> >>
> >> Freeman
> >> －－－－－－－－－－－－－
> >> Freeman(Yue) Fang
> >>
> >> Red Hat, Inc.
> >> FuseSource is now part of Red Hat
> >> Web: http://fusesource.com | http://www.redhat.com/
> >> Twitter: freemanfang
> >> Blog: http://freemanfang.blogspot.com
> >> http://blog.sina.com.cn/u/1473905042
> >> weibo: http://weibo.com/u/1473905042
> >>
> >> On 2012-11-11, at 下午8:38, Gege wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
> >> over
> >>> HTTP.
> >>>
> >>> I want network callflows to be as simple as possible (no callbacks,
> plain
> >>> simple request/answer) and i want to be resources-efficient because
> some
> >>> requests might be long (and i'll have long-polling for events).
> >>>
> >>> So, I need to have asynchronous implementations (in java) of both
> client
> >>> and servers.
> >>>
> >>> Here is where i stand:
> >>>
> >>> SOAP (jax-ws) :
> >>> - asynchronous client : OK (wsimport + binding.xml)
> >>> - asynchronous server : not supported yet by CXF (AsyncProvider is
> >>> specified in jax-ws 2.2, it's not the most simple to implement (handle
> >> the
> >>> XML myself...) but it should be able to do the job, might be supported
> in
> >>> jax-ws-ri by sun).
> >>>
> >>> REST (jax-rs) :
> >>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
> >>> asynchronous client and I really hope someone can give me a pointer
> >>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
> >> fixes
> >>> that i'll post once i've tested a bit more
> >>>
> >>> For now, I feel like there are some pieces missing.
> >>> Of course i could implement a REST client myself, but i feel it's a
> >> waste.
> >>> There are libraries and utilities everywhere and what I want to do
> seems
> >>> pretty much in the scope of jax-rs and jax-ws).
> >>>
> >>> Thanks in advance.
> >>
> >>
>
>
Re: Asynchronous
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Actually it's no such limitation that you must use wsdl first way with async, you can write class like GreetMeSometimeResponse yourself, though it's a little bit hard and error prone, and yeah we recommend the wsdl first way.
Freeman
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-11-12, at 下午4:59, Gege wrote:
> Thanks !
>
> Just to be sure, since the callback is of type
> AsyncHandler<GreetMeSometimeResponse>, does that mean that the webservice
> must be created from WSDL, and not from Java ?
>
> That would be logical : i did not fount the @UseAsyncMethod anywhere. So i
> started to code something on top of async @WebServiceProvider, do myself je
> jaxb glue, and i was going to do some mapping between @WebServiceProvider
> and methods of a class. I had the same requirement that the WS must be
> created from WSDL.
>
> I guess CXF already did it for me. Good ! :-)
>
>
> 2012/11/12 Freeman Fang <fr...@gmail.com>
>
>> Hi,
>>
>> FYI, for the jaxws server side asynchronous, since CXF 2.6.x, you can use
>> @UseAsyncMethod which will leverage CXF Continuations API underlying, take
>> a look at jaxws_async sample(especially the README.txt which explain the
>> Server Side Asynchronous models) shipped with CXF 2.6.x kit to get more
>> details.
>>
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman(Yue) Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://fusesource.com | http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-11-11, at 下午8:38, Gege wrote:
>>
>>> Hi,
>>>
>>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
>> over
>>> HTTP.
>>>
>>> I want network callflows to be as simple as possible (no callbacks, plain
>>> simple request/answer) and i want to be resources-efficient because some
>>> requests might be long (and i'll have long-polling for events).
>>>
>>> So, I need to have asynchronous implementations (in java) of both client
>>> and servers.
>>>
>>> Here is where i stand:
>>>
>>> SOAP (jax-ws) :
>>> - asynchronous client : OK (wsimport + binding.xml)
>>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>>> specified in jax-ws 2.2, it's not the most simple to implement (handle
>> the
>>> XML myself...) but it should be able to do the job, might be supported in
>>> jax-ws-ri by sun).
>>>
>>> REST (jax-rs) :
>>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>>> asynchronous client and I really hope someone can give me a pointer
>>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
>> fixes
>>> that i'll post once i've tested a bit more
>>>
>>> For now, I feel like there are some pieces missing.
>>> Of course i could implement a REST client myself, but i feel it's a
>> waste.
>>> There are libraries and utilities everywhere and what I want to do seems
>>> pretty much in the scope of jax-rs and jax-ws).
>>>
>>> Thanks in advance.
>>
>>
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
Thanks !
Just to be sure, since the callback is of type
AsyncHandler<GreetMeSometimeResponse>, does that mean that the webservice
must be created from WSDL, and not from Java ?
That would be logical : i did not fount the @UseAsyncMethod anywhere. So i
started to code something on top of async @WebServiceProvider, do myself je
jaxb glue, and i was going to do some mapping between @WebServiceProvider
and methods of a class. I had the same requirement that the WS must be
created from WSDL.
I guess CXF already did it for me. Good ! :-)
2012/11/12 Freeman Fang <fr...@gmail.com>
> Hi,
>
> FYI, for the jaxws server side asynchronous, since CXF 2.6.x, you can use
> @UseAsyncMethod which will leverage CXF Continuations API underlying, take
> a look at jaxws_async sample(especially the README.txt which explain the
> Server Side Asynchronous models) shipped with CXF 2.6.x kit to get more
> details.
>
> Freeman
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-11-11, at 下午8:38, Gege wrote:
>
> > Hi,
> >
> > I'm using CXF between two endpoints (both are AS) in SOAP and/or REST
> over
> > HTTP.
> >
> > I want network callflows to be as simple as possible (no callbacks, plain
> > simple request/answer) and i want to be resources-efficient because some
> > requests might be long (and i'll have long-polling for events).
> >
> > So, I need to have asynchronous implementations (in java) of both client
> > and servers.
> >
> > Here is where i stand:
> >
> > SOAP (jax-ws) :
> > - asynchronous client : OK (wsimport + binding.xml)
> > - asynchronous server : not supported yet by CXF (AsyncProvider is
> > specified in jax-ws 2.2, it's not the most simple to implement (handle
> the
> > XML myself...) but it should be able to do the job, might be supported in
> > jax-ws-ri by sun).
> >
> > REST (jax-rs) :
> > - asynchronous client (cxf-wadl2java) : ? i did find anything about
> > asynchronous client and I really hope someone can give me a pointer
> > - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some
> fixes
> > that i'll post once i've tested a bit more
> >
> > For now, I feel like there are some pieces missing.
> > Of course i could implement a REST client myself, but i feel it's a
> waste.
> > There are libraries and utilities everywhere and what I want to do seems
> > pretty much in the scope of jax-rs and jax-ws).
> >
> > Thanks in advance.
>
>
Re: Asynchronous
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
FYI, for the jaxws server side asynchronous, since CXF 2.6.x, you can use @UseAsyncMethod which will leverage CXF Continuations API underlying, take a look at jaxws_async sample(especially the README.txt which explain the Server Side Asynchronous models) shipped with CXF 2.6.x kit to get more details.
Freeman
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-11-11, at 下午8:38, Gege wrote:
> Hi,
>
> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
> HTTP.
>
> I want network callflows to be as simple as possible (no callbacks, plain
> simple request/answer) and i want to be resources-efficient because some
> requests might be long (and i'll have long-polling for events).
>
> So, I need to have asynchronous implementations (in java) of both client
> and servers.
>
> Here is where i stand:
>
> SOAP (jax-ws) :
> - asynchronous client : OK (wsimport + binding.xml)
> - asynchronous server : not supported yet by CXF (AsyncProvider is
> specified in jax-ws 2.2, it's not the most simple to implement (handle the
> XML myself...) but it should be able to do the job, might be supported in
> jax-ws-ri by sun).
>
> REST (jax-rs) :
> - asynchronous client (cxf-wadl2java) : ? i did find anything about
> asynchronous client and I really hope someone can give me a pointer
> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
> that i'll post once i've tested a bit more
>
> For now, I feel like there are some pieces missing.
> Of course i could implement a REST client myself, but i feel it's a waste.
> There are libraries and utilities everywhere and what I want to do seems
> pretty much in the scope of jax-rs and jax-ws).
>
> Thanks in advance.
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
I met another "issue".
I was editing my WSDL and wsdl2java stopped generating asynchronous client apis.
I added a bindings.xml file for wsdl2java with
<enableAsyncMapping>true</enableAsyncMapping>.
It does not solves anything about the client api (maybe there is
something it doesn't like in my wsdl, i'll check stop-by-step when
starting from my original wsdl).
But on the generated server, I now have a third method signature in
the generated interface :
public InviteResponse invite(Invite parameters)
public Future<?> inviteAsync(Invite parameters, final
AsyncHandler<InviteResponse> asyncHandler)
public Response<InviteResponse> inviteAsync(Invite parameters);
What is that third method with Response<InviteResponse> as the return type ?
Is it an "old" (pre servlet 3) asynchronous API that will rely on
underlying synchronous IO (thus not thread-efficient ?) Looks like
this method is jax-ws compliant since the response type is "import
javax.xml.ws.Response;".
2012/11/13 Gege <ge...@gmail.com>:
> 2012/11/12 Daniel Kulp <dk...@apache.org>:
>> Interesting. In theory, those classes are all provides by the system runtime since they've been built into the JDK for a long time. Thus, they should be pulled from there unless they are either endorsed via the normal endorse mechanisms or something explicitely sets some sort of parent last class loader and doesn't allow them to pass through.
>
> You're totally right, that's why only some persons have this issue: I
> voluntary changed the behavior of the classloader using
> ocntainer-specific parameters in jonas and jboss.
>
> Why ?
>
> Because many java EE containers come with tons of "services". However
> those services (like jax-ws auto deployment based on CXF ^_^) come
> with a fixed version of ... CXF in this case. But I want to use CXF
> 2.7.0, and my container contains CXF 2.5.2. I don't want to ask the
> installation team to mess with the container, so I put the parameter
> to change the classpath order. Now, for my war only, the embedded jars
> will be looked at first when looking for a class. That way I'm not
> dependent (well... less than before) of the container. Of course my
> war is bigger because I don't re-use the container's included libs.
>
> But in this case, a usually invisible problem (the alien classes in
> xmlbeans) becomes visible ^_^
>
> Anyway, thanks a lot for your support ! I realize that i mightbe in a
> specific situation, wanting asynchronous api and NIO everywhere, and
> even with this classloader tweak ! !
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
2012/11/12 Daniel Kulp <dk...@apache.org>:
> Interesting. In theory, those classes are all provides by the system runtime since they've been built into the JDK for a long time. Thus, they should be pulled from there unless they are either endorsed via the normal endorse mechanisms or something explicitely sets some sort of parent last class loader and doesn't allow them to pass through.
You're totally right, that's why only some persons have this issue: I
voluntary changed the behavior of the classloader using
ocntainer-specific parameters in jonas and jboss.
Why ?
Because many java EE containers come with tons of "services". However
those services (like jax-ws auto deployment based on CXF ^_^) come
with a fixed version of ... CXF in this case. But I want to use CXF
2.7.0, and my container contains CXF 2.5.2. I don't want to ask the
installation team to mess with the container, so I put the parameter
to change the classpath order. Now, for my war only, the embedded jars
will be looked at first when looking for a class. That way I'm not
dependent (well... less than before) of the container. Of course my
war is bigger because I don't re-use the container's included libs.
But in this case, a usually invisible problem (the alien classes in
xmlbeans) becomes visible ^_^
Anyway, thanks a lot for your support ! I realize that i mightbe in a
specific situation, wanting asynchronous api and NIO everywhere, and
even with this classloader tweak ! !
Re: Asynchronous
Posted by Daniel Kulp <dk...@apache.org>.
On Nov 12, 2012, at 5:07 PM, Gege <ge...@gmail.com> wrote:
> With CXF 2.7.0
> I managed to use server-side @UseAsyncMethod with client-side
> generated by cxf too (to have nio).
>
> Just one remark though, i fell into this one with the AS JOnAS when
> using the client:
> https://issues.apache.org/jira/browse/XMLBEANS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>
> CXF depends on xmlbeans 2.5.0 that includes :'( some org.x3c.dom (not
> all) classes and lead to many issues if :
> 1 - other version of xml-api is on classpath
> 2 - in the classpath order the war is before the other libraries
>
> Because some (not all) of xml-api's classes get "overriden" by the one
> packaged in xmlbean.
Interesting. In theory, those classes are all provides by the system runtime since they've been built into the JDK for a long time. Thus, they should be pulled from there unless they are either endorsed via the normal endorse mechanisms or something explicitely sets some sort of parent last class loader and doesn't allow them to pass through.
> No luck... That's my case, and i specifically want to invert the
> classpath order (my war first) in order not to be bothered by the
> packaged versions of CXF in the AS...
>
> According to the bug tracker xmlbeans >= 2.5.1 fixed this issue
> (simply removed the classes). I added an explicit dependency to
> xmlbeans 2.6.0 in my pom and everybody's happy again. Maybe it could
> be a solution to upgrade the version of the xmlbeans dependency in CXF
> ?
I have no problem with updating the xmlbeans version. Running the tests now.
Dan
>
> Hope this explaination (I spend quite a bit of time clarifying this
> ^_^) will help fellows googlers.
>
> 2012/11/12 Gege <ge...@gmail.com>:
>> I sent the mail before finishing it ...
>> And so i wanted to conclude by saying that all that was left was doing
>> some introspection glue in order to map the object to a java method.
>>
>> But; yeah, there is some work to do before arriving to a "simple"
>> method call. But it might be re-usable. I'm surprised that it's not
>> already existing somewhere.
>>
>> 2012/11/12 Gege <ge...@gmail.com>:
>>>> That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability.
>>>
>>> I've been playing around with sun's Provider, the mapping to JAXB
>>> isn't *very* difficult if you do wsdl-first
>>>
>>> Create a context with the generated ObjectFactory class
>>> _jaxbContext = JAXBContext.newInstance(ObjectFactory.class);
>>>
>>> Then it's almost immediate to get the java objects :
>>> public void invoke(Source source, AsyncProviderCallback<Source> cbak,
>>> WebServiceContext ctxt) {
>>> JAXBElement jaxbRequest = (JAXBElement)
>>> _jaxbContext.createUnmarshaller().unmarshal(source);
>>> GetHelloWorldAsString getHelloWorldAsString =
>>> (GetHelloWorldAsString) jaxbRequest.getValue();
>>>
>>> Then it's "almost" the same thing for the answer :
>>>
>>> GetHelloWorldAsStringResponse getHelloWorldAsStringResponse =
>>> objectFactory.createGetHelloWorldAsStringResponse();
>>> getHelloWorldAsStringResponse.setReturn(/*somth*/);
>>>
>>> JAXBElement<GetHelloWorldAsStringResponse> jaxbResponse =
>>> objectFactory.createGetHelloWorldAsStringResponse(getHelloWorldAsStringResponse);
>>>
>>> ByteArrayOutputStream os = new ByteArrayOutputStream();
>>> _jaxbContext.createMarshaller().marshal(jaxbResponse, os);
>>> ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray());
>>> cbak.send(new StreamSource(is));
>>> }
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
With CXF 2.7.0
I managed to use server-side @UseAsyncMethod with client-side
generated by cxf too (to have nio).
Just one remark though, i fell into this one with the AS JOnAS when
using the client:
https://issues.apache.org/jira/browse/XMLBEANS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
CXF depends on xmlbeans 2.5.0 that includes :'( some org.x3c.dom (not
all) classes and lead to many issues if :
1 - other version of xml-api is on classpath
2 - in the classpath order the war is before the other libraries
Because some (not all) of xml-api's classes get "overriden" by the one
packaged in xmlbean.
No luck... That's my case, and i specifically want to invert the
classpath order (my war first) in order not to be bothered by the
packaged versions of CXF in the AS...
According to the bug tracker xmlbeans >= 2.5.1 fixed this issue
(simply removed the classes). I added an explicit dependency to
xmlbeans 2.6.0 in my pom and everybody's happy again. Maybe it could
be a solution to upgrade the version of the xmlbeans dependency in CXF
?
Hope this explaination (I spend quite a bit of time clarifying this
^_^) will help fellows googlers.
2012/11/12 Gege <ge...@gmail.com>:
> I sent the mail before finishing it ...
> And so i wanted to conclude by saying that all that was left was doing
> some introspection glue in order to map the object to a java method.
>
> But; yeah, there is some work to do before arriving to a "simple"
> method call. But it might be re-usable. I'm surprised that it's not
> already existing somewhere.
>
> 2012/11/12 Gege <ge...@gmail.com>:
>>> That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability.
>>
>> I've been playing around with sun's Provider, the mapping to JAXB
>> isn't *very* difficult if you do wsdl-first
>>
>> Create a context with the generated ObjectFactory class
>> _jaxbContext = JAXBContext.newInstance(ObjectFactory.class);
>>
>> Then it's almost immediate to get the java objects :
>> public void invoke(Source source, AsyncProviderCallback<Source> cbak,
>> WebServiceContext ctxt) {
>> JAXBElement jaxbRequest = (JAXBElement)
>> _jaxbContext.createUnmarshaller().unmarshal(source);
>> GetHelloWorldAsString getHelloWorldAsString =
>> (GetHelloWorldAsString) jaxbRequest.getValue();
>>
>> Then it's "almost" the same thing for the answer :
>>
>> GetHelloWorldAsStringResponse getHelloWorldAsStringResponse =
>> objectFactory.createGetHelloWorldAsStringResponse();
>> getHelloWorldAsStringResponse.setReturn(/*somth*/);
>>
>> JAXBElement<GetHelloWorldAsStringResponse> jaxbResponse =
>> objectFactory.createGetHelloWorldAsStringResponse(getHelloWorldAsStringResponse);
>>
>> ByteArrayOutputStream os = new ByteArrayOutputStream();
>> _jaxbContext.createMarshaller().marshal(jaxbResponse, os);
>> ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray());
>> cbak.send(new StreamSource(is));
>> }
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
I sent the mail before finishing it ...
And so i wanted to conclude by saying that all that was left was doing
some introspection glue in order to map the object to a java method.
But; yeah, there is some work to do before arriving to a "simple"
method call. But it might be re-usable. I'm surprised that it's not
already existing somewhere.
2012/11/12 Gege <ge...@gmail.com>:
>> That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability.
>
> I've been playing around with sun's Provider, the mapping to JAXB
> isn't *very* difficult if you do wsdl-first
>
> Create a context with the generated ObjectFactory class
> _jaxbContext = JAXBContext.newInstance(ObjectFactory.class);
>
> Then it's almost immediate to get the java objects :
> public void invoke(Source source, AsyncProviderCallback<Source> cbak,
> WebServiceContext ctxt) {
> JAXBElement jaxbRequest = (JAXBElement)
> _jaxbContext.createUnmarshaller().unmarshal(source);
> GetHelloWorldAsString getHelloWorldAsString =
> (GetHelloWorldAsString) jaxbRequest.getValue();
>
> Then it's "almost" the same thing for the answer :
>
> GetHelloWorldAsStringResponse getHelloWorldAsStringResponse =
> objectFactory.createGetHelloWorldAsStringResponse();
> getHelloWorldAsStringResponse.setReturn(/*somth*/);
>
> JAXBElement<GetHelloWorldAsStringResponse> jaxbResponse =
> objectFactory.createGetHelloWorldAsStringResponse(getHelloWorldAsStringResponse);
>
> ByteArrayOutputStream os = new ByteArrayOutputStream();
> _jaxbContext.createMarshaller().marshal(jaxbResponse, os);
> ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray());
> cbak.send(new StreamSource(is));
> }
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
> That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability.
I've been playing around with sun's Provider, the mapping to JAXB
isn't *very* difficult if you do wsdl-first
Create a context with the generated ObjectFactory class
_jaxbContext = JAXBContext.newInstance(ObjectFactory.class);
Then it's almost immediate to get the java objects :
public void invoke(Source source, AsyncProviderCallback<Source> cbak,
WebServiceContext ctxt) {
JAXBElement jaxbRequest = (JAXBElement)
_jaxbContext.createUnmarshaller().unmarshal(source);
GetHelloWorldAsString getHelloWorldAsString =
(GetHelloWorldAsString) jaxbRequest.getValue();
Then it's "almost" the same thing for the answer :
GetHelloWorldAsStringResponse getHelloWorldAsStringResponse =
objectFactory.createGetHelloWorldAsStringResponse();
getHelloWorldAsStringResponse.setReturn(/*somth*/);
JAXBElement<GetHelloWorldAsStringResponse> jaxbResponse =
objectFactory.createGetHelloWorldAsStringResponse(getHelloWorldAsStringResponse);
ByteArrayOutputStream os = new ByteArrayOutputStream();
_jaxbContext.createMarshaller().marshal(jaxbResponse, os);
ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray());
cbak.send(new StreamSource(is));
}
Re: Asynchronous
Posted by Daniel Kulp <dk...@apache.org>.
On Nov 12, 2012, at 12:14 PM, Gege <ge...@gmail.com> wrote:
> It does help !
>
> I'm indeed actually trying both apache's CXF and sun's "jaxws-rt +
> jax-rs-ri" and it looks like what i want to do isn't finally so
> simple.
>
> Thanks for pointing out that AsyncProvider is sun-specific. I
> misunderstood and thought that it was some newer feature of jax-ws
> that wasn't implemented yet in CXF. Does that mean that there is no
> "official" way to do an asynchronous implementation of a web-service
> (unlike for jax-rs 2.0) ? I was about to "prefer" sun's impl because i
> thought that i would be building over a standardized API (portability
> for the future).
For a while, I kind of thought they may try and push for a 2.3 version of JAX-WS that would include some server side async stuff, but so far, I haven't heard anything in that regard. Thus, all options right now are proprietary to the implementation/vendor. The 2.2 version of JAX-WS more or less predates the Servlet 3 stuff so async server side really wasn't an option. Now that there are Servlet3 based containers available, it would be work looking at, IMO.
That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability.
> I thought that the whole point of the asynchronous impl would be to
> use transport based on NIO (non-blocking input / output), to be
> thread-efficient.
> So it's interesting to notice that it's not always the case ! I would
> probably had discovered that later... In a less gentle way ^_^
LOL.
The main issue (for both CXF and the RI) is that there isn't any sort of NIO based HTTP client within the JDK. To keep the dependency requirements to a minimum, we both use the HttpURLConnection that is in the JDK by default. There is also a performance impact as all the NIO based implementations seem to be a bit slower than the blocking HttpURLConnection when using synchronous methods. With CXF, even if the non-blocking http transport is on the classpath, by default we'll use the faster HttpURLConnection based client for sync calls. The async transport is just used for async calls.. (that is controllable via settings though)
> The asynchronous jax-rs client isn't a heavy requirement because the
> rest client would be a browser. However the (true) asynchronous
> soap-server, soap-client, rest-server are important points in order to
> have a scalable app. Looks like CXF have them all.
Yep. :-)
Dan
> 2012/11/12 Daniel Kulp <dk...@apache.org>:
>>
>> On Nov 11, 2012, at 7:38 AM, Gege <ge...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
>>> HTTP.
>>>
>>> I want network callflows to be as simple as possible (no callbacks, plain
>>> simple request/answer) and i want to be resources-efficient because some
>>> requests might be long (and i'll have long-polling for events).
>>>
>>> So, I need to have asynchronous implementations (in java) of both client
>>> and servers.
>>>
>>> Here is where i stand:
>>>
>>> SOAP (jax-ws) :
>>> - asynchronous client : OK (wsimport + binding.xml)
>>
>> Kind of. With 2.6.x and old as well as the reference impl of JAX-WS, the async clients still consume a thread per request as the underlying HTTPUrlConnection would require that. Thus, it may not meet your "resource-efficent" requirements.
>>
>> If you use CXF 2.7.0, you can add the Async based http transport which would allow thousands of outstanding calls with a limited thread pool.
>>
>> http://cxf.apache.org/docs/asynchronous-client-http-transport.html
>>
>>
>>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>>> specified in jax-ws 2.2, it's not the most simple to implement (handle the
>>> XML myself...) but it should be able to do the job, might be supported in
>>> jax-ws-ri by sun).
>>
>> The AsyncProvider thing is specific to Sun/Oracles JAX-WS implementation. CXF does not "really" support it. I'm not sure if the @UseAsyncMethod annotation would work with CXF's provider thing. I'd have to test that. Interesting thought.
>>
>> In general, the UseAsyncMethod thing that CXF supports or direct use of the continuations is much more flexible.
>>
>>
>>
>>> REST (jax-rs) :
>>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>>> asynchronous client and I really hope someone can give me a pointer
>>
>> 2.7.0 does add SOME of the JAX-RS async client API's, but I don't think on the wadl2java stuff. The WebClient now has methods that take an InvocationCallback object that can be used to asynchronously get the response. However, same limitations as soap. By default, it would be on a background thread. With the async http transport, we can do more without the 1:1 request:thread relationship. As the JAX-RS 2.0 spec matures, more of this will be updated to support the new asynch features in the spec.
>>
>>
>> Hope all that helps!
>> Dan
>>
>>
>>
>>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
>>> that i'll post once i've tested a bit more
>>>
>>> For now, I feel like there are some pieces missing.
>>> Of course i could implement a REST client myself, but i feel it's a waste.
>>> There are libraries and utilities everywhere and what I want to do seems
>>> pretty much in the scope of jax-rs and jax-ws).
>>>
>>> Thanks in advance.
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Asynchronous
Posted by Gege <ge...@gmail.com>.
It does help !
I'm indeed actually trying both apache's CXF and sun's "jaxws-rt +
jax-rs-ri" and it looks like what i want to do isn't finally so
simple.
Thanks for pointing out that AsyncProvider is sun-specific. I
misunderstood and thought that it was some newer feature of jax-ws
that wasn't implemented yet in CXF. Does that mean that there is no
"official" way to do an asynchronous implementation of a web-service
(unlike for jax-rs 2.0) ? I was about to "prefer" sun's impl because i
thought that i would be building over a standardized API (portability
for the future).
I thought that the whole point of the asynchronous impl would be to
use transport based on NIO (non-blocking input / output), to be
thread-efficient.
So it's interesting to notice that it's not always the case ! I would
probably had discovered that later... In a less gentle way ^_^
The asynchronous jax-rs client isn't a heavy requirement because the
rest client would be a browser. However the (true) asynchronous
soap-server, soap-client, rest-server are important points in order to
have a scalable app. Looks like CXF have them all.
2012/11/12 Daniel Kulp <dk...@apache.org>:
>
> On Nov 11, 2012, at 7:38 AM, Gege <ge...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
>> HTTP.
>>
>> I want network callflows to be as simple as possible (no callbacks, plain
>> simple request/answer) and i want to be resources-efficient because some
>> requests might be long (and i'll have long-polling for events).
>>
>> So, I need to have asynchronous implementations (in java) of both client
>> and servers.
>>
>> Here is where i stand:
>>
>> SOAP (jax-ws) :
>> - asynchronous client : OK (wsimport + binding.xml)
>
> Kind of. With 2.6.x and old as well as the reference impl of JAX-WS, the async clients still consume a thread per request as the underlying HTTPUrlConnection would require that. Thus, it may not meet your "resource-efficent" requirements.
>
> If you use CXF 2.7.0, you can add the Async based http transport which would allow thousands of outstanding calls with a limited thread pool.
>
> http://cxf.apache.org/docs/asynchronous-client-http-transport.html
>
>
>> - asynchronous server : not supported yet by CXF (AsyncProvider is
>> specified in jax-ws 2.2, it's not the most simple to implement (handle the
>> XML myself...) but it should be able to do the job, might be supported in
>> jax-ws-ri by sun).
>
> The AsyncProvider thing is specific to Sun/Oracles JAX-WS implementation. CXF does not "really" support it. I'm not sure if the @UseAsyncMethod annotation would work with CXF's provider thing. I'd have to test that. Interesting thought.
>
> In general, the UseAsyncMethod thing that CXF supports or direct use of the continuations is much more flexible.
>
>
>
>> REST (jax-rs) :
>> - asynchronous client (cxf-wadl2java) : ? i did find anything about
>> asynchronous client and I really hope someone can give me a pointer
>
> 2.7.0 does add SOME of the JAX-RS async client API's, but I don't think on the wadl2java stuff. The WebClient now has methods that take an InvocationCallback object that can be used to asynchronously get the response. However, same limitations as soap. By default, it would be on a background thread. With the async http transport, we can do more without the 1:1 request:thread relationship. As the JAX-RS 2.0 spec matures, more of this will be updated to support the new asynch features in the spec.
>
>
> Hope all that helps!
> Dan
>
>
>
>> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
>> that i'll post once i've tested a bit more
>>
>> For now, I feel like there are some pieces missing.
>> Of course i could implement a REST client myself, but i feel it's a waste.
>> There are libraries and utilities everywhere and what I want to do seems
>> pretty much in the scope of jax-rs and jax-ws).
>>
>> Thanks in advance.
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: Asynchronous
Posted by Daniel Kulp <dk...@apache.org>.
On Nov 11, 2012, at 7:38 AM, Gege <ge...@gmail.com> wrote:
> Hi,
>
> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over
> HTTP.
>
> I want network callflows to be as simple as possible (no callbacks, plain
> simple request/answer) and i want to be resources-efficient because some
> requests might be long (and i'll have long-polling for events).
>
> So, I need to have asynchronous implementations (in java) of both client
> and servers.
>
> Here is where i stand:
>
> SOAP (jax-ws) :
> - asynchronous client : OK (wsimport + binding.xml)
Kind of. With 2.6.x and old as well as the reference impl of JAX-WS, the async clients still consume a thread per request as the underlying HTTPUrlConnection would require that. Thus, it may not meet your "resource-efficent" requirements.
If you use CXF 2.7.0, you can add the Async based http transport which would allow thousands of outstanding calls with a limited thread pool.
http://cxf.apache.org/docs/asynchronous-client-http-transport.html
> - asynchronous server : not supported yet by CXF (AsyncProvider is
> specified in jax-ws 2.2, it's not the most simple to implement (handle the
> XML myself...) but it should be able to do the job, might be supported in
> jax-ws-ri by sun).
The AsyncProvider thing is specific to Sun/Oracles JAX-WS implementation. CXF does not "really" support it. I'm not sure if the @UseAsyncMethod annotation would work with CXF's provider thing. I'd have to test that. Interesting thought.
In general, the UseAsyncMethod thing that CXF supports or direct use of the continuations is much more flexible.
> REST (jax-rs) :
> - asynchronous client (cxf-wadl2java) : ? i did find anything about
> asynchronous client and I really hope someone can give me a pointer
2.7.0 does add SOME of the JAX-RS async client API's, but I don't think on the wadl2java stuff. The WebClient now has methods that take an InvocationCallback object that can be used to asynchronously get the response. However, same limitations as soap. By default, it would be on a background thread. With the async http transport, we can do more without the 1:1 request:thread relationship. As the JAX-RS 2.0 spec matures, more of this will be updated to support the new asynch features in the spec.
Hope all that helps!
Dan
> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes
> that i'll post once i've tested a bit more
>
> For now, I feel like there are some pieces missing.
> Of course i could implement a REST client myself, but i feel it's a waste.
> There are libraries and utilities everywhere and what I want to do seems
> pretty much in the scope of jax-rs and jax-ws).
>
> Thanks in advance.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com