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...