Hype is Over! SOA is Real!!

In the blog entry on SOA Lessons: The end of the hype cycle? Revisiting 2007, Judith Hurwitz is talking about end of the hype and beginning of the reality for SOA.

There are mistakes mentioned:

My main observation about 2007 was that it was a year of learning about SOA. It was also a year when people made lots of mistakes including:

1. Let’s code thousands of cool web services and see what happens — guess what…no one knew what to do with them!

2. Let’s create a corporate wide SOA implementation this year — what’s wrong with boiling the ocean? (too obvious to make a comment on this one)

3. If we implement an Enterprise Service Bus we are all done with SOA…right? — wrong!

4. Hey, we are reusing a service in the same application but we’re not getting very much value….(try reusing in a different application)

And there are successes mentioned:

I saw many big successes with SOA in 2007. Many companies are understanding that SOA is, in fact, a business strategy based on codifying business services that represent best practices for business policy and process. These companies are taking a long view — not expecting instant results. Many of these organizations are finding strong returns on investments but they would rather not tip off the competition. Before starting one SOA project, our team had to sign three different non-disclosure documents!

And the part I like the most, the predictions:

I think that we are at the end of the over hyped stage of the SOA market. It is inevitable in any new market that it begins with unreasonable expectations. When customers start using the approach to solve real problems, it is always harder than the hype would suggest. The reality is that transforming software from purpose driven, single use applications to flexible, agile, and reusable services that are loosely coupled is hard work. In fact, the fact that we are getting over the hype phase actually means that SOA is real!

The Need for SOA with PHP

In this post on “why PHP users should be serious on SOA?” I have discussed why a mainstream scripting language such as PHP would need to consider the implications of SOA more seriously than it is now.

It used to be LAMP or WAMP; It is only a matter of time before they become LASP or WASP, where S is for Services.

.NET and PHP in SOA

Can a .NET application talk to a PHP application? Can a PHP application talk to a .NET application? Yes for both cases. But, how? Well there could be multiple ways, but the most obvious answer is with Web services.

Ok, so I can use PHP5 SOAP extension and get the job done? Yes to some extent. With PHP5 SOAP extension you can get started. However, if you use WSO2 Web services framework for PHP, you can do more.

Do more in the sense? In addition to SOAP, you can get .NET and PHP to exchange binary data attachments as well as secure messages that are signed or encrypted or both.

In short, they are interoperable.

Most Exciting SOA Features of WSO2 WSF/PHP 1.2.0 Release

We have packed and tested WSO2 Web services framework version 1.2.0. Release note will go out next Monday.

I am very excited about this release, because it has improved support for loose coupling and interoperability. Always, clean interfacing is welcome when interconnecting services. This release has put some considerable effort to improve the integration with enhanced WSDL support. The key SOA friendly features to look out for are:

• WSDL generation
  • We have improved the code first model a great deal. This release will have the greatest WSDL generation capabilities that the PHP world has ever seen
• WSDL Mode improvements
  • Now you can provide a WSDL with security policies and the framework is capable of dealing with those policies and enforce them

As always, it is open source (Apache 2.0  license) and free to download and use as you wish. Download now and enjoy these excitements!!!

SOA with Ruby

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

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

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

Interesting blog on Just doing SOA. 

More inclined to the .NET side but still interesting.

SOA Tool for C Fans

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

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.