Tower of Hanoi in Scala

Had a little fun with scala after 2 months, an implementation of Tower of Hanoi:

object Hanoi{
    def move(n:Int, fromTower:String, toTower:String, usingTower:String):Unit = {
        if (n==0) return
        move(n-1, fromTower, usingTower, toTower);
        println("Moving from " + fromTower + " to " + toTower)
        move(n-1, usingTower, toTower, fromTower);
    }
}

Drools session at Indianapolis Java User Group

I attended a JBoss Drools session at the Indianapolis JUG yesterday evening. The session was presented by Ray Ploski, a Principal Solution Architect with Redhat.
Ray went over the breadth of product offerings within the Drools Umbrella -

• Drools Expert(the Rule engine)
• Drools Guvnor(Rules Hosting/Management)
• Drools Fusion(Complex Event Processing) 
• Drools Planner(Planning)
• Drools Flow(Process Flow)

All these product offerings is together referred to as the "Drools Business Logic Integration Platform". 

I had gone into the meeting with the mistaken assumption that Drools is just a rule engine and came out  a little wiser. 

Some notes that I have from the meeting are the following:

• Ray has hosted the presentation, samples at this location - http://bit.ly/cjug-drools-2011
• Drools Flow is being merged into jBPM5 - with support for Graphical process flows tightly integrated with Drools Expert.
• Rules and other artifacts can be versioned within Guvnor - internally it uses JCR as the API for versioning with Jack Rabbit as the implementation
• Java code can implement a pull based model, to pull in rules from Guvnor - at a specified schedule pull in the latest rules from Guvnor, thus reflecting the rule changes without needing to restart application
• Drools Expert uses a MVEL dialect to express the condition(LHS) part of the rule
• One of the largest Drools users has Million and a half rules defined!

PS: E-gineering hosted this meeting at their great new office location.

java.lang.ClassCastException: org.apache.cxf.transport.servlet.CXFServlet cannot be cast to javax.servlet.Servlet

I was getting this exception:

java.lang.ClassCastException: org.apache.cxf.transport.servlet.CXFServlet cannot be cast to javax.servlet.Servlet
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1116)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4350)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4659)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)

when trying to start up Tomcat using maven command -

mvn tomcat:run

on this application -

git://github.com/bijukunjummen/memberservice-codefirst.git

It turns out that the issue is related to a dependency that CXF pulls in which conflicts with Tomcats version of Servlet class. The fix is to change the maven dependency from:

  <dependency>
   <groupId>org.apache.cxf</groupId>
   <artifactId>apache-cxf</artifactId>
   <version>${cxf.version}</version>
   <type>pom</type>
  </dependency>

to the specific set of CXF libs:

  <dependency>
   <groupId>org.apache.cxf</groupId>
   <artifactId>cxf-rt-frontend-jaxws</artifactId>
   <version>${cxf.version}</version>
  </dependency>
  <dependency>
   <groupId>org.apache.cxf</groupId>
   <artifactId>cxf-rt-transports-http</artifactId>
   <version>${cxf.version}</version>
  </dependency>
  <dependency>
   <groupId>org.apache.cxf</groupId>
   <artifactId>cxf-rt-transports-http</artifactId>
   <version>${cxf.version}</version>
  </dependency>
  <dependency>
   <groupId>org.apache.cxf</groupId>
   <artifactId>cxf-rt-ws-security</artifactId>
   <version>${cxf.version}</version>
  </dependency>
  <dependency>
      <groupId>org.apache.ws.security</groupId>
      <artifactId>wss4j</artifactId>
      <version>1.6.0</version>
  </dependency> 

Now

mvn tomcat:run

should run through just fine.

Enabling WS-Security Username Token Profile for Apache CXF service

This article describes how to create a code first webservice. I am going to extend the sample provided to support WS-Security Username Token profile. It is a way for the callers of the service to prove their identity by providing username and a password.

To recap the previous article, it is very simple to expose a code first webservice using Apache CXF with Spring. Apache CXF provides a custom Spring namespace to easily configure the endpoint:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
 xmlns:context="http://www.springframework.org/schema/context"
 xmlns:jaxws="http://cxf.apache.org/jaxws"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
        http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">

 <import resource="classpath:META-INF/cxf/cxf.xml"/>
 <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
 

 <bean id="memberendpoint" class="org.bk.memberservice.endpoint.DefaultMemberEndpoint"/>
 
 <jaxws:endpoint address="/memberservice" id="memberservicehttp" implementor="#memberendpoint" >
 </jaxws:endpoint>

