JNDI, JMS, JPA, XML

Enterprise Java Jan-June 2014

Prepared by: Mr. Hitesh Kumar Sharma & Mr. Ravi Tomar Page 1 Prepared for : B.Tech CS VI Sem (MFT+O&G+OSS+CCVT)

Unit 6: Overview: JNDI, JMS, JPA, XML

Introduction of JNDI

Introduction to JMS, JMS Configuration

Introduction of JPA & XML

Packaging and Deploying J2EE application



1.0. JNDI OVERVIEW

The Java Naming and Directory Interface (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the Java programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of directories new, emerging, and already deployed can be accessed in a common way.

Architecture The JNDI architecture consists of an API and a service provider interface (SPI). Java applications use the JNDI API to access a variety of naming and directory services. The SPI enables a variety of naming and directory services to be plugged in transparently, thereby allowing the Java application using the JNDI API to access their services. See the following figure.

Packaging The JNDI is included in the Java 2 SDK, v1.3 and later releases. It is also available as a Java Standard Extension for use with the JDK 1.1 and the Java 2 SDK, v1.2. It extends the v1.1 and v1.2 platforms to provide naming and directory functionality.



To use the JNDI, you must have the JNDI classes and one or more service providers. The Java 2 SDK, v1.3 includes three service providers for the following naming/directory services:

Lightweight Directory Access Protocol (LDAP) Common Object Request Broker Architecture (CORBA) Common Object

Services (COS) name service Java Remote Method Invocation (RMI) Registry

Other service providers can be downloaded from the JNDI Web site or obtained from other vendors. When using the JNDI as a Standard Extension on the JDK 1.1 and Java 2 SDK, v1.2, you must first download the JNDI classes and one or more service providers. See the Preparations lesson for details on how to install the JNDI classes and service providers.

The JNDI is divided into five packages:

javax.naming javax.naming.directory javax.naming.event javax.naming.ldap javax.naming.spi

1.1.NAMING PACKAGE

The javax.naming package contains classes and interfaces for accessing naming services.

Context

The javax.naming package defines a Context interface, which is the core interface for looking up, binding/unbinding, renaming objects and creating and destroying subcontexts. The most commonly used operation is lookup(). You supply lookup() the name of the object you want to look up, and it returns the object bound to that name. For example, the following code fragment looks up a printer and sends a document to the printer object to be printed.

Printer printer = (Printer)ctx.lookup("treekiller"); printer.print(report);



Names

Every naming method in the Context interface has two overloads: one that accepts a Name argument and one that accepts a java.lang.String name. Name is an interface that represents a generic name--an ordered sequence of zero or more components. For the methods in the Context interface, a Name argument that is an instance of CompositeName represents a composite name , so you can name an object using a name that spans multiple namespaces. A Name argument of any other type represents a compound name. (Names are covered in the Beyond the Basics trail.) The overloads that accept Name are useful for applications that need to manipulate names, that is, composing them, comparing components, and so on.

A java.lang.String name argument represents a composite name. The overloads that accept java.lang.String names are likely to be more useful for simple applications, such as those that simply read in a name and look up the corresponding object.

Bindings listBindings() returns an enumeration of name-to-object bindings. Each binding is represented by an instance of the Binding class. A binding is a tuple containing the name of the bound object, the name of the object's class, and the object itself. list() is similar to listBindings(), except that it returns an enumeration of NameClassPair. NameClassPair contains an object's name and the name of the object's class. list() is useful for applications such as browsers that want to discover information about the objects bound within a context but that don't need all of the actual objects. Although listBindings() provides all of the same information, it is potentially a much more expensive operation.

References Objects are stored in naming and directory services in different ways. A service that supports storing Java objects might support storing an object in its serialized form. However, some naming and directory services do not support the storing of Java objects. Furthermore, for some objects in the directory, Java programs are but one group of applications that access them. In this case, a serialized Java object might not be the most appropriate representation. A reference might be a very compact representation of an object, whereas its serialized form might contain a lot more state.



The JNDI defines the Reference class to represent a reference. A reference contains information on how to construct a copy of the object. The JNDI will attempt to turn references looked up from the directory into the Java objects that they represent so that JNDI clients have the illusion that what is stored in the directory are Java objects.

The Initial Context In the JNDI, all naming and directory operations are performed relative to a context. There are no absolute roots. Therefore the JNDI defines an initial context, InitialContext, which provides a starting point for naming and directory operations. Once you have an initial context, you can use it to look up other contexts and objects.

Exceptions The JNDI defines a class hierarchy for exceptions that can be thrown in the course of performing naming and directory operations. The root of this class hierarchy is NamingException. Programs interested in dealing with a particular exception can catch the corresponding subclass of the exception. Otherwise, they should catch NamingException.

1.2.DIRECTORY PACKAGE

The javax.naming.directory package extends the javax.naming package to provide functionality for accessing directory services in addition to naming services. This package allows applications to retrieve attributes associated with objects stored in the directory and to search for objects using specified attributes.

The Directory Context The DirContext interface represents a directory context. It defines methods for examining and updating attributes associated with a directory object. You use getAttributes() to retrieve the attributes associated with a directory object (for which you supply the name). Attributes are modified using modifyAttributes(). You can add, replace, or remove attributes and/or attribute values using this operation. DirContext also behaves as a naming context by extending the Context interface. This means that any directory object can also provide a naming context. For example, a directory object for a person might contain attributes about that person as well as



provide a context for naming objects, such as the person's printers and file system relative to that person directory object.

Searches DirContext contains methods for performing content-based searching of the directory. In the simplest and most common form of usage, the application specifies a set of attributes--possibly with specific values--to match and submits this attribute set to the search() method. Other overloaded forms of search() support more sophisticated search filters.



2.0. JMS (JAVA MESSAGING SERVICES)

Messaging is a method of communication between software components or applications.

A messaging system is a peer-to-peer facility

o A messaging client can send messages to, and receive messages from, any other

client.

o Each client connects to a messaging agent that provides facilities for creating,

sending, receiving, and reading messages.

Messaging enables distributed communication that is loosely coupled.

o A component sends a message to a destination, and the recipient can retrieve the

message from the destination.

o The sender and the receiver do not have to be available at the same time in order

to communicate.

o The sender does not need to know anything about the receiver; nor does the

receiver need to know anything about the sender.

o The sender and the receiver need to know only which message format and which

destination to use.

Messaging also differs from e-mail.

o E-mail is a method of communication between people or between software

applications and people.

o Messaging is used for communication between software applications or software

components.

2.1.MESSAGE-ORIENTED MIDDLEWARE (MOM)

Message-oriented middleware is a software application or messaging agent that provides

facilities for creating, sending, receiving, and reading messages synchronously or

asynchronously between system components.

A client which produces the message is called a producer and the client which receives the



message is called a consumer. All the messages sent are stored in a particular location which is

called a destination.

2.2. JMS API

The Java Message Service is a Java API that allows applications to create, send, receive, and

read messages. The JMS API defines a common set of interfaces and associated semantics that

allow programs written in the Java programming language to communicate with other

messaging implementations.

The JMS API enables communication that is not only loosely coupled but also,

Asynchronous: A JMS provider can deliver messages to a client as they arrive; a client does not

have to request messages in order to receive them.

Reliable: The JMS API can ensure that a message is delivered once and only once. Lower levels of

reliability are available for applications that can afford to miss messages or to receive duplicate

messages.



2.3.JMS APPLICATION

A JMS application is composed of the following parts:

JMS Clients – These are the Java language programs that send and receive messages.

Non-JMS Clients – These are clients that use a message system’s native client API instead of JMS.

Messages – Each application defines a set of messages that are used to communicate information

between its clients.

JMS Provider – This is a messaging system (MOM) that implements JMS API in addition to the other

administrative and control functionality required of a full featured messaging product.

Administered Objects – Administered objects are preconfigured JMS objects created by an

administrator for the use of clients.

2.4.JMS ADMINISTERED OBJECTS

There are two types of JMS administered objects:

ConnectionFactory – This is the object a client uses to create a connection with a provider.

Destination – This is the object a client uses to specify the destination of messages it is sending and

the source of messages it receives.

Administered objects are placed in a JNDI namespace by an administrator.



2.5.JMS MESSAGING MODELS

The JMS API supports two models:

Point-to-Point (PTP) Model

In point-to-point messaging model, a producer creates and sends a message which will be received

only by a single consumer.

In point-to-point model, the message destination is called “Queue”.

PTP characteristics,

o Each message has only one consumer.

o A sender and a receiver of a message have no timing dependencies. The receiver can fetch

the message whether or not it was running when the client sent the message.

o The receiver acknowledges the successful processing of a message.



Publish/Subscribe Model

In publish/subscribe model, any number of clients can subscribe to a message destination and

when a client sends (publishes) a message to the destination, that message is received by all clients

who have subscribed to that destination.

In this model, the message producer is called publisher and the consumers are called subscribers.

Also the message destination is called “Topic”.

Publish/Subscribe model characteristics,

o Each message can have multiple consumers.

o Publishers and subscribers have a timing dependency. A client that subscribes to a topic

can consume only messages published after the client has created a subscription, and the

subscriber must continue to be active in order for it to consume messages.



2.6.JMS PROGRAMMING MODEL

ConnectionFactory

an administered object that encapsulates a set of connection configuration parameters.

o A client uses it to create a Connection to a JMS provider.

o JMS clients find administered objects by looking them up in a JNDI namespace.

o Connection factories come in two forms implementing either QueueConnectionFactory or

TopicConnectionFactory interfaces.



At the beginning of a JMS client program, you usually perform a JNDI API lookup of the connection

factory.

For example, the following code fragment obtains an InitialContext object and uses it to look up the

QueueConnectionFactory and the TopicConnectionFactory by name. You can choose any of the

below three options based on your requirement. 01

02

03

04

05

06

07

08

09

10

Context context = new InitialContext();

//1. ConnectionFactory

ConnectionFactory connectionFactory =

(ConnectionFactory) context.lookup("ConnectionFactory");

//2. QueueConnectionFactory

QueueConnectionFactory queueConnectionFactory =

(QueueConnectionFactory) context.lookup("QueueConnectionFactory");

//3. TopicConnectionFactory

TopicConnectionFactory topicConnectionFactory =

(TopicConnectionFactory) context.lookup("TopicConnectionFactory");

Connection

encapsulates a virtual connection with a JMS provider.

Like connection factories, connections come in two forms, implementing either the

QueueConnection or the TopicConnection interface.



1

2

3

4

5

6

7

8

//1. Connection

Connection connection = connectionFactory.createConnection();

//2. QueueConnection

QueueConnection queueConnection =

queueConnectionFactory.createQueueConnection();

//3. TopicConnection

TopicConnection topicConnection =

topicConnectionFactory.createTopicConnection();

A JMS client usually creates a connection, one or more sessions, and a number of message

producers.

When an application completes, you need to close any connections that you have created. Closing

a connection also closes its sessions and their message producers and message consumers. 1

2

3

connection.close();

queueConnection.close();

topicConnection.close();

Destination

A Destination object is a JMS administered object that encapsulates a provider-specific address for

storing and retrieving messages.

Destination, like session, comes in two forms, implementing either the Queue or

the Topicinterface.



We use Session object to create a destination

Client uses JNDI API to look up destination. The following line of code looks up a queue and a

topic. 1

2

3

Destination destination = (Queue)context.lookup(“queue/MyQueue”);

Queue queue = (Queue)context.lookup(“queue/MyQueue”);

Topic topic = (Topic)context.lookup(“topic/MyTopic”);

Session

Session is a lightweight JMS object which acts as a single-threaded context for producing and

consuming messages. Session creates,

o Message producers,

o Message consumers,

o Messages,

o Message Destination (Queue or Topic)

Sessions, like connections, come in two forms, implementing either the QueueSession or the

TopicSession interface.

We use Connection object to create a session.



1

2

3

4

5

6

7

8

//1. Session

Session session = connection.createSession(false,

Session. DUPS_OK_ACKNOWLEDGE);

//2. QueueSession

QueueSession queueSession = queueConnection.createQueueSession(false,

Session.AUTO_ACKNOWLEDGE);

//3. TopicSession

TopicSession topicSession = topicConnection.createTopicSession(true, 0);

Message

JMS application produces and consumes message.

The Message interface is the root interface of all JMS messages. There are five types of message:

BytesMessage, TextMessage, ObjectMessage, StreamMessage and MapMessage.

We use Session object to create a message



1

2

3

4

5

6

TextMessage message = session.createTextMessage();

message.setText("Hello EJB3 MDB!!!");

BytesMessage byteMessage = session.createBytesMessage();

MapMessage mapMessage = session.createMapMessage();

StreamMessage streamMessage = session.createStreamMessage();

ObjectMessage objMsg = session.createObjectMessage();

MessageProducer

A message producer is an object created by a session and is used for sending messages to a

destination.

MessageProducer comes in two forms implementing either the QueueSender or the TopicPublisher

interface.

We use Session object to create a message producer.

The following snippet shows how to create a message producer, queue sender and a topic

publisher. 1

2

3

MessageProducer producer = session.createProducer(destination)

QueueSender queueSender = queueSession.createSender(queue);

TopicPublisher topicPublisher = topicSession.createPublisher(topic);

Once a message producer is created, you can use it to send messages.

1 queueSender.send(message);



2 topicPublisher.publish(message);

MessageConsumer

an object created by a Session that is used for receiving messages sent to a destination.

2.7.MESSAGE DRIVEN BEAN

A message-driven bean (MDB) is an enterprise bean that allows Java EE applications to

process messages asynchronously. In other words, an MDB is anasynchronous message

consumer.

A message-driven bean is invoked by the container as a result of the arrival of a message at

the destination or endpoint that is serviced by the message-driven bean.

The messages can be sent by any Java EE component (an application client, another

enterprise bean, or a web component) or by a JMS application or system that does not use Java

EE technology.

A message-driven bean instance is created by the container to handle the processing of the

messages for which the message-driven bean is the consumer. Its lifetime is controlled by the

container.

When a message arrives, the container calls the message-driven bean’s

onMessage(Message message) method to process the message. The onMessage() method

normally casts the message to one of the five JMS message types and handles it in accordance

with the application’s business logic. The onMessage() method can call helper methods or can

invoke a session bean to process the information in the message or to store it in a database.



Messaging using MDB Consumer

2.8.MDB CHARACTERISTICS

Message-driven beans have the following characteristics.

They execute upon receipt of a single client message.

They are invoked asynchronously.

They are relatively short-lived.

They do not represent directly shared data in the database, but they can access and update

this data.

They can be transaction-aware.

They are stateless.

2.9.LIFECYCLE CALLBACK METHODS

The following lifecycle event callbacks are supported for message-driven beans.

PostConstruct

The PostConstruct callback occurs after the container creates a new instance of MDB and before

the first message listener method invocation on the bean. This is at a point after which any

dependency injection (DI) has been performed by the container.



PreDestroy

The PreDestroy callback occurs before the bean is removed from the pool or destroyed.

The PostConstruct and PreDestroy lifecycle callback interceptor methods execute in an

unspecified transaction and security context.

2.10.MDB LIFECYCLE

When a client sends a message to a Destination for which a message-driven bean is the

consumer, the container selects one of its method-ready instances and invokes the instance’s

message listener method.

The following steps describe the life cycle of a message-driven bean instance:

A message-driven bean instance’s life starts when the container invokes newInstance on the

message-driven bean class to create a new instance.



Next, the container injects the bean’s MessageDrivenContext, if applicable, and performs any

other dependency injection as specified by metadata annotations on the bean class or by the

deployment descriptor.

The container then calls the bean’s PostConstruct lifecycle callback methods, if any.

The message-driven bean instance is now ready to be delivered a message sent to its associated

destination or endpoint by any client or a call from the container to a timeout callback method.

When the container no longer needs the instance (which usually happens when the container

wants to reduce the number of instances in the method-ready pool), the container invokes

thePreDestroy lifecycle callback methods for it, if any. This ends the life of the message-driven

bean instance.



3. JPA (JAVA PERSISTENCE API)

The process of mapping Java objects to database tables and vice versa is called "Object-relational

mapping" (ORM). The Java Persistence API (JPA) is one possible approach to ORM. JPA is a

specification and several implementations are available. Popular implementations are Hibernate,

EclipseLink and Apache OpenJPA. The reference implementation of JPA is EclipseLink. Via JPA the

developer can map, store, update and retrieve data from relational databases to Java objects and

vice versa. JPA permits the developer to work directly with objects rather then with SQL statements.

The JPA implementation is typically called persistence provider. JPA can be used in Java-EE and Java-

SE applications. The mapping between Java objects and database tables is defined via persistence

metadata. The JPA provider will use the persistence metadata information to perform the correct

database operations. JPA typically defines the metadata via annotations in the Java class.

Alternatively the metadata can be defined via XML or a combination of both. A XML configuration

overwrites the annotations. The following description will be based on the usage of annotations. JPA

defines a SQL-like Query language for static and dynamic queries. Most JPA persistence provider

offer the option to create automatically the database schema based on the metadata.

3.1. ENTITY

A class which should be persisted in a database it must be annotated with javax.persistence.Entity. Such a

class is called Entity. JPA will create a table for the entity in your database. Instances of the class will

be a row in the table. All entity classes must define a primary key, must have a non-arg constructor

and or not allowed to be final. Keys can be a single field or a combination of fields. JPA allows to

auto-generate the primary key in the database via the @GeneratedValue annotation. By default, the table

name corresponds to the class name. You can change this with the addition to the annotation

@Table(name="NEWTABLENAME").

3.2. PERSISTENCE OF FIELDS

The fields of the Entity will be saved in the database. JPA can use either your instance variables

(fields) or the corresponding getters and setters to access the fields. You are not allowed to mix both

methods. If you want to use the setter and getter methods the Java class must follow the Java Bean

naming conventions. JPA persists per default all fields of an Entity, if fields should not be saved they

must be marked with @Transient.



By default each field is mapped to a column with the name of the field. You can change the default

name via @Column(name="newColumnName").

The following annotations can be used.

Table 1. Annotations for fields / getter and setter

@Id Identifies the unique ID of the database entry

@GeneratedValue Together with ID defines that this value is generated automatically.

@Transient Field will not be saved in database

3.3. RELATIONSHIP MAPPING

JPA allows to define relationships between classes, e.g. it can be defined that a class is part of

another class (containment). Classes can have one to one, one to many, many to one, and many to

many relationships with other classes. A relationship can be bidirectional or unidirectional, e.g. in a

bidirectional relationship both classes store a reference to each other while in an unidirectional case

only one class has a reference to the other class. Within a bidirectional relationship you need to

specify the owning side of this relationship in the other class with the attribute "mappedBy",

e.g. @ManyToMany(mappedBy="attributeOfTheOwningClass".

@OneToOne

@OneToMany

@ManyToOne



Table 2. Relationship annotations

3.5. ENTITY MANAGER

The entity manager javax.persistence.EntityManager provides the operations from and to the database, e.g.

find objects, persists them, remove objects from the database, etc. In a JavaEE application the entity

manager is automatically inserted in the web application. Outside JavaEE you need to manage the

entity manager yourself. Entities which are managed by an Entity Manager will automatically

propagate these changes to the database (if this happens within a commit statement). If the Entity

Manager is closed (via close()) then the managed entities are in a detached state. If synchronize

them again with the database a Entity Manager provides the merge() method. The persistence

context describes all Entities of one Entity manager.

3.6. PERSISTENCE UNITS

The EntityManager is created by the EntitiyManagerFactory which is configured by the persistence unit. The

persistence unit is described via the file "persistence.xml" in the directory META-INF in the source

folder. A set of entities which are logical connected will be grouped via a persistence unit.

"persistence.xml" defines the connection data to the database, e.g. the driver, the user and the

password,

@ManyToMany

JNDI, JMS, JPA, XML

Education

java naming

naming javax

naming services

jndi api

jndi classes

directory interface

jndi architecture

enterprise java