First bump in the SCA investigation

During evalutations and investigations you sometimes come to a point where you hit the wall and finds an issue that leaves a big question mark in your head. Suffice to say I just hit one of those moments...

If you've followed my previous posts you know that I've recently started to look into how the SCA Tuscany runtime and composition model could be utilized for building transport/implementation neutral services at my client.

The existing strategy is based on building webservices with JAX-WS, Java's standard WebService framework. One great feature of any WS framework is the ability to define message interceptors/handlers that will be injected before the message receives the actual service. These handlers have access to the entire soap message, including the soap headers. So you could i.e. define a company-wide custom soapheader with meta-data which should be acted upon by each and every service before (or even after) invocation.

This takes care of non-functional requirements such as traceability, security, end-to-end header propagation etc, since those aspects of the call can be separated from the actual business service.

Looking at the SCA spec and what the tooling provides I have yet to find the similar function in the SCA world. Even if you i.e. expose a component as a webservice binding I cant find any way to specify my chain of handlers that should get invoked for incoming requests.

Looking into the SCA 1.1 specification it states that jax-ws handlers are not included in the standard, but should/could be implemented by vendor implementations. From what I can see IBM has not chosen to do so in the current version of the SCA feature pack runtime nor tooling.

This seems a bit strange to me since I know that the BPM (0.9 SCA) products has had the support for adding handlers to a webservice export for a long time.

I'll definately be going to dig into the subject more, since it could prove to be a big no-go for us as we otherwise would have to revise our entire call-chain strategy for i.e. composite services.

To you readers out there, have you had experiences with interceptors/handlers in the SCA context? I might be missing some obvious features that you know about? If so, I'd be very delightful for all advices you could provide.

Over and out...

Combining OpenSCA (WAS FP) and Classic SCA (WESB), continued

In my previous post I mentioned that I'm currently assigned to test the interopability between an SCA component developed in RSA with the IBM BPM products version of SCA.

I should perhaps start with a little background on the subject of SCA in the IBM products to give a little insight of the need for the test.

The history of SCA (from an IBM perspective)
IBM was a major influencer during the standardization of SCA and started to incorporate the framework as an early adopter before the standard was finalized. This version was called 0.9 and is the framework that the Process Server and ESB is built upon.

Unfortunately (for IBM at least) the standardization body did not agree on some of the naming conventions and functionalities that IBM had specified in their draft version. Therefore there are some subtle differences between the 1.0 version and the IBM 0.9 version. The architecture as whole is fairly similar, but some implementation specifics differ.

IBM has since then released a feature pack for its Application Server (which both WPS and WESB is deployed to) that implements the SCA 1.0 standard.
It is (at least to my knowledge) based on the Apache Tuscany SCA runtime and has a nice tooling support in Rational Application Developer.

The idea behind SCA is to compose your applications from separate building blocks, each with a defined interface. This makes it possible to separate the bindings and the underlying implementation as well as the data representation for each component. As long as you adhere to the interface you can connect to the component through its exposed physical bindings.
This makes it possible to i.e. expose a java service over JMS, WS, java etc by configuration rather than implementation. It also separates non-functional requirements such as Quality of Service and security to name a few from the actual implementation. Think of SCA as WebServices on steroids and you get the picture..

SCA is also a binding mechanism, which allows intra-JVM calls to a service through pass-by-reference rather than the ordinary serialization/deziralization normally required for i.e. a WS-call.
This has the benefit that if you'd like to call an SCA-composed service that is in the same JVM, you could call it directly without passing a physical transport. At the same time, if your service should be reachable from the outside all you have to do is to define a transport binding as well, i.e. SOAP/Http or SOAP/JMS.

So, back to the task...

I'm currently investigating whether it is possible (and beneficiary) to call a 1.0 SCA component from the 0.9 version provided in the WPS stack of products through an internal SCA binding. This could influence my client to bundle their services into SCA components to ease future integration with these types of products when they will be required by business projects.

