J2EE

Differences between Point to Point Messaging Model and Publish Subscribe Messaging Model

May 2, 2017 By j2eereference Leave a Comment

Differences between Point to Point Messaging Model and Publish Subscribe Messaging Model is explained in this article. Point to Point Messaging Model and Publish Subscribe Messaging Model are the two different messaging paradigms supported by Java Message Service (JMS). These messaging paradigms are programming models that support asynchronous way of messaging between diverse systems.

Listed below are the differences between Point to Point Messaging Model and Publish Subscribe Messaging Model is explained in this article. Point to Point Messaging Model and Publish Subscribe Messaging Model:

Point to Point Messaging Model	Publish Subscribe Messaging Model
JMS Destination is Queue	JMS Destination is Topic
JMS Producer is called as Sender	JMS Producer is referred as Publisher
JMS Consumer is called as Receiver	JMS Consumer is referred as Subscriber
In Point to Point Messaging Model, message can be received by only one JMS Consumer	In Publish Subscribe Messaging Model, a message can be received by several JMS Consumers
There is no time dependency laid for the receiver to receive the message. If in case the receiver is unavailable to receive the message at any point of time, then queue will store the message until receiver is ready to receive it	There is a time dependency that is laid between the Producer and Consumer in Publish Subscribe Messaging Model
When the Consumer receives the message, it will send an acknowledgement back to the Producer	No acknowledgement is sent by the Consumers when they receive the message
There is no further classification of Point to Point Messaging Model	Publish Subscribe Messaging Model is further classified into Persistent Messaging Model and Non-Persistent Messaging Model. In Persistent Messaging Model, messages are stored in the JMS Server until there are delivered to the Destination, but in Non-Persistent Messaging Model, there is no intermediate storage option
Point to Point Messaging Model contains four possible architectures namely: One Producer connected with one Consumer One Producer connected to several Consumers Several Producers connected to one Consumer Several Producers connected to several Consumers In all these possible architectures, a Producer has a limitation to send a message to only one Consumer. This is because, Point to Point Messaging Model enforces one to one relationship between the Producer and Consumer	Publish Subscribe Messaging Model contains only three possible architectures namely: One Producer connected to several Consumers Several Producers connected to one Consumer Several Producers connected to several Consumers In all these possible architectures, Producer has the leverage to send a message to one or more (many) Consumers. This is because, Publish Subscribe Messaging Model enforces one to many relationship between the Producer and Consumer

Point to Point Messaging Model Architecture

May 1, 2017 By j2eereference Leave a Comment

Point to Point Messaging Model is a messaging paradigm supported by JMS (Java Message Service). Point to Point Messaging Model is called as P2P model in short. It is intended to provide asynchronous message transmission between sender and receiver using queues. In this article, lets discuss about Point to Point Messaging Model Architecture in detail.

In Point to Point Messaging Model, the components are:

Destination: Queue
JMS Producer: Sender
JMS Consumer: Receiver

Point to Point Messaging Model Architecture

In Point to Point Messaging Model, JMS Sender and JMS Receiver will be configured to a Queue. JMS Sender will send a message to the JMS Receiver through Queue. JMS Receiver will receive the message from the Queue and read it. The Point to Point Messaging Model architecture is diagrammatically represented below:

Also, what will happen if the JMS Receiver is not active or alive when the JMS Sender sends the message? Even in this case, message transmission will happen successfully. If the Receiver is not available, the Queue will store the message until the Receiver becomes available to receive the message. This is because Point to Point Messaging Model does not enforce any time line dependency between the Sender and Receiver.

Possible Ways to Implement Point to Point Messaging Model Architecture

Point to Point Messaging Model Architecture can be implemented in the following ways:

Single sender and single receiver connected to a queue
Single sender and several receivers connected to a queue
Several senders and single receiver connected to a queue
Several senders and several receivers connected to a queue

Any number of Senders and Receivers can be configured to a Queue as listed above, but the JMS Message sent by one Sender can be received by only one Receiver. This is because Point to Point establishes a 1 to 1 relationship between the Sender and Receiver. Thus in Point to Point messaging model, message from one sender cannot be transmitted to multiple receivers.

Publish Subscribe Messaging Model Architecture

