Ivan Sanchez

If you’re looking for a simple solution to expose/access services using Java, maybe you should consider using SpringHttpInvoker. Here’s a quick recipe of how to use it (extracted from Spring docs). Let’s start with the domain class:

public class Account implements Serializable{
    private String name;
    public String getName(){
      return this.name;
    }
    public void setName(String name) {
      this.name = name;
    }
}

The service interface:

public interface AccountService {
    public void insertAccount(Account account);
    public List getAccounts(String name);
}

And some implementation of the service:

// the implementation doing nothing at the moment
public class AccountServiceImpl implements AccountService {
    public void insertAccount(Account acc) {
        // do something...
    }
    public List getAccounts(String name) {
        // do something...
    }
}

In order to expose this service you’ll need a ServletDispatcher configured inside your web.xml like the following:

<servlet>
    <servlet-name>remoting</servlet-name>
    <servlet-class>
    org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
    <servlet-name>remoting</servlet-name>
    <url-pattern>/remoting/*</url-pattern>
</servlet-mapping>

And then it’s just a matter of exposing your service in the WEB-INF/remoting-servlet.xml file:

<bean name="/AccountService"
  class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
    <property name="service" ref="accountService"/>
    <property name="serviceInterface" value="example.AccountService"/>
</bean>

And that’s all you need! To access it on the client application, you just need to declare the remote service:

<bean id="httpInvokerProxy"
  class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
    <property name="serviceUrl" 
        value="http://remotehost:8080/remoting/AccountService"/>
    <property name="serviceInterface" value="example.AccountService"/>
</bean>

After this point your client application can use your service transparently via the accountService proxy. As simple as it should be!

How do you tell if a team is agile? If the last years trying to follow the principles of the manifesto taught me something is that in a good software project people want to be accountable.

We’re knowledge workers. What we deliver is a direct result of the perception of the problems we are exposed to. Yet, there are a lot of people trying to escape from the responsibilities our job requires.

Some of these responsibilities include:

• Design decisions (TDD)
• Impact of our changes on the rest of the project (CI)
• Sharing knowledge and the code where it’s represented (PP/Standards)
• Making sure what is delivered has any value (Reviews/Frequent Releases)

In this context there’s no room for peonage. Our job is basically to make decisions all the time and being agile is about making sure we can answer (and answer well!) for our actions.

That’s why I agree with Patrick Kua’s post about this topic. We have to understand the business problems and the possible solutions. We have to help each other to build something. We can’t stop learning. We can’t  be limited by our normal role. And most important: we have to care.

Thanks to Gojko and the guys from Skillsmatter I’ll be running a regular coding dojo in London. The challenges, languages, session formats and any other related topic will be discussed in the new coding-dojo-london group, so if you’re interested in attending any session or learning more about how the dojo works, it’s a good idea to subscribe.

My idea with this group is also help people interested in running other dojos in the city. So far I know Danilo from ThoughtWorks and the guys from YouDevise who are doing that, and I hope to see more next year.

The first session will be on 1st of December and the idea is to have one session every 2 weeks starting in January. All the sessions are free but be aware that some sessions may have limited number of people.