Samstag, 18. September 2010

Simple RPC over HTTP using Hessian

From time to time i am asked to recommend a mechanism for a simple and lightweight RPC over HTTP(S) communication that for example could easily be integrated into a Rich Client or Mobile Client and that could pass firewalls.

Well, here's a short guide to get started with Hessian. The Hessian binary web service protocol makes web services usable without requiring a large framework. As it is a binary protocol, it is well-suited for sending binary data without any need to extend the protocol with attachments.

More info can be found here.

I would like to provide you here with a simple 3 step by step tutorial to get started using it. It is really that simple!

1. We start from the service interface and the corresponding implementation that will run on the remote server (all in package de.arconsis.wstest)

public interface IBusinessService { 
    public int myBusinessMethod(String param1, String param2);
}

public class BusinessServiceImpl implements IBusinessService {
    public int myBusinessMethod(String param1, String param2) {
        System.out.println("BS: " + param2 + param2);
        return param2.length() + param2.length();
    }
}

2. We put the compiled .class files into a WAR file under WEB-INF/classes or as a jar in the WEB-INF/lib as well as the hessian-3.1.2.jar and add the following entries to the web.xml and finally deploy the WAR.
<servlet>
        <servlet-name>hessian</servlet-name>
        <servlet-class>
            com.caucho.hessian.server.HessianServlet
        </servlet-class>
        <init-param>
            <param-name>home-class</param-name>
            <param-value>
                de.arconsis.wstest.BusinessServiceImpl
            </param-value>
        </init-param>
        <init-param>
            <param-name>home-api</param-name>
            <param-value>
                de.arconsis.wstest.IBusinessService
            </param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
        <url-pattern>/hessian</url-pattern>
        <servlet-name>hessian</servlet-name>
    </servlet-mapping>


3. Now we just need to call that remote service over HTTP from a client. Let's assume that the webserver with the Hessian Servlet is running on the localhost:8080. Make sure that the hessian-3.1.2.jar as well as the IBusinessService interface is also available in the classpath of the client. To make the remote call transparent it might be a good idea to hide the remote nature by using just the business service interface in the client that will be obtained by a factory.
package de.arconsis.wstest;

public class BusinessServiceFactory {
    private static BusinessServiceFactory self;


    private BusinessServiceFactory() {
    }

    public static BusinessServiceFactory getInstance() {
        if (self == null) {
            self = new BusinessServiceFactory();
        }
        return self;
    }


    public IBusinessService getBusinessService() {
        //return new BusinessServiceImpl();
        return new BusinessServiceRemoteImpl(); 
    }
} 



import com.caucho.hessian.client.HessianProxyFactory;

public class BusinessServiceRemoteImpl implements IBusinessService {

    public int myBusinessMethod(String param1, String param2) {        
        String url = "http://localhost:8080/hessian";

        HessianProxyFactory factory = new HessianProxyFactory();
        IBusinessService remote = null;
        
        try {
            remote = (IBusinessService) factory.create(IBusinessService.class, url);
        } catch (Exception e) {
            e.printStackTrace();
        }        
        return remote.myBusinessMethod(param1, param1);
    }
}


Hessian will use a dynamic proxy internally and handle all the magic using HTTP as transfer protocol as well as the de-/serializing of the parameters and return objects.

I hope this short guide will help someone ... ;-)

~Wolfgang

Engage Quality Assurance

In a recent project there was a lot of discussion how to introduce Quality Assurance (QA) into an "agile" project. One key learning from the sprint retrospectives was that more formalism and more "process" would be required to achieve the desired quality of the product. The challenge was to find the right balance between needed formalism and unwanted organizational overhead and bureaucracy on one side and responsibility of each individual and non-effective & proven not-to-work selforganized QA by the development team itself on the other side.

Many discussions were going on with the customer and within the team and I was lucky to read a book by Coplien/Harrison (Organizational Patterns of Agile Software Development) by that time that brought my personal opinion to the point.

I would like to share the core statement with some personal additions and remarks here:

The engagement of the customer, requirements engineering and development is the key element of QA!

