Eugene Kuleshov's Blog

Eugene Kuleshov's Homepage
Eugene Kuleshov is an independent consultant. He has over twelve years of experience in software design and development and specializing in application security, enterprise integration (EAI) and message oriented middleware. His list of clients include large financial and insurance companies.

Meet dev2dev editor.

Executing tasks with java.util.concurrent API

  ExecutorService executor = ...
  ArchiveSearcher searcher = ...
  Future future = executor.submit(new Callable() {
      public String call() { 
        return searcher.search(target); 
      }
    });
  displayOtherThings(); // do other things while searching
  try {
    displayText(future.get()); // use future
  } catch(ExecutionException ex) { 
    cleanup();
  }

  <bean id="executorService" 
        class="org.javatx.cj.work.XWorkExecutorService">
    <property name="qcf" ref="workQcf"/>
    <property name="queue" ref="workQueue"/>
    <property name="workHome" ref="workHome"/>
  </bean>

  <bean id="workQcf" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="javatx.workermdb.qcf"/>
  </bean>

  <bean id="workQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="javatx.workermdb.queue"/>
  </bean>

  <bean id="workHome" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName">
      <bean id="org.javatx.cj.work.XWorkHome.JNDI_NAME"
        class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/>
    </property>
  </bean>

If you can't handle long task, then break it into pieces

Resolving WebSphereMQ reason codes out of JMS errors.

  ...
  } catch(JMSException ex) {
    Exception exx = ex.getLinkedException() != null ? ex.getLinkedException() : ex;
    String msg = "JMS error: "+exx.getMessage();
    logger.error(msg, exx);
    ...
  }

  com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2072

  ...
  } catch(JMSException ex) {
    Exception exx = ex.getLinkedException() != null ? ex.getLinkedException() : ex;
    String msg = "JMS error: "+exx.getMessage();
    if(exx instanceof MQException) {
      MQException mqex = (MQException) exx;
      msg += " " + MQ_REASON_CODES.get(mqex.reasonCode);
    }
    logger.error(msg, exx);
    ...
  }

/**
 * Helper class to resolve MQSeries reason codes
 * (c) 2005, Eugene Kuleshov. All rights reserved
 */
public class MQReasonCodeResolver {
  private static final Logger logger =
      Logger.getLogger(MQReasonCodeResolver.class);
    
  public static final String MQ_EXCEPTION_CLASS =
      "com.ibm.mq.MQException";
  public static final String RC_FIELD_PREFIX = "MQRC_";
  public static final String RC_VALUE_FIELD = "reasonCode";

  /**
   * Resolve reson code from MQException
   * 
   * @param mqex MQException to resolve
   * @return symbolic name for reason code from MQException
   */
  public static String resolve(Exception mqex) {
    Class c = mqex.getClass();
    try {
      Field f = c.getField(RC_VALUE_FIELD);
      Object key = f.get(mqex);
      Field[] fields = c.getFields();
      for( int i = 0; i < fields.length; i++) {
        Field ff = fields[ i];
        String name = ff.getName();
        if(name.startsWith(RC_FIELD_PREFIX) && 
           ff.get(null).equals( key)) {
          return name;
        }
      }
    } catch( Exception ex) {
      logger.warn("Unable to resolve reason code; "+ex.toString());
    }
    return "unknown";
  }

  /**
   * Verify if reason code can be resolved
   * 
   * @param mqex MQException to resolve
   * @return symbolic name for reason code from MQException
   */
  public static boolean canResolve(Exception exx) {
    Class c = exx.getClass();
    while(Exception.class.isAssignableFrom(c)) {
      if(MQ_EXCEPTION_CLASS.equals(c.getName())) return true;
      c = c.getSuperclass();
    }
    return false;
  }
    
}

  ...
  } catch(JMSException ex) {
    Exception exx = ex.getLinkedException() != null ? ex.getLinkedException() : ex;
    String msg = "JMS error: "+exx.getMessage();
    if(MQReasonCodeResolver.canResolve(exx)) {
      msg += " "+MQReasonCodeResolver.resolve(exx);
    }
    logger.error(msg, exx);
    ...
  }

  MQJE001: Completion Code 2, Reason 2072 MQRC_SYNCPOINT_NOT_AVAILABLE

Implementing J2EE-based services for a real world.

Bobby Woolf posted a blog entry "How to Implement a Service in J2EE". He is suggesting to use SSB if service using synchronous transport (such as HTTP or RMI) and MDB in case if transport is asynchronous (e.g. JMS or JCA).

Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.

It is hard to disagree with this. Services exposed as SSB and MDB managed by J2EE application server is a really good option, because it automatically provides remoting, transactionality, security, pooling, load balancing, failover recovery, etc. to both client an service provider and especially if you can afford to use an application server there is truly no point to reinvent the wheel and spend time on reimplementing these services.

Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean/POJO. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.

So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.

