The more interesting question for developers has to do with infrastructure software. In my mind LAMP is really a proxy for “infrastructure software” If you’ve been paying any attention at all to the development of web application software, you know that there is a lot happening with various kinds of infrastructure software.

is understandable. Almost all the current PaaS vendors have developed mechanisms to harvest commons based peer production. Ultimately all of this ends up in some server of a vendor locked away in a data center somewhere. Most of the vendors use open source software heavily for their PaaS offerings and some have open sourced bits and pieces of their platform. While I’m certainly not the overzealous freedom fighter I was, this awfully sounds like writing open source applications for a proprietary platform. Not that it’s necessarily a bad thing. Unlike developing software on a proprietary operating system, developing on a proprietary platform as a service offering is limited in various aspects which are unique to its usecase.

So, IMHO, a more interesting problem to tackle in an environment like this is open source platform as a service. You still have a hosted service where people can just develop applications and forget about underlying technical details of the platform, where your data is residing and so on. At the same time this entire platform is open source! Sounds like a pipe dream but it’s a reality. I hope this will set a trend that other vendors follow, eventually.

The open source platform as a service is Stratos. The hosted platform reside in cloud.wso2.com where anyone can register for free (during the alpha and beta stages) and get an entire middleware platform at your fingertips with a few clicks. Another bold move is that the code base of the downloadable version and the hosted version are exactly the same! So, the platform itself and hosted applications behave in a predictable manner where ever they’re deployed. Also, it should be mentioned here that most of the services provided by Stratos started their life as standalone programs (like Tomcat). This also, provide invaluable repository of information if anyone wants to study how their should architect their applications to make them cloud native. Source code for the entire platform available here.

SOA patterns is a set of patterns that you’ll likely to encounter when implementing a service oriented architecture in an organization. Sometimes a product that you might be using will not be able to customize according to a well defined pattern. If you have to resort out to non standard communication mechanisms or have to alter your architecture to match what the product can do, then you shouldn’t be using that product to begin with. Cost of making a change later to accommodate a business need might be too high in such a scenario. I’ll be exploring how to configure open source software products to implement some of the well defined SOA patterns in coming posts.

Usually in technically adept circles you can hear virtualization being used more often than the term cloud computing, the technology that enable computers to evaporate into small H₂O particles and form clouds. Virtualization tools have been there for a while. It was, IMHO, got popular after Amazon slapped a Web services interface in front of Xen and said, try using this interface to start/stop and manage virtual machines. Having a separate service for persistent storage, again, is a brilliant marketing move. With big investments (such as Intel investing in Joyent) one can guarantee that the cloud space will get cloudier as time progress. This might make projects such as Simple Cloud more attractive.

Adoption rates for cloud computing is going to increase among the big guys. As a survey done by Forrester tells “one out of four large companies plan to use an external provider soon, or have already employed one”. When people are seriously considering moving to cloud platforms, you have to make sure that all the application programs are ready to be run on a virtualized environment. Specially SOA middleware products that the company is using should be compatible and must be able to take advantage of the services provided.

One advantage of moving to cloud computing is the ability to add/remove resources as and when it’s required. If your applications, or middleware products that you’re using is incapable of getting advantage of this elasticity (autoscaling to the inner techie in you) there’s no point, or no value gained by putting your stuff in the cloud. It’s one reason why WSO2 has “cloud enabled” all of the products line. Not only you can host all your services in the cloud using WSO2 middleware products, you can download pre-built images for VMware and KVM to run inside your private virtualized infrastructure. Give it a whirl and see!

The chapter describing the role of governance during the analysis phase of a project was an eye opener for me because I had this wrong impression that SOA governance applied only to the components that is used in a service oriented architecture. This, as I later found out, called run time governance where you monitor the services to ensure they consistently deliver according to the governing policies and metric collection process for each and every service. In the chapter that’s dedicated to run time governance, Todd describe how to define provider/consumer baselines and how to manage them.

After guiding the reader through all the aspects of SOA governance, what should be done and how you should go about doing those, Todd paints a picture of what does it look like when you have implemented all these steps successfully. Then he explains how one can implement SOA governance in his/her organization along with some common challenges that one might face.

I thoroughly enjoyed reading this wonderfully well written book about SOA governance. You can read a sample chapter about service versioning here.

For all these years, it has only been Java/.Net programmers who has been enjoying the luxury of service oriented architectures. These folks understand the value of building a business functionality as a service or exposing an existing functionality as a service. PHP programmers have been building their web based programs happily without having to know what services mean. People in the PHP community has tried to bring Web services into the language with varying degrees of success. These are very courages and thoughtful efforts. But if you analyze them objectively you’ll see that many of these libraries doesn’t contain that much of features in order to build/integrate an application with an existing enterprise app.

What WSF/PHP has done is lower the bar of building PHP applications that can fit with existing applications in an enterprise written in Java/.Net or whatever the language that might be. Also, it has enabled ability to integrate existing PHP applications to your other enterprise applications.

One strong reason companies have embraced developing applications in Java is that so their data will not be isolated from rest of the enterprise data. In the past having a PHP application inside your company might have been frowned upon because it doesn’t make sense to have information which is isolated from all the other applications in the company. This is why most organizations invest in an ERP for example. But now, this has become a non issue. If you’re using open standards inside your enterprise to communicate/integrate applications, using WSF/PHP, you can integrate or extend services seamlessly with rest of your enterprise services.