|
|
|
Features
< Back
Sarbanes Oxley : Technology : Business Process Management
Using XML Appliances to Simplify, Secure, and Scale SOA
By
Scott Morrison
|
|
Scott Morrison
Director of Architecture
Layer 7 Technologies
|
SOA Solves Business Problems
Service Oriented Architecture (SOA) is gaining momentum. Analysts hype it up endlessly, vendors insist their products support it and pundits write about it, lecture on it, and even make a decent living consulting around it. But, for all this attention, what is SOA and does the infrastructure exist now to build one?
Perhaps it is easier to declare what SOA is not; SOA is not about technology. Rather, it is a style of designing systems so that IT is more responsive to the continually changing demands of business. This goal isn?t new; it is as old as an abacuses and slide rules. What makes SOA revolutionary is the underlying acknowledgement that IT follows business and that business is its fundamental reason for being. That SOA is not a technology is the critical insight. CORBA was a technology. Integration brokers are a technology. Enterprise Service Buses (ESBs) are?perhaps unfortunately?becoming defined by technology. SOA, in contrast, is an approach, a philosophy, and ultimately, a goal.
With SOA comes a change in perspective.
Applications do not matter?and machines even less. The focus of the service-oriented architect is on business services; loosely associated functions that are easily composed to solve problems. A service might be an entire application (currency trading) or simply a useful component of one (the currency conversion module). What is important is that this becomes defined, encapsulated, and made available as a building block for larger, distributed applications.
What makes SOA different from any number of process re-engineering fads of the last few decades is that SOA has emerged lockstep with a solid technological underpinning that realizes its promise. XML messaging and Web services in particular are the technological instances of the basic SOA concept. These provide the standardized plumbing to integrate the hodgepodge of systems, applications, and networking infrastructure that are the unfortunate legacy of most modern IT shops.
It is at the Web services layer that one needs to think about the real problems of firewalls and operating systems or routers and languages. Decisions here need to be made under the guiding hand of a SOA. Implementation needs to drive toward the goals set by this approach. By doing so, SOA serves the needs of business.
XML appliances are a new class of product designed specifically to manage the day-to-day challenges of rolling out XML applications and Web services allowing IT organizations to create a true Service-Oriented Architecture. These have emerged as the critical piece of infrastructure underpinning the corporate SOA.
Why an Appliance?
XML appliances reside between senders and receivers of information. Using Web services, a caller of a service does so using specifically formulated XML documents. For example, a commerce website built on SOA principles might use a third-party credit card validation service and a centralized shipping service. Under an SOA, a business decision such as moving toward de-centralized shipping distribution centers (e.g. country-based distribution points) should only require a change in message routing; sending requests to a remote shipping service instead of the local, centralized instance.
If senders and receivers communicate via an intermediate rather than directly, either side can become insulated from extraneous details and largely immune to localized changes. This helps to foster a quality called loose coupling between the communicating parties, which is desirable in an SOA. Applications composed of collections of loosely coupled services are simpler to design and maintain, and most importantly are more responsive to change.
There are a number of good arguments for implementing intermediary functionality through appliances rather than as software deployed on existing servers. The most compelling is performance. XML appliances need to accommodate very high transaction rates to be effective. In a large organization with high message volumes this is only achievable with purpose-built hardware that accelerates operations such as cryptography and XML document processing, both of which greatly tax general-purpose CPUs, but lend themselves to high-performance implementation in specialized silicon. XML appliances that lack XML acceleration functionality arel not be able to meet the processing demands when SOA becomes ubiquitous in an organization.
Related to performance is scalability. XML appliances must cluster to be scalable and manageable. As load increases, additional hardware appliances can be added and automatically integrated into the running SOA without imposing additional management. Appliances stack easily in equipment room racks alongside router infrastructure, conventional firewalls, and other mission critical communications components. Because they are contained physical units that already have factory-installed functionality ready-to-go, integration is usually as simple as setting a few local network parameters and connecting a few cables.
Another important consideration is security. In most organizations, the initial role of XML appliances is to manage the security challenges of Web services, so clearly, the appliance itself must be secure or the entire security model becomes suspect. An appliance allows complete lock down of the environment hosting this security application, done by experts in this discipline. Constructing a similarly bulletproof operating environment on a general-purpose application server customized for every installation is simply not feasible. Furthermore, the very physicality of an appliance encourages better security practices. Appliances are invariably deployed in secure data centers and feature tamper-evident packaging, which is critical for high-security applications using cryptography and public key infrastructure (PKI).
The final consideration is simple manageability. Physical appliances that cluster effectively are much easier for network operations personnel to manage on a day-by-day basis. If an appliance fails, the other cluster appliances assume the load automatically. New appliances can join the cluster at anytime and synchronize with the current operational policies. This is vastly superior to software-based solutions a their dependencies on operating system configurations, patch levels, application servers and databases.
Simplifying SOA
We have already observed that the decoupling between senders and receivers is a basic tenet of SOA. XML appliances support this in application networks by insulating each side from dependencies by the other. XML appliances can dynamically route messages achieving complete location independence between clients and servers. This permits organic reconfiguration of networks to accommodate changing loads, differing security requirements, or simple redundancy and failover. Removing routing interdependencies simplifies applications and contributes to reuse and re-composition.
Effective management of complexity has always been the greatest challenge in IT. Arguably, this is why SOA exist and XML appliances are a concrete means to achieve it. Centralizing functionality such as routing, transformation, and security enforcement into an XML appliance cluster provides a high-level architectural/operational view of the running service oriented network. This simplifies management, encourages agile deployment of applications, and advocates a consistency that is essential in a modern security network.
SOA is about integrating distributed functionality and XML appliances play a critical role.. XML appliances provide accelerated data transformation, which is a requirement to reconcile differing views of data. Consider something as simple as naming data fields. One application wants to make queries for productID, the database application holds this, but calls it an SKU and will only respond to queries for this name. The best practice here is to map this field at runtime on an intermediate XML appliance and thus integrate the applications immediately and unchanged. This is a better strategy than physically modifying one application or the other, which might break other hidden dependencies. The former leverages loose coupling; the later builds dependency in code, tightens coupling, and discourages reuse and re-composition.
Securing SOA
The soul of good security is consistency. Give five developers the same security challenge and you will receive five different implementations?all slightly different; some better, some worse. System crackers exploit the weak implementations. Good security is security applied the same way, everywhere.
XML appliances implement and enforce this consistency by extracting security from applications, centralizing it within hardened processors, and providing declarative management tools to promote visibility, audit, and enforcement. Security becomes the responsibility of a dedicated corporate security officer, not a continuously changing group of employee and contracted developers.
In the security role, XML appliances act as a Policy Enforcement Point (PEP). Policy here gathers all the security-related functions that are applied to a stream of XML exchanged between two applications. Privacy, integrity, authentication, authorization, and audit are all critical components that an XML appliance manages.
Nevertheless, an appliance cannot act in isolation. It is clear that it must integrate with existing investments in an organization?s identity infrastructure including such diverse elements as directories, access control systems, single sign-on, and PKI. A basic characteristic of an XML appliance in an SOA is its ability to leverage a wide variety of existing infrastructure.
Technologies like Web services are not just about the integration of applications. They are also about the integration of security models. Few large organizations have the luxury of a single central identity infrastructure. Diversity is much more common. How do you integrate a Windows client with a Kerberos token to an HR system requiring SAP credentials? Integrating security models is an area where XML appliances demonstrate value. They immediately provide the mapping and transformation functions to bring about these types of integrations without costly redevelopment and adaptation of existing applications.
Scaling SOA
Organizations often approach SOA cautiously. They study it, court vendors, and flirt with Proof of Concepts. But every good architect is mindful of scaling. If SOA is successful in an organization, will the infrastructure that supports it be able to scale effectively?
Well-designed XML appliances will scale, but it is not as simple as some vendors might want you to believe. Appliances should first address vertical scalability; that is, offer a range of different models with different performance and feature characteristics. There needs to be a clear upgrade roadmap accommodating the inevitable new developments in processor technology. In this game, Moore?s Law is your best friend.
Horizontal scalability, achieved by adding additional appliances and balancing load between them, is another attractive strategy that has the additional benefit of fault tolerance. However, this is where technology can come up short. Deploying multiple XML appliances behind load balancing infrastructure is a common design pattern; however, you need to ensure the appliances have clustering capabilities to provide the manageability and security gains that are essential in a large deployment. Horizontal scalability only works when clusters instantly and automatically distribute policy changes among all members. Cluster management is only effectively when a single monitoring and management console aggregates all appliances into a virtual whole. Clusters are only secure when appliances coordinate among themselves to defeat simple attacks like replay of messages. Clusters are only effective at enforcing SLA when transaction rate and status information is available to all cluster members simultaneously so they can make instantaneous decisions about permitting a transaction to proceed. These are arduous demands but in order to successfully scale an appliance-based SOA infrastructure, they must be addressed.
Regardless of the approach to scaling, migration among different environments presents unique challenges. At minimum, most large organizations will host separate development and production environments. Many even provide several staging environments to validate new applications or infrastructure configurations before permitting them to travel up the chain on the way to production. Applications and infrastructure need to be enable this model, not impede it. XML appliances can help here. They must support partitioning and virtualization so that multiple, separate environments can be hosted on a single physical device; making more effective use of existing resources. Furthermore, XML appliances must provide migration utilities that push configuration and policy options up to the next environment making deterministic changes where appropriate (such as mapping IP addresses for the test lab to their equivalents in production). The goal is to automate these tasks to the greatest extent possible in order to minimize the chances of unscheduled downtime due to operator errors introduced during migration.
The Plumbing That Makes SOA a Reality
If you were to ask a real architect?that is, one who designs buildings, not computer systems?to define modernism, they would likely talk about approach, philosophy, historical precedents, style and feel. They wouldn?t talk of materials or construction techniques, except where these specifically contribute to the movement. But, it is the materials and how they are applied that ultimately constructs the building that stands as a concrete example of the goals that modernism strove to achieve.
So too, with SOA. XML appliances are becoming an essential infrastructure element that is necessary to build a SOA. Just using these does not make an SOA; but applied within a greater initiative, they help to realize the architecture just as concrete, steel and glass did for many of the great buildings of the last century.
Scott Morrison
Director of Architecture
Layer 7 Technologies
Scott Morrison is the VP of Engineering and Chief Architect at Layer 7 Technologies, where he is leading a team to develop the next generation of security infrastructure for Web services.
An architect and developer of highly scalable, enterprise systems for over 15 years, he has extensive experience across industry sectors as diverse as health, travel and transportation, and financial services. Scott has also been a director of technology at Infowave Software, a maker of wireless security and acceleration software for mobile devices, and held senior architecture positions with IBM.
Before shifting to the private sector, he spent a number of years at the world-renowned medical research program of the University of British Columbia, studying neurodegenerative disorders using medical imaging technology.
Scott is a dynamic and highly sought-after speaker. He has published over 40 book chapters, magazine articles, and papers in medical, physics, and engineering journals. He is the recent co-author of Java Web Services Unleashed, and Professional JMS.
His current interests are in Web services security, secure mobile computing, grid systems, and enterprise system architectures. Scott is currently active as one of four co-editors on the WS-I Basic Security Profile.
Scott holds a Bachelor of Computer Science degree (honours) from Simon Fraser University.
|
|
|
|
|
