Month: November 2014

Websphere Shared Library

Shared libraries are files used by multiple applications. Examples of shared libraries are commonly used frameworks like Apache Struts or log4j. You use shared libraries typically to point to a set of JARs and associate those JARs to an application, a Web module, or the class loader of an application server.

Shared libraries are especially useful when you have different versions of the same framework you want to associate to different applications.

Shared libraries are defined using the administration tools. They consist of a symbolic name, a Java class path, and a native path for loading JNI libraries.

1

However, simply defining a library does not cause the library to be loaded. You must associate the library to an application, a Web module, or the class loader of an application server for the classes represented by the shared library to be loaded. Associating the library to the class loader of an application server makes the library available to all applications on the server.

Note: If you associate a shared library to an application, do not associate the same library to the class loader of an application server.

You can associate the shared library to an application in one of two ways:

  • You can use the administration tools. The library is added using the Shared libraries references link under the References section for the enterprise application.

4

5

  • You can use the manifest file of the application and the shared library. The shared library contains a manifest file that identifies it as an extension. The dependency to the library is declared in the application’s manifest file by listing the library extension name in an extension list.

3

Configuring websphere for external third party non-JCA JMS provider

WAS v6.1 supports the use of third-party JMS providers within its runtime environment through the use of a generic JMS provider. A generic JMS provider must be defined to WAS before any JMS resources can be configured for that provider.

Defining a generic JMS provider to WAS ensures that the JMS provider classes are available on the application server classpath at runtime.

WAS interaction with a generic JMS provider –

The JMS administered objects for a generic JMS provider are bound into the local JNDI name space within WebSphere Application Server. These JNDI entries act as aliases to the real JMS administered objects that have been configured in the external JNDI name space of the messaging provider.

1

This indirection is achieved by providing additional JNDI information when configuring the JMS administered objects for the generic JMS provider. JMS client application code is not affected in any way. It is the responsibility of the WebSphere runtime to resolve accesses to the real JNDI entries in the external name space.

WebSphere is not responsible for binding the JMS administered objects into the external name space. This administrative task, along with creating the underlying messaging objects, queues, and topics, must be performed using the tools provided by the generic JMS provider.

Configuring a JMS provider for a third party non-JCA messaging provider:

  1. Start the administrative console.
  2. In the navigation pane, click Resources > JMS->JMS providers. The existing messaging providers are displayed, including the default messaging provider and the WebSphere MQ messaging provider.
  3. To define a new third-party non-JCA messaging provider, click New in the content pane. Otherwise, to change the definition of an existing messaging provider, click the name of the provider.
  4. Specify the following required properties. You can specify other properties, as described in a later step.

         Name: The name by which this messaging provider is known for administrative purposes within WebSphere Application Server.

         External initial context factory: The Java classname of the initial context factory for the JMS provider.

        External provider URL: The JMS provider URL for external JNDI lookups.

5. Optional: Click Apply. This enables you to specify additional properties.

6. Click OK

7. Save the changes to the master configuration.

2

Configuring a JMS connection factory for a third party non-JCA messaging provider:

  1. Display the third-party non-JCA messaging provider. In the navigation pane, click Resources > JMS->JMS providers.
  2. Select the third-party non-JCA messaging provider for which you want to configure a connection factory.
  3. Optional: Select the Scope setting corresponding to the scope of the connection factories that you want to view or change.
  4. In the content pane, under Additional Properties, click Connection factories This displays a table listing any existing JMS connection factories, with a summary of their properties.
  5. To browse or change an existing JMS connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
    1. Click New in the content pane.
    2. Specify the following required properties. You can specify other properties, as described in a later step.

                  Name: The name by which this JMS connection factory is known for administrative purposes within IBM® WebSphere® Application Server.

                 Type: Select whether the connection factory is for JMS queues (QUEUE) or JMS topics (TOPIC).

                 JNDI Name: The JNDI name that is used to bind the JMS connection factory into the WebSphere Application Server namespace.

                 External JNDI Name: The JNDI name that is used to bind the JMS connection factory into the namespace of the messaging provider.

C. Click Apply. This defines the JMS connection factory to WebSphere Application Server, and enables you to browse or change additional properties.

6. Click OK.

7. Save any changes to the master configuration.

3

Configuring a JMS destination for a third party non-JCA messaging provider:

  1. Start the administrative console.
  2. In the navigation pane, click Resources > JMS->JMS providers.
  3. Click the name of the third-party non-JCA messaging provider.
  4. In the content pane, under Additional Properties, click Queues for point-to-point messaging or Topics for publish/subscribe messaging.This displays a table listing any existing JMS destinations, with a summary of their properties.
  5. To browse or change an existing JMS destination, click its name in the list. Otherwise, to create a new destination, complete the following steps:
    1. Click New in the content pane.
    2. Specify the following required properties. You can specify other properties, as described in a later step.

                 Name: The name by which this JMS destination is known for administrative purposes within WebSphere Application Server.

                 Type: Select whether the destination is for JMS queues (QUEUE) or JMS topics (TOPIC).

                 JNDI Name: The JNDI name that is used to bind the JMS destination into the WebSphere Application Server namespace.

                 External JNDI Name: The JNDI name that is used to bind the JMS destination into the namespace of the messaging provider.

    1. Click Apply. This defines the JMS destination to WebSphere Application Server, and enables you to browse or change additional properties.

