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 [EMAIL PROTECTED] http://dankulp.com/blog
