Hello, dear friends. In this video, we will continue examining components with administered objects. Let's begin. Administered objects are objects that are configured administratively as opposed to programmatically. The message provider allows these objects to be configured and then, makes them available in the JNDI name space. Like JDBC data sources, administered objects are created only once. There are two types of administered objects; connection factories and destinations. Connection factories are used by clients to create a connection to a destination. Destinations are message distribution points that receive, hold, and distribute messages. Destinations can be queues, DTP or topics, pub/sub. Clients access these objects through portable interfaces by looking them up in the JNDI name space or through injection. In the GlassFish server, there are several ways to create these objects either by using the administration console with the as admin command or the REST interface. Since JMS 2.0, you can even use the JMS connection factory definition and JMS destination definition annotations to define these objects programmatically.

JMS is a standard Java API that allows applications to create, then receive and read messages asynchronously. It defines a common set of interfaces and classes that allow programs to communicate with other message providers. JMS is analogous to JDBC. JMS connects to several databases like Derby, MySQL, Oracle, DB2 etc., and connects to several providers like OpenMQ, MQ Series, SonicMQ etc. The JMS API has evolved ever since its creation. For historical reasons, JMS offers three alternative sets of interfaces for producing and consuming messages. These very different interfaces evolved in JMS 1.0, 1.1, and 2.2 and are referred to as legacy API, classic API and simplified API respectively. JMS 1.0 made a clear difference between the point-to-point and publish subscribe bottles. It defined two domain specific APIs, one for point-to-point use and one for pub/sub topics. That's why you can find QueueConnectionFactory and TopicConnectionFactory API instead of the generic connection factory.

For example, the JMS 1.1 API also known as the classic API provided a unified set of interfaces that could be used with both P-to-P and pub/sub messaging. Here, this table shows the generic name of an interface and the legacy names for each model QueueSession and TopicSession. As you can see in this table, JMS can consist of seven different components. Also in this table, you can see the JMS exception. We will examine these components in the next video. But first, we have to talk about the JMS version history. JMS 1.1 was still a verbose and low level API compared to JPA or EJB. JMS 2.0 introduces a simplified API that offers all the features of the classic API but requires fewer interfaces and is simpler to use. I will not discuss the legacy API, but I need to introduce the classic API because first of all, you will still find millions of lines of code using the JMS 1.1 classic API. And second, this simplified API technically relies on the classic one. The JMS classic API provides classes and interfaces for applications that require a messaging system.

This API enables asynchronous communication between clients by providing a connection to the provider and a session where messages can be created, sent or received. These messages can contain text or other different kinds of objects. I think that's enough for this video. Let's take a break here. In the next video, we will continue exploring JMS with API components. See you in the next video.