AZA (Alvaro Vilaplana García) in JAVA

Template method and Command pattern, a good combination to create generic algorithms

2011-06-20T21:18:00.004+01:00

Introduction
With this post I want to share some strategies to face generic algorithms where each step is no tight with concepts. Just on the fly configuration (i.e. using IoC framework) is tight with a specific use case.

Definition of patterns

Template method pattern defines the program skeleton of an algorithm. One or more of the algorithm steps can be overridden by subclasses to allow differing behaviours while ensuring that the overarching algorithm is still followed.

Command pattern defines an object used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

Three terms with the command pattern are:

The client instantiates the command object and provides the information required to call the method at a later time.

The invoker decides when the method should be called.

The receiver is an instance of the class that contains the method's code.

New Template method approach

Both patterns used together can help to construct a generic algorithm that conceptually executes generic steps.

From template, the idea of creating an algorithm that executes several steps to achieve a task.

From the command, The idea of building general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.

With use of an IoC framework, the instance variable List steps can be injected with specific implementations.

The next two sequence diagrams show the interactions between all the components.
In the first, the template is injected with the following instances of

ConcreteCommand2
ConcreteCommand4
ConcreteCommand5

In the second, the template is injected with the following instances of

ConcreteCommand1
ConcreteCommand3
ConcreteCommand5

Java EE 5 Annotations and Resource Injection in some container managed components

2010-03-29T18:01:00.003+01:00

The Annotations that are required by a Java EE technology compliant web container:

Annotations

@DeclareRoles (*)

@RunAs (*)

@EJB

@EJBs

@Resource

@Resources

@PersistenceContext

@PersistenceContexts

@PersistenceUnit

@PersistenceUnits

@PostConstruct

@PreDestroy

@WebServiceRef

@WebServiceRefs

Annotations must be supported on the following container managed classes that implement the following interfaces:

Component Type	Component Type Classes implementing the following interfaces	Notes
Servlets	javax.servlet.Servlet	Java Servlet Specification version 2.5 References must be injected prior to any lifecycle methods being called and the component instance being made available the application.
Filters	javax.servlet.Filter
Listeners	javax.servlet.ServletContextAttributeListener javax.servlet.ServletRequestListener javax.servlet.ServletRequestAttributeListener javax.servlet.http.HttpSessionListener javax.servlet.http.HttpSessionAttributeListener javax.servlet.AsyncListener
ManagedBean	JavaServer Faces Specification v 2.0 Only beans declared to be in request, session, or application scope are eligible for *resource injection. Methods on managed beans declared to be in request, view, session, or application scope, annotated with @PostConstruct, must be called by the JSF implementation after resource injection is performed (if any) but before the bean is placed into scope. Methods on managed beans declared to be in request, session, or application scope, annotated with @PreDestroy*, must be called by the JSF implementation before the bean is removed from its scope or before the scope itself is destroyed, whichever comes first. In the case of a managed bean placed in view scope, methods annotated with @PreDestroy must only be called when the view scope is destroyed.

(*) Annotations not allowed in Managed Bean

OO concepts: Adapter pattern

2010-03-18T17:51:00.000Z

Introduction

In this post I sum up the Adapter pattern, an interesting OO pattern very useful in many situations. From my point of view, in the most enterprise situations where I needed to integrate with external systems, the idea of using adapter pattern provided to the systems a transparent way to communicate with other interfaces.

It is relevant to mention that this pattern is very important to build the ANTICORRUPTION LAYER in Domain Driven Design.

Description

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that could not otherwise because of incompatibles interfaces.

Scenario

The figure shows a design of a Web search engine that queries the databases of multiple libraries.

Libray1SearchEngine and Libray2SearchEngine classes have already implemented. These two classes implement Searchable interface so that the SearchInvoker class can call them interchangeably.

Let assume that a search implementation for a third library is wanted. Most of the code is already written in the Libray3SearchEngine class.

This class is used in a previously developed client-server application. Unfortunately, Libray3SearchEngine does not have all the needed functionality and has a different interface than the other search engine classes. The library plans to continue using the previously developed client-server application, so if you modified Libray3SearchEngine, you would have to maintain two versions of the class. You don’t want to complicate SearchInvoker by making it deal with the different interfaces, so you need a way to adapt Libray3SearchEngine to the Searchable interface.

Solution

The Adapter pattern recommends creating a new Adapter class that implements the DesiredInterface and propagates requests to the existing Adaptee class. The Client class calls methods on Adapter, not on Adaptee. If the DesiredInterface requires some functionality that is not supported by Adaptee, Adapter can implement that functionality directly.

Object Adapter Strategy Structure

Class Adapter Strategy Structure

Solution in this scenario

Consequences

The advantages of using the Adapter pattern are:

§ The client class is not complicated by having to use a different interface and can use polymorphism to swap between different implementations of DesiredInterface.

§ The adaptee class is not modified.

The disadvantages of using the Object Adapter strategy are:

§ There are two objects involved, so you must create an additional object.

§ All requests are forwarded, so there is a slight increase in the overhead.

The disadvantages of using the Class Adapter strategy are:

§ The interface of the adapter class also supports the interface of the adaptee class, so the client is coupled to the adaptee class.

§ In Java programming language, the single subclassing slot for a class is used up in adaptation. Therefore, you must use interfaces to support other features.

References

Gamma, Helm, Johnson, and Vlissides 2004. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley.

OO concepts: Observer pattern

2010-02-10T17:55:00.001Z

Introduction

In this post I sum up the Observer pattern, an interesting OO pattern very useful in many situations.

Description

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

The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject’s state.

This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.

Basic Pattern

Complex Pattern

Consequences

The advantages are:

§ You can vary and independently reuse classes for the Subject and Observer objects.

§ The abstract classes (or interfaces) are coupled together. Therefore, the coupling is looser than if the concrete classes were coupled.

§ You can easily add Observer objects without a single change to the Subject object.

The disadvantages are:

§ An observer system can become flooded with updates if the granularity of the update is too fine or its frequency too high. This is a critical problem in distributed systems.

§ The observer system often calls the subject when it receives a notification. This can create a bottleneck, preventing the timely update of the other observer systems.

References

