Service Scalability

Over the past few weeks I have spoken with several customers who are implementing SOA in various stages and have decided to employ Web Services as the foundation. One of the key concerns is scalability and the ability to handle large volume for public / private services. An approach that evolved from these discussions was the following:

- For new services, specify governance in the Service Analysis / Modeling phase. This should specify the SLA for the Service and help identify the potential reuse and usage pattern that may be experienced.

- Services typically begin with a single instance using protocols such as HTTP

- Service scalability should be tested via Performance tools to determine how it degrades with load, supportable performance etc.

- Services should be monitored using JMX or similar API to determine runtime usage and usage patterns.

- Make services stateless so that they can be easily clustered.

- If service usage is higher than anticipated, consider configuring a cluster of service instances and use Hardware or Software load balancing.

- If throttling is desired, have service instances read requests from a JMS Queue as this places an abstraction between the service consumer / service provider. Queues allow for asynchronous communication and persistence point for inbound requests. Services can then throttle how quickly requests are processed without losing messages.

Deployment / Test of simple BPEL Process in Apache ODE

In my previous post I spoke of the configuration / startup of Apache ODE. This morning I deployed one of the examples and tested it using the provided sendsoap.sh utility and SOAPUI. A couple of things were necessary to do this:

1) New processes are stored in a folder with the process name and include:
- BPEL File
- WSDL(s) File
- deploy.xml (deployment descriptor)
- other necessary files
2) The folder is stored under the directory.
3) On startup the server will load the processes and report on it within the server log file as shown below:



4) The Apache ODE User Guide then describes a way to test services using a script called sendsoap.sh under the Apache ODE Distribution bin directory. To get this to run I needed to open up permissions using chmod. One this was complete the syntax for executing this is:

/bin/sendsoap.sh (URL to the web service) (SOAP file sample)

or in the case of what is provided in the distro:

/bin/sendsoap.sh http://localhost:8080/ode/processes/helloWorld examples/HelloWorld2/testRequest.soap

When executed the following is returned in the client window:



The tomcat/catalina server window shows the following:



5) Testing in SOAPUI, the following was executed and the results are shown in the following image:
- Created new project in SOAPUI
- Selected WSDL
- Generated a message
- Invoked Service

Setting up Apache ODE within Tomcat / Axis2

So it has been a busy week and I have had little time to work on the Open Source BPEL investigation. I have decided for simplicty sake that I start with Apache Axis2 versus Apache ServiceMix. This will allow me to quickly fire in SOAP requests and not have to become familiar with the ServiceMix infrastructure. I will tackle this next and apply what is learned here to that.

So here are the steps that I followed to get Apache ODE installed within Axis2. I made the mistake of initially downloading the Axis2 binary distro versus Tomcat. The Apache ODE instructions work with Tomcat/Axis but not Axis2 standalone.

1) Download Apache Tomcat 6.0.16
2) Download Apache Axis2 1.3 WAR distribution
3) Download Apache ODE 1.1.1 WAR distribution
4) Copy axis2.war to tomcat/webapps
5) Copy ode.war to tomcat/webapps
6) Set JAVA_HOME
7) Run Tomcat using tomcat/bin/catalina.sh run

The console then shows the following on startup:



Success!

I then accessed the Axis2 Console and could see the Apache ODE Services by going to http://localhost:8080/ode.



Next will be deployment of a BPEL sample into Apache ODE and invoking using SOAPUI.

Cheers!