Strategy Pattern and J2EE

Discussions

J2EE patterns: Strategy Pattern and J2EE

  1. Strategy Pattern and J2EE (3 messages)

    Define a family of algorithms, encapsulate each, and make them interchangable in J2EE component. Strategy lets the algorithm vary independently from clients that use it. Article gives overview to use Strategy pattern in J2EE component with example.

    Use the strategy pattern when
     a. many related classes differ only in their behaviour. Strategies provide a way to configure a class with one of many behaviors.
     b. you need different variants of an algorithm.
     c. an algorithm uses data that client shouldn't know about.
    Use strategy pattern to avoid exposing complex, algorithm-specific data structure.
     d. a class defines many behaviors, and these appear as multiple condition statements in its operations.

    Sample code implementing Strategy pattern:

    import java.io.*;

    public interface InterfaceAlgorithm
    {

    public void executeAlgorithm();


    } // End of interface

    // Beginning of class

    class Algorithm1 implements InterfaceAlgorithm
    {

    public void executeAlgorithm() { prt(); }

    public void prt() { System.out.println(" Class is Algorithm1."); }


    }// End of class

    // Beginning of class

    class Algorithm2 implements InterfaceAlgorithm
    {

    public void executeAlgorithm() { prt(); }

    public void prt() { System.out.println(" Class is Algorithm2."); }


    } // End of class


    // Beginning of class

    class Context
    {

    public Context(InterfaceAlgorithm algo){ _algo = algo; }

    public void contextInterface() {
    _algo.executeAlgorithm(); }

    private InterfaceAlgorithm _algo;

    } //End of class

       In the above code InterfaceAlgorithm interface common to all supported algorithm classes Algorithm1 and Algorithm2. Class Context is configured with different algorithm object either object of Algorithm1 class or Algorithm2 class and maintains a reference to InterfaceAlgorithm type class.
      The advantage of this pattern is scalability of J2EE component which uses this pattern.
      
    Developing application as J2EE component makes it pluggable and portable. Now the question is about the type of bean used in J2EE component. It depends upon the situation.
    If we have to keep conversational state for that user then stateful session bean should be used in J2EE component
    If we don't have to keep conversational state then stateless session bean should be used in J2EE component for example
      J2EE component for currency converter
      J2EE component for file converter
         file converter includes
               doc to text converter
               text to pdf converter
               pdf to text converter
               
    or any utillity where no converstional stte need to be maintained.
    In the my current work i have used strategy pattern in developing a J2EE component (converter). This pattern have added the scalability in component and made this component more portable and easily pluggable.

    In last i want to mention some drawbacks of Strategy pattern
     a. Add communication overhead between objects
     b. Increased number of objects.

    for further information about J2EE component, developed by me, please contact raghvendra_singh0 at lycos dot com

       
  2. Strategy Pattern and J2EE[ Go to top ]

    I think that unless you have very tight performance requirements, coding the strategy pattern as Java may be the wrong thing to do.

    Think a little bigger and imagine using say BEA Process Integrator as your strategy pattern implementation. Developers looking at building Web Services, Portals, B2B or trying to build J2EE servers being used in integration type applications will find a product like Process Integrator much more useful than something they knock together in Java.

    They then model the strategy using the tooling with the BPM product and plugin their application logic using JMS or session beans etc.

    Strategies in these systems tend to be asynchronous, longer lived than a single thread, multiple transactions, etc. As the rules encoded in the strategy object become more complex then a maintenance problem can develop. Products like Versata are examples of this sort of inner VM strategy products and this problem has been noted.

    But, if you're building anything substantial then having a BPM (business process manager) component can be invaluable. If you're an IBM shop then look at MQ Workflow which also integrates with WebSphere nicely using MQ Series (JMS or MQI) and also integrates with legacy systems well.
  3. Strategy Pattern and J2EE[ Go to top ]

    The use of the strategy pattern shouldn't be limited to large-scale, asynchronous systems providing an interface to configure the underlying algorithm. This pattern is relatively easy to implement and I've used it in Java before, where the end user is given a number of options as to what algorithm to use in a given context, and the appropriate algorithm is then substituted and executed. There is no need for multi-threading (though this can easily be done) as only one algorithm is executed in a given context - this a a common approach in the Finance industry. Certainly, if you're doing process integration or serious workflow you may want to implement a mutil-threaded approach with third party software but in my experience this is usually the exception rather than the norm. I prefer to use inheritance with this patttern so that a default algorithm is always implemented.
  4. The BusinessPolicy component is implemented with the strategy pattern, see eBUSINESS SMART COMPONENTS and BusinessPolicy