Gamma, Helm, Johnson, and Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - Anticorruption layer

2010-02-02T14:32:00.003Z

Introduction

In this post I sum up the most important concepts about Domain Driven Design.

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

Scenario

On a large project, one subsystem will often have to interface with several other, independently developed subsystems. These will reflect the problem domain differently. When systems based on different models are combined, the need for the system to adapt to the semantics of the other system can lead to a corruption of the new system’s own model.

We should create an isolating layer, ANTOCORRUPTION LAYER, to provide clients with functionality in terms of their own domain model. The layer talks to other system through its existing interface, requiring little or no modification to other system. Internally, the layer translates in both directions as necessary between the two models.

Note: ANTOCORRUPTION LAYER is not a mechanism for sending messages to another system, is a means of linking two BOUNDED CONTEXTS.

Designing the interface

The public interface of the ANTICORRUPTION LAYER usually appears as a set of SERVICES. Building a whole new layer responsible for the translation between the semantics of the two systems gives us an opportunity to reabstract the other system’s behavior and offer its services and information to our system consistently with our model.

Implementation

The ANTICORRUPTION LAYER is a combination of FAÇADES, ADAPTERS and translator, along with the communication and transport mechanisms needed to talk between systems.

A FAÇADE is an interface for a subsystem that simplifies access for the client and makes the subsystem easier to use. It should be written strictly in accordance with the other system’s model. The FAÇADE belongs in the BOUNDED CONTEXT of the other system. It just presents a friendlier face specialized for your needs.

An ADAPTER is a wrapper that allows a client to use a different protocol than that understood by the implementer of the behavior. When a client sends a message to an ADAPTER, it is converted to a semantically equivalent message and sent on to the “adaptee”. The response is converted and passed back.

For each SERVICE we define, we need an ADAPTER that supports the SERVICE’s interface and knows how to make equivalent requests of the other system or its FAÇADE.

The remaining element is the translator. The ADAPTER’s job is to know how to make a request. The actual conversion of conceptual objects or data is a distinct, complex task that can be placed in its own object, making them both much easier to understand. A translator can be a lightweight object that is instantiated when needed. It needs no state and does not need to be distributed, because it belongs with the ADAPTER it serves.

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - Factories and Repositories

2010-01-15T17:23:00.020Z

Introduction

In this post I sum up the most important concepts about Domain Driven Design.

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

Encapsulating with FACTORIES

A FACTORY encapsulates the knowledge needed to create a complex object or AGGREGATE, which may itself have no responsibility in the domain model but is still part of the domain design. Provide an interface that encapsulates all complex assembly and that does not require the client to reference the concrete class of the objects being instantiated.

There are some PATTERNS to design FACTORIES

1. FACTORY METHOD

2. ABSTRACT FACTORY

3. BUILDER

Requirements for a FACTORY are:

§ Each creation method is atomic and enforces all invariants of the created object or AGGREGATE.

§ A FACTORY should only be able to produce an object in a consistent state.

§ For an ENTITY, this means the creation of the entire AGGREGATE, with all the invariants satisfied, but probably with optional elements still to be added.

§ For an immutable VALUE OBJECT, this means that all attributes are initialized to their correct final state. If the interface makes it possible to request an object that can not be created correctly, then an exception should be raised or some other mechanism should be invoked that will ensure that no improper return value is possible.

§ The FACTORY should be abstracted to the type desired, rather than the concrete classes created.

Accessing with REPOSITORIES

The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology.

A REPOSITORY represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the REPOSITORY inserts them or deletes them from the database.

Clients request objects from the REPOSITORY using query methods that select objects based on criteria specified by the client, typically the value of certain attributes. The REPOSITORY retrieves the requested object, encapsulating the machinery of database queries and metadata mapping. Repositories can implement a variety of queries that select objects based on whatever criteria the client requires.

A REPOSITORY lifts a huge burden from the client, which can now talk to a simple, intention-revealing interface, and ask for what it needs in terms of the model. To support all this requires a lot of complex technical infrastructure, but the interface is simple and conceptually connected to the domain model.

For each type of object that needs global access, create an object that can provide the illusion of an in-memory collection of all objects of that type. Set up access through a well-known global interface. Provide methods to add and remove objects, which will encapsulate the actual insertion or removal of data in the data store. Provide methods that select objects based on some criteria and return fully instantiated objects or collections of objects whose attribute values meet the criteria, thereby encapsulating the actual storage and query technology. Provide REPOSITORIES only for AGGREGATE roots that actually need direct access. Keep the client focused on the model, delegating all object storage and access to the REPOSITORIES.

REPOSITORIES have many advantages, including the following:

1. They present clients with a simple model for obtaining persistent objects and managing their life cycle.

2. They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources.

3. The communicate design decisions about object access.

4. They allow easy substitution of a dummy implementation, for use in testing.

The REPOSITORY will delegate to the appropriate infrastructure services to get the job done.

Note: Leave the transaction control to the client who presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - ENTITIES, VALUE OBJECTS, DOMAIN SERVICES AND AGGREGATES

2010-01-06T16:17:00.012Z

Introduction

In this post I sum up concepts about Domain Driven Design:

§ Entities

§ Value Objects

§ Domain Services

§ Aggregates

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

ENTITY

An object defined primarily by its identity and not by their attributes. ENTITIES have life cycles that can change their form and content, but a thread of continuity must be maintained. Their class definitions, responsibilities, attributes, and associations should resolve around who they are, rather than the particular attributes they carry.

VALUE OBJECT

An object that represents a descriptive aspect of the domain with no conceptual identity and we care about only for what they are, not who or which they are.

VALUE OBJECTS are often passed as parameters in messages between objects. They are frequently transient, created for an operation and then discarded.

VALUE OBJECTS are used as attributes of ENTITTIES (and other VALUES).

DOMAIN SERVICES

There are important domain operations that can not find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things. Forcing the required domain functionality to be responsibility of ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.

The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS, it is defined purely in terms of what it can do for a client. A SERVICE tends to be named for an activity. A SERVICE should still have defined responsibility, and that responsibility and the interface fulfilling it should be defined as part of the domain model. Operations should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects.

A DOMAIN SERVICE has three characteristics:

1. 1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.

