• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer
  • Core Java
  • Design Patterns
  • JSP
  • Servlets
  • Building Tools
  • jQuery
  • Spring
  • Hibernate
  • Mongo DB
  • More
    • HTML
    • SCJP
    • AJAX
    • UML
    • Struts
    • J2EE
    • Testing
    • Angular JS

J2EE Reference

  • Home
  • About Us
    • Java Learning Centers
  • Contact Us

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

 

 

 

Filed Under: J2EE Tagged With: Differences between Point to Point Messaging Model and Publish Subscribe Messaging Model, Different messaging paradigms supported by Java Message Service, Java Message Service, JMS, Messaging Model, point to point messaging model, Point to Point Messaging Model Vs Publish Subscribe Messaging Model, Publish Subscribe Messaging Model

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:

Point to Point Messaging Model Architecture

 

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.

 

Filed Under: J2EE Tagged With: JMS Consumer, JMS Destination, JMS Producer, JMS receiver, JMS sender, p2p model, point to point messaging model, point to point messaging model architecture, queue

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:

Publish Subscribe Messaging Model

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.

Filed Under: J2EE Tagged With: Durable Messaging Model, JMS, JMS Server, Non-Durable Messaging Model, Non-Persistent Messaging Model, Persistent Messaging Model, Publish Subscribe Messaging Model, Publish Subscribe Messaging Model Architecture, Publisher, Subscriber

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.

 

Filed Under: J2EE Tagged With: difference, Java Message Service, JMS, Remote Procedure Call, RPC

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:

1
2
3
4
5
6
7
8
//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:

BytesMessage
1
2
3
4
5
6
7
8
9
10
//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:

StreamMessage
1
2
3
4
5
6
7
8
9
10
11
12
//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());

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:

ObjectMessage
1
2
3
4
5
6
7
8
9
10
11
//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:

MapMessage
1
2
3
4
5
6
7
8
9
10
11
12
13
14
//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');

 

Filed Under: J2EE Tagged With: BytesMessage, different types of messages, javax.jms.Message, JMS API, MapMessage, message types, ObjectMessage, StreamMessage, TextMessage

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.

Filed Under: J2EE Tagged With: Java Message Service Advantages, Java Message Service Benefits, JMS advantages, JMS Benefits

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:

JMS Programming Model

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.

Filed Under: J2EE Tagged With: Connection Factory, Destination, Java Message Service, JMS, JMS Connection, JMS Message Consumer, JMS Message Listener, JMS Message Producer, JMS Programming Model, JMS Session

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:

J2EEReference.com Sample JSP Page
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<%@ 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>

Output of the above program is:

J2EEREFERENCE.COM JSP OUTPUT

Related Posts

  • JSP Page Directives
  • JSP FAQ
  • JSP Quiz
  • JSP Elements
  • JSP Life Cycle
  • JSP Introduction

Filed Under: J2EE, JSP Tagged With: JavaServer Pages, JSP

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 12th 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.

Filed Under: J2EE Tagged With: applet, client tier, EIS tier, EJB, enterprise application, HTML, J2EE, J2EE architecture, Java EE, Java EE 7, Java EE 8, Java Enterprise Edition, JSP, middle tier, multi-tier architecture, servlets, web tier

Primary Sidebar

FOLLOW US ONLINE

  • View J2eereference-166104970118637’s profile on Facebook
  • View j2eereference’s profile on Twitter
  • View j2eereference’s profile on LinkedIn

Subscribe by email

Recent posts

  • Java Buzzwords
  • Anonymous Inner Class in Java
  • Network Programming – java.net Package
  • Java Regular Expressions
  • Method Local Inner Class in Java
  • URL Processing in Java
  • Iterator Design Pattern Implementation using Java
  • Strategy Design Pattern Implementation using Java
  • Decorator Design Pattern
  • Adapter Design Pattern Implementation using Java
  • JSF Composite Components
  • JSF UI Components
  • What is JavaServer Faces (JSF)?
  • GOF Design Patterns
  • History and Need for Design Patterns

Footer

Core Java
Design Patterns
JSP
Servlets
HTML
Building Tools
AJAX
SCJP
jQuery
Testing
Spring
UML
Struts
Java Centers
Java Training
Home
About Us
Contact Us
Copyright © j2eereference.com. All right reserved.