Gigavox‘s engineers made the decision to leverage Amazon‘s infrastructural web services in order to save time and money with Amazon‘s pay per use pricing model. Gigavox‘s case is interesting because they use most of Amazon‘s infrastructural web services and you can see how you can combine the various services to build a complex application. They use S3 for storage, EC2 for batch processing and SQS to connect the the various subsystems. You can see a diagram of the architecture here.

The episode has two guests, Jeff Barr from Amazon and Doug Kaye from Gigavox.

The article discusses data in a service oriented world. It distinguishes data that exists inside the service (private service implementation data) from data that exists outside of the service boundaries (data transferred between services) and talks in depth about the characteristics of each type of data.

BTW You can also see Pat Helland talking about SOA in this TSS.net interview.

It is nice to see a tutorial on GRID computing that actually tells you how to implement something…

WSDL-first (where the developer writes the WSDL first, then generates stubs and implements the code of the service using the generated stubs) is the most pure way of web service development since the developer concentrates on the format of messages and on message exchange patterns. Also WSDL-first is the best way to achieve interoperability. Unfortunately it is not usually the most productive. This is because both WSDL and XSD are complex standards and are hard to write manually.

WSDL-first is not the only way to do contract-first service development. You can create an interface, produce the WSDL from that interface and never change it (keep it immutable). This way the WSDL produced will always be the same and you get away with the versioning problems. You can change the implementation of the service by changing the class that implements the exposed service interface without changing the interface.

Similar techniques are used in object oriented system where in some languages, like Java, changing an interface breaks binary compatibility (see Evolving Java-based APIs). In these cases techniques like numbered interfaces are used to overcome this limitation.

The major benefit from this approach is productivity. Coding interfaces in statically typed programming languages is easy and when you specify the web service related metadata with annotations you can create a web service very quickly.

This way is used by Steve Swartz in his “Introduction to Indigo” MSDNTV episode to develop a simple web service using Indigo. In Java we have JSR-181 web service annotations that can be used to expose classes and interfaces as web services. You can find a stable JSR-181 implementation at Apache Beehive.

Below I implement the web service that Steve Swartz implemented in “Introduction to Indigo” MSDNTV episode in Java with JSR-181 annotations.

Define an endpoint with an interface + annotations:

import javax.jws.WebMethod;
import javax.jws.WebService;
 
@WebService(
        serviceName="IMyService",
        targetNamespace="uuid:12341234-1234-1234-1234"
)
public interface IMyService {
 
        @WebMethod
        public String mangle(String s);
}

and then implement the interface:

import javax.jws.WebService;
 
@WebService(endpointInterface="IMyService")
public class MyService implements IMyService {
 
        public String mangle(String s) {
                char[] chars = s.toCharArray();
                //We don't have Arrays.reverse() in Java
                int offset = chars.length - 1;
                for (int i = 0;  i < chars.length / 2; i++) {
                        char c = chars[i];
                        chars[i] = chars[i + offset];
                        chars[i + offset] = c;
                        offset -= 2;
                }
 
                return new String(chars);
        }
}

Please note that AFAIK MyService does not have to implement IMyService and that the endpointInterface member inside the @WebService annotation is the construct that creates the link between the service and its implementation.

Of course interface-first isn’t perfect either. The developer is creating a web service while dealing with methods, parameters and objects so the web services produced might be more object-centric (introducing interoperability problems) than required. The first of the above articles has a really good discussion on when to use WSDL-first and when code-first (expose a class not an interface) that has some information that also apply to WSDL-first vs interface-first. ]]> http://www.tzavellas.com/techblog/2005/07/31/contract-first-service-development/feed/ 0 http://www.tzavellas.com/techblog/2005/07/31/onjava-axis2-article/ http://www.tzavellas.com/techblog/2005/07/31/onjava-axis2-article/#comments Sun, 31 Jul 2005 18:11:45 +0000 spiros http://www.tzavellas.com/techblog/?p=17 OnJava has published an article about how to implement message oriented web services in Apache Axis2. The title of the article is “Web Services Messaging with Apache Axis2: Concepts and Techniques” and it is written by Srinath Perera and Ajith Ranabahu (both Axis2 developers).

I believe that the above article is very interesting since it provides an introduction to both messaging and the API of the new version of Axis.