2. 2. The interface is defined in terms of other elements of the domain model.

3. 3. The operation is stateless.

SERVICES IN LAYERS

Application services: are the interface used by the outside world. These services could map outside messages to internal operations and processes, communicating with services in the Domain and Infrastructure layers to provide cohesive operations for outside clients.

Domain services: Embeds business rules. These use the infrastructure services to do their tasks.

Infrastructure services: communication with external resources like databases, file systems, web service end points, etc.

AGGREGATES

An AGGREGATE is a set of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary.

§ The boundary defines what is inside the AGGREATE.

§ The root is a single, specific ENTITY contained in the AGGREATE. The root is the only member that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other.

It is difficult to guarantee the consistency of changes to objects in a model with complex associations. Invariants are consistency rules that must be maintained whenever data changes and will involve relationships between members of the AGGREGATE. The invariants applied within an AGGREAGATE will be enforced with the completion of each transaction.

Rules for implementing AGGREGATES:

1. The root ENTITY has global identity and is ultimately responsible for checking invariants. ENTITIES other than root inside the boundary have local identity, unique only within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.

2. 2. Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY.

3. 3. The root ENTITY can hand references to internal ENTITIES to other objects, but those objects can use them only transiently, and they may not hold on to the reference. The root may hand a copy of a VALUE OBJECT to another object, and it does not matter what happens to it, because it is a VALUE and no longer will have any association with the AGGREGATE.

4. 4. Only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.

5. 5. Objects within the AGGREGATE can hold references to other AGGREGATE roots.

6. 6. A delete operation must remove everything within the AGGREGATE boundary at once.

7. 7. When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.

Example - Bank Customer

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - Layered architecture

2009-12-29T14:13:00.048Z

1. Introduction

In this post I sum up the most important concepts about Domain Driven Design.
I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

2. Domain Driven Design elements

In future posts I will show my understanding about the following concepts:

Layered Architecture
Services
Entities
Value Objects
Aggregates
Repositories
Factories

3. Isolating the domain with a Layered architecture

The design and implementation of business logic constitute the domain layer. Isolating the domain implementation is a prerequisite for domain-driven design.

User interface

It shows information to the user

It interprets the user´s commands.

Application Layer

It defines the jobs the software is supposed to do.
The tasks are meaningful to the business or necessary for interaction with the application layers of other systems.

This layer is thin and does not contain business rules or knowledge

It coordinates tasks and delegates work to collaborations of domain objects in the next layer down.

Domain Layer or Model layer

It represents concepts of the business and the business rules.

The state that reflects the business situation is controlled and used here

This layer is the heart of the business software.

Infrastructure Layer

Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on.

This infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.

Martin Fowler says: “If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design”.

4. References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.

Locking in JPA 2.0

2009-12-08T14:26:00.000Z

1. Introduction

The JPA specification 2.0 assumes that the databases to which persistence units are mapped will be accessed by the implementation using read-committed isolation (or a vendor equivalent in which long-term read locks are not held).

2. Optimistic Locking

Optimistic locking is a technique that is used to insure that updates (merge operation) to the database data corresponding to the state of an entity are made only when no intervening transaction has updated that data since the entity state was read.

Version Attributes

The Version field or property is used by the persistence provider to perform optimistic locking. An entity is automatically enabled for optimistic locking if it has a property or field mapped with a Version mapping.

@Entity

@Table(name = "ITEMS")

public class Item implements Serializable {

@Id

@Column(name = "ITEM_ID")

private Long itemId;

@Column(name = "ITEM_NAME")

private Long itemName;

@Version

@Column(name = "OPT_LOCK")

private Integer version;

…

}

The persistence provider's implementation of the merge operation must examine the version attribute when an entity is being merged and throw an OptimisticLockException if it is discovered that the object being merged is a stale copy of the entity—i.e. that the entity has been updated since the entity became detached.

The version attribute is updated by the persistence provider runtime when the object is written to the database.

UPDATE ITEMS SET ITEM_NAME = 'Name test', OPT_LOCK = 2 WHERE ITEM_ID = 700 AND OPT_LOCK = 1

Optimistic lock modes

If transaction calls lock(entity, LockModeType.OPTIMISTIC) on a versioned object, the entity manager must ensure that neither dirty read nor non-repeatable read occurs.

If transaction calls lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) on a versioned object, the entity manager must ensure that neither dirty read nor non-repeatable read occur and force an increment to the version at the end of the transaction, even if the entity is not modified.

Note: LockModeType.OPTIMISTIC is synonymous with LockModeType.READ and LockModeType. OPTIMISTIC_FORCE_INCREMENT is synonymous with LockModeType.WRITE.

3. Pessimistic Locking

Pessimistic concurrency locks the database row when data is read and it ensures that transactions do not update the same entity at the same time, which can simplify application code, but it limits concurrent access to the data which can cause bad scalability and may cause deadlocks. Pessimistic locking is better for applications with a higher risk of contention among concurrent transactions.

Pessimistic locking guarantees that once a transaction has obtained a pessimistic lock (long-term database locks) on an entity instance:

• No other transaction (whether a transaction of an application using the Java Persistence API or any other transaction using the underlying resource) may successfully modify or delete that instance until the transaction holding the lock has ended.

• If the pessimistic lock is an exclusive lock (LockModeType.PESSIMISTIC_WRITE or LockModeType.PESSIMISTIC_FORCE_INCREMENT), that same transaction may modify or delete that entity instance.

A persistence provider may use an underlying database platform's SELECT FOR UPDATE statements to implement pessimistic locking if that construct provides appropriate semantics, or the provider may use an isolation level of repeatable read.

Pessimistic lock modes

These lock modes are used to immediately obtain long-term database locks. Any locks must be obtained immediately and retained until transaction completes (commits or rolls back).

If transaction calls lock(entity, LockModeType.PESSIMISTIC_READ) or lock(entity, LockModeType.PESSIMISTIC_WRITE) on an object, the entity manager must ensure that dirty read nor non-repeatable read occurs.

If transaction calls lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT) on a versioned object, the entity manager must ensure that dirty read nor non-repeatable read occurs and must also force an update (increment) to the entity's version column.

4. API to use

There are multiple APIs to specify locking an Entity:

