SOA / Web Services / Java

A Technology Blog

Archive for May, 2010

Some Java Best Practices

Posted by Vivek on May 23, 2010

— Only one top level class should be defined per file.

— Visibility of variables, methods and class should be kept as minimum as possible.

— Import only required classes in your program.

— Do not use unused method, variables or classes. Make sure comments are used as per the java

coding standards. 

— Avoid using finalize method as garbage collection is not predictable.

— Every method should contain Java Doc and describe input and output parameters.
/**
         * <Method description goes here>
         *
         * @param parameter name description
         * @return return description
         * @throws exception decription
         */

— Use proper indentation. Make use of your IDE (eclipse, jedeveloper etc) which provides built-in features. For ex. Ctrl + Shift + F when using eclipse can help reduce checkstyle errors and improve indentations.
— Declare only one varible per line. For ex:
instead of
private int x = 10, int y = 20, int z = 30;
use
private int x = 10;
private int y = 20;
private int z = 30;

— All variables should be initialized before they are accessed. Use lazy initialization if you

want to initialize a variable only when it is needed.

— Declare and Use local variables within a method. Do not reuse the variable.

— Declare static variables private and provide a public/protected method for other objects to

access it. For ex:
private static int myAge;

public static int getMyAge() {
   return myAge;
}

— Use paranthesis to indicate operator precedence.

— Do not use hardcoded values in the program. Use constants files instead.

— Use null pointer checks wherever applicable.

— keep methods short. If possible, it should contain 25 statements or less. Try not to exceed 80 characters when coding a line of code.

— Always use curly braces for blocks of code especially if-else.

— Nesting should not be more than 3 levels if possible.

— Boolean values should be implicit in an if statement. For ex:
instead of
if(myFlag == true){…}
use
if(myFlag){..}

— use values on left side during comparisons to avoid any null pointer exception. For ex:
instead of
if((myMethod.getMyFirstName()).equals(“Henry”)){..}
use
if((“Henry”).equals(myMethod.getMyFirstName())){..}
if getMyFirstName() returns null in first expression, it will throw a NPE. This is avoided in

the second statement.

— Do not access a method through another method.For ex:
avoid this.getMyName().getMyFirstName();

— Use System.arraycopy( ) to copy an array.

— Always, set the size of collection objects. Use Set, List etc instead of HashSet, ArrayList etc.

— Class names must start with an Capital letter. Method and variable names should begin with lowercase. Exception classes must end with the word Exception. Use uppercase for all constant names and use underscore to seperate words (For ex: static final int MY_DATE_OF_BIRTH = 26;).

— A method should be declared abstract in a class which will not be instantiated. 

— Present exceptions to the user in a proper manner. Do not just catch and log exception, if

applicable. Do not use empty catch blocks or catch or throw the classes Throwable or Exception.
Use finally block for clean up activities and do not throw any exception from a finally block.
Try to classify exceptions as Business Exception and System Exception and deal accordingly.

— Avoid using multiple return statements in a method.

— Use synchronized method only if it is applicable. For example: Use StringBuilder if only one

thread is going to use it at a time instead of StringBuffer, which is synchronized.

— Avoid using StringTokenizer. Avoid methods like String.toUpperCase() and String.toLowercase( )

that copy the characters of the string.

— Use log4j or apache commons logging framework instead of System.out.print() statements.

— Logging at entry and exit methods must be at TRACE level.

— Use ThreadLocal to allow accessing states from a thread.

— Clone() method can be used to avoid invocation of constructors.

— Create objects early in the application and do not destroy until they are utilized completely.
 
— Avoid method calls from loops. Use inline statements even if it causes redundant code.

— Use short circuit operators instead of bit wise operators. For ex: && is better than &

— Use ? for an unknown object type. For ex:
instead of Collection<object> use Collection<?>

— Use annotations wherever applicable. For ex: @override to indicate that this method overrides a method, @SuppressWarnings to suppress warnings from compiler.

— Use caching if repeatedly accessing a constant piece of code or performing IO operation on a

constant file.

— Encourage use of Writing Junit test cases.

— Improve coverage of code. Use tools like EMMA, cobertura.

— Use checkstyle and PMD for improving layout of code.

Advertisements

Posted in Java/J2EE | Tagged: , , | Leave a Comment »

SOAMOA – New kid in the block

Posted by Vivek on May 15, 2010

This is just an extension to my previous post (SOA Testing). Most of the java developers look to automate web service testing. If you are using SOAPUI, this is possible by writing junit test cases and then invoking SOAPUi projects from junit for a particular test case. It might be the case that you do not want to rely on any tool while testing and end up creating test cases that creates and invokes request for you. With the same intention, I was looking for a free tool and found this one – SOAMOA.

Still in its infancy stage, this tool may not be used for all your testing needs but some features look promising. The GUI is not too great. It doesn’t offer you to set preferences and does not support web services standards. For all this, you already have a free tool SOAPUI (not the pro version). The only striking feature is the ability to generate junit test cases and groovy script based upon your request. You just need to import your WSDL and create SOAP Request as you generally do in SOAPUI. 