Well, it had been discussed a lot some time ago when IoC containers started to became popular. This is seems too strong statement to say that POJO-based design is leaking support of security, transactions, remoteness, etc. Those are really crosscutting concerns and has very little or nothing to do with actual business logic. Moreover these separate concerns don't really require unit testing, but only integration testing.

In my opinion the much more flexible approach that benefits from both is to use EJB's only as a Service Facade for boundaries that may have remoting, transactionality, etc. and keep actual business logic implementation in POJO's driven by some IoC container. Then EJB code will look something like this (with XDoclet annotations):

  private RequestProcessor requestProcessor;

  /**
   * @ejb.interface-method view-type = "both"
   * @ejb.transaction type = "RequiresNew"
   */
  public String request( String msg) {
    return requestProcessor.submitSync( msg);
  }

Where requestProcessor is a POJO managed by Spring. Note that code is so simple that practically require no testing at component level.

This is how service components are wired together.

Notice that POJO component can be still used outside container (e.g. in a standalone client), which is particularly handy for testing and debugging.

The above approach has several significant benefits during development. The following table provides comparison between EJB and POJO-based component development. As you can see, POJOs make testing easier and the time for the entire change/build/deploy/test/verify cycle is about 5...10+ times less in this case and allows more dynamic development process.

There are many other benefits with POJO-based implementation that I'd like to talk about in other posts.

Implementing Work Manager specification on J2EE 1.3

  InitialContext ctx = new InitialContext();
  WorkManager workManager = ( WorkManager) ctx.lookup( "org.javatx.cj.work.WorkManager");
    
  workManager.schedule(new TestWork( "work1"));
  workManager.schedule(new TestWork( "work2"));

Visualize WebLogic's config.xml

All configuration parameters of the WebLogic server are stored to single config.xml file saved in the domain directory. This config file is a primary source of information about all configuration parameters including JDBC connection pools, JMS, JTA, logging, clustering, deployed application, etc.

Note that reference documentation does not recommend editing config.xml directly!

The good thing about config.xml is that it can be viewed in any text editor. For example:

<?xml version="1.0" encoding="UTF-8"?>
<Domain ConfigurationVersion="8.1.3.0" Name="mydomain">
    <Server ExpectedToRun="false" JMSThreadPoolSize="10"
        ListenAddress="" ListenPort="7001" Name="myserver"
        NativeIOEnabled="true" ReliableDeliveryPolicy="RMDefaultPolicy"
        ServerVersion="8.1.3.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
...
    <JDBCConnectionPool DriverName="oracle.jdbc.driver.OracleDriver"
        InitialCapacity="1" MaxCapacity="10" Name="wliBackupPool"
        Password="{3DES}lU/aklIfTfKSok8gf4WpNg=="
        PreparedStatementCacheSize="300"
...

From the above config fragment you can see that JDBC connection pool with name wliBackupPool is using non-XA JDBC driver oracle.jdbc.driver.OracleDriver.

Unfortunately, for a heavily customized server that has several applications deployed, config.xml could be very large and browsing it without a special tool or XML-aware editor is no fun at all. However it is still the fastest way to verify server configuration.

One of the possible solutions to this issue is to transform config.xml to more readable document. There are lot of different tools can be used to do that and most of them will require special configuration. From other hand, these days pretty much any workstation has web browser and most if not all of them can apply XSL and CSS document transformations on the fly. You can specify stylesheet location using special processing instruction in XML document and browser will use that stylesheet to transform data before rendering it on the screen. For example:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl"
   href="http://dev2dev.bea.com/blog/euxx/config.xsl"?>
<Domain ConfigurationVersion="8.1.3.0" Name="mydomain"?>
  <Server ExpectedToRun="false" JMSThreadPoolSize="10"
...

I've prepared a simple XSL transformation that shows structure of the config.xml. After adding above instruction to config.xml it can be opened in a web browser.

Another handy thing is that for every config element there is a link to an appropriate place in the WebLogic Server Configuration Reference.

October 2007

Search this blog:

Archives

May 2006
January 2006
November 2005
August 2005
June 2005
April 2005

Categories

Recent Entries

Meet dev2dev editor.

Executing tasks with java.util.concurrent API

If you can't handle long task, then break it into pieces

Articles

High Performance Message Processing with BMT Message-Driven Beans and Spring
Addressing the traditional MDB-based message consumption model, Dmitri Maximovich and Eugene Kuleshov show how this scenario can be refactored to increase performance with non-transactional message retrieval while retaining once-and-only-once quality of service. Jan. 30, 2006

Using the Spring AOP Framework with EJB Components
EJB components can comfortably coexist with the Spring Framework. In this article, Eugene Kuleshov shows how, and demonstrates how this naturally leads to a wealth of additional functionality that can be transparently added using AOP. Dec. 19, 2005

Using and hacking Subclipse - the Subversion plugin for Eclipse
Subversion is a compelling replacement for the CVS version control system. This article shows how to access a Subversion repository (such as CodeShare) using the Subclipe Eclipse plug-in, and how to extend the plug-in itself. Nov. 30, 2005

All articles by Eugene Kuleshov »