[service-orientated-architecture] Epperson on SOA & High Performance

[Gervas Douglas]

SOA and High Performance by Dirk Epperson, Kabira Tuesday, October 24, 2006 In the last few years, there's been explosive growth in message volumes, in particular with online billing, digital transactions, and micro-payments in financial services and telecom. At the same time we are seeing rapid adoption of SOA-based systems. But can businesses that demand high performance from their systems realistically deploy an SOA-based system? Ask any developer with SOA experience: it's well known that popular Web Service protocols -- in particular the default implementation of Web Services as SOAP over http -- are not designed for high performance environments, e.g. banking and telecom systems that must reliably process thousands of messages per second. Current SOA deployments are at risk to reliably handle major traffic volumes that are the status quo in today's mission critical environments, let alone be expected to manage the dramatic growth expected over the next few years. Indeed, industry analyst Gartner, Inc. estimates that by 2010, more than 20 percent of new transactional applications will express at least high-end transaction processing requirements for scalability (greater than 10,000 concurrent accesses) and performance (greater than 500 transactions per second), up from less than 10 percent in 2005. (Gartner, Inc. "Architecture and Platforms for Extreme OLTP," Massimo Pezzini, December 2005.) Unless and until we have high performance standards for Web Services, SOA will never become a standard architecture for demanding applications. The answer is a service-oriented approach to transaction processing, which is ideal for today's SOA-based business applications and services that require flexibility, scalability, reliability, and maximum performance. The good news is that the technology exists today to make this a reality. However, that technology will not come from SOA stack vendors who today provide a default Web Services implementation of SOAP over http. As it's defined today it is insufficient for high performance applications. First, the transaction system needs to be SOA-compliant. There are various definitions of what "SOA compliant" means, but the key elements Gartner talks about are: *The transaction system needs to be looked at as a series of modular services. *The system should utilize request-response processing. *Each service should be abstracted from the client to enable loose coupling. *SOA does not require a specific protocol between a client and service. Only the definition of interface is required. *Services need to be designed to be useful and usable by other applications *An organization's top level of services should be usable from outside the organization. Next, to truly achieve high performance, SOA services need to demonstrate mainframe level characteristics. These characteristics include large scalability "up" -- to take advantage of multiple CPU's or blades, and multiple cores per chip -- and "out" across multiple nodes as well as high availability, high performance, large memory footprint and load balancing. The system should be able to take an easy-to-use Web Services interface -- let's use SOAP over http again -- and recast it in another high performance protocol technology to provide high speed processing. A robust transaction system will allow users to leverage faster protocols for high speed needs, such as payment processing, and still be able to use default Web Services for medium to slow speed requirements, such as customer data queries. Further, companies will have more robust results if both the Client and the Service of a given interaction are both high-performance implementations. That configuration will optimize the protocol to provide high performance on up to "ultra high performance" for companies with the greatest demands. However, merging the concepts of SOA and high performance does not completely solve the problem. Another major requirement for today's transaction systems is business agility, one of the core reasons to implement an SOA. The rapid advances in digital technologies force businesses to constantly update their offerings, roll out new services and maintain or improve service levels to remain competitive. But for organizations relying on last-generation proprietary or hybrid transaction processing technologies, scaling to compete in the real-time arena becomes steadily more difficult as their IT infrastructure ages. The result is that the expense of maintaining quality eventually dominates available resources making expansion or creation of new services out of the question. We don't have to look far for real life examples of where the need for agility and high performance collide. Financial services and telecom have already invested significantly in SOA strategies yet now face some of the most complex and demanding high performance transaction challenges. For example, business models in the financial services and payments industries are under stress as the global economy becomes ever more reliant on digital transactions. The need to process payments in real-time is forcing acquirers, payment processors and exchange networks to re-evaluate their infrastructure requirements. By deploying a high performance, SOA-compliant platform, financial services firms could have the power to address four key requirements: *Service higher transaction volumes in real time; *Deliver high availability, providing zero down time; *Reduce IT maintenance costs, therein keeping pace with the need to drive down the cost of transactions; and *Have the flexibility to shorten time-to-market for new service offerings. Consider telecom: Providers need such a solution to open up new business opportunities and create competitive differentiators by enabling them to optimize response time and throughput in their services, provisioning and mediation systems. Indeed, many telecom operators are in the oxymoronic position of looking for the "killer" services application to increase Average Revenue Per User (ARPU), but are terrified that a wildly popular service will bog down parts of the network, because the service cannot scale to meet the demand. The oncoming telecom convergence will place unavoidable demands on existing infrastructure. Quadruple services that rely on greater interactivity like video on demand and gaming will increase the complexity and number of transactions to be securely processed. Also, as providers move towards needing to deliver the same quality of service to pre- and post-paid customers, these complex transactions need to be processed in real-time to enable service innovations like online charging and billing. On a positive note, telecom operators have collaborated to rework the older, heavyweight protocol for service delivery, called Parlay, into a new lightweight SOA protocol called Parlay-X. This standard is much easier for third-party service providers to understand and implement, but the current XML based version has a reputation of being too slow for anything but simple trials. Overall, adding SOA capabilities to telecom's high performance standards would provide: *Real-time performance to deliver flexibility and rapid time to market for the convergence of prepaid, postpaid, and other new services increasing the ARPU. *Faster time-to-revenue by leveraging flexible, fully configurable meta-catalogues and workflows, and rapid deployment of third-party content providers. *Rapidly integrated new service applications and network inventories and elements. To conclude, it's important for developers, functional managers, and business executives to realize that an SOA can succeed in a high performance environment. And for SOA deployments to flourish, they must be able to succeed in these situations. Companies need to break out of the siloed, concrete-like computing models if they are to meet the growing demands of their customers and compete effectively in the next decade. But they cannot sacrifice high performance to gain flexibility. The good news is that this is not an either/or situation -- you can have both. Dirk Epperson co-founded Kabira Technologies in 1996. He holds a Bachelor's degree in physics from Harvey Mudd College and a Master's degree in engineering from Yale University. You can find this article at: http://www.line56.com/articles/default.asp?articleid=7978     Gervas   __._,_.___ SPONSORED LINKS Computer software Computer security software Computer software program Computer fax software Computer virus software Your email settings: Individual Email|Traditional Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___