6. Click OK.

7. Save any changes to the master configuration.

4

Set custom property for the JMS destination:

Set custom properties of the provider to map external JNDI names. Below is just for illustration & ease of reference purpose:

– java.naming.connectionFactoryNames = ConnectionFactory
– java.naming.queue.MyQueue = MyQueue
– java.naming.topic.MyTopic = MyTopic

5

Managing message listener resources for message-driven beans:

  1. Start the administrative console.
  2. In the navigation pane, click Servers > Server Types > WebSphere application servers->server_name > [Communications] Messaging > Message listener service > [Additional Properties] Listener Ports > listener_port
  3. Select the name of the listener port that you want to work with. This displays the properties of the listener port in the content pane.
  4. Click OK.
  5. Save your changes to the master configuration.
  6. To have a changed configuration take effect, stop then restart the application server.

Create a Message Listener Port for message-driven beans. Below is just for illustration & ease of reference purpose:
– Set the connection factory JNDI, e.g. “ConnectionFactory”
– Set the destination JNDI, e.g. “MyTopic”

6

7

In the MDB project’s “ibm-ejb-jar-bnd.xmi” file, refer to the above message listener as –


<?xml version="1.0" encoding="UTF-8"?>

<ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ejb="ejb.xmi" xmlns:ejbbnd="ejbbnd.xmi" xmi:id="EJBJarBinding_1416464607405">

<ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/>

<ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1416464607406" listenerInputPortName="AMQ_JMS_TopicPort">

<enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#SampleMDB"/>

</ejbBindings>

</ejbbnd:EJBJarBinding>

Strategy Pattern

Strategy Pattern is one of the behavioral design pattern which defines a set of encapsulated algorithms that can be swapped to carry out a specific behavior at runtime without causing tight coupling. It is also known as Policy Pattern.

The Strategy pattern is to be used where you want to choose the algorithm to use at runtime.

One of the example of this pattern is Collection.sort() method that takes Comparator parameter. Based on different implementations of Comparator interfaces, the Objects are getting sorted in different ways.

On the downside, clients must be aware of different Strategies. The pattern has a potential drawback in that a client must understand how Strategies differ before it can select the appropriate one. Clients might be exposed to implementation issues. Therefore you should use the Strategy pattern only when the variation in behavior is relevant to clients.

Let’s try to illustrate the pattern with an example. Below is the class diagram for ease of reference –

classdiagram

First of all we will create the interface for our strategy:


package com.sanjit;

public interface OnlinePaymentStrategy {

public void pay(double amount);

}

Now we will have to create concrete implementations of algorithms for payment using netbanking/credit card:


package com.sanjit;

public class NetbankingPaymentStrategy implements OnlinePaymentStrategy {

/* (non-Javadoc)

* @see com.sanjit.OnlinePaymentStrategy#pay(double)

*/

@Override

public void pay(double amount) {

/*

* Logic for payment through netbanking goes here..

*/

System.out.println("Pay - " + amount + " through netbanking");

}

}

And now credit card strategy:


package com.sanjit;

public class CreditCardPaymentStrategy implements OnlinePaymentStrategy {

/* (non-Javadoc)

* @see com.sanjit.OnlinePaymentStrategy#pay(double)

*/

@Override

public void pay(double amount) {

/*

* Logic for payment through credit card goes here..

*/

System.out.println("Pay - " + amount + " through credit card");

}

}

Now our algorithms are ready and we can implement shopping item & cart. The payment method will require input as Payment strategy:


package com.sanjit;

public class ShoppingItem {

private int qty;

private double price;

public int getQty() {

return qty;

}

public void setQty(int qty) {

this.qty = qty;

}

public double getPrice() {

return price;

}

public void setPrice(double price) {

this.price = price;

}

}

The shopping cart:


package com.sanjit;

import java.util.List;

public class Cart {

private List items;

public List getItems() {

return items;

}

public void setItems(List items) {

this.items = items;

}

public double calculateCartPrice() {

double cartPrice = 0;

for (ShoppingItem item : items) {

cartPrice += item.getQty() * item.getPrice();

}

return cartPrice;

}

public void pay(OnlinePaymentStrategy ops) {

ops.pay(calculateCartPrice());

}

}

Now the main class for test purpose:-


package com.sanjit;

import java.util.ArrayList;

import java.util.List;

