It's hard to turn anywhere today without seeing something about service-oriented architecture, or SOA, and a debate about the "right" way to do it. That's not surprising, I guess, since every new computing trend generates debate and every vendor tries to promote their technology as the right technology – the right product – that will allow customers to take the most advantage of a new approach. It's a scramble as vendors try to aggressively reposition their existing product suites to take advantage of customer interest in a hot IT trend. It's unfortunate, though, because this behavior often creates a lot of confusion and potential disillusionment, as promises made often do not turn into promises kept and technology solutions sold as appropriate for SOA may turn out not to be.
To set the right perspective on this, it's important to note that SOA is, by definition, distributed. The purpose of a service is to communicate remotely with another service, typically to share data. The purpose of an SOA is to change the approach of IT from building bespoke, monolithic applications to building applications that are developed and integrated more and more using assets from a collection of shared, reusable functionality, i.e. services.
A distributed SOA infrastructure represents the easiest way to deploy and consume shared, reusable services, facilitating incremental adoption (both economically and technically) and enable greater deployment flexibility, adaptability and maintainability (e.g., single services can be certified for update more easily than an entire application).
Unfortunately, centralized approaches to SOA infrastructure continue to be developed and proposed. Vendors will go to great lengths to convince the technology buying public that what they're offering is already SOA compliant, always was, always will be and was truly designed from the beginning to facilitate their customers' move to SOA, no matter whether it was originally designed to be a JEE application server or EAI system.
In other words, vendors taking an opposing view to distributed SOA infrastructure often do so because that's the nature of the software infrastructure they already have. A refried EAI hub or JEE-based stack or any other solution that requires request messages to be passed through a central control point, cannot be considered truly distributed since all access to services must be routed through a central hub or a server. This centralized approach to SOA adds cost, limits reuse, reduces flexibility and introduces a potentially expensive bottleneck. In the worst case it could even negate the reasons for moving to SOA in the first place. People are bound to be disappointed if the flexibility of their SOA infrastructure does not meet their requirements.
One only has to look to the World Wide Web to see an example of a distributed application that very successfully meets its users' requirements. The Web is the largest distributed application ever built and it's distributed by nature, like an SOA should be. When you use a browser to click on a link to a URL, your request is not routed through some kind of central controlling authority deployed in a server or a hub. Your request goes directly from your browser to the Web server hosting the page you have requested. This approach works fine for the Web and it also works fine for an enterprise's SOA. Web endpoints can be updated individually without breaking clients, affecting other sites or requiring any update to a central hub or server, since requests do not have to pass through one in the first place. A good SOA infrastructure also supports these capabilities.
Fortunately, an infrastructure solution exists that embraces the distributed nature of SOA. The distributed approach to SOA infrastructure uses smart endpoints that service enable applications and allow them to find and directly communicate with other services. Enterprise qualities of service, such as high availability or advanced security, can also be included in the endpoints to preserve the capabilities upon which existing mission critical applications rely. Distributed SOA infrastructure is about creating an IT environment that is platform neutral, standards-based and highly flexible, so that it can respond better to an ever-changing technology and business landscape. A distributed SOA environment is therefore better able to support the technical and economic requirements of an SOA based application. Finally, a distributed approach to SOA infrastructure allows you to move at your own pace, deploying services one or two at a time, adding features such as orchestration, registry/repository, management and so on as needed and not before.
I'm not saying that EAI systems, hub and spoke based applications or JEE server centric approaches to SOA infrastructure are all bad or wrong. Many times existing corporate application functionality depends upon one or more of these implementation styles. All I'm saying is that a good SOA infrastructure shouldn't constrain your design options to what any one of these things can do – in fact a good SOA infrastructure embraces and includes them among the collection of reusable service assets.
A parallel between the benefits of distributed SOA and the airline industry can be seen in the way in which the low-cost operators are challenging the established carriers. The approach of the established operators is based on an expensive hub and spoke model that funnels passengers through a small number of dedicated travel hubs. Large planes that cost more to operate, fly from spoke airport to hub airport, where passengers are processed for further travel to their final destinations. In this model the planes cost more to operate and airport facility charges are higher. With the rise of low-cost airlines, which operate on a more distributed, point-to-point model (smaller planes directly flying to smaller airports), the airlines that are tied to the traditional hub model are taking a significant financial hit.
SOA customers do not need more of the same old bloated and expensive software stacks. Customers need better software specifically designed for the requirements represented by the SOA trend – to improve the way in which existing (and new) IT functional assets are provide to applications. SOA designs need a good way to create and deploy reusable services that can be called upon simply and directly when and where needed. Customers need low cost options that allow them to start small with incremental adoption, using point-to-point communication solutions that avoid expensive new servers and hubs, adding quality of service and other features as required. In short, they need SOA infrastructure that really meets the inherently distributed nature of an SOA.
