cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Jetty Continuations in CXF
Date Mon, 03 Nov 2008 15:57:10 GMT
On Monday 03 November 2008 9:41:59 am Sergey Beryozkin wrote:
> Hi,
>
>
> It's an interesting idea. Worth having it in mind. However, I'm thinking,
> how reasonable it is to expect that a user would want to write a
> Continuations code portable across multiple transports ? I'd imagine that a 
> user which wishes to do explicit continuations would do them with HTTP
> transport in mind, well, at least now that Jetty Continuations are
> available, 

No.   I actually expect this to be more important for the JMS folks than the 
HTTP folks which is why it needs to be transport independent.   Basically, 
MOST HTTP users expect a fairly synchronous invokation path.   That's pretty 
much how its "always been" so people using HTTP, unless they specifically 
know about the jetty continuations, wouldn't even think about it.    JMS 
folks on the other hand are much more in tuned to the ideas around 
asynchronous communication and events.    

> with Servlet 3.0 supporting suspended invocations too. Otherwise 
> we'd need to come up with our own ContiniationsSupport and Continuation
> classes - that's why would user use JettyContiations support and expect ths
> code work say with JMS or indeed with some other transport other than HTTP
> ?

We also promote the idea that the same "impl" can be used on multiple 
transports/bindings.   Thus, the continuation code needs to be abstracted out 
to hide the underlying transport. 

Also, I've started looking into the MINA based HTTP stuff (mostly for Async on 
the client side, but also as a possible Jetty replacement).   Thus, this 
needs to be abstracted out so that if we do replace Jetty, existing code 
would still work.


> I think we have two scenarious to look at. First one is when a CXF acts as
> a request provider for some ServiceMix components (implicitly serving as
> 'application code') - which is what CXF-1835 is mostly about.

Right.  Which can be JMS or HTTP or CORBA or .....     The ServiceMix 
components pretty much do exactly what an Impl would do except they have 
direct access to the message instead of the WebServiceContext.   Thus, either 
way, we need to abstract it out a bit.


> Another one is about CXF service application code doing Continuations
> 
> I think it does - but I'd just like to start with just HTTP in mind, just
> to get going and consider a transport portability issue at the the next
> stage.

I'd have to say -1 to that.   Or at least it doesn't get merged up into any of 
the 2.1.x/2.0.x branches until it's completely abstracted.   Once it gets 
merged up and potentially released, we need to support it as is relatively 
indefinitely and I don't want to support a "half baked" solution that is tied 
directly to a particular http implementation.  


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message