One runtime, many servers

August 27, 2006

One of the improvements we have in store for the next release of Cape Clear is ability to target a web service at a single runtime, but deploy it on different servers from Cape Clear Studio. This means a web service project (module) can be deployed on e.g. a local server, a remote server or a clustered server without having to adjust its target runtime in Eclipse. We’re looking to push this improvement back into the Eclipse WTP project. To follow the progress of this, see this Eclipse bug.

Advertisements

Cape Clear Software has been named a ‘Company to Watch’ in the 8th Annual Intelligent Enterprise Editor’s Choice Awards

One of the key features that first hooked me on Eclipse was its (Java) refactoring capabilities. Refactoring is an indispensable tool in the Java code jockeys toolbox, and Eclipse makes it easy. The Eclipse Language Toolkit (LTK) provides a framework within which to build refactorings.

As we move into the realm of service-oriented programming, developing services that can be deployed on Enterprise Service Buses, I’d like to see the same level of refactoring available for SOA artifacts. By SOA artifacts I mean things like WSDL, BPEL, deployment descriptors, as well as Java classes and other language files. At the detail level, the relationships between these artifacts can be complex.

With WSDL described services, when the WSDL changes some refactoring often happens automatically i.e. tooling can regenerate the proxy code for a service when the WSDL describing the service changes. But beyond this kind of thing, more sophisticated refactoring is required. In fact, whether this refactoring is done explicitly by the user, or implicitly by the tooling reacting to changes in WSDL and automatically altering other artifacts, much of what needs to be done is the same.

The use case I’m starting with is a simple one. A BPEL script implements a service defined using WSDL. The BPEL script invokes another service also defined in WSDL. It should be possible to rename a portType operation by highlighting the operation in the WTP WSDL Editor in Eclipse, right clicking and choosing Refactor | Rename. I’m considering both the cases of the service implemented and the service invoked.

It is worth noting that the WSDL editor in Eclipse 3.2 provides a basic rename refactoring feature, but to date I think its pretty limited.

The LTK provides a high level framework for refactoring, within which I’m going to put the framework for SOA artifact refactoring. The basic steps are something like this:

  1. Identify the refactoring the user wishes to perform e.g. renaming a WSDL portType operation.
  2. Find all the projects and artifacts in the workspace that should be changed.
  3. Perform the initial sanity check.
  4. Ask the user for more information if necessary.
  5. Calculate the changes required to each artifact.
  6. Check that each artifact will still be valid after the changes.
  7. Present the changes to the user for acceptance or alteration.
  8. Commit the changes.

Lets have a look at a snippet from a really simple WSDL file, HelloWorld.wsdl, that shows an operation called sayHello:








Lets suppose this WSDL operation has a SOAP binding. The operation name also appears in the binding and in the soapAction attribute in the binding:







As in the example, by convention message names often follow the form: Request, Response. It would be great if the user could choose to also rename these as an optional part of renaming the operation name.

One of the Eclipse plugins I’m going to develop will house the framework core. The implementations of the various parts of the framework can be contributed via extension points.

Lets consider the problem of finding all the relevant artifacts and the projects that house them across the Eclipse workspace. While this first use case considers just WSDL and BPEL, the search-for-artifacts step, at a high level, is general enough.

The job of the Artifact Finders is to find projects and their artifacts that require changing in response to the operation rename.

Consider the case where the HelloWorld.wsdl file lives in one project, some projects have a link to it and others have a copy of it. The projects with a link to it are easy enough to find. Any projects that contain a file called HelloWorld.wsdl are also candidates, but just because one WSDL file has the same name as another does not mean they represent the same service, or the same version of the service. A trickier case again is where the WSDL file is indirectly referenced e.g. it is imported by another WSDL file, or referenced in a descriptor file. For these latter cases we may require some deep searching, which could be time consuming, so we need to bear that in mind.

Artifact Finders are one element of the framework. The Artifact Finder interface will look something like this:

public interface IArtifactFinder {
public RefactoringParticipant[] findArtifacts(SOAArtifactRefactoringArguments args);
}

And the extension point is defined like this:




id=”foo.id”
name=”Foo Refactor BPEL Artifact Finder”
class=”org.codecurl.soa.refactor.finders.FooFinderImpl”/>

Lets look next at the changes required to the BPEL script, considering first the case where the BPEL service implements the interface defined by the HelloWorld.wsdl file. The variable definitions for the input and output messages may need be to changed (if the user has chosen to also rename the input and output message types):




For consistency, we should allow the user to rename the variables too if the message type names are changing. The receive starts the process:


operation=”sayHello” variable=”sayHelloRequest”
createInstance=”yes”>

So the operation name is changing and maybe also the variable name. And the process ends with a reply:


operation=”sayHello” variable=”sayHelloResponse”>

Again, the operation name and possibly the variable name will change.

In the case where the BPEL process is invoking the HelloWorld service, we need to consider the invoke element. The operation name attribute value will change, and the inputVariable and outputVariable attribute values may change:


operation=”sayHello” inputVariable=”sayHelloRequest”
outputVariable=”sayHelloResponse”>

We need to set up the invoke call by populating the sayHelloRequest message, so we should look for assign elements that use the variables:



Bob




Callbacks (onMessage) also need to be considered.

One of things I want is APIs for refactoring the various models (WSDL, BPEL, whatever). I like to start with a “perfect” API for something like this, and then implement that with off the shelf components (like WSDL4J) and whatever additional code is required.

Once I have the framework plugin working for this simple example, I will look at contributing to the appropriate Eclipse project/area. Maybe the SOA Tools Platform and/or the LTK.

There is a nice clickable SCA diagram available that describes the basic SCA concepts.

I got a JDJ newsletter in my inbox today entitled “Harnessing Collective Innovation with Web 2.0-2”. Who writes this stuff? Sad. Ok, Mr. Symth? Now all my blog needs is some AJAX – oh! There it is 🙂

boolean mightGoOnFire = checkBatteryId(myLaptop, “http://www.dellbatteryprogram.com/”);
if (mightGoOnFire) {
orderNewBattery(
http://www.dellbatteryprogram.com/”);
Thread.sleep(60480000); // expect to wait for a very long time for the replacement! 😦
}
else {
beHappy(); // 🙂
}

“One of the best ESB products available and it wins our Editor’s Choice Award for functionality and performance.” – IT Week, July 31, 2006

“Clear’s Cape Clear ESB 6.6 provides an intuitive and capable platform for creating, managing and deploying services, processes and data for an SOA infrastructure.”

And Cape Clear will just keep getting stronger – we have a host of goodies in store for later this year. I can’t wait! 🙂