1. EntityManager methods: lock, find, refresh

2. Query methods: setLockMode

3. NamedQuery annotation: lockMode element

Transaction isolation levels, consenquences and configuration

2009-11-26T14:34:00.002Z

1. Introduction

In this post I sum up the different isolation levels and how we can configure them in JBoss AS depending on the type of datasource defined for our JEE application.

2. JDBC transaction isolation levels

Transaction isolation levels specify what data is visible to statements within a transaction. These levels directly impact the level of concurrent access by defining what interaction is possible between transactions against the same target data source.

READ UNCOMMITTED: allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row.

READ COMMITTED: prohibits a transaction from reading a row with uncommitted changes in it. This is the default level for most of databases.

REPEATABLE READ: prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read").

SERIALIZABLE: includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.

NONE: transactions are not supported.

Depending on your isolation level we can have three phenomena:

Dirty reads

1. Transaction A inserts a row into a table.

2. Transaction B reads the new row.

3. Transaction A rolls back.

4. Transaction B may have done work to the system based on the row inserted by transaction A, but that row never became a permanent part of the database.

Nonrepeatable reads

1. Transaction A reads a row.

2. Transaction B changes the row.

3. Transaction A reads the same row a second time and gets the new results.

Phantom reads

1. Transaction A reads all rows that satisfy a WHERE clause on an SQL query.

2. Transaction B inserts an additional row that satisfies the WHERE clause.

3. Transaction A re-evaluates the WHERE condition and picks up the additional row.

Isolation Level	Dirty Read	Nonrepeatable Read	Phantom Read
READ UNCOMMITTED	Permitted	Permitted	Permitted
READ COMMITTED	No Permitted	Permitted	Permitted
REPEATABLE READ	No Permitted	No Permitted	Permitted
SERIALIZABLE	No Permitted	No Permitted	No Permitted

3. How to set transaction isolation level in JBoss AS 4.2.2

