Hello there. In this lesson, we'll talk about JMS API. So, let's start. Messaging in Java is mostly represented by JMS, which can be used in applications running in a standard Java SC or an enterprise Java EE environment. MDBs simply represent a way for stateless session EJBs to be message consumers and are bound to the EJB specification. Up until the late 1980s, companies did not have an easy way to link different applications. Developers had to write separate software adapters for systems to translate data from source applications into a format that the destination system could understand and vice versa. Because of the disparity of servers processing capabilities and availabilities, buffers were created to decouple the processing, so that the overall time wouldn't be prolonged. A lack of homogeneous transport protocols created low-level protocol adapters. Toward the end of the 1980s, middleware began to emerge, which solved these integration issues. The first MOMs were created as separate pieces of software that could sit in the middle of applications and manage the plumbing between systems.

They were able to manage different platforms, different programming languages, various network protocols, and diverse hardware. The JMS specification was first published in August 1998. It was created by the major middleware vendors to bring messaging capabilities to Java. JSR 914 went through minor changes: JMS 1.0.1,  1.0.2, and 1.0.2b to finally reach the 1.1 version in April 2002. JMS 1.1 was integrated into J2EE 1.2 and has been a part of Java EE since. However, JMS and MDBs are not part of the web profile specification. This means they are only available on application servers implementing the full Java EE 7 platform. JMS 1.1 didn't change for more than a decade. Since Java EE 5, the APIs have slowly been modernized to fit the language changes, annotations, generics except for JMS. It was time for JMS to follow the same path; make use of the annotations and simplify its API. In fact, several changes have been made to the JMS API to make it simpler and easier to use.

Connection, session, and other objects with the close() method now implement the java.jang.AutoCloseable interface to allow them to be used in a Java SE 7 try-with-resources statement. A new simplified API has been added, which offers a simpler alternative to the standard and legacy APIs. A new method, getBody, has been added to allow an application to extract the body directly from the message without the need to cast it first to an appropriate subtype. A set of new unchecked exceptions have been created, all extending from JMS runtime exception. New send methods have been added to allow an application to send messages asynchronously. Most of the communications between components that you have seen so far are synchronous. One class calls another. A managed bin invokes in EJB, which calls an entity and so on. In such cases, the invoker and the target must be up and running for the communication to succeed. And the invoker must wait for the target to complete before proceeding. With the exception of asynchronous calls in EJB, thanks to the @Asynchronous annotation, most Java EE components use synchronous calls, local or remote. When we talk about messaging, we mean loosely coupled asynchronous communication between components.

Message-Oriented Middleware, MOM, is software; a provider that enables the exchange of messages asynchronously between heterogeneous systems. It can be seen as a buffer between systems that produce and consume messages at their own pace. Example, one system is 24/7, the other only runs at night. It's inherently loosely coupled as producers don't know who is at the other end of the communication channel to consume the message and perform actions. The producer and the consumer do not have to be available at the same time in order to communicate. In fact, they don't even know about each other and they use an intermedia buffer. In this respect, MOM differs completely from technologies such as Remote Method Invocation, RMI, which require an application to know the signature of a remote applications methods. Today, a typical organization has many applications often written in different languages that perform well-defined tasks. MOM is based on an asynchronous interaction model, so it allows these applications to work independently, and at the same time, form part of an information workflow process.

Messaging is a good solution for integrating existing and new applications in a loosely coupled asynchronous way as long as the producer and consumer agree on the message format and the intermediate destination. This communication can be local within an organization or distributed among several external services. So, that's it. Hope to see you in our next lesson. Have a nice day.