Oct 10 2007 4:19AM GMT
Posted by: Dilip Krishnan
SOA,
Web services
Just as with any service in our day to day lives; e.g. auto repair etc.; services in software also come with contracts and service level agreements between every service provider and consumer. As services evolve and consumers uptake newer technologies and services, it becomes very important to “label”/”certify” every service contract/agreement because this is what enables a service provider to guarantee support for a “certified” service and a consumer to depend on a “certification” and hold the provider accountable for honoring the same. Versioning is a mechanism for “labeling” service contracts in a machine readable form.
Every service oriented application lives in a service ecosystem. The size of a service ecosystem could be from a single application to multiple applications that use services as a means to scale. At the other end of the spectrum it goes all the way upto a set of composable services in the cloud e.g. Amazon’s Mechanical Turk Service or Microsoft’s Biztalk Service. The greater the exposure of the service to consumers the more fragile it becomes in terms of changes in service interfaces. Small changes in “primitive” services have the potential to cause ripple effect of changes that affect dependent services and ultimately the consuming applications. One way to define primitive services is that they are the smallest unit of reuse in a service ecosystem. Breaking changes to these services need to be carefully planned to minimize these ripple effects. In the next couple of weeks we’ll look concrete examples on how to version and manage the evolution of services in an SOA ecosystem.
Next time : Service Versioning - Contracts
Oct 2 2007 6:40PM GMT
Posted by: Dilip Krishnan
SOA
Service oriented architecture (SOA) has been around for a long time. Only it used to be called by different names. Its NOT a new technology, its only a way of thinking about the various pieces in an enterprise application landscape and how they interact with each other; an example of a technology is web services and it can be used to achieve service orientation, but the vice-versa is not always the best solution neither is it the only choice.
Service oriented applications are only as good as the business analysis that goes into defining the various business entities and processes. Its a way to discover business and process inefficiencies and articulate them in a manner thats a “living document” of the current processes. With globalization and the consolidation of business, a.k.a. mergers and acquisitions, its inevitable that business processes and rules associated with them constantly change over time. To keep up with the change is crucial to the success of organizations. SOA is a way to provide business agility, one of the key measures of a successful SOA effort.
Nick Malik has a great post titled “Beware of SOA in a box” where he talks about vendors tools for SOA and how it MUST align with business
“So when you decide to move to SOA, you will inevitably have to pick some tools and products to empower your implementation. In that process, look to insure that the vendor can tell you how to get from where YOU are to where THEY want you to be. Is that destination where your organization wants to go? Can you get in for a low cost? Can you measure value? If your choice doesn’t let you answer these questions… why pick it?
* Buying a tool that you don’t use… that’s bad.
* Buying a tool that forces you to make expensive changes to your process before you see value… that’s worse.“
He is right-on about the questions companies must ask themselves before investing in tools. Just as object oriented analysis provides encapsulation, modularization and reusability in software development; the principals of SOA provide to business processes. Technologies that enable service orientation are only a means to an end and need to adapt to businesses not the other way around.