Developers might feel that they got everything right, but "a good dose of customer reality" can help them to bring the perspective that development of 100% perfect software is impossible.
It happens too often that organizations defer quality until "later" or make the mistake to equate QA with testing, which occurs later in the development process. The production of high quality work and early feedback is key to address fundamental quality problems and finalize a project successfully.

Remember: QA is not equal to Testing!

It is very important that developers perform their own testing but it is also a fact that they get blindsided very often by their own design thinking in terms of what needs to be tested. Further, they may use testing as their quality criterion. In contrast to the ideals of XP, test development shouldn't be blindsided by the developer perspective and QA needs to be seperated and independent in the interest of objectivity.

Remember: You can't test quality into a product - you can only build a product and test its quality!

QA needs to be established as a central role and needs to be legitimized by the organization. QA organization should be outside the context of development but needs to be tightly coupled with development as soon as development has something to test. The test plan creation can be done in parallel with the coding.
The planning and reporting of tests should not be accountable to the development organization. The sense of accountability for the development organization is to deliver a quality product that is free of bugs (minimized the bugs) that an QA organization might find.

Remember: Developers declare the system to be ready for testing!

QA needs to work closely together with architecture and requirements engineering as well in order to understand the needs and challenges the system will face in future. The QA people need to have the skills and the experience to "look behind" the things expressed explicitly in requirements/needs and specification documents and identify the core of the needs/pains and requirements and make sure that this is reflected in the system.

Remember: QA should be engaged early in the project. The system of quality is prevention, not appraisal!

In order for a separate QA to be effective, it must have frequent and positive interaction with develoment. It is not just the developers' responsibility to engage the testers - but the testers must reach out the developers as well.


Remember: Quality is free ... :-)

Yours,
Wolfgang

A small step to source code quality improvment

Today I would like to share some basic source control checkin rules with you that work well in agile teams and support the QA process. Actually i've seen some projects that would be happy if that was their QA process ... ;-)

These steps don't cause much formalism or other overhead (or cost a lot of time if applied regularly) and greatly help to keep your team-colleagues as friends ... :-)


