Is the continuation features of Jetty not needed with servlet 3.0 asychronous I/O?
Is there a difference or how should I as a developer see things? Can someone elaborate on this topic?
If you know that you are always deploying to a Servlet 3.0 compliant container, and you are comfortable with the asynchronous servlet API, then there's no need for Jetty continuations.
The two things continuations give you are:
They have an (arguably) simpler API.
They are (somewhat) portable to servlet 2.x containers.
To be clear on this last point, the continuation API is portable between containers, but it has the following behaviour:
On Jetty 6, 7 or 8 it will use Jetty's native asynchronous functionality
On servlet 3.0 containers it will use the asynchronous servlet API
On other (2.x) containers it will behave synchronously.
Some more info (but getting a little dated) is available here
The continuation filter was kind of a hot fix in order to overcome the issue of the servlet API (which basically is thread per request) and server push functionalities. The async Feature defined in servlet API 3.0 replaces this Filter and allows asynchrounous processing of a request based in configuration in your Web.xml.
Related
Different services version could support different features.
For example version 1 of service not support feature x, but version 2 support feature x.
Is there are some standard or practical way to inform which features are supported in current service version?
I think to some way that information could be obtained from commit descriptions. Is there some standard to obtain that information? Or should every service inform about it in own way.
Or should every service inform about it in own way.
Don't do this. This will couple your service with others. Others shouldn't know how to handle your version, but you should know how to handle different versions.
If you use REST and synchronous communication between microservices, you have to look at REST API Versioning or here. This type of versioning allows you to have multiple versions running in the same infrastructure. Then, each microservice should know how to call a specific version of a microservice.
If you have asynchronous communication with an Event Bus, then your Emitter should send backward-compatible events, to not break other microservices.
We have a system using EJB 3 Stateless bean which is also exposed as web service.
There's a integration request from other team that want our system to fire a notification to other system after invocation (by web services or other means). Since this is not totally related to our system I would prefer to have this feature loosely coupled with our own system instead of hard coding these features in to our system code.
Is there any feature on EJB or web services that can achieve what I desire? We would require a method level invocation listener so that when the EJB method/ web service get invoked, it can trigger a callback/message so we can do something according to it. I would expect it to be some kind of annotation/configuration for setting up JMS or something.
We are using JBoss as the application server. If there's any JBoss specific solution it's also welcomed.
I would suggest two options:
use JMS. When you mentioned loose coupling, JMS first crossed my mind - you can put a message on some queue/topic after method invocation and let the listener to perform futher actions. JMS messages can carry various kinds of objects - the only request is that class implements Serializable (ObjectMessage#setObject); other advantage is that you can (un)deploy your Stateless bean and other system independently. They can be on different JVMs.
use Interceptors. Technically, they would be invoked before your methods runs, but of course there is always some nice workaround :-) Here is the official documentation about Interceptors, but since you mentioned that you're using JBoss, there can be also found some interesting material on JBoss pages.
I am a novice in C++, but have a lot of experience in Java EE.
I need to write a small app which is heavily asynchronous. It receives data from HTTP and stores it in a Queue (it needs to have guaranteed delivery and very high throughput), something like ActiveMQ or OpenMQ, maybe via JMS.
Then another C++ app/listener takes out data from the Queue (through some Listener which is activated by the Queue directly, not by my pooling), connects to a MySQL database and does some business logic calculations and sends the message to another Queue.
In Java EE this would be a web app that would send messages to a JMS queue. Message-Driven Beans would be consumers of these messages in an EJB module, and a Session EJB would send messages to the outgoing JMS queue.
Can someone with C++ experience please explain some basics to me:
Is JMS the only option for C++ for guaranteed delivery Queues? Do you suggest ActiveMQ or something else, having in mind that the message Consumer would be in C++.
Do I need to create some kind of a multi-threaded daemon in C++ that listens for Queue messages, or is this thread creation (message consumption) part of ActiveMQ's implementation of C+ consumers?
Any other suggestions on how to implement the scenario above would be very much appreciated.
EDITED: I would prefer a message broker and client to be in C++. ActiveMQ is a Java product, which is not really what we need.
1 - JMS - Java Message Service - is just an API reference for Java and Java only. There is no standard in messaging that applies to C++ except for AMQP (which is, to my opinion, not really working cross implementation as good as it should). To C++ you kinda have to rely on specific vendor libraries for each message broker implementation.
Suggestions of implementations:
ActiveMQ - It has a nice C++ API (Called CMS) which is modeled and named after JMS - so you will feel familiar with the API. The main broker will run on Java non the less - might be the simplest choice.
IBM WebSphere MQ - Not open source, enterprise class broker that runs native (written in C), and has C++ libraries. Rather nice when you get over the learning curve and the price does not matter.
RabbitMQ - Very popular reliable messaging with high performance and open source. Has C++ client libs but is written in Erlang and runs within the erlang/otp runtime.
Apache QPID - Less known AMQP/JMS broker. Comes in two flavours server side, Java and C++ where the C++ broker has better performance. Comes with C++ client libs.
2 - For multi threading, the JMS specs does not really come with a solution either. It's more like the Java EE container (or Spring Framework) that simply wrapps the management of threads and relieves the developer from it. ActiveMQ does not come with much more than a few support classes in this case and as far as I know, none of the other vendor libraries does either. So, look for some library that wrapps threading (I have no clue) or deal with the consumer threads yourself. It shouldn't all that messy, done right.
According to literature on the web, I can see that there are two specifications related to Web Services Eventing:
WS-BaseNotification - submitted by OASIS in 2004
WS-Eventing - submitted by W3C in 2006
To me, both seem to have the same functionality. What is the most acceptable specification in the industry now?
You can't compare SOAP (message encoding part of webservices stack) with AMQP or JMS (also transfer protocol). With SOAP 1.2 you can use JMS transport binding (only for RPC). AMQP builds on TCP, so you can use "SOAP over AMQP" as well as "SOAP over TCP". You can see this paper to see where SOAP in webservices stack relies.
To the question.
Two competing standards:
WS-Eventing W3C Public Draft
WS-Notification 1.3 OASIS-Standard (replaced WS-Events), which grew to family of 3 specs:
WS-BaseNotification (very similar to WS-Eventing)
WS-BrokeredNotification (optional)
WS-Topics (optional)
are also converging in each version update.
There is no "leader" in the industry.
WS-Eventing is simpler sister of WS-Notification, which can be advantage in some cases. For example WS-Eventing doesn't define Pause/ Resume Subscription (but you can unsubscribe/subscribe), broker intermediary (but there is a way to do it), etc.
Implementation which can intelligently switch between these ws-* specifications can be found here.
The way, how to add message queuing, isn't defined by any. This is where AMQP binding or websocket subprotocols binding will play the role in the future of webservices stack, I think.
I think most people these days would not use SOAP but rather rely on simpler protocols (AMQP/JMS in this case) but if you do need/want to use SOAP WS-Notification (which is the parent standard for WS-BaseNotification) is the more widely supported protocol (e.g. by ServiceMix or IBM WebSphere)
There is an excellent article by Young Yang that explains how to use wsimport to create web service client artifacts that have asynchronous web service calls. Asynchrony requires that the WSDL has the tag
<enableAsyncMapping>true</enableAsyncMapping>
in its bindings section. If you are using the bottom-up approach with JAX-WS annotated Java classes you can't do this directly in the WSDL because the WSDL is a generated artifact on the web server. Instead you use build tools like Ant or Maven to include this binding when wsimport is executed on the WSDL.
The generated client artifacts have asynchronous method calls that return a
Future<?>
or a
Response
which is a Future.
My question after reading Yang's article is why not just roll my own asynchronous web service calls using Executors and Futures. Do the artifacts created by wsimport offer some advantage that I can't see over a roll-your-own approach?
If anyone has experience or insight with both approaches I would appreciate your feedback.
In theory, the generated asynchronous clients wouldn't need to block threads. By passing an AsyncHandler, the system can use NIO to register for an event when the web service call is complete, and it can call that handler. No threads need to block at all.
If you put your synchronous web service call into an executor, it will still end up blocking a thread until the result arrives, although at least this blocking is limited to the thread pool in the executor.
As soon as you have many hundreds of threads floating around, your system performance will degrade due to context switching.
Whether the web service library under the hood actually uses NIO is another matter. It doesn't appear to be required by the JAX-WS specification. Using JDK 1.6 and setting a break point server side, I set 100 clients off to call the server. Using JVisualVM I attached to the client and could see that it had created one new thread per call to the server. Rubbish!
Looking around on the web I found that Apache CXF supports limiting the pool of threads used in async calls. Sure enough, using a client generated with CXF and putting the right libraries on the classpath as discussed here, a retest showed that only 25 threads were being used.
So why use the jax-ws API rather than build your own? Because building your own takes more work ;-)
I know that it does not reach the prompted question, but just complementing one information included on question:
"Instead you use build tools like Ant or Maven to include this binding when wsimport is executed on the WSDL."
It is possible generate the asynchronous client by a adding a custom xml file using the option -b to the wsimport:
Example:
wsimport -p helloAsyncClient -keep http://localhost:8080/helloservice?wsdl -b customAsync.xml
The customAsync.xml content:
<jaxws:bindings
wsdlLocation="http://localhost:8080/helloservice?wsdl"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws">
<jaxws:enableAsyncMapping>true</jaxws:enableAsyncMapping>
</jaxws:bindings>
It is just one more way to generate asynchronous client beyond by using ant or maven :)