• The expression ${} represents immediate evaluation which means that the expression is evaluated and the result returned as soon as the page is first rendered. Immediate evaluation expressions are always read-only value expressions.

For example, ${student.name} uses immediate evaluation syntax where the expression accesses the name property of Student, gets its value, adds the value to the response, and gets rendered on the page.

• The expression #{} represents deferred evaluation which means that the technology using the expression language can use its own machinery to evaluate the expression sometime later during the page’s lifecycle.  Deferred evaluation expressions can be ‘Value expressions’ that can be used to both read and write data and ‘Method expressions’.

For example, #{student.name} uses deferred value syntax where the expression accesses the name property of Student, gets its value and optionally can modify the value, adds the value to the response and gets rendered on the page. Here, the evaluation of the expression is deferred.

The tag libraries supported by JSF are:

1. JavaServer Faces Core Tag Library – This library consists of tags for JavaServer Faces custom actions that are independent of any particular render kit. This has a prefix as ‘f:’ and the URI is http://java.sun.com/jsf/core
2. JavaServer Faces HTML Tag Library –  This library consists of JavaServer Faces component tags for all UIComponent objects in a web application. This has a prefix as ‘h:’ and the URI is  http://java.sun.com/jsf/html
3. JavaServer Faces Facelets Tag Library – This library consists of tags for templating. This has a prefix as ‘ui:’ and the URI is http://java.sun.com/jsf/facelets

In addition to these tag libraries, JSTL Core Tag library and JSTL Functions Tag Library are also supported.

Facelets technology is introduced from JavaServer Faces 2.0, is the preferred presentation technology for building JavaServer Faces technology-based web applications. Facelets is a powerful but lightweight page declaration language that is used to build JSF views using HTML style templates and to build component trees. Facelets features include the following:

• Use of XHTML for creating web pages
• Support for Facelets tag libraries in addition to JavaServer Faces and JSTL tag libraries
• Support for the Expression Language (EL)
• Templating for components and pages

The functionality provided by a JavaServer Faces application is similar to that of any other Java web application. A typical JavaServer Faces application includes the following parts:

• A set of web pages in which components are laid out
• A set of tags to add components to the web page
• A set ofmanaged beans, which are lightweight container-managed objects (POJOs) with minimal requirements. They support a small set of basic services, such as resource injection, lifecycle callbacks and interceptors.
• A web deployment descriptor (web.xml file)
• Optionally, one or moreapplication configuration resource files, such as a faces-config.xml file, which can be used to define page navigation rules and configure beans and other custom objects, such as custom components
• Optionally, a set of custom objects, which can include custom components, validators, converters, or listeners, created by the application developer
• Optionally, a set of custom tags for representing custom objects on the page

JavaServer Faces technology is a server-side component framework for building Java technology-based dynamic web applications.

JavaServer Faces technology consists of the following:

• An API for representing components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all these features.
• Tag libraries for adding components to web pages and for connecting components to server-side objects

A nondurable subscriber can receive only messages that are published while it is active. A durable subscriber can receive messages that were sent when they were not active. Durable subscribers are created using Session.createDurableSubscriber method. A durable subscription can have only one active subscriber at a time.

A durable subscriber registers a durable subscription by specifying a unique identity that is retained by the JMS provider. If a durable subscription has no active subscriber, the JMS provider retains the subscription’s messages until they are received by the subscription or until they expire.

The unique identity of a durable subscriber can be set with the following:

• A client ID for the connection
• A topic and a subscription name for the subscriber

The client ID can be set administratively for a client-specific connection factory using either the command line or the Administration Console. The JMS provider stores the messages sent or published to the topic, as it would store messages sent to a queue. If the program or another application calls createDurableSubscriber using the same connection factory and its client ID, the same topic, and the same subscription name, then the subscription is reactivated and the JMS provider delivers any messages that were published while the subscriber was inactive.

In a publish/subscribe model, there is 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.

The JMS API relaxes this timing dependency to some extent by allowing subscribers to create durable  subscriptions, which receive messages sent while the subscribers are not active. Durable subscriptions provide the flexibility and reliability of queues but still allow clients to send messages to many recipients. Durable subscriptions offer the reliability of queues to the publish/subscribe message domain.

There are ten levels of message priority in JMS. The ten levels of priority range from 0 (lowest) to 9 (highest). If you do not specify a priority level, the default level is 4. A JMS provider tries to deliver higher-priority messages before lower-priority ones but does not have to deliver messages in exact order of priority.

Message priority can be set:

• Using the setPriority method of the MessageProducer interface to set the priority level for all messages sent by that producer. For example, the following call sets a priority level of 7 for a producer:

producer.setPriority(7);

• Using the long form of the send or the publish method to set the priority level for a specific message. The third argument sets the priority level. For example, the following send call sets the priority level for message to 3:

producer.send(message, DeliveryMode.NON_PERSISTENT, 3, 10000);

Message persistence can be set using the two delivery mode fields of the DeliveryMode interface.

• The PERSISTENT delivery mode, the default, instructs the JMS provider to take extra care to ensure that a message is not lost in transit in case of a JMS provider failure. A message sent with this delivery mode is logged to stable storage when it is sent.
• The NON_PERSISTENT delivery mode does not require the JMS provider to store the message or otherwise guarantee that it is not lost if the provider fails.

You can specify the delivery mode in either of two ways:

• Use the setDeliveryMode method of the MessageProducer interface to set the delivery mode for all messages sent by that producer. For example, the following call sets the delivery mode to NON_PERSISTENT for a producer:

producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

• Use the long form of the send or the publish method to set the delivery mode for a specific message. The second argument sets the delivery mode. For example, the following send call sets the delivery mode for message to NON_PERSISTENT:

producer.send(message, DeliveryMode.NON_PERSISTENT, 3, 10000);

The third and fourth arguments set the priority level and expiration time.

If you do not specify a delivery mode, the default is PERSISTENT. Using the NON_PERSISTENT delivery mode may improve performance and reduce storage overhead, but you should use it only if your application can afford to miss messages.

The basic reliability mechanisms in JMS that ensure message delivery are:

1. Message Acknowledgement – Various levels of acknowledgement can be specified for a message.
2. Message Persistence – Messages should be specified as PERSISTENT, meaning they must not be lost in the event of a provider failure.
3. Message Priority –  Priority levels for messages can be set, which can affect the order in which the messages are delivered.
4. Message Expiration Time – An expiration time for messages can be set, so they will not be delivered if they are obsolete.
5. Temporary Destination – Temporary destinations can be created that last only for the duration of the connection in which they are created.