Basic Checkin Rules: Before Classes are checked in, they ...

  • must compile!
  • must contain useful JavaDoc like a Class description and meaningful doc for all public methods, i.e. this often means "add missing documentation" (not neccessarily for getter/setter and also optional if JavaDoc can be "inherited" from base class)
  • must be Checkstyle compliant and be formated (using project standard configurations that are mandatory for all developers) (Eclipse Plugin: http://eclipse-cs.sourceforge.net/)
  • must be scanned and cleaned with Findbugs for BadSmells, etc ... (Eclipse Plugin: http://findbugs.cs.umd.edu/eclipse/) // If a found item is not fixed on purpose you need to have a good reason/explanation
  • must be free from System.out.println and therefore must use (don't overdo this) "if (LOG.isDebugEnabled() ) LOG.debug(...)"
  • must contain a useful and traceable SVN/CVS commit message


The senior developers/architects/scrum master/project managers or similar should do random-samples from time to time and the team mates should "force" each other to stick to these rules for the sake of the whole team (times of code ownership are over). If possible, a continuous integration tool should automatically check some of these source code quality attributes regularly.

Note: These rules don't help necessarily the quality of the algorithms or business logic that you write!

The source code is some kind of business card that is left at the customer site when the project is over and so it must be taken care of ...

Although this is not a silver bullet for a total turn-around if your code quality is crap, it could be a start for improvement or a great starting point if you start on the "green field" and don't have all processes and guidelines in place yet.

I hope that some ideas are useful for you ... try it out ... and as usual: Don't hurt yourself!

~Wolfgang

Business Ethics: Code of Conduct

I had a very interesting discussion with a former collegue of mine a while ago about business ethics, honesty & loyalty at work and the propable conflicts with the goals to achieve a maximum revenue, be ahead of your competitors, survive on the markt and sometimes even make the customer happy ...

Where he stood for the point that in the end the success (also including happy customers) counts and in critical situations "everybody is it's own best friend", all other things and business behaviour are a "matter of style", I personally believe that you are never succsessful if you push business ethics aside, no matter if the results turn out to be"successful" (even from the point of view of a happy customer). If you act otherwhise you even put the reputation of the customer at risk!

I asked him: What is the price for failing (e.g. unhappy customer)? What if the things that are done in the "grey zone" come to the surface? What are you willing to do to keep these things invisible? Can you see all the impacts? Where should the thin line be drawn and who can be the judge?
Well, the price is too high in my opinion - you not only put shame on yourself but you put shame on the company you work for and probably the whole profession.
My thinking goes the other way ... why don't we explain to our customers that we think (a lot) about these topics and that we are committed to ethical behaviour and think that this is an important enough thing to mention. Actually, this could be the "small thing" that makes you different from others ( if service portfolio is equal ;-) ). The important thing here is that you HAVE to believe in what you preach and to keep what you promise!

I can hardly remember when these questions were on an agenda or slide for a sales business presentation ;-)

Well, as an example I personally signed the PMI Code of Conduct after my certification and when I went to customers or spoke with potential partners I always made sure that these principles count for me. After the first strange looks at me, my feeling was always that this not only helped me to put down a baseline for the key rules to work together, but also built up trust on the other side which is essential these days when we think about the responibility and trust that needs to be given to us as consultants and service providers.

I think that it is a good idea to make it explicit (e.g. write it down and hand it over) as a professional that you are committed to business ethics and that your work should be judged by the compliance to this comittment.
I would like to lend some quotes from Stephen R. Covey that go something like this: “While we are free to choose our actions, we are not free to choose the consequences of our actions.” and "... private victories are the ancestors of public victories."

As an example you can find below the PMI Code of Professional Conduct that can be applied in a similar way to other professions ... (in short is says you will not lie, not betray anybody and you will take responsibility for your actions):
------

As a PMI Project Management Professional (PMP®), I agree to support and adhere to the
responsibilities described in the PMI PMP Code of Professional Conduct.

I. Responsibilities to the Profession 
A.Compliance with all organizational rules and policies 
1.Responsibility to provide accurate and truthful representations concerning all information
directly or indirectly related to all aspects of the PMI Certification Program,
including but not limited to the following: examination applications, test item banks,
examinations, answer sheets, candidate information and PMI Continuing Certification
Requirements Program reporting forms.
2.Upon a reasonable and clear factual basis, responsibility to report possible violations of
the PMP Code of Professional Conduct by individuals in the field of project management.
3.Responsibility to cooperate with PMI concerning ethics violations and the collection of
related information.
4.Responsibility to disclose to clients, customers, owners or contractors, significant circumstances
that could be construed as a conflict of interest or an appearance of impropriety.
B.Candidate/Certificant Professional Practice
1.Responsibility to provide accurate, truthful advertising and representations concerning
qualifications, experience and performance of services.
2.Responsibility to comply with laws, regulations and ethical standards governing professional
practice in the state/province and/or country when providing project management services.
C.Advancement of the Profession
1.Responsibility to recognize and respect intellectual property developed or owned by others,
and to otherwise act in an accurate, truthful and complete manner, including all activities
related to professional work and research.
2.Responsibility to support and disseminate the PMP Code of Professional Conduct to
other PMI certificants.

II. Responsibilities to Customers and the Public 
A.Qualifications, experience and performance of professional services 
1.Responsibility to provide accurate and truthful representations to the public in advertising,
public statements and in the preparation of estimates concerning costs, services and
expected results.
2.Responsibility to maintain and satisfy the scope and objectives of professional services,
unless otherwise directed by the customer.
3.Responsibility to maintain and respect the confidentiality of sensitive information obtained
in the course of professional activities or otherwise where a clear obligation exists.
B.Conflict of interest situations and other prohibited professional conduct
1.Responsibility to ensure that a conflict of interest does not compromise legitimate interests
of a client or customer, or influence/interfere with professional judgments.
2.Responsibility to refrain from offering or accepting inappropriate  payments, gifts or
other forms of compensation for personal gain, unless in conformity with applicable
laws or customs of the country where project management services are being provided.