</beans>

This exposes the memberendpoint bean above as a fully configured webservice.

To secure this service using usernametoken, first implement a callback for CXF to invoke to validate the credentials passed by the user:

package org.bk.memberservice.endpoint;

import java.io.IOException;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;

import org.apache.ws.security.WSPasswordCallback;

public class UsernameTokenCallback implements CallbackHandler {

 @Override
 public void handle(Callback[] callbacks) throws IOException,
   UnsupportedCallbackException {
  Callback callback = callbacks[0];
  WSPasswordCallback pc = (WSPasswordCallback) callback;

//              Retrieve and set the real password..which will be validated 

//              by CXF validator against the digest password

pc.setPassword("test");
  System.out.println("Received cred: " + pc.getIdentifier() + " : " + pc.getPassword());
//  validate the credentials
//              boolean isValid = true;
//              throw IO Exception if the credentials are not valid
//  if (!isValid) {
//   throw new IOException("Bad Credentials");
//  }
 }
}

To wire this Callback handler with the service endpoint, CXF uses a concept called the interceptor, basically the webservice call is handled by the interceptors before being handed over to the service.

<jaxws:endpoint address="/memberservice" id="memberservicehttp"
  implementor="#memberendpoint">
  <jaxws:inInterceptors>
   <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
    <constructor-arg>
     <map>
      <entry key="action" value="UsernameToken" />
      <entry key="passwordType" value="PasswordDigest" />
      <entry key="passwordCallbackRef">
       <ref bean="usernameTokenCallback" />
      </entry>
     </map>
    </constructor-arg>
   </bean>
  </jaxws:inInterceptors>
 </jaxws:endpoint>

That's it!! the endpoint is now secured using UsernameToken profile. To test this, bring up the endpoint, use SOAP UI to send a normal request, it will fail with the message that a ws-security header is required - this is the username token soap header that is expected as part of the request.

 Fix this by adding the username and password, select "digest" as the password type and the service invocation should just work.
Updated Sample available at: git://github.com/bijukunjummen/memberservice-codefirst.git
Reference:
1. WS-Security reference in Wikipedia: http://en.wikipedia.org/wiki/WS-Security
2. WS-Secuirty usernametoken profile specs at OASIS: http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf
3. Apache CXF reference: http://cxf.apache.org/docs/ws-security.html
4. New changes as part of WSS4J - http://coheigea.blogspot.com/2011/02/wspasswordcallback-changes-in-wss4j-16.html

Quick and Dirty fixtures for tests

This is a quick and dirty approach that I use to quickly add fixtures for a entity test, say if I am testing an entity of the following type:

@Entity
@Table(name="gtdcontexts")
public class GtdContext {
    @Size(min = 1, max = 50)
    private String name;
...

In my test Spring context file, I have entries to instantiate beans of the type:

 <bean name="context1" class="org.bk.simplygtd.domain.GtdContext"  p:name="context1"/>
    <bean name="context2" class="org.bk.simplygtd.domain.GtdContext"  p:name="context2"/>
    <bean name="context3" class="org.bk.simplygtd.domain.GtdContext"  p:name="context3"/>
    <bean name="context4" class="org.bk.simplygtd.domain.GtdContext"  p:name="context4"/>
    <bean name="context5" class="org.bk.simplygtd.domain.GtdContext"  p:name="context5"/>

Now in my test class, I autowire in a Map in the following way:

 
 @Autowired
 Map<String, GtdContext> gtdContextsMap;

Spring in this case autowires in all the GtdContexts instances into this Map, with the key as the bean name and the value being the instance. So now that the map is populated, a test embedded database can be populated with these fixtures:

<jdbc:embedded-database type="H2" id="dataSource"></jdbc:embedded-database>

