Posts Tagged ‘web services’

Notes on the Spring-WS tutorial

September 26, 2009

Today I have reviewed a proof of concept I have done in order to decide which Web Services framework matches the requirements of a bioinformatics project. Because of forgetting to store a file in the versioning system, I had to review the whole tutorial and to look for the file within the Spring tutorial. What is interesting, until now nobody published the full content of the Spring-WS tutorial.

So, here is my pom.xml. I am using Apache Maven2 in order to strictly enforce the versions of the JAR files. Nobody is constrained to use Maven, but without it, it would be very difficult to sort out the transient dependencies.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi=""
 <name>holidayService Spring-WS Application</name>
 <dependency> <!-- required by AbstractJDomPayloadEndpoint -->

I am using the jetty plugin in order to be able to run the application right from the command line; xalan dependency is required in order to avoid the exception “java.lang.IllegalStateException: Could not find SAAJ on the classpath” thrown by Spring-WS, corrected in a newer version of xalan.

Also according to the tutorial, the file spring-ws-servlet.xml, a regular Spring context file, describes the external interface of the Web Service and the associated Java classes. This file has to be placed in the src/main/webapp/WEB-INF directory.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

 <bean id="holidayEndpoint" class="">

 <bean class="">
 <property name="mappings">
 <prop key="{}HolidayRequest">holidayEndpoint</prop>
 <property name="interceptors">
 <bean class="" />

 <bean id="holiday" class="">
 <property name="builder">
 <bean class="">
 <property name="schema" value="/WEB-INF/hr.xsd" />
 <property name="portTypeName" value="HumanResource" />
 <property name="locationUri" value="http://localhost:8080/holidayService/" />


And here is the implementation of According to Maven customaries, this have to be placed in the src/main/java subdirectory of the project. I have tried to keep the implementation minimal by avoiding further service instantiations, unrelated to Spring-WS:


import java.text.SimpleDateFormat;
import java.util.Date;

import org.apache.commons.logging.Log;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.Namespace;
import org.jdom.xpath.XPath;

public class HolidayEndpoint extends AbstractJDomPayloadEndpoint {

 private XPath startDateExpression;

 private XPath endDateExpression;

 private XPath nameExpression;

 public HolidayEndpoint() throws JDOMException {
 Namespace namespace = Namespace.getNamespace("hr", "");
 startDateExpression = XPath.newInstance("//hr:StartDate");
 endDateExpression = XPath.newInstance("//hr:EndDate");
 nameExpression = XPath.newInstance("concat(//hr:FirstName,' ',//hr:LastName)");

 protected Element invokeInternal(Element holidayRequest) throws Exception {
 SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
 Date startDate = dateFormat.parse(startDateExpression.valueOf(holidayRequest));
 Date endDate = dateFormat.parse(endDateExpression.valueOf(holidayRequest));
 String name = nameExpression.valueOf(holidayRequest);

 // do something meaningful with the extracted data.
 System.out.println("Start date: "+startDate+" end Date: "+ endDate+" Employee: "+name);
 return null;

My final file structure is:

|-- pom.xml
`-- src
 `-- main
   |-- java
   |   `-- com
   |       `-- razvan
   |           `-- hr
   |               `-- ws
   |                   `--
   `-- webapp
     `-- WEB-INF
        |-- hr.xsd
        |-- spring-ws-servlet.xml
        `-- web.xml

The web.xml is pretty standard for Spring applications:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="" xmlns:xsi=""

 <display-name>Spring test application</display-name>




This is the whole Web Service application. In order to run the application try from the command line:

mvn clean install jetty:run

This will compile the war file and start an instance of the jetty web server.

By accessing the address: http://localhost:8080/holidayService/holiday.wsdl you can see the generated WSDL associated to your described web service. While leaving the jetty running, you may attempt to create a client, in order to see the message printed within the invokeInternal method. Following it will be described a Java client, but it is possible to build your client using any other language or platform.

Using the Eclipse wizard create a new empty Java project, than create using the wizard a new “Web Service Client”. Provide the address of the wsdl and you will have a bunch of Java classes describing your web service and the required XML parsers dependencies in your newly created project. Create a new main class in the default package named, with the following content:

import java.math.BigInteger;
import java.util.Date;


public class TestWs {
 public static void main(String[] args) {
 try {
 HumanResourceServiceLocator loc = new HumanResourceServiceLocator();
 HumanResource myserv = loc.getHumanResourcePort();

 HolidayType ht = new HolidayType(new Date(), new Date());
 EmployeeType et = new EmployeeType(new BigInteger("100"), "Razvan",
 HolidayRequest req = new HolidayRequest(ht, et);;
 } catch (Exception e) {


Run the class, and you will be able to observe the message in the maven window.

A few conclusions of the test are:

– Spring-WS is a great approach if the schema definitions of the data model already exists.

– The required xalan dependency is a bug in Spring-WS dependency requirements, fortunately Maven made possible the correction.

– The element wsdl:definitions is optional, the tutorial worked without it as well.


EJB3 Remote client: Hello world vs production usage

April 17, 2008

Yesterday I have made the first remote client for an Session bean. Hello world bean worked great, with a little research about how to configure the JNDI client to connect to the Glassfish server and what to provide in the CLASSPATH. I had to duplicate the remote interface and to delete the EJB annotation, since these JARs shouldn’t be imported on the client. I won’t do it in a production application, so I am ready for J2EE dependencies on the client as well.

The evil is as usual in detail. I don’t use EJB to write Hello word software. My session beans work with complex objects, persisted as entities. The beans do refer another beans, in one-to-many relations. In order to load such a list, the client needs to depend on the persistence library of the server, since that list is not a “vanilla” java.util.HashSet class, but one from TopLink or Hibernate, depending on the chosen EJB persistence.

So, near the entity beans, I had to import also the TopLink libraries in the client.

A solution to move from this dependency forest would be to employ web services. Regarding them, my experiences were not encouraging: they crash when receiving a reflexive reference (object A references object B and B references A) and they suffer performance issues both on server and client side when serving large collections.

Another ideas, is to use the value object pattern. This would mean at least duplication of my data model; but remember, I use MDA, so my model is generated from an UML model. Maybe the build of some plain objects could provide a special client JAR file (beans and service interfaces) and a copy mechanism from the beans, to be used on server side.