April 28, 2017 By j2eereference Leave a Comment

Publish Subscribe Messaging Model is a messaging paradigm supported by JMS (Java Message Service). It is intended to provide asynchronous message transmission between publisher and subscriber using topics. In this article, lets discuss about Publish Subscribe Messaging Model Architecture in detail.

In Publish Subscribe Messaging Model, the components are:

Destination: Topic
JMS Producer: Publisher
JMS Consumer: Subscriber(s)

Publish Subscribe Messaging Model Architecture

In Publish Subscribe Messaging Model, JMS Publisher and JMS Subscriber will be configured to a Topic. JMS Publisher will create messages and publish those messages in Topics. Different JMS Subscribers will subscribe to the Topics of their interest and consume all the messages that are published in those Topics. The Publish Subscribe Messaging Model architecture is diagrammatically represented below:

Unlike Point to Point Messaging Model, the Publish Subscribe Model has a timeline dependency. The messages can be consumed by the Subscribers if the Subscriber is active at that time and only if the Subscriber is subscribed to that Topic in which the message is published.

Possible Ways to Implement Publish Subscribe Messaging Model

Publish Subscribe Messaging Model Architecture can be implemented in the following ways:

Single publisher and several subscribers connected to a Topic
Several publishers and single subscriber connected to a Topic
Several publishers and several subscribers connected to a Topic

Any number of Publishers and Subscribers can be configured to a Topic as listed above, but the JMS Message published by one publisher will be consumed by all the subscribers who have subscribed to that Topic. This is because Publish Subscribe Messaging Model establishes a 1 to Many relationship between the Publisher and Subscriber.

Publish Subscribe Messaging Model Classification

Publish Subscribe Messaging Model can further be classified into two different models namely:

Persistent Messaging Model – It is also called as Durable Messaging Model. This model has the capability to store messages in the JMS Server until it is delivered to the destination.
Non-Persistent Messaging Model – It is also called as Non-Durable Messaging Model. This model does not store messages in the JMS Server.

How JMS is different from RPC?

April 26, 2017 By j2eereference Leave a Comment

This article is intended to explain how JMS is different from RPC. JMS is the acronym of Java Message Service and RPC is the acronym of Remote Procedure Call. Both JMS and RPC are involved in message transmission. However, JMS is different from RPC in the way the messaging is done. The difference between JMS and RPC is explained in the tabular column below:

Java Messaging Service (JMS)	Remote Procedure Call (RPC)
JMS is asynchronous in nature. When a message has to be transmitted, Sender will send the message to the receiver. With this, Sender’s job is done and it will continue with its further processing. Receiver will receive the message and continue with its own processing. No acknowledgement is sent from the receiver to sender after receiving the message. This is because, JMS is asynchronous.	RPC is synchronous in nature. Unlike JMS, the invoker of the remote procedure call will invoke the method and continue to wait until the invoked method completes its execution. Once when the invoked method execution is complete, then the control returns back to the invoker. This is because, RPC is synchronous in behaviour.
There is no coupling between the sender and receiver of the message in JMS. Thus, JMS allows new senders and receivers to be added dynamically thereby managing variations in complexity over a period of time. Hence, JMS is loosely coupled.	RPC establishes tight coupling between the systems that interact with one another. When the invoker invokes a remote method, the invoker will get blocked until the response comes back to the invoker.
When there is an unexpected failure, JMS will store the messages that are pending to be delivered. When the system is up, the stored messages will be transmitted to the corresponding receivers.	When there is an unexpected failure, the failure will impact the entire system. Thereby, the entire system will go down.

Different types of messages available in JMS API

April 21, 2017 By j2eereference Leave a Comment

Different types of messages available in JMS API are TextMessage, BytesMessage, StreamMessage, ObjectMessage and MapMessage. As already known, JMS API offers specialised service of transmitting messages between brokers and nodes in a single direction asynchronously. The message bodies are available in javax.jms.Message of JMS API. However, actual classes of the messages are not available as part of API and they are defined by the corresponding providers.

Rest of the article explains in detail about different types of messages available in JMS API:

1. TextMessage

TextMessage is used to store string values of any specific length. Here is a code snippet to demonstrate TextMessage:

//Create a TextMessage
TextMessage sampleTextMsg = session.createTextMessage();

//Store values within TextMessage
sampleTextMsg.setText(“sample content”);

// Retrieve values from TextMessage
String storedText = sampleTextMsg.getText();

//Create a TextMessage

TextMessage sampleTextMsg = session.createTextMessage();

//Store values within TextMessage

sampleTextMsg.setText(“sample content”);

// Retrieve values from TextMessage

String storedText = sampleTextMsg.getText();

2. BytesMessage

BytesMessage is a basic type of message that can store sequence of bytes that are uninterpreted. BytesMessage can literally store anything. Here is an associated code snippet for BytesMessage:

//Create BytesMessage
BytesMessage sampleBytesMsg = session.createBytesMessage();

//Storing an array of numbers in BytesMessage
byte[] byteArray = new byte[]{66,68,70};
sampleBytesMsg.writeBytes(byteArray);

// Fetch the stored numbers by doing required casting
byte[] msgContent = new byte[3];
sampleBytesMsg.readBytes(msgContent);

//Create BytesMessage

BytesMessage sampleBytesMsg = session.createBytesMessage();

//Storing an array of numbers in BytesMessage

byte[] byteArray = new byte[]{66,68,70};

sampleBytesMsg.writeBytes(byteArray);

// Fetch the stored numbers by doing required casting

byte[] msgContent = new byte[3];

sampleBytesMsg.readBytes(msgContent);

3. StreamMessage

StreamMessage is a type of message that can wrap a stream of primitive values that are of unlimited length. Given below is a code snippet demonstrating StreamMessage:

//Create a StreamMessage
StreamMessage sampleStreamMsg = session.createStreamMessage();

//Store values within StreamMessage
sampleStreamMsg.writeBoolean(false);
sampleStreamMsg.writeBoolean(true);
sampleStreamMsg.writeBoolean(false);

// Retrieve values from StreamMessage
System.out.println(sampleStreamMsg.readBoolean());
System.out.println(sampleStreamMsg.readBoolean());
System.out.println(sampleStreamMsg.readBoolean());

//Create a StreamMessage

StreamMessage sampleStreamMsg = session.createStreamMessage();

//Store values within StreamMessage

sampleStreamMsg.writeBoolean(false);

sampleStreamMsg.writeBoolean(true);

sampleStreamMsg.writeBoolean(false);

// Retrieve values from StreamMessage

System.out.println(sampleStreamMsg.readBoolean());

Output will be false, true, false.

4. ObjectMessage

Using ObjectMessage, an object can be wrapped as a message and transmitted across, but the object must be serializable. Here is a code snippet example of ObjectMessage:

//Create an ObjectMessage
ObjectMessage  sampleObjMsg = session.createObjectMessage();

//Create a ValueObject and initialize it with values
ValueObject vObj = new ValueObject(‘sampleField’,54);

//Store the ValueObject within ObjectMessage
sampleObjMsg.setObject(vObj));

//Retrieve the stored ValueObject from the ObjectMessage
vObj = (ValueObject) sampleObjMsg.getObject();

//Create an ObjectMessage

ObjectMessage sampleObjMsg = session.createObjectMessage();

//Create a ValueObject and initialize it with values

ValueObject vObj = new ValueObject(‘sampleField’,54);

//Store the ValueObject within ObjectMessage

sampleObjMsg.setObject(vObj));

//Retrieve the stored ValueObject from the ObjectMessage

vObj = (ValueObject) sampleObjMsg.getObject();

5. MapMessage

MapMessage is a type of message that is defined with a key value pair. Map is also referred as hash or dictionary. String objects are stored as Keys and String objects or any primitives can be stored as values. Since values can include primitives, it should be taken care that the value cannot be null. Here is a code snippet demonstrating MapMessage:

//Create a MapMessage
MapMessage sampleMapMsg = session.createMapMessage();

//Set Key Value Pair with type String
sampleMapMsg.setString('SampleKey', 'SampleValue');

// Retrieve String value using Key
sampleMapMsg.getString('SampleKey');

//Set Key Value Pair without specifying type
sampleMapMsg.setObject('SampleKey1', 'SampleValue1');