  for (Map.Entry<String, GtdContext> entry:gtdContextsMap.entrySet()){
   this.gtdContextDao.persist(entry.getValue());
  }

That is it! an embedded h2 database with some sample entries will be ready for tests

Sample Contract First Service using Spring-WS 2.0

I have now updated the sample for this article, to use Spring WS 2.0, which now provides a annotation based model for Webservice endpoints. The amount of configuration required to define a Webservice endpoint has reduced considerably between Spring WS 1.x and Spring WS 2.0  - most of the routine boilerplate to define an endpoint has moved from configuration to an annotation:
Whereas earlier, the endpoint would have been defined by a code of the following signature:

public class GetMemberDetailsEndpoint extends
  AbstractMarshallingPayloadEndpoint {
 private MemberManager memberManager;
 protected Object invokeInternal(Object requestObject) throws Exception {
  MemberDetailsRequest request = (MemberDetailsRequest) requestObject;
  MemberDetail memberDetail = memberManager.getMemberDetails(request
    .getId());
  MemberDetailsResponse response = new MemberDetailsResponse(memberDetail);
  return response;
 }

......
}

With Spring-WS 2.0 the endpoint can be more intuitively defined with the following signature:

@Endpoint
public class GetMemberDetailsEndpoint {

 @Autowired private MemberManager memberManager;

 @PayloadRoot(namespace = "http://bk.org/memberservice/", localPart = "MemberDetailsRequest")
 @ResponsePayload
 public MemberDetailsResponse getMemberDetails(@RequestPayload MemberDetailsRequest request) throws Exception {
  MemberDetail memberDetail = memberManager.getMemberDetails(request
    .getId());
  MemberDetailsResponse response = new MemberDetailsResponse(memberDetail);
  return response;

 }

.....

}

Updated code available at:
git://github.com/bijukunjummen/memberservice-contractfirst.git

Contract First and Code First Webservice Development

There are generally two styles for Webservice Development - Contract First and Code First.

Contract First is an approach where the developer starts from defining a contract for the webservice using a WSDL and then goes about generating/developing the codebase - typically using stacks that allow code to be generated from the wsdl.

Code First on the other hand is an approach where the developer starts by defining an interface, then generates the contract for the webservice using tools that allow translating an interface to wsdl.

I have used both approaches now for different projects over time and but am not very opinionated about either of the approaches. A purist approach would be to start with the contract, which I have personally advocated in the past, however in some real world projects I have tended to go with a code first approach, for a few reasons:

1. Good tool support is required to define a reasonably involved wsdl - Eclipse is not good enough to create a quality wsdl - I would recommend IBM RAD or XML Spy for creating wsdl's
2. A very deep knowledge of XML schema language is required to generate good constructs
3. Development time is generally slower -  as creating a wsdl takes a good amount of time

Code First Approach on the other hand is quick. Let me illustrate by changing my DZone Example which is a Contract First example to a Code First using Apache CXF:

The contract for the service was:

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ms="http://bk.org/memberservice/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="memberservice" targetNamespace="http://bk.org/memberservice/">
 <wsdl:types>
  <xsd:schema targetNamespace="http://bk.org/memberservice/" elementFormDefault="qualified">
   <xsd:complexType name="MemberDetailType">
    <xsd:sequence>
     <xsd:element name="name" type="xsd:string"/>
     <xsd:element name="phone" type="xsd:string"/>
     <xsd:element name="city" type="xsd:string"/>
     <xsd:element name="state" type="xsd:string"/>
    </xsd:sequence>
   </xsd:complexType>
   <xsd:element name="MemberDetailsRequest">
    <xsd:complexType>
     <xsd:sequence>
      <xsd:element name="id" type="xsd:string"/>
     </xsd:sequence>
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="MemberDetailsResponse">
    <xsd:complexType>
     <xsd:sequence>
      <xsd:element name="memberdetail" type="ms:MemberDetailType"/>
     </xsd:sequence>
    </xsd:complexType>
   </xsd:element>
  </xsd:schema>
 </wsdl:types>
 <wsdl:message name="MemberDetailsRequest">
  <wsdl:part element="ms:MemberDetailsRequest" name="parameters"/>
 </wsdl:message>
 <wsdl:message name="MemberDetailsResponse">
  <wsdl:part element="ms:MemberDetailsResponse" name="parameters"/>
 </wsdl:message>
 <wsdl:portType name="memberservice">
  <wsdl:operation name="GetMemberDetails">
   <wsdl:input message="ms:MemberDetailsRequest"/>
   <wsdl:output message="ms:MemberDetailsResponse"/>
  </wsdl:operation>
 </wsdl:portType>
 <wsdl:binding name="memberserviceSOAP" type="ms:memberservice">
  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
  <wsdl:operation name="GetMemberDetails">
   <soap:operation soapAction="http://bk.org/memberservice/GetMemberDetails"/>
   <wsdl:input>
    <soap:body use="literal"/>
   </wsdl:input>
   <wsdl:output>
    <soap:body use="literal"/>
   </wsdl:output>
  </wsdl:operation>
 </wsdl:binding>
 <wsdl:service name="memberservice">
  <wsdl:port binding="ms:memberserviceSOAP" name="memberserviceSOAP">
   <soap:address location="http://localhost:8081/memberservice/services/MemberDetailsRequest"/>
  </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

Let us start by defining a java interface that can sufficiently mimic this WSDL:

package org.bk.memberservice.endpoint;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;

import org.bk.memberservice.message.MemberDetailsRequest;
import org.bk.memberservice.message.MemberDetailsResponse;

@WebService
public interface MemberEndpoint {
 @WebMethod(operationName = "MemberDetailsRequest")
 @WebResult(name = "MemberDetailsResponse", targetNamespace = "http://bk.org/memberservice/")
 MemberDetailsResponse getMemberDetails(
   @WebParam(name = "MemberDetailsRequest") MemberDetailsRequest memberDetailsRequest);
}

and the JAXB2 annotations on the request and response types:

package org.bk.memberservice.message;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "MemberDetailsRequest", namespace="http://bk.org/memberservice/")
public class MemberDetailsRequest {

