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.
Archive for August, 2006
27
Aug
06
One runtime, many servers
22
Aug
06
Cape Clear – one to watch
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:
- Identify the refactoring the user wishes to perform e.g. renaming a WSDL portType operation.
- Find all the projects and artifacts in the workspace that should be changed.
- Perform the initial sanity check.
- Ask the user for more information if necessary.
- Calculate the changes required to each artifact.
- Check that each artifact will still be valid after the changes.
- Present the changes to the user for acceptance or alteration.
- 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 
16
Aug
06
Almost not so happy laptop days
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!
I am so glad to see that in the latest SCA draft specification the assembly composition has been greatly simplified using a recursive model. I thought the whole module, fragment, sub-system and system thing was hopelessly confusing (how many times did I read the 0.9 spec?!). Now we have Composities (which are just the same as Components) that include other Components and so on. So its basically composite services and services.
The Cape Clear ESB University is an educational and training initiative aimed at providing software developers, systems integrators and IT architects with the information and tools they need to ensure the success of their Service-Oriented Architecture (SOA) projects. These live educational webcasts, which will be held during the month of August, will support organizations in the design, development, deployment and management of SOA and ESB projects, using relevant business case examples.
You can register for these courses here.
The first course covers the Principles of SOA Design Using Enterprise Service Bus. This session focuses on the SOA creation process, principles of good SOA design, and the use of an ESB to enable SOA projects.
During this event you will learn:
- Service-Oriented Architecture: The accepted architecture for reducing development costs, increasing IT agility and improving IT/business alignment
- Enterprise Service Bus: The new technology platform for realizing SOA
- Standards: What are the standards that relate to SOA?
- True ESB: The standards-based ESB platform for SOA
On these courses you can learn how Enterprise Service Bus can Leverage your SOA Initiative.
The Cape Clear ESB University has been designed to accommodate the diverse needs of those who are responsible for creating a SOA strategy, design and implementation, helping to ensure projects result in reduced development costs, and increased business agility.
The ESB University webcasts will include sessions on the following topics:
- Course 1: The Principles of SOA Design Using Enterprise Service Bus
- Course 2: SOA–Introduction to Process Orchestration and Top Down Service Design
- Course 3: Mapping and Transforming Diverse Data Formats Using SOA
- Course 4: Service Enablement and Quality of Service with SOA
Sign up now!
—————————————
Course 1, August 9, 2006
8 AM PDT/11 AM EDT/4 PM GMT
The Principles of SOA Design Using Enterprise Service Bus
—————————————
Course 2, August 16, 2006
8 AM PDT/11 AM EDT/4 PM GMT
SOA – Introduction to Process Orchestration and Top Down Service Design
—————————————
Course 3, August 23, 2006
8 AM PDT/11 AM EDT/4 PM GMT
Mapping and Transforming Diverse Data Formats Using SOA
—————————————
Course 4, August 30, 2006
8 AM PDT/11 AM EDT/4 PM GMT
Service Enablement and Quality of Service with SOA
—————————————