As far as I know we can configure it within server/my_server/deploy/*-ds.xml (i.e oracle-ds.xml, mysql-ds.xml).

There are two types of datasources where we can define it:

local-tx-datasource: identifies a datasource that uses single phase commit transactions, therefore there is just one resource per JTA transaction (local transaction).

xa-tx-datasource: identifies a datasource that uses two phase commit transactions, therefore there are more than one resource per JTA transaction (global transaction).

Note: Use xa-tx-datasource when it is really needed. It is expensive in terms of performance.

The element to set is

transaction-isolation: specifies the java.sql.Connection transaction isolation level to use. The constants defined in the Connection interface are the possible element content values and include:

TRANSACTION_READ_UNCOMMITTED

TRANSACTION_READ_COMMITTED

TRANSACTION_REPEATABLE_READ

TRANSACTION_SERIALIZABLE

TRANSACTION_NONE

We can find further information in this link JBoss web site

Introducing security concepts in JBoss AS

2009-11-23T12:23:00.001Z

Authentication in JBoss AS

Authentication is the process by which a system verifies the identity of a user. There are two important concepts:

Principal: a human user, machine or process that’s trying to prove its identity on another system.

Credentials: one or more forms of identifications provided by a principal, i.e. passwords, certificates or any other reliable form of identification.

Security data can be kept in different data sources, so JBoss SX has different login modules that can read security information from different locations such as a database or an LDAP server.

Authorization in JBoss AS

Authorization is the process of verifying that a principal has sufficient privileges to access an application resource.

Authorization is often achieved by assigning one or more roles to a principal and then associating one or more roles with a component or resource that a principal might want to access. When the principal tries to access the component, the system looks at the roles allowed to access the component and the roles assigned to the principal. If the principal has one of the roles assigned to the component, then he can access the component; otherwise, the principal can’t access the component. This process is called role-based authorization.

Java EE defines declarative, role-based authorization for standard component technologies such as servlet, JSP, and EJB. Declarative authorization means that you can assign roles to components via configuration without the need to write any code.

Note: There are certain situations where role-based security doesn’t cut it. This fact becomes evident when the security you want to apply depends on the context of the request that the user sends. Applying security based on information in the request is often called context-based security, or programmatic security. For example, you want to allow a bank employee to enter deposits under 10,000 GPB, but anything over 10,000 GPB would require manager’s approval.

You can implement context-based security in several ways for each of the different component models. For EJBs, you can use JBoss SX security proxies or EJB3 interceptors. For web applications, you can use servlet filters, custom valves, or interceptors.

Configuring security

Each Java EE component or resource has a different mechanism for defining security. The definition of what method to use and what should be secured is defined in each component’s standard deployment descriptor. But, the Java EE specification doesn’t specify the underlying security implementation; it doesn’t describe where the security data should be kept, how it should be retrieved, or how it should be validated. Each application server vendor has to create its own security implementation and allow programmers to configure and use it through vendor-specific deployment descriptors.

JBoss AS’s security implementation is called JBoss SX, which builds on top of the Java Authentication and Authorization Service (JAAS) to secure all the Java EE technologies running in the application server.

When a request comes into JBoss AS, the targeted application component or resource (web application, EJB application, JMS queue/topic, or whatever), it may be—doesn’t need to know where the underlying security data exists or how it’s accessed. The component request is routed to a JBoss SX component called a security domain, an abstraction used to secure all requests made to a component. The security domain performs any necessary security checks and notifies the component whether the user can proceed or not. The security domain knows how to use one or more login modules to load security data from a data source.

Security domains are configured at the server level and can be used by any component within the server. Security domains are bound into JNDI when the server starts; pointing to the security domain’s JNDI context maps a component to a security domain. You can add or modify existing security domain definitions within the server/my_server/conf/login-config.xml file.

Note: When you define a security domain in the login-config.xml file, JBoss SX doesn’t automatically bind the security domain into JNDI. JBoss SX only binds a security domain into JNDI after you deploy an application that references the security domain.

Everything together - Step by Step Example

Bank’s secure Java EE-enabled website with a secure public-key certificate from a trusted certificate authority (CA).

Alvaro accesses the bank website and clicks on a link that should take his to her account summary. This link might be something like https://www.alvarobank.com/accountSumm.

The page is accessed via a secured protocol (HTTPS), the server sends its secure certificate to Alvaro’s web browser, like all major browsers, has a list of well-known certificate authorities. On receiving the bank’s certificate, her browser turns around and asks the trusted certificate authorities if the certificate belongs to the bank C.

Assuming that one of the certificate authorities acknowledges the authenticity of the bank’s certificate, Alvaro’s browser tries to forward her to the account summary page he originally requested.

Alvaro can now trust that he’s accessing his bank and that nobody can intercept her communication with her bank. Also, as long as he accesses the bank over the secure protocol, all her communications are transferred over a secure channel.

The bank needs to know if it can trust him. The URL for the account summary page is secured with form-based authentication. Users also must be a part of the AccountHolder role before accessing the page. Before Alvaro can access the account summary page, his request is intercepted by the JBoss Web Server web container. The container realizes that the URL that he’s accessing is secured, so it checks with the security framework to see if Alvaro is already logged in. After realizing that he’s not, a login form is sent back to Alvaro, prompting him for his username and password.

When Alvaro types in her credentials (user and password) and submits the form, the web container receives the form submission and passes Alvaro’s credentials to the application server’s security framework. The security framework accesses security information from a database, which it queries to determine whether or not Alvaro can access to the resource he’s requesting. First, the security framework should authenticate Alvaro, comparing the password she supplies against a known password to see if she should be granted access to the system at all. Then, the security framework should authorize Alvaro, determining if his username is associated with a role that can access the resource.

Everything matches up, so the security framework returns control back to the web container. Now that Alvaro’s credentials have been verified, the web container forwards her request to the resource associated with the URL for the account summary.

The account summary page is implemented as a servlet. In order for the servlet to render Alvaro’s account summary information, it needs to access her account information.

The servlet makes a call to the getAccountSummary(User u) method on a session EJB called Account, which runs in the EJB container. Because the EJB container runs locally, the servlet automatically propagates the security credentials.

The EJB method only allows access to users with the AccountHolder role. The EJB server accesses the JBoss SX security framework to determine if Alvaro is authenticated and authorized to access the resources. Again, access to the EJB method succeeds, and Alvaro’s account information loads from the application database. After the account summary loads, control returns to the servlet, which renders the output and sends it back to Alvaro, still over a secure channel.

Transfer Obejcts vs Business Objects (JPA entities) across the tiers

2009-11-15T21:25:00.006Z

Introduction

In this article I try to launch a very common technical discussion about what is the best approach, Transfer objects or Business objects (JPA entities) across the tiers. Once more time, I think that there is no a golden rule. It depends on the use case, the complexity of the application in terms of architecture and frameworks used.

Transfer Object across the tiers

Pros

1. Reduces network traffic in distributed systems. Transfer objects are passed to the client in a single remote call.

2. Improves client performance by removing any need to assemble data models.

3. Decouples business logic from the client and keeps it in the business tier.

4. Improves transaction performance by isolating the components that can be updated.

Cons

1. Data in transfer objects might get obsolete. The transfer object has a copy of the data which is not automatically updated if the data changes on the server.

2. The system can be complicated when using concurrent access or transaction management processes.

3. Synchronization logic can complicate the system if updatable transfer objects are used.
Object creation overhead on the server side increases.

Business Object across the tiers

Pros

1. Good approach in simple presentation tier design.

2. Makes easier the development in business and presentation tier because there is no need to assemble data models.

Cons

1. Couples presentation tier and business tier.

Note: If the business requirements don’t change often I consider that is good point to use them but otherwise it could be a nightmare for each single change to adapt the presentation tier.

2. In the case that the user interface requires a complex set of properties:

2.1. The domain model to pass across tiers can become heavyweight in terms of memory.

2.2. The development in the presentation tier can be complex because we need to navigate across multiple business objects to get the properties.

2.3. The development in business tier can become very tedious because we will load a lot of properties in the domain model (properties from BO1 -> properties from BO2 -> properties from BO3 and so on). There are two approaches to have all the properties in presentation tier:

2.3.1 In business tier: Eager relationships in JPA entities.

   2.3.2 In business tier: “Fetch Join” in application services.

   Note: Some frameworks keep transaction opened during the render of the user interface.
   In the case the relationships in the JPA entities can be defined as LAZY. We do not have
   to be worry about exceptions as org.hibernate.LazyInitializationException in the case of
   using Hibernate as JPA provider.

JMS: Message-driven Bean - Part 3

2009-11-04T16:55:00.000Z

Introduction

The message-driven bean model develops an Enterprise Bean that is asynchronously invoked by the container to handle the processing of incoming messages.

From the perspective of the client, the existence of a message-driven bean is completely hidden behind the destination or endpoint for which the message-driven bean is the message listener.

Implementing the MessageListener

A message-driven bean implements javax.jms.MessageListener interface (JMS Message driven bean). The container uses the listener interface to register the message-driven bean with the message provider and to pass incoming messages by invoking implemented message listener methods. There are different ways to define a message-driven bean.

1. @MessageDriven (name="ShippingRequestJMSProcessor",

messageListenerInterface="javax.jms.MessageListener")

public class ShippingRequestProcessorMDB {

2. public class ShippingRequestProcessorMDB implements MessageListener

3. Deployment descriptor.

The bean’s message listener method void onMessage(Message message) is called by the container when a message has arrived for the bean to service. The message listener method contains the business logic that handles the processing of the message.

Note: If the message-driven bean class implements more than one interface other than java.io.Serializable, java.io.Externalizable, or any of the interfaces defined by the javax.ejb package, the message listener interface must be specified by the messageListenerInterface element of the MessageDriven annotation or the messaging-type element of the message-driven deployment descriptor element.

Activation Configuration Properties

The activationConfig property of the @MessageDriven annotation allows you to provide messaging system-specific configuration information through an array of ActivationConfigProperty instances.

ActivationConfigProperty
propertyName	propertyValue	Description
destinationType	javax.jms.Queue	Tells the container this JMS MDB is listening to a queue.
destinationType	javax.jms.Topic	Tells the container this JMS MDB is listening to a topic.
destinationName	jms/ShippingRequestQueue	Specifies that we are listening for messages arriving at a destination with the JNDI name of jms/ShippingRequestQueue.
connectionfactoryJndiName	jms/QueueConnectionFactory	Specifies the JNDI name of the connection factory that should be used to create JMS connections for the MDB.
acknowledgeMode	AUTO_KNOWLEDGE	The session automatically acknowledges receipt after a message has been received or is successfully processed.
acknowledgeMode	DUPS_OK_ACKNOWLEDGE	The session can lazily acknowledge receipt of the message.
subscriptionDurability	Durable	Once a consumer obtains a durable subscription on a topic, all messages sent to the topic are guaranteed to be delivered to the consumer.
subscriptionDurability	NonDurable (By default)	In the pub-sub domain, a message is distributed to all currently subscribed consumers. In general, this is much like a broadcast message in that anyone who is not connected to the topic at the time does not receive a copy the message.
messageSelector	JMSType = ‘car’ AND color = ‘blue’ and weight > 2500	Determines which messages a JMS message-driven bean is to receive.

Example 1.

@MessageDriven(

name="ShippingRequestProcessor",

activationConfig = {

@ActivationConfigProperty(

propertyName="destinationType",

propertyValue="javax.jms.Queue"),

@ActivationConfigProperty(

propertyName="connectionFactoryJndiName",

propertyValue="jms/QueueConnectionFactory"

@ActivationConfigProperty(

propertyName="destinationName",

propertyValue="jms/ShippingRequestQueue")

}

)

Using bean lifecycle callbacks

The container is responsible for the following:

1. A MDB instance’s life starts when the container invokes newInstance on the MDB class to create a new instance. Next, the container injects the bean’s MessageDriverContext, 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.

2. The MDB 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 the timeout callback method.

3. When the container no longer needs the instance (happens when the container wants to reduce the number of instances in the method-ready pool), the container invokes the PreDestroy lifecycle callback methods for it, if any. This ends the life of the MDB instance.

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

•PostConstruct.

•PreDestroy.

A message driven bean can be registered with the EJB timer service for time-based event notifications. The container invokes the appropriate bean instance timeout callback method when a timer for the bean has expired.

The AroundInvoke business method interceptor methods are supported for message-driven beans.

Serializing Message-Driven Bean Methods

The container serializes calls to each message-driven bean instance. Most containers will support many instances of a message-driven bean executing concurrently; however, each instance sees only a serialized sequence of method calls. Therefore, a message-driven bean does not have to be coded as reentrant.

The container must serialize all the container-invoked callbacks (e.g., lifecycle callback interceptor methods and timeout callback methods), and it must serialize these callbacks with the message listener method calls.

Concurrency of Message Processing

A container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class, although the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. Message-driven beans should therefore be prepared to handle messages that are out of sequence: for example, the message to cancel a reservation may be delivered before the message to make the reservation.

Transaction Context of Message-Driven Bean Methods and acknowledgment

If the MDB uses container-managed transaction demarcation:

§ In message listener methods

REQUIRED. The message receipt is part of the transaction and message acknowledgment is handled automatically as a part of the transaction commit.

NOT_SUPPORTED.

§ In timeout callback methods

REQUIRED.

REQUIRES_NEW.

NOT_SUPPORTED.

If the MDB uses bean-managed transaction demarcation uses the javax.transaction.UserTransaction interface to demarcate transactions, the message receipt is not part of the transaction. The receipt is acknowledged by the container (AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE).

Dealing with Exceptions

A message-driven bean’s message listener method must not throw the java.rmi.RemoteException.

Message-driven beans should not, in general, throw RuntimeExceptions.

A RuntimeException that is not an application exception thrown from any method of the message-driven bean class (including a message listener method and the callbacks invoked by the container) results in the transition to the “does not exist” state. If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message.

From the client perspective, the message consumer continues to exist. If the client continues sending messages to the destination or endpoint associated with the bean, the container can delegate the client’s messages to another instance.

The message listener methods of some messaging types may throw application exceptions. An application exception is propagated by the container to the resource adapter.

Some Basic Scenarios

Scenario 1.

Scenario 2.

JMS: Reliable and robust applications - Part 2

2009-10-26T14:15:00.002Z

1. Introduction

This post explains how to use features of the JMS API to achieve the level of reliability and performance your application requires. All this content is taken from my summaries based on the specification.

2. Basic Reliability Mechanisms

2.1 Controlling Message Acknowledgment

Until a JMS message has been acknowledged, it is not considered to be successfully consumed; this ordinarily takes place in three steps.

1. The client receives the message.

2. The client processes the message.

3. The message is acknowledged. Acknowledgment is initiated either by the JMS provider or by the client, depending on the session acknowledgment mode.

Let’s pay attention in the following:

QueueSession createQueueSession(boolean transacted, int acknowledgeMode)

         throws JMSException

TopicSession createTopicSession(boolean transacted, int acknowledgeMode)

          throws JMSException

If the first parameter is true, the session is transacted and the acknowledgment happens automatically when a transaction is committed. If a transaction is rolled back, all consumed messages are redelivered.

If the first parameter is false, the session is nontransacted and the value in the parameter acknowledgeMode indicates whether the consumer or the client will acknowledge any messages it receives, ignored if the session is transacted.

• Session.AUTO_ACKNOWLEDGE. The session automatically acknowledges a client’s receipt of a message either when the client has successfully returned from a call to receive or when the MessageListener it has called to process the message returns successfully. A synchronous receive in an AUTO_ACKNOWLEDGE session is the exception to the rule that message consumption is a three-stage process. In this case, the receipt and acknowledgment take place in one step, followed by the processing of the message.

• Session.CLIENT_ACKNOWLEDGE. A client acknowledges a message by calling the message’s acknowledge method. In this mode, acknowledgment takes place on the session level: Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been consumed by its session. For example, if a message consumer consumes ten messages and then acknowledges the fifth message delivered, all ten messages are acknowledged.

• Session.DUPS_OK_ACKNOWLEDGE. This option instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should be used only by consumers that can tolerate duplicate messages. This option can reduce session overhead by minimizing the work the session does to prevent duplicates.

If messages have been received but not acknowledged when a QueueSession terminates, the JMS provider retains them and redelivers them when a consumer next accesses the queue. The provider also retains unacknowledged messages for a terminated TopicSession with a durable TopicSubscriber. Unacknowledged messages for a nondurable TopicSubscriber are dropped when the session is closed.

2.2 Specifying Message Persistence

The JMS API supports two delivery modes for messages to specify whether messages are lost if the JMS provider fails. These delivery modes are fields of the javax.jms.DeliveryMode interface.

• The PERSISTENT delivery mode (by 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. This mode may improve performance and reduce storage overhead, but you should use it only if your application can afford to miss messages.

2.3 Setting Message Priority Levels

You can use message priority levels (0 lowest to 9 highest, 4 default) to instruct the JMS provider to deliver urgent messages first. You can set the priority level in either of two ways.

2.4 Allowing Messages to Expire

By default, a message never expires. If a message will become obsolete after a certain period, however, you may want to set an expiration time. You can do this in either of two ways.

2.5 Creating Temporary Destinations

The JMS API enables you to create destinations:

QueueSession.createTemporaryQueue

TopicSession.createTemporary

They last only for the duration of the connection in which they are created. The only message consumers that can consume from a temporary destination are those created by the same connection that created the destination. Any message producer can send to the temporary destination. If you close the connection that a temporary destination belongs to, the destination is closed and its contents lost.

You can use temporary destinations to implement a simple request/reply mechanism (see JMSReplyTo, JMSCorrelationID, JMSMessageID).

3. Advanced Reliability Mechanisms

3.1 Creating Durable Subscriptions

To make sure that a pub/sub application receives all published messages, use PERSISTENT delivery mode for the publishers. In addition, use durable subscriptions for the subscribers.

The TopicSession.createSubscriber method creates a nondurable subscriber and can receive only messages that are published while it is active.

The TopicSession.createDurableSubscriber method creates a durable subscriber. A durable subscription can have only one active subscriber at a time.

A durable subscriber registers a durable subscription with a unique identity that is retained by the JMS provider. Subsequent subscriber objects with the same identity resume the subscription in the state in which it was left by the previous subscriber. 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.

You establish the unique identity of a durable subscriber by setting the following:

• A client ID for the connection

• A topic and a subscription name for the subscriber

With a durable subscriber, the subscriber can be closed and recreated, but the subscription continues to exist and to hold messages until the application calls the unsubscribe method.

3.2 Using JMS API Local Transactions

You can group a series of operations together into an atomic unit of work called a transaction. If any one of the operations fails, the transaction can be rolled back, and the operations can be attempted again from the beginning. If all the operations succeed, the transaction can be committed.

In a JMS client, you can use local transactions to group message sends and receives. The JMS API Session interface provides commit and rollback methods that you can use in a JMS client. A transaction commit means that all produced messages are sent and all consumed messages are acknowledged. A transaction rollback means that all produced messages are destroyed and all consumed messages are recovered and redelivered unless they have expired.

A transacted session is always involved in a transaction. As soon as the commit or the rollback method is called, one transaction ends and another transaction begins. Closing a transacted session rolls back its transaction in progress, including any pending sends and receives.

In an Enterprise JavaBeans component, you cannot use the Session.commit and Session.rollback methods. Instead, you use distributed transactions.

You can combine several sends and receives in a single JMS API local transaction. If you do so, you need to be careful about the order of the operations. You will have no problems if the transaction consists of all sends or all receives or if the receives come before the sends. But if you try to use a request-reply mechanism, whereby you send a message and then try to receive a reply to the sent message in the same transaction, the program will hang, because the send cannot take place until the transaction is committed. Because a message sent during a transaction is not actually sent until the transaction is committed, the transaction cannot contain any receives that depend on that message’s having been sent.

It is also important to note that the production and the consumption of a message cannot both be part of the same transaction. The reason is that the transactions take place between the clients and the JMS provider, which intervenes between the production and the consumption of the message.

Another way of putting this is that the act of producing and/or consuming messages in a session can be transactional, but the act of producing and consuming a specific message across different sessions cannot be transactional.

Because the commit and the rollback methods for local transactions are associated with the session, you cannot combine queue and topic operations in a single transaction.

You can, however, receive from one queue and send to another queue in the same transaction, assuming that you use the same Queue-Session to create the QueueReceiver and the QueueSender. You can pass a client program’s session to a message listener’s constructor function and use it to create a message producer, so that you can use the same session for receives and sends in asynchronous message consumers.

JMS: Basic Concepts - Part 1

2009-10-16T16:28:00.007+01:00

1. Introduction

My intention with this post is to summarize the most important ideas behind of JMS. As always, I am not trying to reinvent the wheel and all the notes are taken from the specification.

2. What Is the JMS API?

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

The JMS API enables distributed 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.

3. When Can You Use the JMS API?

An enterprise application provider is likely to choose a messaging API over a tightly coupled API, such as Remote Procedure Call (RPC), under the following circumstances.

• The provider wants the components not to depend on information about other components’ interfaces, so that components can be easily replaced.

• The provider wants the application to run whether or not all components are up and running simultaneously.

• The application business model allows a component to send information to another and to continue to operate without receiving an immediate response.

4. JMS API Architecture

A JMS application is composed of the following parts.

• JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features. An implementation of the J2EE platform at release 1.3 includes a JMS provider.

• JMS clients are the programs or components, written in the Java programming language, that produce and consume messages.

• Messages are the objects that communicate information between JMS clients.

• Administered objects are preconfigured JMS objects created by an administrator for the use of clients.

• Native clients are programs that use a messaging product’s native client API instead of the JMS API. An application first created before the JMS API became available and subsequently modified is likely to include both JMS and native clients.

5. Messaging Domains

Point-to-Point Messaging Domain

Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages.

Queues retain all messages sent to them until the messages are consumed or until the messages expire.

PTP messaging has the following characteristics:

• Each message has only one consumer.

• 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.

• The receiver acknowledges the successful processing of a message.

Publish/Subscribe Messaging Domain

Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic’s multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.

Pub/sub messaging has the following characteristics.

• Each message may have multiple consumers.

• 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.

The JMS API relaxes this timing dependency to some extent by allowing clients to create durable subscriptions. Durable subscriptions can 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.

6. Message Consumption

Messaging products are inherently asynchronous in that no fundamental timing dependency exists between the production and the consumption of a message. However, the JMS Specification uses this term in a more precise sense. Messages can be consumed in either of two ways:

• Synchronously. A subscriber or a receiver explicitly fetches the message from the destination by calling the receive method. The receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit.

• Asynchronously. A client can register a message listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener’s onMessage method, which acts on the contents of the message.

7.Main elements in JMS application

Administered Objects

Two parts of a JMS application—destinations and connection factories—are best maintained administratively rather than programmatically. The technology underlying these objects is likely to be very different from one implementation of the JMS API to another. Therefore, the management of these objects belongs with other administrative tasks that vary from provider to provider.

JMS clients access these objects through interfaces that are portable, so a client application can run with little or no change on more than one implementation of the JMS API.

Connection Factories

A connection factory is the object a client uses to create a connection with a provider.

A connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator.

Context ctx = new InitialContext();

QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup("QueueConnectionFactory");

TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) ctx.lookup("TopicConnectionFactory");

Destinations

A destination is the object a client uses to specify the target of messages it produces

and the source of messages it consumes.

Topic myTopic = (Topic) ctx.lookup("MyTopic");

Queue myQueue = (Queue) ctx.lookup("MyQueue");

Connections

A connection encapsulates a virtual connection with a JMS provider. A connection could represent an open TCP/IP socket between a client and a provider service daemon. You use a connection to create one or more sessions.

QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();

TopicConnection topicConnection = topicConnectionFactory.createTopicConnection();

Sessions

A session is a single-threaded context for producing and consuming messages. You use sessions to create message producers, message consumers, and messages. Sessions serialize the execution of message listeners.

A session provides a transactional context with which to group a set of sends and receives into an atomic unit of work.

TopicSession topicSession = topicConnection.createTopicSession(false,

Session.AUTO_ACKNOWLEDGE);

QueueSession queueSession = queueConnection.createQueueSession(true, 0);

Message Producers

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

QueueSender queueSender = queueSession.createSender(myQueue);

TopicPublisher topicPublisher = topicSession.createPublisher(myTopic);

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

queueSender.send(message);

topicPublisher.publish(message);

Message Consumers

A message consumer is an object created by a session and is used for receiving messages sent to a destination. A message consumer allows a JMS client to register interest in a destination with a JMS provider. The JMS provider manages the delivery of messages from a destination to the registered consumers of the destination.

QueueReceiver queueReceiver = queueSession.createReceiver(myQueue);

TopicSubscriber topicSubscriber = topicSession.createSubscriber(myTopic);

You use the TopicSession.createDurableSubscriber method to create a durable topic subscriber.

Message Listeners

A message listener is an object that acts as an asynchronous event handler for messages.

This object implements the MessageListener interface, which contains one method, onMessage. In the onMessage method, you define the actions to be taken when a message arrives.

You register the message listener with a specific QueueReceiver or TopicSubscriber by using the setMessageListener method. For example, if you define a class named TopicListener that implements the MessageListener interface, you can register the message listener as follows:

TopicListener topicListener = new TopicListener();

topicSubscriber.setMessageListener(topicListener);

A message listener is not specific to a particular destination type. The same listener can obtain messages from either a queue or a topic, depending on whether the listener is set by a QueueReceiver or a TopicSubscriber object. A message listener does, however, usually expect a specific message type and format. Moreover, if it needs to reply to messages, a message listener must either assume a particular destination type or obtain the destination type of the message and create a producer for that destination type.

Your onMessage method should handle all exceptions. It must not throw checked exceptions, and throwing a RuntimeException, though possible, is considered a programming error.

The session used to create the message consumer serializes the execution of all message listeners registered with the session. At any time, only one of the session’s message listeners is running.

In the J2EE 1.3 platform, a message-driven bean is a special kind of message listener. For details, see Section 6.2 on page 75.

Exception Handling

The root class for exceptions thrown by JMS API methods is JMSException. Catching JMSException provides a generic way of handling all exceptions related to the JMS API.

8. Examples

Example 1 - Sending Messages to a Queue

* Look up connection factory and queue. If either does

* not exist, exit.

try {

queueConnectionFactory = (QueueConnectionFactory)

jndiContext.lookup("QueueConnectionFactory");

queue = (Queue) jndiContext.lookup(queueName);

} catch (NamingException e) {

......................

}

* Create connection.

* Create session from connection; false means session is not transacted.

* Create sender and text message.

* Send messages, varying text slightly.

* Send end-of-messages message.

* Finally, close connection.

try {

queueConnection = queueConnectionFactory.createQueueConnection();

queueSession =

queueConnection.createQueueSession(false,

Session.AUTO_ACKNOWLEDGE);

queueSender = queueSession.createSender(queue);

message = queueSession.createTextMessage();

for (int i = 0; i < NUM_MSGS; i++) {

message.setText("This is message " + (i + 1));

queueSender.send(message);

}

* Send a non-text control message indicating end of

* messages.

queueSender.send(queueSession.createMessage());

} catch (JMSException e) {

.............

} finally {

if (queueConnection != null) {

try {

queueConnection.close();

} catch (JMSException e) {

.............

}

Example 2 - Publishing Messages to a Topic

* Look up connection factory and topic. If either does

* not exist, exit.

try {

topicConnectionFactory = (TopicConnectionFactory)

jndiContext.lookup("TopicConnectionFactory");

topic = (Topic) jndiContext.lookup(topicName);

} catch (NamingException e) {

............

}

* Create connection.

* Create session from connection; false means session is

* not transacted.

* Create publisher and text message.

* Send messages, varying text slightly.

* Finally, close connection.

try {

topicConnection =

topicConnectionFactory.createTopicConnection();

topicSession =

topicConnection.createTopicSession(false,

Session.AUTO_ACKNOWLEDGE);

topicPublisher = topicSession.createPublisher(topic);

message = topicSession.createTextMessage();

for (int i = 0; i < NUM_MSGS; i++) {

message.setText("This is message " + (i + 1));

topicPublisher.publish(message);

}

} catch (JMSException e) {

............

} finally {

if (topicConnection != null) {

try {

topicConnection.close();

} catch (JMSException e) {

............

}