Gridshore software engineering weblog - Webservices

Last entry ...

nospam@example.com (Jettro Coenradie) — Sat, 19 Jan 2008 20:58:56 +0100

Welcome to the last entry of this blog. No I am not quitting, I am just moving. I just installed a new blog software framework. I was starting to dislike the way to interact and I wanted something that contained more out of the box. I am in the middle of moving to wordpress software. There is a very good reason to do this. I had found a great tool on the mac called MarsEdit. And again this could not be used with serendipity. I hope I did make a good choice. Since there is a lot of information in the old blog, I did not take this blog offline. It will stay to exist, but I will not make changes there anymore.

I hope to see you at the new version of the blog (check the page at http://www.gridshore.nl). You can attach you feedreader to the following url: feed://www.gridshore.nl/feed/

Web service versioning in the java world

nospam@example.com (Allard Buijze) — Mon, 20 Aug 2007 13:04:00 +0200

There are many blog entries and articles out there about web service versioning. So why write another? In my day-to-day work, I am often asked about how to solve web service versioning issues. The articles on the web provide different ways to do it, but do not take the impact on the codebase, deployment and testing into consideration. Now that's exactly what I'll be trying to do in this article.

First, I'll briefly describe what I mean with Web Service versioning. Then, I'll shed some light on different possible solutions. Finally, I'll compare all of these solutions in terms of complexity, codebase, deployment and testing.

Web service versioning, real or just a myth?

Many, maybe even all, projects that involve web services will encounter a problem they call "web service versioning". But what is it? And does it really exist?

A web service is a piece of code, published under a more or less strict contract (WSDL and XSD), that can be called by other pieces of code across the web. This contract poses a problem, because your users depend on this contract to communicate with your application. If your request or response message format changes, it will most probably break the contract, causing your clients to send invalid messages and being unable to parse your responses.

So, if you change the contract, are we still talking about the same service? Or is it just another service you are providing? In terms of web services, it will be just another service. However, developers think in terms of code and classes. Since the major part of the codebase will be the same for the new service, we like to think of it as a new version. So, web service versioning doesn't really exist, but we want our classes to be reused. Now we've put our finger on the sore spot.

Why versioning web services is an issue

Web Service versioning doesn't exist. So why is it an issue? Because developers (myself included) want to be able to reuse existing classes for new versions of a service. So, in our Version Control System (VCS, e.g. Subversion or CVS) repository weÂ?ll want to create a branch for the old version, and continue development in our main branch. We'd want to deploy our application with our old JAR and the new one and provide some mechanism for selecting either the old classes or the new ones.

That's when class loading comes in to play and ruin our day. Java isn't able to load the two different classes with the same name, at least, not in this case. It will load class com.mycompany.MyService from only one of both jars, whichever is first on the classpath. For java to accept different implementations of a same class, you'd have to do some class loader tricks.

Solutions for service versioning

The web is full of solutions for versioning. I'll mention each solution briefly, and explain how it is set up. At the end of this blog entry, I will compare these solutions in terms of codebase, deployment and testing.

1. Don't do versioning. Force clients to migrate to the newest version available.This is often tried as the first solution, but will most likely fail. Often, client applications are managed by another project, not in the area of influence of the project developing the web service provider. The cons are mostly financial: who's going to pay for the migration of the client? I'm not going into more detail on this solution, as it doesn't solve the versioning problem.

2. Deploy another EAR file containing the new version of the web service, leaving the old application untouched.In terms of development and maintenance of the codebase, this is the easiest solution. Just create a branch in your VCS for the old version and continue the development in the main branch. Since the old application is totally unmodified, it doesn't have to be tested when a new version is created. However, your deployers will have to deploy and maintain one applications per supported version.
In case of bug fixes, there is another choice to be made. Will the bug be fixed in each version, or just in the latest one. In the first case, the code has to be changed in several locations in you repository. Fortunately, today's VCS tools (e.g. TortoiseSVN) allow you to easily merge changes across branches. Then, testers have to test each modified application and the deployer has to redeploy them.

In conclusion, this solution is easy for the developers, but has more impact on testers and deployers.

3. Deploy a single EAR file, with a WAR file per versionBeware! For this solution to work, all version specific code should be placed in the WEB-INF/lib dir of your WAR file, and each WAR file must have its own class loader.

Just like the previous solution, you can create a branch in your VCS and merge changes across branches. However, a change in one version of the code will change the composition of the entire EAR file, and thus affect other versions, even if the specifications of that version haven't changed. This means that there is no way to guarantee that old versions are unaffected by changes in newer versions. This puts some extra load on the testers. The deployers however will only have to deploy and maintain a single application, regardless of the number of versions it supports.

4. Use different package names for each versionOn several blog sites, this solution is provided as "the one" to use. If you take java out of the equation, it might be very interesing, because your request and response messages are very clear about the version of the service. However, in the real world, developers use binding frameworks such as jaxb or augis. This would mean different package names (and rewriting code) for each version. This makes solutionÂ the worst of all for developers, as the entire codebase has to be changed for each new version.

I am not going into detail about this solution, because it is not a solution to the "versioning" problem. Here, we are just creating a completely new service, with all new classes. No resuse. However, do take this option into consideration for at least a few minutes. Depending on the size of your codebase, it might just not be such a bad solution.

5. Use a framework that supports advanced class loadingPeople who know me would probable wonder by now: "When will he mention OSGi"?. Well, just about now. Frameworks that implement the OSGi specification (e.g. Equinox, Knoplerfish and Felix), are able to load different implementations of the same class, and understand the difference between them. Jettro Coenradie and I have given a presentation on Web Service versioning using OSGi that the Spring 2007 conference (see http://www.nljug.org/pages/events/content/jspring_2007/sessions/00003/). We've also dedicated a website to provide information on the subject: http://www.osgisamples.com.

This solution is probably the most difficult one to implement. It is most likely that neither the developers, nor the testers and deployers have knowledge about OSGi and the impact on their work. However, if this knowledge is available to your project, make sure to consider this solution.

Comparing the solutions

Now that I have mentioned each solution briefly, it is time to put them in the ring to compete against each other. Here we go:

EAR versioning
(endpoint versioning)
WAR versioning
(endpoint versioning)
Package versioning
(namespace versioning)
OSGi
(any type of versioning you like)
How the versions are recognized
By endpoint
Either the EARs will be deployed on different app servers, or the WARs inside will have different contexts
By endpoint
Each WAR in the ear wil have a different context (e.g. /services/v1 and /services/v2)
By namespace
We're talking about different services here. The dispatching process will send each service to the appropriate class
Any way you like. You have complete influence on the dispatching process.
Complexity to set up
No specific set up to be done. Make sure to use a VCS.
Slightly complex. Use e.g. maven to build the WAR files and include the necessary versions in your EAR. Make sure version specific classes and jars are included inside the WAR.
Not complex at all to set up, but each new version will require you to create new classes or rename the old ones.
Consider each new version as a completely new service in your web service dispatcher
Very complex for beginners. OSGi introduces some extra features and a different mindset than Â?normalÂ? java programming.
Impact on codebase, bug fixing and maintenance
Little impact. Keep in mind that each fixed version will have to be redeployed. Use your VCS tools to merge changes across branches.
Little impact. Each modified version will have to be rebuilt and each WAR included in the EAR file. Use your VCS tools to merge changes across branches.
Huge impact. The amount of classes will double with each version. Merging across branches is no longer possible, since class names are different.
You application will have to be set up in a modular fashion. If it already is, the impact on your codebase is small. You can use VCS tools to merge changes, since class names donÂ?t change.
Impact on deployment effort
Highest impact on deployers. Each version requires an extra EAR to be maintained.
Small impact on deployers. There is only a single EAR file to deploy and maintain.
Small impact on deployers. There is only a single EAR file to deploy and maintain.
Small impact on deployers. There is only a single EAR file to deploy and maintain.
Impact on testers
Small impact. Old versions are remained intact when deploying new versions.
Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.
Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.
Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.
Flexibility
Very high. Since versions are completely separate, changes in one version do not affect the other.
High. Because all versions share a common (EAR) class loader, there are some limitations. Especially when using native code.
Low. All versions must use the same shared libraries, as all versions share a single class loader.
Very high. The versioning and dispatching mechanism is completely configurable to your projects needs. Each version of the web service can depend on different versions of external libraries.

Using Spring-ws for creating a webservice

nospam@example.com (Jettro Coenradie) — Wed, 04 Jul 2007 20:33:52 +0200

My previous post was about creating a client with the spring-ws project. This dis take me some time to grasp. But without a published webservice a client is of no much use. Therefore I also had a look at the server side. To my surprise this was even easier than expected. I did have some requirements for the sample:

wsdl generation
marshalling/unmarshalling using jaxb2

That does not sound to bad does it? Well try to do it with axis and you'll be surprised. If you know a little bid about spring-webmvc and the use of the dispatcher, you know you need one configuration file for spring. For the webservice I had to provide the spring config file and one class, yes really, just one class. I used maven to generate the jaxb stuff and this is wat I did:



web.xml

<servlet>

  <servlet-name>spring-ws /servlet-name>

  <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>

</servlet>

<servlet-mapping>

  <servlet-name>spring-ws /servlet-name>

  <url-pattern>/* /url-pattern>

</servlet-mapping>

The spring-ws framework provides a special servlet that receives the requests. No the really hard part, the spring configuration for the endpoint:



<bean class="org.springframework.ws.server.endpoint.mapping.SimpleMethodEndpointMapping">

  <property name="endpoints" ref="congressRegistrationEndpoint"/>

</bean>

<bean id="congressRegistrationEndpoint"  class="nl.gridshore.samples.springws.server.JaxbMarshallingMethodEndpoint">

  <property name="marshaller" ref="marshaller"/>

  <property name="unmarshaller" ref="unmarshaller"/>

</bean>

<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">

  <property name="contextPath" value="nl.gridshore.samples.jaxb"/>

</bean>

<bean id="unmarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">

  <property name="contextPath" value="nl.gridshore.samples.jaxb"/>

</bean>

First check the endpoint mapping, this class SimpleMethodEndpointMapping is found by the dispatcher to map all incoming requests to endpoints. In our case we map to our only endpoint called the congressRegistrationEndpoint. This class has a special super class that needs a marshaller and unmarshaller. Other than that it needs nothing. By convention the name of the Request is used by the super class to know which method to call. In our case we have a CongressRegistrationRequest. Therefore we need to implement to method handleCongressRegistrationRequest as you can see in the following coded block.



public CongressRegistrationResponse handleCongressRegistrationRequest(CongressRegistrationRequest request) {

  ObjectFactory objectFactory = new ObjectFactory();

  CongressRegistrationResponse response = objectFactory.createCongressRegistrationResponse();

  response.setRegistrationCode("code333");

  return response;

}

In this code the argument and the return value are JAXB objects. I created the most easy method, do nothing with the request and always return the same response. Bu as you can see the code itself is very clean. I do not need to do a lot of conding. I think this is probably one of the easiest implementations I have seen that works in java 1.4 as well.

That is it for one of the requirements. Now I also wanted a solution for generating the wsdl. In the end this is only some springframework configuration. You also need an xsd, but you have already used this to generate the jaxb classes with maven. So we can reuse it. Check the following configuration



<bean id="service" class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition">

  <property name="builder">

    <bean class="org.springframework.ws.wsdl.wsdl11.builder.XsdBasedSoap11Wsdl4jDefinitionBuilder">

      <property name="schema" value="/WEB-INF/classes/congressregistration.xsd"/>

      <property name="portTypeName" value="services"/>

      <property name="locationUri" value="http://localhost:8080/spring-ws-sample-server/"/>

      <property name="targetNamespace" value="http://www.gridshore.nl/samples/definitions"/>

    </bean>

  </property>

</bean>

So you need the location of the xsd, the name of the bean is used to find the wsdl. The locationUri locates the endpoint and the targetNamespace is the namespace used in the xsd. By entering the following url you can find the wsdl.
http://localhost:8080/spring-ws-sample-server/service.wsdl

You can check the code at the google code project.

I know it is pretty short, but with the code you should be able to understand it.

greetz Jettro

Creating a webservice client using Spring-ws and maven2

nospam@example.com (Jettro Coenradie) — Sat, 30 Jun 2007 21:25:00 +0200

Last week I attended the SpringOne Congress in Antwerp. Just one or two days before the congress I wanted to create a proof of concept for a client connecting to a webservice. I have been using the proxy way (spring-remote), but I did not really like the way this works. Therefore I was looking for something else. I stumbled upon the Spring Webservices project. I did try this out before, but not for clients. I started working and it did not look very complicated. I must admit I needed the help from Arjen Poutsma himself to make it work, but now I have a very light weight solution. I like the approach very much, therefore I will briefly describe the solution I have created. You can of course find the sources online as well. Check the google code subversion repo for gridshore.

Overview of application

Build application using maven2

Web application build using spring webmvc

Webservice client created using spring-ws

Mapping between objects and xml using jaxb2 and spring-oxm

Maven 2 for building

This time not much details about the maven2 part. There are some things interesting though. Most important part is the creation of the jaxb generated classes using the maven2 jaxb2 plugin.

Using spring-webmv for web project

I do not think it is really interesting to talk a long time about this. There can be found a lot (better) resources online. I used the spring webmvc project to make the client i18n compatible, used the form controllers from spring to help with the error messages and validation stuff. For the webservices part the most interesting thing starts in the file service-applicationcontext.xml. This spring configurtion file contains the webservice client, the converters for jaxb (using generics to abstract the technique marshalling technique).

Webservice client created using spring-ws

Let's start by having a look at the configuration:



<bean id="congressRegistrationDAO"

    class="nl.gridshore.samples.springws.integration.wsclient.impl.CongressRegistrationGateway">

  <property name="defaultUri" value="${cr.endpoint}" />

  <property name="marshaller" ref="marshaller"/>

  <property name="unmarshaller" ref="unmarshaller"/>

  <constructor-arg index="0" ref="congressRegistrationRequestConverter"/>

  <constructor-arg index="1" ref="congressRegistrationResponseConverter"/>

</bean>

<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">

  <property name="contextPath" value="nl.gridshore.samples.jaxb"/>

</bean>

<bean id="unmarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">

  <property name="contextPath" value="nl.gridshore.samples.jaxb"/>

</bean>

This configured class is the class that knows how to connect to the webservice. It uses a few values and classes to do it's work. The defaultUri is used to find the endpoint to connect to (we obtain it from a property file). Since we use JAXB2 to marshall and unmarshall the request we need the marshaller and unmarshaller. These (un)marshallers are provided by spring-ws as well. Actually they are provided by spring-oxm. The interface for the marshaller is the same as for the unmarshaller. The only thing you need to provide is the package where the jaxb files are generatd in. The other two references are converters used to convert the application specific components to JAXB2 components. More on this later as well. So the most important class is the Gateway class. Let's have a look at that now.



package nl.gridshore.samples.springws.integration.wsclient.impl;



import nl.gridshore.samples.springws.domain.RegistrationDetails;

import nl.gridshore.samples.springws.integration.converter.Converter;

import nl.gridshore.samples.springws.integration.wsclient.CongressRegistrationDAO;



import org.springframework.ws.client.core.support.WebServiceGatewaySupport;

import org.springframework.ws.soap.client.core.SoapActionCallback;



public class CongressRegistrationGateway extends WebServiceGatewaySupport implements CongressRegistrationDAO {

  private final Converter requestConverter;

  private final Converter responseConverter;

	

  public CongressRegistrationGateway(Converter requestConverter,  

      Converter responseConverter) {

    this.requestConverter = requestConverter;

    this.responseConverter = responseConverter;

  }

	

  public String registerForCongress(final RegistrationDetails registrationDetails) {

    Object request = requestConverter.convert(registrationDetails);

    Object response = getWebServiceTemplate().marshalSendAndReceive(request);

    return responseConverter.convert(response);

  }

}

This is it, really. I show you the complete class, but in the end the most important works takes place in one line. That's the one in bold. Here we use the special webServiceTemplate class and ask it to marshall our request object and send it as a soap message to the configured endpoint. Ofcourse you can do a lot more, but for most situations this is all it takes. Do not forget to extend the WebServiceGatewaySupport class.

Mapping between objects and xml using jaxb2 and spring-oxm

Not much to tell here as well. I keep saying this, but that's because it is true. We have configured the marshaller and the unmarshaller which are provided by spring-oxm. We also call the right method from the template adapter called marshalSendAndReceive. I did create an interface and some implementations that enable the gateway to be ignorand to the type of marshalling and unmarshalling we use. This is my first try to do something with generics. There can be a better way, if you know one, please let me know as well . Let's start with the generic interface.



public interface Converter {

  public E convert(T toBeConverted);

}

So we have an interface specifying we have a object as a parameter and an object as a return type. Then there is a method called convert that uses these generic types. At the moment I have two concrete implementations for creating the JAXB request and handling the JAXB Response. One of them is presented below.



public class CongressRegistrationResponseConverter implements Converter {

  public String convert(CongressRegistrationResponse toBeConverted) {

    String response = toBeConverted.getRegistrationCode();

      return response;

  }

}

As you can see we now have a concrete implementation for the generic interface. The returned object is a String and the parameter is a JAXB object called CongressRegistrationResponse. Now look back at the gateway code, check that there is no jaxb reference in that code.

Again check out the code at google code subversion repo for gridshore. You can already find the code for a server implementation there as well. The next blog will deal with the server. I am also working on a sample about the Rule engine called Drools. so stay tuned.

Providing a webservice with Spring and axis

nospam@example.com (Jettro Coenradie) — Sun, 25 Jun 2006 22:00:00 +0200

Finally I found some time to start experimenting with a webservice. I know I am not the first to write about creating your own webservice, still I think this is worth reading. I am writing a step by step creation of a webservice via maven2, axis 1.4 and spring 2.0RC1. Ofcourse you can use older versions, but I want to be ready for the future and keep on using this sample. For now I am working with a HelloWorld sample. I will make it more complicated when needed to show interesting things.

Download the sources here

Step 1 - Configuring your maven project environment
We create a new directory to store all projects : ~/WebservicePoc
Within this directory use the archetype of maven to create a structure for a web project:
The groupid is used within the create pom. The artifactId is used as project id and to create the folder to store all files in. The archetypeArtifactId defines the type of structure to create, in our case a web project.



mvn archetype:create 

          -DgroupId=com.coenradie.webservicespoc 

          -DartifactId=webservice-jaxrpc-style 

          -DarchetypeArtifactId=maven-archetype-webapp

Now it is time to create the pom in the root project directory. Beware if you create this pom first, the archetype:create won't work. Execute the command in a temporary directory and copy the files into the sub-directory of the module we are creating.



...

	<groupId>com.coenradie.webservicespoc</groupId>

	<version>1.0-SNAPSHOT</version>

	<artifactId>WebservicePoc</artifactId>

	<packaging>pom</packaging>

	<name>Webservice proof of concept</name>

	<inceptionYear>2006</inceptionYear>

	<url>http://localhost:8080/webservicepoc</url>

...

	<modules>

		<module>webservice-jaxrpc-style</module>

	</modules>

...

For a complete look at the pom, have a look at the downloadable source code.

We also need to make some adjustments to the generated pom of the webservice-jaxrpc-style module. Again have a look at the sources. Time to try the first compile. Execute the following command in the root of the project:



~/WebservicePoc/mvn install

Step 2 - Decide upon the libraries that we are going to use
For the application we are going to create we are going to use some libraries. We do not want to code ourselves to much. We are going to use the spring library and axis. Add these to the module pom.



  <dependencies>

    <dependency>

      <groupId>org.springframework</groupId>

      <artifactId>spring</artifactId>

      <version>2.0-RC1</version>

    </dependency>

    <dependency>

      <groupId>axis</groupId>

      <artifactId>axis</artifactId>

      <version>1.4</version>

    </dependency>

    <dependency>

      <groupId>axis</groupId>

      <artifactId>axis-jaxrpc</artifactId>

      <version>1.4</version>

    </dependency>

You will notice a problem with spring and maven 2 at the moment of writing. Maven provides the solution in the error message, we need to install the maven library manually. There aresome other options, but for now this is the easiest one. First download spring version 2.0 RC1, than issue the following command:



mvn install:install-file 

          -DgroupId=org.springframework 

          -DartifactId=spring 

          -Dversion=2.0-RC1 

          -Dpackaging=jar

          -Dfile=%PATH_TO_JAR%/spring.jar

Step 3 - Time to get the eclipse wtp to work
I want to deploy the webservice via tomcat and ofcourse I want a nice environment for debugging, deploying, and developing. I like to work with spring WebTools project, there is a pretty good integration with maven from the maven perspective. Lets use that. Fire up your eclipse (with wtp) and create a workspace. Do not create this workspace inside our projects, do it on another part of the disk. After creating this workspace, add the maven repository as a variable by using the following command:



mvn eclipse:add-maven-repo -Declipse.workspace=%PATH_TO_WORKSPACE%/WebservicePoc

Now let maven generate the eclipse project and classpath files, issue the following command:



mvn -Dwtpversion=1.0 eclipse:eclipse

You are ready to import the project into eclipse, "File > Import > Existing projects into workspace"

step 4 - Lets publish a webservice
The webservice is deployed within a web container. Both axis and the spring container run in a servlet. There is a connection between the two via the servlet endpoint which will be discussed in a while. These servlets are configured in the web.xml file. The template for the file is generated by maven, lets add the servlets, servlet mappings and a spring specific parameter.



	<context-param>

		<param-name>contextConfigLocation</param-name>

		<param-value>

			classpath:/applicationContext.xml

		</param-value>

	</context-param>

This parameter specifies the locations where spring can find the configuration files for the container. The applicationContext.xml contains the definition of the beans in the Business service domain. There is another configuration file for spring thats needs to be present. This is the default spring config file based on the name of the servlet that configures the spring container. In our case this file does not contain any beans, but it must be available. It must be called action-servlet.xml since we have given the spring dispatcher servlet the name action. The file should reside next to the web.xml in the WEB-INF folder.



	<servlet>

		<servlet-name>action</servlet-name>

		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

		<load-on-startup>1</load-on-startup>

	</servlet>



	<servlet>

		<servlet-name>axis</servlet-name>

		<servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class>

		<load-on-startup>2</load-on-startup>

	</servlet>



    <servlet-mapping>

        <servlet-name>action</servlet-name>

        <url-pattern>*.html</url-pattern>

    </servlet-mapping>



	<servlet-mapping>

		<servlet-name>axis</servlet-name>

		<url-pattern>/services/*</url-pattern>

	</servlet-mapping>

Here you can see the spring dispatcher servlet and the axis servlet. Most important to notice is the load-on-startup parameter that tells the order of loading the servlets. The axis servlet connects to the loaded spring context via the special endpoint. Therefore the spring servlet needs to be loaded first. You do not need the dispatcher servlet if you plan to expose only webservices. If you also want to include spring mvc or the like, you do need the dispatcher servlet.

Next task is to configure the axis webservice, this is done via the server-config.wsdd file.



	<service name="JaxrpcwebserviceProvider" provider="java:RPC">

		<parameter name="className"

			value="com.coenradie.webservicepoc.server.jaxrpcstyle.ServiceProvider"/>

		<parameter name="allowedMethods" value="*"/>

		<beanMapping qname="webservicepoc:MessageBean" xmlns:webservicepoc="urn:MessageBean" 

			languageSpecificType="java:com.coenradie.webservicepoc.server.jaxrpcstyle.MessageBean"/>

	</service>

We are creating a jaxrpc style webservice with the name JaxrpcwebserviceProvider. Axis should redirect all calls to this service to the endpoint of type ServiceProvider. This is a subclass of a special spring implementation of the servletendpoint, this class is will be discussed later on. As you can see from the wsdd file, all public methods are exposed via the webservice. As a transport object we use the MessageBean.

Now all configuration is in place, time to do some real coding. We need to implement the following classes and interfaces.
MessageService and MessageServiceImpl - Business service interface and implementation
MessageBean - Object returned via the jaxrpc webservice
RemoteMessageService - Remote interface that is implemented by the service endpoint and therefore implemented by the webservice.
ServiceProvider - the special webservice endpoint that contains access to the laoded spring context. The endpoint contains the method that is called via axis.



public interface MessageService {

	String getMessage();

}



public class MessageServiceImpl implements MessageService {

	public String getMessage() {

		return "Message from my server";

	}

}



public interface RemoteMessageService extends Remote {

	public MessageBean getMessage() throws RemoteException;

}



public class MessageBean implements Serializable {

	private static final long serialVersionUID = -7014683074252469915L;

	private String message;

	private String createDate;

	

	public String getCreateDate() {

		return createDate;

	}

	public void setCreateDate(String createDate) {

		this.createDate = createDate;

	}

	public String getMessage() {

		return message;

	}

	public void setMessage(String message) {

		this.message = message;

	}

}

The most important class is the endpoint, this is the class that gets called by axis. The spring superclass takes care of obtaining the spring web context. You can use this context to find spring wired beans. In our case we use it to find the Business service object MessageService.



public class ServiceProvider extends ServletEndpointSupport implements RemoteMessageService {

	private MessageService messageService;

	

	protected void onInit() {

		this.messageService = (MessageService)getWebApplicationContext().getBean("messageService");

	}

	

	public MessageBean getMessage() {

		MessageBean messageBean = new MessageBean();

		messageBean.setMessage(messageService.getMessage());

		messageBean.setCreateDate(new Date().toString());

		

		return messageBean;

	}

}

Time to fire up the server. You can use the run on server with a right mouse click on the project within eclipse wtp. Popup a browser and go to the following url:
http://localhost:8080/webservice-jaxrpc-style/services
That should give you an overview of all deployed services, probably only the JaxrpcwebserviceProvider.

Step 5 - Using xml spy to send a message via soap to the webservice
The webservice is deployed, you can have a look at the wsdl file, nice. Now we want to call the webservice. We can write a special java client. There is however an easier way with xmlspy. Since this blog item is all about exposing the webservice and not about creating a client, I will use xmlspy.

Fire up xmlspy and use the menu: SOAP > Create new soap request and enter the next url in the pop-up box:
http://localhost:8080/webservice-jaxrpc-style/services/JaxrpcwebserviceProvider?wsdl
After clicking oke, choose the getMessage() operating name, the following request is generated:



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<SOAP-ENV:Body>

		<m:getMessage xmlns:m="http://jaxrpcstyle.server.webservicepoc.coenradie.com" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Then we can send the request over soap via xmlspy: SOAP > Send request to server



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

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<soapenv:Body>

		<ns1:getMessageResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://jaxrpcstyle.server.webservicepoc.coenradie.com">

			<getMessageReturn href="#id0"/>

		</ns1:getMessageResponse>

		<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:MessageBean" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="urn:MessageBean">

			<createDate xsi:type="soapenc:string">Mon Jun 26 09:48:31 CEST 2006</createDate>

			<message xsi:type="soapenc:string">Message from my server</message>

		</multiRef>

	</soapenv:Body>

</soapenv:Envelope>

That concludes this article, I learned a lot while writing this item, hope you learned something while reading. The coming weeks I want to write about creating a client, doing document style webservices, using spring webservices component and security. Stay tuned.

	EAR versioning (endpoint versioning)	WAR versioning (endpoint versioning)	Package versioning (namespace versioning)	OSGi (any type of versioning you like)
How the versions are recognized	By endpoint Either the EARs will be deployed on different app servers, or the WARs inside will have different contexts	By endpoint Each WAR in the ear wil have a different context (e.g. /services/v1 and /services/v2)	By namespace We're talking about different services here. The dispatching process will send each service to the appropriate class	Any way you like. You have complete influence on the dispatching process.
Complexity to set up	No specific set up to be done. Make sure to use a VCS.	Slightly complex. Use e.g. maven to build the WAR files and include the necessary versions in your EAR. Make sure version specific classes and jars are included inside the WAR.	Not complex at all to set up, but each new version will require you to create new classes or rename the old ones. Consider each new version as a completely new service in your web service dispatcher	Very complex for beginners. OSGi introduces some extra features and a different mindset than Â?normalÂ? java programming.
Impact on codebase, bug fixing and maintenance	Little impact. Keep in mind that each fixed version will have to be redeployed. Use your VCS tools to merge changes across branches.	Little impact. Each modified version will have to be rebuilt and each WAR included in the EAR file. Use your VCS tools to merge changes across branches.	Huge impact. The amount of classes will double with each version. Merging across branches is no longer possible, since class names are different.	You application will have to be set up in a modular fashion. If it already is, the impact on your codebase is small. You can use VCS tools to merge changes, since class names donÂ?t change.
Impact on deployment effort	Highest impact on deployers. Each version requires an extra EAR to be maintained.	Small impact on deployers. There is only a single EAR file to deploy and maintain.	Small impact on deployers. There is only a single EAR file to deploy and maintain.	Small impact on deployers. There is only a single EAR file to deploy and maintain.
Impact on testers	Small impact. Old versions are remained intact when deploying new versions.	Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.	Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.	Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version.
Flexibility	Very high. Since versions are completely separate, changes in one version do not affect the other.	High. Because all versions share a common (EAR) class loader, there are some limitations. Especially when using native code.	Low. All versions must use the same shared libraries, as all versions share a single class loader.	Very high. The versioning and dispatching mechanism is completely configurable to your projects needs. Each version of the web service can depend on different versions of external libraries.