public class Main {

/**

* @param args

*/

public static void main(String[] args) {

List itemList = new ArrayList();

ShoppingItem item1 = new ShoppingItem();

item1.setQty(10);

item1.setPrice(100);

itemList.add(item1);

ShoppingItem item2 = new ShoppingItem();

item2.setQty(5);

item2.setPrice(10);

itemList.add(item2);

Cart cart = new Cart();

cart.setItems(itemList);

//Pay by credit card

cart.pay(new CreditCardPaymentStrategy());

//Pay by netbanking

cart.pay(new NetbankingPaymentStrategy());

}

}

Output on running the Main class:

Pay – 1050.0 through credit card

Pay – 1050.0 through netbanking

Visitor Pattern

Visitor Pattern is one of the behavioral design pattern which is used when we have to manage algorithms, relationships & responsibilities on a group of similar kind of objects at runtime, thus decoupling the operations from the object’s structure. So, Visitor pattern can provide additional functionality to a class without actually changing it.

The pattern should be used when you have distinct & unrelated operations to perform across a structure of objects. This avoids adding in code throughout your object structure that is better kept separate, so it encourages cleaner code. In summary, if you want to decouple some logical code from the elements that you’re using as input, visitor is probably the best pattern for the job.

On the downside, the arguments & return types for the visiting methods needs to be known in advance, so the Visitor pattern is not good for situations where these visited classes are subject to change. Every time a new type of Element is added, every Visitor derived class must be amended.

Also, it can be difficult to refactor the Visitor pattern into code that wasn’t already designed with the pattern in mind. And, when you do add your Visitor code, it can look obscure. The Visitor is powerful, but you should make sure to use it only when necessary.

Let’s try to illustrate the pattern with an example. Below is the class diagram for ease of reference –

classdiagram_1

First, let’s create our general visitable  interface:


package com.sanjit;

public interface ShoppingItem {
      public void accept(Visitor visitor);
}

 

Now, we’ll create a concrete implementation of our interface, Games :


package com.sanjit;

public class Games implements ShoppingItem {

      private double price;
      private int qty;

      public double getPrice() {
            return price;
      }

      public void setPrice(double price) {
            this.price = price;
      }

      public int getQty() {
            return qty;
      }

      public void setQty(int qty) {
            this.qty = qty;
      }

      @Override
      public void accept(Visitor visitor) {
            visitor.visit(this);
      }
}

 

and now for the Music:


package com.sanjit;

public class Music implements ShoppingItem {

      private double price;
      private int qty;

      public double getPrice() {
            return price;
      }

      public void setPrice(double price) {
            this.price = price;
      }

      public int getQty() {
            return qty;
      }

      public void setQty(int qty) {
            this.qty = qty;
      }

      @Override
      public void accept(Visitor visitor) {
            visitor.visit(this);
      }
}

As you can see it’s just a simple POJO, with the extra accept method added to allow the visitor access to the element. We could add in other types here to handle other items.

Now we’ll move on to the Visitor interface. For each different type of concrete element here, we’ll need to add a visit method. As we’ll just deal with Games & Music for now, this is as simple as:


package com.sanjit;

public interface Visitor {
      void visit(Games items);
      void visit(Music items);
}

The implementation of the Visitor can then deal with the specifics of what to do when we visit a Game or Music.


package com.sanjit;

public class CartVisitor implements Visitor {

      private double cartCost;

      public double getCartCost() {
            return cartCost;
      }

      public void setCartCost(double cartCost) {
            this.cartCost = cartCost;
      }

      @Override
      public void visit(Music items) {
         cartCost += items.getQty() * items.getPrice();
      }

      @Override
      public void visit(Games items) {
            cartCost += items.getQty() * items.getPrice();
      }
}

As you can see it’s a simple formula, but the point is that all the calculation for cart is done in one central place.

To drive this visitor, we’ll need a way of iterating through our shopping cart, as follows:


package com.sanjit;

import java.util.List;

public class Cart {

      private List items;

      public List getItems() {
            return items;
      }

      public void setItems(List items) {
            this.items = items;
      }

      public void calculateCartPrice() {

            CartVisitor cartVisitor = new CartVisitor();

            for(ShoppingItem item:items){
                  item.accept(cartVisitor);
            }

            System.out.println("Total Cart Cost: " + cartVisitor.getCartCost());
      }
}

Note that if we had other types of item here, once the visitor implements a method to visit that item, we could easily calculate the total cart cost.

The whole point of this pattern is to allow you separate out certain logic from the elements themselves, keeping your data classes simple.

Now the main class for test purpose:-


package com.sanjit;

import java.util.ArrayList;

import java.util.List;

public class Main {

          public static void main(String[] args) {

            Music m = new Music();
            m.setPrice(50);
            m.setQty(10);

            Games g = new Games();
            g.setPrice(100);
            g.setQty(100);

            List items = new ArrayList();
            items.add(m);
            items.add(g);

            Cart cart = new Cart();
            cart.setItems(items);
            cart.calculateCartPrice();
      }

}

Output on running the Main class:

Total Cart Cost: 10500.0