SOA What?
David Bressler of Progress Software, who acquired SOA vendor Actional in January 2006 wrote a very thought provoking post on marketing that really ended up being a post about SOA and where Progress fits into the "SOA continuum". He raises some questions, and problems, with SOA and product categories that ties in nicely with an excellent blog post on the subjectTodd Biske wrote a while back containing some concepts that he presented at Burton's Catalyst 2006. One of the confusing things about any market is the wide variety of names used to describe the products and solutions that fit into the wider technology landscape. There are a distinct set of SOA product categories, or SOA What as David calls them. The problem is that there is a lot of overlap in responsibilities between those categories. For example, SOA gateways and SOA management both provide a similar set of proxy-focused capabilities: content based routing, transformation, even service-enablement, but SOA gateways rarely include the robust monitoring and alerting side of management, choosing instead to integrate with existing network management systems (NMS) like HP OpenView or IBM's Tivoli instead. That makes it difficult to know what you're getting out of a SOA Management product, because it could mean a completely different set of responsibilities when coming from vendor X as it does from vendor Y. So after thinking about for a while, I think that by combining the David's SOA What categories with Todd's list of intermediary responsibilities we can come up with two distinct categories that makes the picture of the market a bit clearer and simpler. It comes down to products falling into two primary focus areas with regards to SOA services: managing them and delivering them. Delivery requires a different focus than management, and vice-versa. Delivery is concerned with protocols, security, and functionality traditionally associated with the network, while management is primarily service-focused, concerned with access, integration, and monitoring and, in the case of design-time governance, managing the service life-cycle. So maybe one of the ways of clearing up the muddy landscape in SOA-land is for vendors to give a clearer picture of their SOA "focus". For example, F5 is, in this model, clearly focused on SOA delivery and not management, and I'd argue that Progress' portfolio is primarily focused on management, not delivery, with some design-time governance and testing thrown in for good measure (now where does that fit??) I'm not sure if there's really a good solution to the issues raised by David but I think one way to start would be to delineate responsibility of intermediaries across the infrastructure. It certainly makes the picture a lot clearer and by associating responsibilities (and not features) with a particular category it's easier for someone to understand what a particular vendors' solution offers. Part of the problem is certainly getting on the same page and using the same language. What's funny about that is that one of the premises of SOA was to get business and IT folks using the same language to better align IT with the business. We need to apply that to the vendor and product landscape, as well, so as vendors we can better align our products with customer needs. If you want high-availability and load-balancing of services, you should be able to easily find a vendor focusing on SOA delivery and not wonder whether those delivery features available in a product that focuses on management or governance is going to be "good enough" or not. And vice-versa.Reliability does not come from SOA Governance
An interesting InformationWeek article asks whether SOA intermediaries such as "enterprise service bus, design-time governance, runtime management, and XML security gateways" are required for an effective SOA. It further posits that SOA governance is a must for any successful SOA initiative. As usual, the report (offered free courtesy of IBM), focuses on SOA infrastructure that while certainly fitting into the categories of SOA intermediary and governance does very little to assure stability and reliability of those rich Internet applications and composite mashups being built atop the corporate SOA. Effective SOA Requires Intermediaries via InformationWeek In addition to attracting new customers with innovative capabilities, it's equally important for businesses to offer stable, trusted services that are capable of delivering the high quality of service that users now demand. Without IT governance, the Web-oriented world of rich Internet applications and composite mashups can easily become unstable and unreliable. To improve your chances for success, establish discipline through a strong IT governance program where quality of service, security, and management issues are of equal importance. As is often the case, application delivery infrastructure is relegated to "cloud" status; it's depicted as a cloud within the SOA or network and obscured, as though it has very little to do with the successful delivery of services and applications. Application delivery infrastructure is treated on par with layer 2-3 network infrastructure: dumb boxes whose functionality and features have little to do with application development, deployment, or delivery and is therefore beneath the notice of architects and developers alike. SOA intermediaries, while certainly a foundational aspect of a strong, reliable SOA infrastructure, are only part of the story. Reliability of services can't be truly offered by SOA intermediaries nor can they be provided by traditional layer 2-3 (switches, routers, hubs) network infrastructure. A dumb load-balancer cannot optimize inter-service communication to ensure higher capacity (availability and reliability) and better performance. A traditional layer 2/3 switch cannot inspect XML/SOAP/JSON messages and intelligently direct those messages to the appropriate ESB or service pool. But neither can SOA intermediaries provide reliability and stability of services. Like ESB load-balancing and availability services, SOA intermediaries are largely incapable of ensuring the reliable delivery of SOA applications and services because their tasks are focused on runtime governance (authentication, authorization, monitoring, content based routing) and their load-balancing and network-focused delivery capabilities are largely on par with that of traditional l2-3 network infrastructure. High-availability and failover functionality is rudimentary at best in SOA intermediaries. The author mentions convergence and consolidation of the SOA intermediary market, but that same market has yet to see the issue of performance and reliability truly addressed by any SOA intermediary. Optimization and acceleration services, available to web applications for many years, have yet to be offered to SOA by these intermediaries. That's perfectly acceptable, because it's not their responsibility. When it comes to increasing capacity of services, ensuring quality of service, and intelligently managing the distribution of requests the answer is not a SOA intermediary or a traditional load-balancer; that requires an application delivery network with an application fluent application delivery controller at its core. The marriage of Web 2.0 and SOA has crossed the threshold. It's reality. SOA intermediaries are not designed with the capacity and reliability needs of a large-scale Web 2.0 (or any other web-based) application. That chore is left to the "network cloud" in which application delivery currently resides. But it should be its own "cloud", it's own distinct part of the overall architecture. And it ought to be considered as part of the process rather than an afterthought. SOA governance solutions can do very little to improve the capacity, reliability, and performance of SOA and applications built atop that SOA. A successful SOA depends on more than governance and SOA intermediaries; it depends on a well-designed architecture that necessarily includes consideration for the reliability, scalability, and security of both services and the applications - Web 2.0 or otherwise - that will take advantage of those services. That means incorporating an intelligent, dynamic application delivery infrastructure into your SOA before reliability becomes a problem.
