> This ResponseDispatch proposal is specifically for "long running" async(LRA)
> operation in which case the request information may need to be stored and
> retrieved later when the response is ready. The ResponseDispatch is intended
> encapsulate the correlation between the request and response.
> If the "long running" situation is taken into the consideration, several of
> romixlev's questions might be answered.
I understand that the main focus of the proposal is more on really "long
running" async operations (where long may mean minutes, hours, days).
But on my side, I have more interest in the scalability in terms of number of
requests that can be accepted for processing and processed simultaneously. I
would like to escape the "one-thread-per-request" model, which limits this kind
of scalability. I'd like to be able to accept dozens or even hundreds of
thousands of requests. Each of these requests is not very long running, but
there is a huge number of such requests. Deploymens on the AS and triggering via
HTTP Servlets just does not scale to this extent (mainly due to the one thread
per request approach). We started looking into a standalone usage of JAX-WS (may
be via Grizzly) to overcome some of these issues.
Applications that I have in mind are sort of workflows (distantly similar to
BPEL) exposed via WS. Such workflows receive a huge number of triggering
requests (e.g. from different users) and reacts to them by e.g. invoking other
external SOAP web services based on dynamic conditions and then returning the
results of such invocations back to the caller. Most of the time, these
workflows actually wait for the completion of those external WS invocations.
Once external WS returns a value, it is propagated to the original caller that
triggered the workflow.
As you can imagine, while waiting for results of external WS, the workflow WS
just occupies the thread even though it does not consume any CPU time. This may
result in the situation, where all available threads just wait and no new
request can be processed as all of the threads are occupied. Such outcome is of
course very unfortunate. Therefore, the ability to decouple request processing
from the receiving thread (so that it can be freed for more meaningful tasks
than waiting) and ability to return results later (eventually inside a different
thread) is a very nice solution to this problem.
As far as I understand, your proposal would easily cover such a scenario and
eventually much more.
BTW, I'm aware that there are some other potential solutions, like JMS, etc. But
mentioned workflows should be easy to integrate with e.g. Web 2.0 application.
So, use of JMS is not really an option.
> Because it is long running, the client
> app most likely will not want to call it in the synchronous style, and it has
> use some protocol support (ex. ws-addressing) in order to be async.
See my above comments. Invocations of workflows are not so long running that
clients always need to provide callbacks via WS-Adressing or do polling. More
over, many of Web 2.0 clients cannot easily support WS-addressing.
And then, such an explicitly asynchronous solution requires that both sides
follow this architecture. This is probably fine, if you control (development and
execution) both sides. But in my case, many client apps are developed and
controlled by 3rd parties. Therefore, I cannot force all of them to follow this
way of communication, but still want to support them as good as I can.
> A LRA operation is allowed to use user-defined value types as long as the
> types are supported by JAXB2. The type argument of ResponseDispatch is mapped
> the output message of the wsdl operation. LRA operation is for both java2wsdl
> and wsdl2java. In java2wsdl, in addition to use a parameterized
> as parameter to make a method LRA, we may want to add some new annotations
> @AsyncFault). In wsdl2java, a new wsdl2java customization element may be used
> generate a LRA style method from a wsdl request-response operation. The
> are still under discussion.
OK. I see how you would do java2wsdl and wsdl2java mappings. But what I meant
with my comment is:
Yes, this can be done as you describe. But it would require changes in the
tooling for doing these mappings.
And even more important, it would require that a developer adds a new
ResponseDispatch parameter to the signature of the exposed web method, even
though this parameter is not a real parameter passed by a web service client.
This parameter is actually inserted/injected by the run-time. Why is the return
type in the signature of the exposed method void? And why does the type argument
of this special parameter ResponseDispatch becomes the output message of the
WSDL operation? For usual exposed web methods it would be handled totally
differently. Their return type would be mapped to the output message of the WSDL
operation, wouldn't it?
So, I'm asking if the proposed method of mapping is the most natural way of
doing it? Wouldn't a more transparent approach be easier to use and also require
less modifications in the tooling? In the ideal case, it should be actually
almost transparent for the developer. It should be as easy as adding an
annotation on the web method or having an XML descriptor describing which
methods should be handled asynchronously. BTW, if signatures of web methods are
not touched by LRA, it can be even possible to add such annotations
programatically at run-time (e.g. AOP, etc) to any JAX-WS web service, which
potentially opens up some interesting opportunities.
> If you don't expect your business logic takes a long time to complete, you do
> not need to use this ResponseDispatch programming model. I believe JAX-WS has
> (or will have in near future) the annotations to mark an normal method as
> so that the container knows to deliver the response in async fashion.
Could you elaborate a bit more on this? What annotations exactly do you have in
mind? Can you provide any concrete references?
> I certainly agreed with romixlev in that we want to improve the JavaEE
> programming model so that it supports more scalable implementation. It is not
> clear to me how the LRA/ResponseDispatch programming model could also
> accommodate the threading discussion romixlev had. We would like to have more
> information on this.
OK. I just wanted to say, that there are some very popular non JavaEE frameworks
and languages (Scala, Clojure, Groovy, J-you-name-it, etc) that still use Java
or at least JVM. Those systems could also greatly benefit from using JAX-WS.
Many of these systems do not have some of JavaEE limitations like lack of
explicit control over multi-threading, etc. Some of those system are
significantly more scalable and even provide alternative multi-threading
implementations, e.g. light-weight threads (e.g. Kilim can start 1000000 light-
weight threads on a usual JVM). As you can imagine, it may slightly shift the
perspective. With that in mind, all parts of the spec that somehow depend on
multi-threading or implicitly rely on JavaEE semantics of it may require a
review. It may turn out that these parts of the spec just assume too much, e.g.
that everyone uses only Executors or that number of threads should be kept
In understand, that JSRs are written and agreed in such a way, that it is
"doable" to implement them on a typical deployment platform, which is in many
cases JavaEE. But I think that in general JSRs(especially those representing
major stacks like SOAP, REST and so on) should not ignore or underestimate all
those mentioned alternative systems and frameworks running on top of Java or
JVM, just because they are not part of JavaEE or the like. Eventually, those
systems will become a mainstream. It is better for JSRs and RIs based on it to
be a part of this evolving infrastructure. Otherwise, there is a change to