SOA with Ruby

January 4, 2008

WSO2 Web Services Framework for Ruby 1.0.0 was released this week. This adds comprehensive WS-* support to Ruby, enabling Ruby to be used in SOA implementations that would accomplish the need to inter-operate with heterogeneous implementations such as those in Java and .NET.

This Ruby Web services framework is based on the C Web services framework. That too released its latest version 1.2.0 this week.


Customizing Service Endpoints with Apache Axis2/C

September 30, 2007

My latest article on OT is on “Web Services Endpoints with Apache Axis2/C”. Provides a detailed descriptions on customizing the endpoint address format of hosted Web services with Apache Axis2/C, the Web services engine for providing and consuming Web Services in C.
With these improved features, Apache Axis2/C is gradually becoming an important SOA tool.

SOA and virtualization

September 5, 2007

I read this blog entry on Realizing SOA with service virtualization?

First it has give a brief description on what virtualization is:

At its most basic form, virtualization is an abstraction layer that decouples a resource consumer from the provider of those resources. Virtualized resources allow a single provider to support multiple consumers to achieve higher agility and reuse of those resources. In the virtual machine scenario, the physical hardware is abstracted from the operating system creating unique opportunities for design optimization.

Then it explains the match between SOA and virtualization

Service virtualization realizes many of the professed SOA advantages by abstracting the true service address, binding, and contract necessary to invoke business functionality at a given endpoint. An abstraction layer is also a potential platform for additional behaviors.

SOA – Just do It

August 31, 2007

Interesting blog on Just doing SOA

More inclined to the .NET side but still interesting.

SOA Tool for C Fans

July 11, 2007

Web services is the most popular implementation technology for SOA. All those C fans lacked a comprehensive Web services stack all this time. Yes we have some projects supporting Web services, but most of those lack breadth when it comes to WS-* coverage. WSO2 WSF/C team has announced the release of version 1.0.0 of the Web services framework, that is promising to fill in this gap.

Let me quote form the docs that I myself wrote.

WSO2 Web Services Framework/C (WSO2 WSF/C) is a standards compliant, enterprise grade, open source, C library for providing and consuming Web services in C. WSO2 WSF/C is a complete solution for building and deploying Web services, and is the C library with the widest range of WS-* specification implementations, including MTOM, WS-Addressing, WS-Policy, WS-Security, WS-SecurityPolicy, WS-Reliable Messaging and WS-eventing. It provides the best interoperability- all the Web services specification implementations are tested for interoperability with Microsoft .NET, WSO2 WSAS and other J2EE implementations

WSO2 WSF/C is promising in the C language space as a SOA tool because it allows seamless integration of C applications to other elements in your SOA. It can be used as an SOA enabler.

This project is based on Apache Axis2/C family of projects.

For me, the most important aspects of WSO2 WSF/C are that it is open source and it is comprehensive. It is going to be a promising open source project in C land, and is already being used by WSO2 WSF/PHP to provide Web services support for PHP. And it can be used to enable Web services with other scripting languages such as Perl, Python or Ruby. Thus WSO2 WSF/C provides you with much needed freedom of choice when it comes to the implementation technology in your SOA. It does not matter if you want to use PHP or Perl in your implementation, because WSO2 WSF/C as the Web service enabler underneath, would deliver you the desired SOA characteristics such as interoperability.

Importance of SOA Governance

July 9, 2007

I was reading a Gartner press release on SOA risks. This report highlights some technical and organizational factors that can lead to SOA failure.

“Right level” of governance, and “right level” of service granularity is required for SOA success according to the press release. This again highlights the importance of A in SOA – you need architects to identify the “right levels” and the architect should architect the system with “right levels”.

In other words, the enterprise architecture with service-oriented characteristics is unique to each and every organization.

Among other risk factors, are the documentation and bad selection of components. These are simple factors that we always know that should be in place, but always overlooked. When selecting components, often politics and marketing hype play a bigger role than technical feasibility.

A in SOA

July 7, 2007

There are many who raise concerns on SOA being driven out of its true meaning, mainly because of the hype related marketing surrounding it. However, I have seen some real SOA experts raise concerns on missing A in SOA.

Many people, even software architects, fail to look at SOA as an architectural pattern. Some software vendors try to market products with SOA, and people tend to think that you can place that product in the enterprise IT stack and archive SOA. This school of thought is really against the principles of SOA. Each and every organization need to look into their enterprise needs and build the service oriented architecture. Vendors can have products that assist to realize SOA.

It is incorrect to focus on the technology, when trying to come up with an SOA that suites an organization. Unfortunately, even today, many architects tend to do so.

Irving Wladawsky-Berger on SOA

May 21, 2007

Irving Wladawsky-Berger’s blog entry on SOA, Services and Business Architecture has some clear and concise explanations on SOA characteristics.

Here are some of those that struck my mind:

SOA has been gaining ground as an effective mechanism for defining business services, the software that implements such services, and the software-based tools that enable people to effectively take advantage of them. Unlike traditional software, SOA is based on modularity, composability and interoperability. It encourages the designers of business applications to make sure that the services, components and overall architecture they are defining properly represent the business view, and not the view of the underlying IT infrastructure.

The hope is that with SOA and the many different tools developed around it we will be able to design, simulate and test business services in business terms – prior to their implementation in IT systems. Such architectures would then be much more reflective of the basic concepts of the business – be it a hospital, a retail distribution center, an industrial organization or a government department – rather than those of the IT foundations on which they are being implemented

Apache Axis2/C 1.0.0 Released

May 13, 2007

Apache Axis2/C Team is pleased to announce the release of Apache Axis2/C version 1.0.0
You can download this release from

Key Features

1. Support for one-way messaging (In-Only) and request response messaging (In-Out)
2. Client APIs: Easy to use service client API and more advanced operation client API
3. Transports supported: HTTP
a. Inbuilt HTTP server called simple axis server
b. Apache2 httpd module called mod_axis2 for server side
c. IIS module for server side
d. Client transport with ability to enable SSL support
e. libcurl based client transport
4. Module architecture, mechanism to extend the SOAP processing model
5. WS-Addressing support, both the submission (2004/08) and final (2005/08) versions, implemented as a module
6. MTOM/XOP support
7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This has complete XML infoset support
8. XML parser abstraction
a. Libxml2 wrapper
b. Guththila pull parser support
9. Both directory based and archive based deployment models for deploying services and modules
10. Description hierarchy providing access to static data of Axis2/C runtime (configuration, service groups, services, operations and messages)
11. Context hierarchy providing access to dynamic Axis2/C runtime information(corresponding contexts to map to each level of description hierarchy)
12. Message receiver abstraction
a. Inbuilt raw XML message receiver
13. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool)
a. Axis Data Binding (ADB) support
14. Transport proxy support
15. REST support (more POX like) using both HTTP POST and GET
16. Comprehensive documentation
a. Axis2/C Manual

Major Changes Since Last Release

1. Many Bug Fixes
2. IIS module for server side
3. libcurl based client transport
4. Improvements to overall API to make it more user friendly, stable and binary compatible
5. Transport proxy support
6. Memory leak fixes

We welcome your early feedback on this implementation.
Thank you for your interest in Axis2/C.

— Apache Axis2/C Team —