To make up for those inadequacies, Boubez is urging organizations to adopt the concept of "policy driven" SOA as the new contract abstraction for SOA. "Policy is that extra abstraction layer that decouples services from their implementation, and that decouples not just service providers but service requesters: applications that request services from the same kind of infrastructure and security model and all that extra stuff that you need in the real world," he says.
The only way to architect and implement secure and flexible SOA is to find ways to mediate interactions between services based on a declarative and remediable policy language. Coding interaction policies between services results in brittle SOA infrastructures that cannot accommodate changing security and business needs.
Done right, Boubez says, a policy layer helps ensure SOA can finally start addressing business goals.
There are two main business drivers for SOA: growth and increased productivity. Inside the organization, enterprise application integration (EAI) has played an essential part in increasing productivity by allowing systems to integrate so they work better and faster and empowering users to do more and better things. Externally, integration with partners has been essential for growth: the more people and companies you partner with, and the more services you can offer your customers, the better.
However, as business continues to pursue the goal of making IT more of a strategic tool and less of a necessary evil, SOA also plays into major corporate or strategic goals like the push for flexibility and agility, which requires organizations to excel at integrating with internal and external resources as needed. Flexibility means being able to easily add and change system integrators and the IT platform, while avoiding vendor lock-in. And it means establishing what Boubez calls "one-time configurable ITN policies" that allow changes in partnership agreements, for instance, to be made simply and quickly.
As organizations pursue easier, cheaper and more logical ways to build applications and unite the silos of functionality, the concept of just-in-time integration, a technique for combining new functionalities as quickly and cheaply as required, whether internal or external to the organization, has risen in importance.
"From the architectural perspective, just-in-time integration is a cornerstone of service-oriented architecture," Boubez wrote recently. "Under SOA, applications consist of aggregations of calls to services. Services are simply coarsely-grained functions that are made available to invoking applications using a consistent semantic. They might encapsulate a well-defined unit of business logic, a legacy application or an interface to a data gathering system. What a service does is not a concern of SOA — how it is made available is. One of the fundamental principles of SOA is the idea of loose coupling. Loosely-coupled systems exhibit a flexibility such that a change effected in one component of the system does not break the rest of the system.
"To achieve this, SOAs typically provide a mechanism to publish services and a means for consumers to discover and invoke them dynamically. Web services is an SOA enabling — composed of technologies like SOAP, WSDL and UDDI — that has the unique characteristic of being based on open standards and being independent of the deployment platform. This is in contrast to other SOAs, such as Sun's Jini, and alternative distributed application technologies, such as OMG's CORBA or Microsoft's COM+. But despite the media triumph of Web services, we still have a long way to go from this basic set of technologies to the end goal of just-in-time integration," Boubez says.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.