// Retrieve Object value using Key
sampleMapMsg.getObject(‘'SampleKey1');

//Create a MapMessage

MapMessage sampleMapMsg = session.createMapMessage();

//Set Key Value Pair with type String

sampleMapMsg.setString('SampleKey', 'SampleValue');

// Retrieve String value using Key

sampleMapMsg.getString('SampleKey');

//Set Key Value Pair without specifying type

sampleMapMsg.setObject('SampleKey1', 'SampleValue1');

// Retrieve Object value using Key

sampleMapMsg.getObject(‘'SampleKey1');

Advantages of Java Message Service (JMS)

April 20, 2017 By j2eereference Leave a Comment

Java Message Service (called as JMS in short) enables message transmission between independent applications that are distributed over a network, be it LAN, WAN or wireless network.

Advantages of Java Message Service are listed below:

Asynchronous Communication – Message queue of JMS provides high performance, high throughput due to its asynchronous behaviour. Since JMS message queue is asynchronous, it has the ability to stream the messages upfront for the consumer and then process those messages together in RAM once the consumer is available. This way, JMS has the capability to send several thousands of messages within a second to concurrent consumers using multiple threads and processes.
Extensive Industry Support – JMS specification can be easily implemented in prevailing message servers. For this reason, JMS is the first messaging API for enterprise applications that has gained extensive industry support.
Reliability – Message once sent will surely be delivered to the consumer without any loss of data. Also, message will be sent only once.
Standard JMS Messaging API – Messaging schemes and conventions defined by JMS are widely accepted by messaging systems of several other vendors. Thus, JMS can easily address portability issues and facilitate simple application development.
Simple Java API – Just by quickly learning JMS API, the developers can easily and rapidly write messaging enterprise applications that are portable.
Loose Coupling – JMS has the ability to decouple unrelated systems. Instead of sharing common database, the systems will be communicating via system boundaries.
JMS Based Message Driven Beans – Message Driven Beans of EJB 2.0 is JMS based. Thus, it enables developers to implement asynchronous and scalable EJB applications.
Interoperability – If two applications have different messaging providers, then again they can easily communicate with each other through JMS because of its high interoperability.
Load Balancing – When there is increase in load i.e., lots of messages are received, then the JMS does efficient load balancing by having a pool of message processors.

Java Message Service and JMS Programming Model

April 19, 2017 By j2eereference Leave a Comment

What is JMS?

JMS Is the short form of Java Message Service. JMS is a Java API that permits different applications to create and transmit messages to each other using a communication protocol. This communication protocol is designed using J2EE technology and it offers an effective communication that is asynchronous, reliable and loosely coupled.

Java Message Service offers following messaging services:

Creating a Message
Sending the created Message
Receiving the sent message
Reading the received message

JMS Programming Model

Message transmission is achieved through JMS Programming Model that is depicted below:

As shown in the JMS Programming Model diagram, JMS application is encompassed of six building blocks:

(i) Administered Objects

JMS application offers two different types of administered objects namely:

Connection Factory – The connection factory is used to establish connection with the provider.
Destination – The Destination indicates where the produced messages are targeted to and the source of messages that are consumed.

The connection factory and destination are created in the JMI provider with the help of admin console of the application server. These objects will be stored in the JNDI directory of application server.

(ii) JMS Connection

JMS Connection refers to the virtual connection that is established with the provider.

(iii) JMS Session

JMS Session is used for creating the Message Producers (to produce messages) and Message Consumers (to consume messages).

(iv) JMS Message Producer

JMS Message Producer is an object that is intended to send messages to the corresponding Destination.

(v) JMS Message Consumer

JMS Message Consumer is an object that is intended to receive messages that are sent at a particular Destination.

(vi) JMS Message Listener

JMS Message Listener is an object which tends to behave as asynchronous event handler for the messages. When a message arrives at a destination, corresponding set of actions to be taken place is defined in the JMS Message Listener.

What is JavaServer Pages (JSP)?

April 18, 2017 By j2eereference Leave a Comment

What is JavaServer Pages?

