- Hands-On Cloud:Native Microservices with Jakarta EE
- Luigi Fugaro Mauro Vocale
- 295字
- 2021-07-02 13:47:11
Messaging communications
Java EE offers the ability to implement loosely coupled services that can communicate with each other, maintaining a guarantee of delivery and fault tolerance. This feature is implemented through the JMS that was introduced in Java EE since the beginning of the platform. The purpose of this specification is to decouple services and process messages, producing and consuming them asynchronously.
The new version of the specification, JMS 2.0, which was introduced in Java EE 7, simplifies the use of this specification and reduces the boilerplate that's needed to implement the message producers and consumers.
The following is an easy example of a message producer:
public class AuthorProducer {
@Inject
private JMSContext jmsContext;
@Resource(lookup = "jms/authorQueue")
private Destination queue;
/**
* Send Message.
*/
@Override
public void sendMessage(String message) {
/*
* createProducer: Creates a new JMSProducer object that will be used to
* configure and send messages.
*/
jmsContext.createProducer().send(queue, message);
}
}
Now, it's time to implement the consumer:
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "jms/authorQueue")})
public class AuthorMDB implements MessageListener {
/**
* @see MessageListener#onMessage(Message)
*/
public void onMessage(Message rcvMessage) {
TextMessage msg = null;
try {
if (rcvMessage instanceof TextMessage) {
msg = (TextMessage) rcvMessage;
System.out.println("Received Message from queue: " + msg.getText());
} else {
System.out.println("Message of wrong type: " + rcvMessage.getClass().getName());
}
} catch (JMSException e) {
throw new RuntimeException(e);
}
}
}
It's easy to implement decoupling messaging services in Java EE.
Obviously, this is not enough to declare that the traditional Java EE approach is reactive-friendly.
But the approach we described above can help you update your traditional monolith to be less synchronous and less I/O blocking to better serve the new way to design enterprise and cloud-native architecture.