 public MemberDetailsRequest() {
 }

 public MemberDetailsRequest(String id) {
  this.id = id;
 }

 private String id;

 public String getId() {
  return id;
 }

 public void setId(String id) {
  this.id = id;
 }

}

package org.bk.memberservice.message;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

import org.bk.memberservice.types.MemberDetail;

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "MemberDetailsResponse", namespace="http://bk.org/memberservice/")
public class MemberDetailsResponse {

 public MemberDetailsResponse() {
 }

 @XmlElement(name="memberdetail", namespace="http://bk.org/memberservice/")
 private MemberDetail memberDetail;

 public MemberDetailsResponse(MemberDetail memberDetail) {
  this.memberDetail = memberDetail;
 }

 public MemberDetail getMemberDetail() {
  return memberDetail;
 }

 public void setMemberDetail(MemberDetail memberDetail) {
  this.memberDetail = memberDetail;
 }

}

This generates a wsdl fairly close to the manually generated one, but not quite there - there does not seem to be a good way of controlling the namespace of operation name, and the wrappers around the request and the response xml structures.

So considering these factors, a rule that I have used is:

• If a service is consumed only by a known internal client(say for cases where the same team is the producer AND the consumer) then go for code first, for the speed of development
• If a service is expected to be more widely used, then go for contract first, with careful wsdl design

Sample code used here is available at :
git://github.com/bijukunjummen/memberservice-codefirst.git

Layered vs Big Ball of Mud

Layered arch vs Big Ball Of Mud: 

§  Separation of concerns -  Each layer encapsulates distinct functions –eg Presentation , Business Logic, Data Access in traditional three-tiered architecture.

§  If multiple presentation technology needs to be supported – say Mobile and Web based views, only the presentation tier is affected

§  If a different kind of data access pattern needs to be supported – say Memcache based caching, only the data tier is affected

§  Allows Reuse – lower layers can be re-used by the layers above it.

§  Testability – Each layer can be tested independently.

§  Maintainable – if view breaks, look in the presentation tier. If data seems wrong, look in the data access tier, if business logic seems wrong, look at the business tier

§  Fosters Developer specialization – UI developers looking at Presentation layer

Learning - How do you learn a new technology area

This is the way I ( or for that matter anyone!) picks up a new technology area - a representation using Simplediagrams :

Say I am learning something about the new version of Spring Core -
I would first download Spring Core, play around with the reference applications(the "10 minute test"), try my own application by copying the reference and trying out more variations, until one day I can claim a level of expertise!