SOA - Service Oriented Architecture

How to implement SOA?

Service Oriented Architecture is a orchestration of web services. These web services can be created in Java or .Net. Also, some of these web services are connectors or wrappers provided by various vendors who sell ERP, COBOL legacy systems. The orchestration is achieved using BPEL engines. Because web services are platform independent and XML based to communicate among them SOA is popular.

Note that it is only the interface which is interoperable. Behind the scenes a web service might wrap an EJB, which connects to database using hibernate.

Also, a set of web services which are bundled together as one application because of orchestration using BPEL, may act as an atomic unit of application. In a typical enterprise IT landscape, there could be many such atomic applications and they will have to work together. That is where ESB - Enterprise Service Bus comes in to picture. While there are many open standards for web services like JAX-WS and SOAP, there are no standards for ESB like we have for web services. ESB is infrastructure and backbone for SOA. You cannot buy SOA but you can buy an ESB product. The ESB is like USB which allows a variety of hardware devices to connect to the PC.

For example, ESB allows clients to connect a variety of messaging systems without forcing to create point-to-point channels.

The distinguishing feature of various ESB products have one most important feature and that is to what protocols it supports, like SOAP, HTTP, JMS, HTTPS, SMTP, XMPP, FTP, connectors to various ERP and business applications, to legacy systems like COBOL.

The ESB proves a very important mediation and transformation capability for SOA. For example, if a customer id field changes from all alphabetic characters to all numeric characters, ESB will be very useful to transform this data at the ESB bus level before reaching to a SOAP based service end point.

Having said that it is not always important to have ESB in SOA.

SOA is fundamental to any large enterprise IT system and building products that are readily integrable to SOA should be on the product roadmap of any ISV's product design.


Happy SOA building :)

Tejas Bavishi

Openstack.org - IaaS - Cloud Computing

Openstack.org is providing APIs and open source stack in the area of IaaS, Infrastructure as a Service. So it is more suited to service providers who want to provide virtualization to consumers or more like Amazon EC2 or rackspace like offerings.

Openstack also talks about using the same open source stack in enterprise as private cloud or private IaaS. This is in direct competition with Eucalyptus stack. But I think that openstack is much more advanced and also has lot of open source community support.

Here is the link for openstack.org - Openstack.org

Here is the link for Eucalyptus - Eucalyptus.com

Happy cloud computing :)

Tejas Bavishi

SaaS: Cloud based metering and billing solutions

There are few providers of cloud based metering and billing solutions around the globe. The solutions are very different by each provider, so it is difficult to compare product service provided by one provider to another.

In this scenario, the approach an ISV can take is to evaluate based on solution requirement, market good will and cost charged by the solution provider.

You can google and you will find few companies who provide such support.

It is also not difficult to build your own billing and metering solution based on how complex you want it to be.

Happy cloud computing :)

Tejas Bavishi