If you have a request, for eg.

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/“>
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body xmlns:web=”http://webservices.service.employee.com/“>
        <web:getEmployeeDetail>
            <arg0>
                <employeeId>2000</employeeId>
                <employeeName>Monster</employeeName>
                <company>hell techologies</company>
            </arg0>
        </web:getEmployeeDetail>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Creating Groovy Script for the request will produce the following:

/* Generated GroovyWS Script by SoaMoa, :vivek at Sat May 15 10:53:13 GMT+05:30 2010 */

import groovyx.net.ws.WSClient

def proxy = new WSClient(“file:/C:/…../WEB-INF/wsdl/EmployeeService.wsdl”, this.class.classLoader)
proxy.create()
def arg0 = proxy.create(“com.employee.service.webservices.GetEmployeeDetailRequest”)
arg0.employeeId = 2000
arg0.employeeName = ‘Monster’
arg0.company = ‘hell technologies’
def getEmployeeDetailResponse = proxy.getEmployeeDetail(arg0)

A junit class will look like:

/* Generated Testcase by SoaMoa, :vivek at Sat May 15 10:59:54 GMT+05:30 2010 */

import java.util.Map;
import javax.xml.namespace.QName;
import javax.xml.soap.MessageFactory;
import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPConstants;
import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPEnvelope;
import javax.xml.soap.SOAPMessage;
import javax.xml.soap.SOAPPart;
import javax.xml.ws.Dispatch;
import javax.xml.ws.Service;
import javax.xml.ws.BindingProvider;
import javax.xml.ws.soap.SOAPBinding;

import java.util.Iterator;

import junit.framework.TestCase;

public class GetEmployeeDetailTest extends TestCase {
public void testGetEmployeeDetail() throws Exception {
String endpointURL = “
http://myhost:myport/MyApp/services/EmployeeService“;
QName serviceName = new QName(“
http://webservices.service.Employee.com/“, “EmployeeService”);
QName portName = new QName(“
http://webservices.service.Employee.com/“, “EmployeeServiceWSPort”);
Service service = Service.create(serviceName);
service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING, endpointURL);
Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);
MessageFactory messagefactory = MessageFactory.newInstance(SOAPConstants.SOAP_1_1_PROTOCOL);
SOAPMessage request = messagefactory.createMessage();
SOAPPart part = request.getSOAPPart();
SOAPEnvelope env = part.getEnvelope();
SOAPBody body = env.getBody();

body.addNamespaceDeclaration(“web”, “http://webservices.service.Employee.com/“);
    SOAPElement getEmployeeDetail = body.addChildElement(“getEmployeeDetail”, “web”);
        SOAPElement arg0 = getEmployeeDetail.addChildElement(“arg0”);
            SOAPElement employeeId = arg0.addChildElement(“employeeId”);
            employeeId.addTextNode(“2000”);
            SOAPElement employeeName = arg0.addChildElement(“employeeName”);
            appId.addTextNode(“Monster”);
            SOAPElement company = arg0.addChildElement(“company”);
            EmployeeId.addTextNode(“Hell Technologies”);           
request.saveChanges();

SOAPMessage response = dispatch.invoke(request);
SOAPBody replyBody = response.getSOAPBody();
}
}

 

Posted in SOA Testing | Tagged: , , , | Leave a Comment »

SOA Testing – Tools in the market

Posted by Vivek on May 9, 2010

Here is a list of the leading testing tools available in the market to test the SOA components. I believe that no tool can completely fulfill the testing requirements of an SOA but you can accomplish a lot. The tools should be intelligent enough to carry out:

i. Schema/ WSDL/ SOAP validation
ii. Simulation of webservice, both client and server  i.e., mock services
iii. Testing of web services standards such as web services addressing, security, reliable messaging etc.
iv. WS-I conformance testing
v. Testing of intermediaries
vi. Governance testing. Validation of design and run time policies and Service versioning.
vii. Asynchronous and notification framework testing
viii. Orchestration and Choreography testing
ix. Performance testing

Below is a list of tools that cover some or most of the above points:

1. Green Hat GH Tester : This tools provides comprehensive testing of SOA. Helpful in providing performance and security related testing and validation of SOA and BPM components. You can monitor SOA performance and track service invocation and response.

2. Mindreef SOAPScope Server : Acquired by progress software. Allows creation of mock services, validation and compliance checking.

3. Parasoft SOATest : Helps in performance or load and security testing. Provides governance testing by performing policy enforcement checks. Allows creation of mock services and performing regression testing.

4. Crosscheck Networks SOAPSonar : Performs functional, performance, compliance, and security testing across SOAP, XML, and REST based services.

5. iTKO Lisa : Performs UDDI test/ validation, performance , validation and compliance and mock service testing.

6. Matador Tech Tester : suitable for validation and regression testing.

7. SOAP UI: Performs functional, load/ performance and mock service testing. Also helpful in validation and compliance testing.

 

Posted in SOA Testing | Tagged: , , , , , , | 7 Comments »