Building the service component
I started by defining a simple HelloWorld echo service in the SCA tooling in RAD. The service is the simplest possible that accepts a string i.e. a name and responds with an appended "Hello" plus the input string.



Working top to bottom I set up an SCA project, composite and component implementing the service. The service specifies the WSDL as it's interface.
After implementing the service I chose to add two bindings to the service. One for Webservices calls to simulate an external client, and one SCA binding for intra-calls. Note the names on the bindings in the below picture.

After deploying this contribution to the Process Server the service is reachable as a Webservice on the endpoint http://localhost:9080/hellocomponent/WS ,where "hellocomponent" in the URI is the component and "WS" is the binding name.


Building the client in WID
I then created a simple mediation in WID with an SCA import pointing to the SCA binding. The interface for the import is the original WSDL, and the binding names are shown below. Note that "Module name" specifies which component to call while "Export name" is the name of the binding.
I also created a proxy interface for this service and a mediation to simulate a typical transformation scenario in WID.

The result is that the hellocomponent can be reached both through an SCA binding from Websphere ESB/Process server as well as through a webservice call.

I'll continue to dig deeper into the interopability and will try to see i.e if the internal binding is indeed faster than if the Process server would call the component as a webservice (which is ofcourse also doable). I'll also try to fiddle around with specifying qualifiers (security, transaction scopes etc) and set up a reverse scenario where OSCA calls CSCA.

'til next time.

Over and out...

Combining OpenSCA with IBM Classic SCA (WPS/WESB)

My current client needs to perform a Proof-of-Concept on the interopability between the old style of SCA used by the Websphere BPM products (Process Server and Websphere ESB) with the standard SCA 1.0 that the WAS Feature pack for SCA implements.

So far my task is to package one of their existing services as part of an SCA contribution and verify that it is accessible from a long-running process inside the process server.

The first thing that hit me is that WID doesn't seem to include the SCA tooling plugin that RAD offers, so for the moment it seems to me that I'll have to develop the integration with 2 IDE's, RAD for the Java/SCA part and WID for the WPS parts. Hmm, I'm just wondering how my relatively weak workstation will respond to that.. :-D

Anyway, for guidance I'll be looking at the excellent series of articles at IBM Developerworks:
http://www.ibm.com/developerworks/websphere/library/techarticles/1005_fong/1005_fong.html?ca=drs

I'll keep you updated on my findings as I get along, but it is indeed an interesting subject.

Over and out...

Hunting for the best XML editor for Mule ESB

Recently I've been hunting for a good XML editor to use for authoring Mule ESB configuration files.

Mule is an open source lightweight ESB that is quite simple to work with, but since configuring the flows is all xml-based it can be challenging to learn the ropes in the beginning.

After starting out with the default eclipse xml editor I noticed that it doesn't cope very well with the complex namespace structures that the configuration files require.

The solution?

After trying out a couple editors I finally found the perfect match in the oXygen XML editor (http://www.oxygenxml.com/), whose autocompletion handles Mule ESB's namespaces perfectly. It also exists as an eclipse plugin, making it a good fit together with the Mule IDE (which is eclipse-based).

The downside? It's not free... So I'll be trying it out a little more to see whether the product warrants a purchase.

So, do you have an alternative xml editor that you can tip me about, and preferably a free/open source one? Give me your thoughts, especially if you've been using it in conjuction with Mule.

Over and out...

First meeting with my mentor

Today I had my first meeting with my appointed mentor, a senior and well known technical consultant in the Microsoft world. We had some really interesting discussions regarding carieer goals, future directions, differences between Microsoft and IBM just to name a few topics.

One advice he gave was for me to start blogging more in order to start an online notebook for myself as well as to get in touch with other technology geeks like me.

So here it is! My first blog post of what I hope to be a continious series of posts regarding technical stuff that I come up with at work.

I'll be writing about integration and SOA as well as pure development, mostly Java-based but hopefully I'll manage to fit some Scala in as well since that is a newfound hobby for me.

'til next time.. Over and out!