TMCnet News
What's Next For SOA(Information Week Via Thomson Dialog NewsEdge) The SOA intermediary market is going through rapid consolidation as startups seek to expand beyond their niches and larger players offer suites that claim to cover all of a business' service integration needs. The consolidation is driven partly by the inherent overlapping functionality of traditional SOA intermediary products and partly by the extension of vendors from other market categories into the SOA arena. There are four main types of SOA products: Enterprise Service Bus, design-time governance, runtime management, and security gateway. The functionality of all four has always overlapped somewhat, though each still has certain unique characteristics not found in the others. The most mature is ESB, which shuttles data between services. The least mature is governance, a combination of a catalog and a source code management system. Both are almost always provided as software. SOA management systems and security gateways are the equivalent of network management frameworks and firewalls, respectively, and can be provided as either hardware or software, sometimes from the same vendor. In addition, the growing importance of SOA is encouraging vendors from other market categories to enter the field. On the software side, business process management has always been closely related to SOA, as is the emerging field of complex event processing (CEP). The rich Internet applications (RIAs) of Web 2.0 are driving interest in Web services. On the hardware side, networking players are also moving into SOA, particularly in the areas of management and security, usually through application front ends (AFEs), hardware that can accelerate important functions of all four product categories. ENABLE AND ORCHESTRATE The ESB has two core functions, both of which have been critical to application integration: service enablement and service orchestration. Service enablement happens at the lower level. It means a collection of interfaces that translates the different APIs of mainframes, ERP systems, CRM servers, and other devices and applications into a common language so that they can talk to each other. At a higher level, the ESB can combine the newly exposed services into new applications, known as composite applications. Multiple standards mean that service enablement is usually still necessary even as application platform vendors adopt native Web services interfaces, though it can sometimes be avoided in a single-vendor environment. In addition to ESBs, service enablement is also available in some design-time governance products, as well as specialized integration packages. Orchestration overlaps somewhat with BPM, and many vendors offer integrated products, though so far there's little standardized communications between BPM suites and ESBs. Between the two core ESB functions are translation features, required by most SOAs that link together applications running on multiple platforms or from multiple vendors. These also can be provided by runtime management suites and fall into two main categories: XML transformation and protocol mediation. Both involve converting between data formats and protocols, XML transformation at the application layer and protocol mediation lower down the stack. For example, many enterprises use Java Message Service internally, which must be converted to Web services when traversing the public Internet. In addition, ESBs generally include content-based routing, which refers to routing based on XML elements or other application data rather than network addresses. This is also offered by runtime management and can be accelerated by the dedicated XML hardware and software within security gateways. Increasingly, AFE vendors are offering content-based routing, seeing it as a natural extension of load balancing. Because SOA is such a major undertaking, early ESBs were used only by very large enterprises. They're now becoming commoditized thanks to open source options and their incorporation within other products. An ESB is already a standard offering from application platform vendors and is likely to become one within BPM suites. To address this, ESB vendors are moving higher up the stack to BPM, CEP, and RIAs. GOVERN BY DESIGN In principle, SOA governance means ensuring that services are aligned with business processes, from the moment they're first planned to each time they're accessed by a composite application. In practice, most SOAs involve retrofitting Web services to legacy apps, so most vendors focus more on development than implementation. SOA governance covers two core areas, usually addressed by the same vendors, though often in separate products. The first is the repository, a database that keeps track of every service within the SOA, along with associated metadata and information about policies. Business rules that mandate steps to be performed can be created, but intervention from human developers and testers is still required. Because the repository is so closely involved with the development life cycle, most governance vendors also offer some form of service enablement, and it also overlaps with non-SOA code management products. Second is the registry, a catalog of all available Web services. It can be queried by developers at design time or by applications at runtime, making it more generally applicable than the repository. As a result, other types of vendors, such as ESB and runtime management, are likely to begin offering UDDI functionality even if they aren't at present expanding into full-scale repositories. Governance is the least-mature product category within SOA because dedicated products are needed only in relatively large deployments. It's a likely target for expansion from ESB and Web services management vendors looking to add value, though it may splinter as each targets a different part: ESBs come from the application development world and so are more likely to expand into the repository, while management platforms are more likely to offer the registry. MANAGEMENT CHALLENGES Runtime SOA management has its roots in Web services, so most products are also intended to be used in point Web services deployments that have not been put together in a SOA. As a result, they offer much of the same routing and processing functionality as an ESB. They rarely offer service enablement; everything they deal with is already a Web service. However, the SOA management suite's most important task is service monitoring: keeping track of all the Web services within a SOA. This is important for regulatory and policy compliance, as well as for troubleshooting and to ensure that service-level agreements are met. In a complex SOA, Web services will depend on other services, so management platforms need to track dependencies and understand how one service impacts another. Monitoring can be achieved in three ways. The one that usually offers the best visibility into applications uses agents that are embedded on an application platform or ESB, running alongside services. The disadvantages are that a separate agent must be written for each program and device that's managed, and that it only works within a single enterprise. When an agent can't be run on a platform directly, it can run on a proxy sever through which all traffic is routed. Proxies are easier to scale but can impose a hefty performance hit. A third and newer management architecture avoids agents entirely by accessing native APIs, but this system depends on vendor partnerships. Web services exposed to the Internet need security features that aren't found in ESBs designed for use safely behind the firewall, so most SOA management products can also handle encryption, decryption, digital signature, and AAA (authentication, authorization, and accounting). This functionality is usually found in security gateways, so it has brought gateway vendors into the management area, offering hardware systems that compete with the traditional software approach. Web 2.0 has given the ESB management category a new lease on life, as many RIAs function without an underlying SOA. Such deployments may evolve into more complete SOAs that require an ESB, but there will remain a place for standalone management tools. SECURE THE GATE Security gateways started out as XML accelerator appliances, designed to take the load off systems burdened by bloated, text-heavy XML messages. They can still provide many of these functions, speeding up content-based routing and proxy-based management. However, vendors soon found that the killer app for XML appliances was security, thanks to fears that Web services messages were carrying threats straight through the corporate firewall. As a result, standard firewalls have become application-aware. An XML firewall goes even further up the stack, reading the contents of XML messages to determine whether they are a threat. Because RIAs often use non-XML formats or invoke commands through protocol headers, XML firewalls now need to look beyond XML, examining all application-layer traffic. At present, security gateways are the only products that can provide XML firewall functionality, though AFE vendors are entering the market. Security gateways also are designed to perform other Web services security functions, including XML encryption, digital signature verification, and AAA. They compete with or augment runtime management software. Gateways can also help with lower-level security protocols such as Secure Sockets Layer, though here they're up against AFEs and ordinary firewalls. Although they started out as hardware appliances, security gateways are increasingly being provided as software, with several vendors offering virtual appliances. The switch is also prompting some to move into Web services management and SOA governance. Hardware XML firewalls increasingly will be embedded inside the network infrastructure, supplied by AFEs that can also provide hardware acceleration of other SOA functions. Get the full-length report at: businessinnovation.cmp.com/bizagility Copyright 2007 CMP Media LLC. All rights reserved. Copyright 2007 CMP Media LLC |