We have tried two solutions for implementing partial matching

Single rule per risk profile approach:

• Anded conditions are defined in the object creation LHS part
• Ored conditions are defined using eval keyword as java objects
• Helper classes were used to perform comparison operations on BigInteger  , BigDecimal ,Date and String fields to prevent null pointer exceptions for not supplied fact data
• Scoring:
  • • Implemented by accumulating the conditions score in a globally defined ArrayList within the working memory for example ( c1 && sums.add(new condition(“cond1” , 15))
    • All the risk profile is anded with another eval that invokes proceed method that takes the sums and a threshold, that determines if a risk should be inserted into the working memory or not

Pros: Number of rules = no. of risk profiles + 1

Cons:Extensive use of eval keyword in scoring which removes any optimization done by Drools engine (Alpha nodes sharing , indexing and early tree pruning)

• Multiple rules for each Ored or Scored conditions approach:
  • Anded conditions are defined in the object creation LHS part
  • Ored conditions are defined in different rules in the same activation group with salience governing the conditions order
  • Scoring:
    • Each condition is defined in a separate rule with salience = -1 so that it never fire (accumulate rule is the only one allowed to fire)
    • An accumulate rule is defined for each risk profile that invokes the proceed with the accumulated conditions sums

Pros:Usage of Drools optimization techniques

Cons: Number of rules = no. of risk profiles * no.of ored conditions Or scored conditions + no.of risk profiles + 1

for example if we have 2500 risk profiles, where 500 of them has on average 4 ored and 500 scored conditions (3 conditions each)= 2000 + 4 * 500 + 500 * 3 + 500 + 1 = 6001

For POC case most of the risk profiles contains ored conditions and scoring so for the 2500 risk profiles defined, about 7000 rules were generated.

Performance comparison for both approaches

Test was performed on local standalone OC4J with local Oracle XE database.

Binary packages for single rule per risk profile approach was used as it was not possible to increase the Java heap space more than 1GB on windows XP, thus multiple rules approach failed locally because of Java heap space exceptions.

Note:

This data are manually collected as different criteria are monitored (on first request response time, OC4J memory increases, after first request response time)

Memory Consumption:

• Single Rule per risk profiles approach:
  • Binary package size ~75MB
  • OC4J needed 430-450MB to build a binary package of 2800 rules
  • Load time ~32s to ~1 minute
• Multiple rules approach:
  • Binary package size > 212MB (sum of single packages)
  • OC4J needed >1GB to build a DRL of 7000 rules
  • OC4J needed >1GB to build binary packages of sizes ranging from 20 to 90MB (most of the times the OC4J fails to load)
  • Load time from 7 to 10 minutes

Single Request Performance:

• First time invocation average: 750-1000ms
• Further Requests average: 500-650ms
• Memory increased by about 20-30MB

Six Concurrent Requests Performance

• First time invocation average: >5s
• Further Requests average: 1.5 – 2s

• Memory increased by about 50 – 60 MB

Fifty concurrent requests Performance:

• Memory increased by about 300MB
• First response arrival: ~4-6s
• Last response arrival: ~12-16s

Client Side Validation:

DTO Class UserDto:

public class UserDto implements Serializable {

private int userId;

private String userName;

}

Remote Service interface:

public interface MyService extends RemoteService {

public String saveUser(UserDto userDto);

}

Remote Service Asynchronous interface:

public interface MyServiceAsync {

public void saveUser(UserDto userDto, AsyncCallback<String> callback);

}

The client side call will be as follows:

MyServiceAsync myService = MyService.Util.getInstance();

UserDto user = new UserDto();

user.setUserId(Integer.parseInt(userId.getText()));

user.setUserName(userName.getText());

myService.saveUser(user, new AsyncCallback<String>() {

…

So when user for example enters string in user id, a number format exception will be raised which can be caught and appropriate error messages can be displayed. For debugging purposes the exception details are displayed in FireBug and the Hosted mode server console. (see GWT documentation for the emulated java exceptions).

Server side Validation:

Invalid input types:

The serialized request sent to the RPC service is mentioned as follows:

http://host:8888/TestValidation/?485975FDB961BEAB5B5D6F881FE9205A?demo.client.MyService?saveUser?demo.client.UserDto?demo.client.UserDto/1050776168?text?1?2?3?4?1?5?6?2342?7?

The dispatcher Servlet uses the interface name and method requested to get the bean implementing the requested interface, by using reflection, it gets the method parameters

By using ServerSerializationStreamReader utility class, it de-serializes the request parameter to the actual method parameter:

ServerSerializationStreamReader.deserializeValue(parameterTypes[i]);

The ServerSerializationStreamReader class, validates the parameters for its compatibility with method parameter types, and create the method parameters. If invalid parameters are sent, a serialization exception is sent back to the client (internal server error (code: 500)

Business constraint violations:

Since GWT handles the incorrect types automatically (String instead of integer for example), the business constraints on data transfer objects should be handled by the service invocation layer (RPC Handler)

• Approach 1:
  • Using third party validation party (for example Oval http://oval.sourceforge.net/) which allows defining annotations on the client DTO
• Approach 2:
  • Validating the input DTO manually by the service invocation layer

In order to allow third party annotations to be recognized by the GWT Compiler, the library should be included on the class path of the GWT compiler; this ant script illustrates the idea

<path id=”classpath”>
<pathelement location=”${gwtpath}/gwt-user.jar” />
<pathelement location=”${gwtpath}/gwt-dev-windows.jar” />
<pathelement location=”${src.dir}” />
<fileset dir=”${lib.dir}”>
<include name=”**/*.jar” />
</fileset>
</path>

<target name=”compile-gwt” depends=”init”>
<java classname=”com.google.gwt.dev.GWTCompiler” fork=”true”>
<classpath refid=”classpath” />
<jvmarg value=”-Xmx256M” />
<arg value=”-out” />
<arg value=”${www.dir}” />
<arg value=”${gwt.module}” />
</java>
</target>

Introduction

The JMS specification describes a set of programming interfaces that support distributed, enterprise messaging. An enterprise messaging systems enables independent distributed components or applications to interact through messages.

In the messaging world, messages are not sent directly to other applications. Instead, messages are sent to destinations, known as queues or topics.

JMS specification defines two Messaging paradigms:

• Point To Point (PTP)
  • It uses the message Queue concept.
  • Messages are stored in a Queue destination.
  • The message has only one consumer.
• Publish Subscribe:
  • It uses a Topic to send and receive messages.
  • Each message can have multiple consumers.

Administrator is responsible for defining the destination Queue/Topic with their JNDI names.

JMS Application Components

JMS Clients

Java program that send / receive Messages. Clients can be standalone java applications or Enterprise Java Beans capable of receiving messages asynchronously (Message Driven beans)

Messages

Administered Objects

These are objects created on the Application server. They include the Connection Factory, the topic or queue destinations.

JMS Provider

Known as a Message Oriented Middleware (MOM) system.

JBoss comes with a JMS 1.1 compliant JMS provider called JBoss Messaging or JBossMQ

Setup JMS Connections in JBoss

A connection is needed to the destination Queue/Topic, this can be done using JNDI lookup, but we need first to get the initial context which is the entry point in any JNDI lookup operation.

Hashtable environment = new Hashtable();

environment.put(Context.INITIAL_CONTEXT_FACTORY,

“org.jnp.interfaces.NamingContextFactory”);

environment.put(Context.URL_PKG_PREFIXES,

“org.jboss.naming:org.jnp.interfaces”);

environment.put(Context.PROVIDER_URL, “jnp://localhost:1099″);

InitialContext iniCtx = new InitialContext(environment);

The next step is to create a connection to the destination Queue/Topic

Object tmp = iniCtx.lookup(“ConnectionFactory”);

Then depending on whether we want a Queue or Topic destination we type cast the connection factory object was lookup to either QueueConnectionFactory or TopicConnectionFactory object.

QueueConnectionFactory qcf = (QueueConnectionFactory) tmp;

javax.jms.QueueConnection = qcf.createQueueConnection();

javax.jms.Queue = (Queue) iniCtx.lookup(“queue/testQueue”);

javax.jms.QueueSession = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);

Note that Queues/Topics should be prefixed with queue or topic words.

Create a JMS sender

The Session interface defines different types of messages that can be sent.

PTP Sender

Javax.jms.QueueSender = session.createSender(javax.jms.Queue);

Step 1:

Create business interface created in the client package that extends
RemoteService interface

package demo.client;

public interface Test extends RemoteService {

public static final String SERVICE_URI = "RPCHandler";

public static class Util {

public static TestAsync getInstance() {

TestAsync instance = (TestAsync) GWT.create(Test.class);

ServiceDefTarget target = (ServiceDefTarget) instance;

target.setServiceEntryPoint(GWT.getModuleBaseURL() +
SERVICE_URI);

return instance;

}

}

public String sayHello(String name);

}

Step 2:

Create the asynchronous business interface (e.g. MyServiceAsycn.java).

(Note: The <interfaceName>Async naming convention is important for the GWT compiler)

package demo.client;

public interface TestAsync {

public void sayHello(String s, AsyncCallback<String> callback);

}

Step 3:

The dispatcher Servlet acts as the controller to invoke the services implementations that are defined as spring beans. The dispatcher Servlet uses

WebApplicationContextUtils.getWebApplicationContext(getServletContext()).getBean(interfaceName)

to get the requested service implementation bean. The dispatcher Servlet design follows these steps:

Create an ordinary Servlet to handle all GWT RPC calls, and then Servlet
implementation is responsible for invoking the requested service
method.

Define the service implementation as a spring bean to implement the
business interface defined at the client.

package demo.server;

@Transactional

public class HandlerService implements Test {

public String sayHello(String name) {

return "Hello " + name;

}

Use RPC.decodeRequest utility class to get the RPC request, which contains
the business interface name , method to be invoked and parameters, the
encoded request looks similar to this pattern:

http://host:8888/TestValidation/?485975FDB961BEAB5B5D6F881FE9205A?demo.client.MyService?saveUser

?demo.client.UserDto?demo.client.UserDto/1050776168?text?1?2?3?4?1?5?6?2342?7?

where,

demo.client.MyService: Interface name

saveUser: Method to be invoked

demo.client.UserDto: method parameters object type(s)

Service implementation invocation design approaches:

• The service implementation is defined as a Spring bean , with an ID
  equals to the name of the interface
• The service implementation is defined as a Spring bean with id equals
  to the name of the interface and method (<interface
  FQN>.methodname;

The RPC Handler Servlet ,invokes the method requested in the payload on
the retrieved spring bean

The RPC Handler uses the utility classes that comes with the GWT library
(RPC , RPCServletUtil …)

protected void doPost(HttpServletRequest httpRequest,HttpServletResponse httpResponse) throws ServletException,IOException {

String payload =
RPCServletUtils.readContentAsUtf8(httpRequest);

Object service = null;

String responsePayload = null;

RPCRequest rpcRequest = RPC.decodeRequest(payload);

Class clazz = rpcRequest.getMethod().getDeclaringClass();

service = getService(clazz.getName());

responsePayload = RPC.invokeAndEncodeResponse(service, rpcRequest.getMethod(), rpcRequest.getParameters(), rpcRequest.getSerializationPolicy());

boolean gzipEncode = false;

RPCServletUtils.writeResponse(getServletContext(),httpResponse,responsePayload, gzipEncode);