http://java.sun.com/javaee/technologies/javaee6.jsp

Thanks

Suresh

Also known as  Handle/Body pattern .

This pattern is used to decouple(separate) the abstractions(base classes or interfaces) from their implementations so that we can vary  not only implementations but their abstractions,  independently , one from another.

How is it different from RMI?

Remote Method Invocation(RMI) is tightly coupled in the sense it requires an application to know a remote application’s methods to invoke.

Where as JMS is loosely coupled in the sense that the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender.The sender and the receiver need to know only what message format and what destination to use.The producers send messages to some destination and consumers read messages from that destination.

How is it different from E-mail Service ?

E-mail is a method of communication between people or between software applications and people, where as JMS is a method os communication between software applications or software components.

Messenging Domains:

• Point to Point Messenging :
  Each message is meant for only one consumer and it acknowledges the successful processing of a message.
• Publish-Subscribe Messenging:

Each message may have multiple subscribers and each subscriber subscribes to a particular Topic for consumption and they  must continue to be active in order for it to consume messages

What is MOM and How it is related to JMS:

A JMS application is composed of the following parts:

• A JMS provider: A messaging system that implements the JMS specification.
• JMS clients: Java applications that send and receive messages.
• Messages: Objects that are used to communicate information between JMS clients.
• Administered objects: Preconfigured JMS objects that are created by an administrator for the use of JMS clients.Aadministrators configure administered objects in a Java^TM Naming and Directory Interface^TM (JNDI) API namespace, and JMS clients then look them up, using the JNDI API. J2EE^TM applications always use the JNDI API.

A message is composed of three parts: header, properties, and a body.

• The header, which is required for every message, contains information that is used for routing and identifying messages. Some of these fields are set automatically, by the JMS provider, during producing and delivering a message, and others are set by the client on a message by message basis.
• Properties, which are optional, provide values that clients can use to filter messages. They provide additional information about the data, such as which process created it, the time it was created. Properties can be considered as an extension to the header, and consist of property name/value pairs. Using properties, clients can fine-tune their selection of messages by specifying certain values that act as selection criteria.
• The body, which is also optional, contains the actual data to be exchanged. The JMS specification defined six type or classes of messages that a JMS provider must support:
  1. Message: This represents a message without a message body.
  2. StreamMessage: A message whose body contains a stream of Java primitive types. It is written and read sequentially.
  3. MapMessage: A message whose body contains a set of name/value pairs. The order of entries is not defined.
  4. TextMessage: A message whose body contains a Java string…such as an XML message.
  5. ObjectMessage: A message whose body contains a serialized Java object.
  6. BytesMessage: A message whose body contains a stream of uninterpreted bytes.

The JMS flow looks like this:

Here in the above pic. both Destionations are the same .The above pic has been taken from  here

Also known as Wrapper Pattern.

The Adapter pattern lets you use an existing class to meet a client class’s needs. When a client specifies its requirements in an interface, you can usually create a new class that implements the interface and subclasses an existing class. This approach creates a class adapter that translates a client’s calls into calls to the existing class’s methods. This chapter will introduce you to the Adapter pattern in Java.

–InformIT.com(http://www.informit.com/articles/article.aspx?p=481863)

when developers write web services , they expose only the interfaces to the public(clients), but not the service implementations.But when clients need to consume those  services, they use the service  interfaces to access the services .Sometimes clients feel the service interfaces are not compatible for their usage.Fox ex consider

public interface EmployeeInfo {

public List getEmpNames();

} Assume the developers has already written the implementation class for this and they had exposed this interface to their clients.

Suppose some client wants only the employee first names , then the client feels that this interface is incompatible for its usage as this is returning employees full names  ,

(i) Also developers can’t change the implementation now , because they had already deployeed the service ,

(ii) Another drawback is we cannot add  a new method getEmpFirstNames() in the interafce , because all the sb classes who depend on this interface has to unnecessarily implement this new method.

thats where the Adapter Pattern comes into picture.

Participents: Client, Target,Adapter,Adoptee.

There are 2 types of implementing Adpter Patterns

Class Adapter: uses multiple inheritance for adopting interfaces one into another

Object Adapter: users class composition for adopting interfaces.

The general  call flow will look like this.

When to use?

Use the Adapter pattern when

• you want to use an existing class, and its interface does not match the one you need.
• you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don’t necessarily have compatible interfaces.
• (object adapter only) you need to use several existing subclasses, but it’s impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

Consequences:

Also known as Publish-Subscribe Pattern or Dependents Pattern.

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

When to use this pattern:

• When an abstraction has two aspects, one dependent on the other, Encapsulating these aspects in separate objects lets you vary and reuse them independently.
• When a change to one object requires changing others, and you don’t know how many objects need to be changed.
• When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don’t want these objects tightly coupled.

Participents:

Subject , ConcreteSubject , Observer, ConcreteObserver.

How it works:

The  terminology used for different objects  in this pattern are Subject(Publisher) and Observers(Subscribers).

The Subject is the object who notifies that the change has occured.The Observers are objects  who change their state according the change.

All observers are notified whenever the subject undergoes a change in state.Each observer will query the subject to synchronize its state with the subject’s state.

The Subject notifies its change without even knowing how many dependents(observers) it has and who its observers are.

Any number of observers can subscribe to this subject to receive notifications

Please note that the above pic. is taken from GOF Design Patterns site.

Prons and Cons:

• Abstract(loose) coupling between Subject and Observer
• Support for broadcast communication
• Unexpected updates may cause serious inconsistancy

Note:

Please go through java.util.Observable and java.util.Observer , if you are interested.

A Design Pattern is a language independent style of coding which solves the above stated reoccuring problems and thus they prevent reinventing the wheel.

Generally the software  Design Patterns are classified as

• Creational patterns
• Structural patterns
• Behavioral patterns

But in terms of J2EE , we classify the patterns as

• Presentation tier
• Business tier
• Integration tier

Here are some of the good references for  Design Patterns:

http://sourcemaking.com/design_patterns

http://www.javacamp.org/designPattern/

http://java.sun.com/blueprints/patterns/catalog.html

http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

Recommended Books:

1) Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.

2) Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

3) Design Patterns by Head First  Series