JavaServer Pages was launched by Sun Microsystems in the year 1999. JavaServer Pages is called as JSP in short. JSP is an expedient technology that enables the developers to build dynamic web pages. Generally, stand alone Java code is embedded within static HTML page to form JSP. Additional JSP tags will be used to specialise the functionality of a web page. Rather than HTML, JSP pages can also be formed from XML or other document types. JSP files can be deployed and executed with the help of a web server like tomcat.

Why to use JSP?

JSP provides significantly enhanced performance since JSP embeds dynamic elements within HTML Pages itself
JSP files will always be compiled before it is being handled by the server for further processing
JSP are constructed over Java Servlets and they are translated into servlets during execution. Thus, JSP gets access to all the predominant API’s of Enterprise Java, together with EJB, JDBC, JAXP, JNDI, and much more
Simple applications can have only JSP pages. Complex applications can have JSP as part of MVC (Model View Controller). In MVC Architecture, JSP acts as a View Component wherein JavaBeans will play the role of a Model and Servlets will be the Controller
Most importantly, JSP is a vital portion of J2EE, a complete environment for building enterprise applications. This indicates that JSP can be used in diverse applications ranging from simple straightforward applications to the most complicated and demanding

Sample JSP Page

Here is a simple JSP Page that displays “Have a Great Day” ten times:

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>J2EEReference.com Sample JSP Page</title>
</head>
<body>

<h1> Sample JSP Page from J2EEReference.com</h1>

<% for(int index=0;index<10;index++){ %>
<h5> Have a Great Day!</h5>
<%}%>

</body>
</html>

<%@ page language="java" contentType="text/html; charset=UTF-8"

pageEncoding="UTF-8"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>J2EEReference.com Sample JSP Page</title>

</head>

<body>

<h1> Sample JSP Page from J2EEReference.com</h1>

<% for(int index=0;index<10;index++){ %>

<h5> Have a Great Day!</h5>

<%}%>

</body>

</html>

Output of the above program is:

Java EE or J2EE Architecture

April 17, 2017 By j2eereference Leave a Comment

What is Java EE?

Java EE is the short form of Java Enterprise Edition. Intention of Java EE is to offer an enterprise application development platform containing influential APIs to the developers thereby reducing the development time, lessening complexity of the application, and refining performance of application. Java Enterprise Edition is developed with the help of Java Community Process, which is held accountable for all the Java technologies.

Why the name J2EE?

When Java EE was introduced, its first significant release was termed as Java 2 Enterprise Edition, in short J2EE. Though several versions of Java EE are in place, predominantly Java EE is still called as J2EE.

Latest Version of Java EE

Latest version of Java EE is Java EE 7, which was introduced on 12^th June 2013. However, most awaited stable release of Java EE 8 is expected to happen soon within the end of this year 2017.

J2EE / Java EE Architecture

Java EE provides an environment for development and deployment of web-based enterprise applications using multi-tier architecture, as signified below:

The diagram shown above demonstrates J2EE multi-tier architecture that encompasses several J2EE containers each including its own J2EE components. Here is an overview about the different tiers of J2EE architecture:

Client Tier – Components of Client Tier will run in the client devices / containers. Client Tier components are standalone java applications, static and dynamic HTML pages, and applets.
Middle Tier
- Web Tier – The web tier components namely JSP’s and Servlets execute with the help of J2EE web server in a web container.
- Business Tier – Enterprise Java Beans (EJB) are the business tier components that are executed within the EJB container using J2EE Application Server.
EIS Tier – In the EIS tier, the application related data are stored in a database. EIS tier may also include ERP’s or legacy systems that can be accessed via an API representing Java EE Connector Architecture.

Main navigation

J2EE

Point to Point Messaging Model Architecture

Possible Ways to Implement Point to Point Messaging Model Architecture

Publish Subscribe Messaging Model Architecture

Possible Ways to Implement Publish Subscribe Messaging Model

Publish Subscribe Messaging Model Classification

1. TextMessage

2. BytesMessage

3. StreamMessage

4. ObjectMessage

5. MapMessage

What is JMS?

JMS Programming Model

What is JavaServer Pages?

Why to use JSP?

Sample JSP Page

Related Posts

What is Java EE?

Why the name J2EE?

Latest Version of Java EE

J2EE / Java EE Architecture

Footer