How to apply SOA principles to traditional web application architecture

I promised kudos and comments last week for Ronald Schmelzer's ZapNote on the requirement for a service proxy in SOA implementations and so I shall right now.

While Ron didn't come right out and say it, a major reason the service proxy is an essential component of a successful SOA implementation is that it protects the concept of loose-coupling, a primary foundational principle of SOA. Loose-coupling is generally applied to consumer-producer relationships and essentially requires that there be no code or logic on the consumer (client) that binds it tightly to the service, such as an IP address or security policies. Loose-coupling allows SOA architects to modify services without interrupting the availability or functionality of those services. Loose-coupling also enables reuse by preventing application or process specific logic and policies from being hard-wired into a service.

Loose coupling essentially requires that a service provide just the basics - the business logic - and nothing else. Security policies and processes exist outside the service, and should be applied at run-time through meta-data such as BPEL (Business Process Execution Language) or WS-Policy documents. If you are hard-wiring security policies or transformations into a service you may find later that you've lost the ability to reuse that service in another application or process. Worse, you may find you can use that service again, but you need to modify it to work with your new application which lengthens the development and deployment lifecycle and eliminates the benefits typically achieved through reuse - time and money. As Ron pointed out, tying a consumer (client) to a service (server) is a Bad Idea. A service proxy should be a requirement in order to unlock the full potential of your SOA initiative, and to protect your investment in your new architecture.

Loose-coupling is easily achieved by implementing a service-proxy because the intermediary then becomes the point at which security policy is applied, or processes are orchestrated. Because almost all service-proxies are full proxies, the consumer speaks only to the proxy and never to the services themselves, which maintains the ability to move and modify services without interrupting availability of those services.

I could basically rewrite Ron's treatise as "Why Web Clients and Web Servers Should Never Directly Communicate" with very few modifications because most of the principles contained therein are just as applicable to web applications and application delivery architecture as they are SOA. But rather than do that, I'll just offer up the Reader's Digest Condensed version.

Loose-Coupling for Legacy Apps

Application delivery controllers like BIG-IP have always offered a mechanism for implementing loose-coupling of "legacy" web applications, we just didn't have the cool jargon to apply to the concept.  We used to use the term "application proxy", which admittedly is just not as cool as "loose coupling". Regardless, an application delivery controller is essentially a proxy for your web applications. Clients never talk directly to the application, they talk to the application delivery controller, the proxy. That proxy applies security policies and transformations like URL rewrites before sending the client's request onto the web application. The proxy also performs load balancing functions, and can easily apply content based routing rules to direct client requests to the appropriate application or server.

An application delivery controller sits in the middle of clients and your applications, and makes it easy to perform upgrades, change applications, or apply new security policies without interrupting availability and without requiring changes to the client or application. One of the benefits touted by SOA that is enabled by loose-coupling is the ability to change or upgrade a service without notifying the client. The client should automatically react to any changes as published through the WSDL (Web Service Definition Language) or, more appropriately, the service proxy reacts to those changes so the client need not worry. An application delivery controller performs the same function by masking the actual server on which applications reside. Even if the application changes, the client need not worry because it communicates only with the proxy, the application delivery controller, and not with the actual application.

Upgrades can easily be performed and the application delivery controller can immediately begin directing requests to the new version without interrupting availability of the application. New security policies - changing authentication servers from AD to LDAP, for example - can be applied by the application delivery controller, which means neither client nor application needs be modified.

An application delivery controller an also act globally - a scenario in which the similarities between SOA and application delivery architectures becomes even clearer. A client request is routed not to a server, but to a site, based on a variety of parameters such as availability, location, and required response time. In this scenario, each local application delivery controller acts more like a service, while the global application delivery controller acts like a service-proxy, evaluating a number of factors to determine where a client request should be directed, if at all.  

Application delivery controllers with the capability to execute scripts on requests can provide capabilities similar to transformations achieved via XSLT (eXtensible Stylesheet Language Transformations). Some languages are more robust than others, providing the ability to insert, remove, and modify every aspect of a request - from header to application data. And like orchestration engines such as found in ESBs (Enterprise Service Bus) - a common service proxy inside the data center - some scripting languages can provide conditional routing and processing directives based on application and transport layer (TCP) data. Like the capabilities associated with a service proxy, these transformations can be added, removed, and modified at any time without interrupting service availability and without requiring changes on the client or application server. Sure, you could perform those transformations within the application, but then you're locking that application down and requiring coding and testing to change it, coding and testing that lengthens the development cycle and increase the time needed to deploy as well as the costs associated with development efforts.

Loose-coupling as a term may be peculiar to SOA, but the concept behind it - and its benefits - are just as applicable to non-SOA applications and easily implemented through the addition of an application delivery controller to your architecture. The ability of an application delivery controller to act as an enforcement point as well as a full proxy offers loose-coupling for legacy web applications. This results in the ability to reap many of the benefits of a SOA implementation from a traditional web application architecture.

Imbibing: Coffee