News, Press, & Events

SOA success depends on a SON

July 7, 2006 - Reach Magazine, Jeff Browning

Jeff Browning, director of product management for F5 Networks, looks at how network technology has evolved to better support service oriented architectures, and why incorporating a service oriented network is critical for SOA success.

Service oriented architecture (SOA) represents the most significant transformation in IT application architecture in the past 10-15 years. It affords new levels of agility and flexibility over legacy architectures by resolving the complexity and inflexibility of traditional middleware through open standards and a more loosely coupled approach to designing, developing, and deploying applications.

While much attention is given to the application side of SOA, an oft-overlooked ingredient needed to ensure its successful delivery is the underlying network infrastructure. As important as the application tier is, a new, service-oriented network (SON) approach is crucial to providing a nimble infrastructure that can accommodate the agility and flexibility of SOA. Transforming the application tier without considering the implications of outdated network design poses a significant risk to successful SOA deployments.

Not long ago, the network filled the simple role of transporting application requests from one endpoint to another. Most network devices were virtually 'set and forget' tools that directed traffic over various ports from outside the network to internal application assets. Load balancers - the network technology most relevant to application architects and developers - were basically installed, set up for 'round robin' load balancing, and never touched again.

Now, network devices have become more intelligent, and can work more cooperatively with applications by offloading advanced needs such as application persistence, SSL-acceleration, compression and caching. Some even have bi-directional proxy capabilities to control application flows, enabling applications and network to work in concert.

Unfortunately, many organisations still rely on old devices that are not optimised to effectively handle XML Web services traffic. With Web services and XML, a tremendous amount of context is embedded within the requests passed via SOAP and HTTP. From self-describing data to selectively encrypted elements, understanding the traffic and being able to alter its flow to better direct requests and responses is critical to successful SOA. Further, in an SOA world where faster application development and service reuse speeds up application change, the burden of configuration change management is significantly increased. A new breed of product and overall network design is needed to support SOA implementations.

There are two critical reasons why old generation network technology knows little about Web services. First, most traditional devices are connection specific. They cannot natively understand the traffic flowing through them, and rarely dig deeply into the application payload where much of the application logic resides within Web services traffic.

Second, most network products do not provide the Web services-friendly API needed to support the constantly changing configuration needs of Web services, whether requested individually or as part of composite services.

Why is this so critical for your SOA plans? Consider a basic real world scenario.You have built a mission critical Web service using SOAP that brokers transactions between your primary business partners and internal order processing system. But traditional network devices cannot tell the difference between a Web page request and a SOAP application request. This lack of understanding will play a significant role in how reliability is orchestrated with your SOA.

One day, an unforeseen market event (say an interest rate change for a financial services firm), floods your system with transactions. Older load balancing devices might distribute requests as needed to the next available server that can support them. But if servers become overloaded, the older devices make it hard to understand the reasons why. Further, based on the unique priority of different Web service requests, it is even more difficult to know where to send them in order to comply with the business requirements influencing your SOA strategy.

Intelligent full-proxy devices however, can identify SOAP faults or exceptions and associate them with the actual application server returning the SOAP error codes. Advanced devices can even queue these faults and retry requests to another service endpoint before returning an error to the requesting client. This ensures a better client experience and makes error logging and troubleshooting easier due to native Web service fluency.

Smart network devices can also prioritise requests based on enforced rules and logic, removing the burden from the application servers that support the requests. Combine this application knowledge with bloated XML traffic and it's easy to see how a high performance network device can come in handy to crunch the bits into faster, more secure, more intelligent application flows.

But a network technology must be more than just intelligent to effectively support SOA. In a traditional network load balancer world, configuration changes are made via a GUI or command line interface. Efficiency focused network operators commonly collect together hard-coded scripts written for a specific configuration of IP addresses and servers. These usually work for static environments and events, but the approach conflicts with the agility and flexibility that SOA enables. Architecturally, it opposes the loosely coupled philosophy of SOA. The brittle coupling breaks as changes are made to support business logic, creating more of the challenges that SOA is intended to remove.

The use of SNMP as a common interface language for network integration is also inherently insecure, and requires developers to learn management information bases (MIBs) that define how and what to communicate as defined by the network device.

To support SOA, a network API - or network control plane - that openly understands Web services language and loosely couples the network resources, IP addresses, pools of servers, and configurations is needed. It will automate mission-critical configurations and make the critical connection between the application realm and the network realm, and is critical to building and deploying a SON.

To understand SON, one must view the network and servers as SOA sees applications. The underlying network and associated resources required to deliver SOA applications are active participants in the SON architecture model, which also delivers agility and flexibility through virtualisation of key infrastructure resources, commands and business logic.

From an agility perspective, this approach enables a SON to dynamically expand and contract based on any variety of performance, availability, or security issues that may develop, to ensure the successful delivery of services in the SOA. Knowledge gleaned by intelligent devices about various Web service needs (plus an API to execute dynamic configuration changes) provides the orchestration engine to support SON. New applications can be deployed faster, without complete reconfiguration of the network resources.

To illustrate this, visualise a data centre with ten servers and a single Web service replicated across each server. The network device virtualises the separate server IP addresses as one 'virtual IP' which is supported by the 'pool' of servers. Requests made for a Web service defined as one virtual IP are directed to the servers best able to support them.

Using our previous financial industry example, as requests increase, the network device can monitor requests, look for errors, and invoke configuration changes to alter device set-up, adding more standby servers to the pool or even redirecting new requests to another data centre running additional instances of the Web service. Additionally, prioritised requests based on client request ID or other factors could be sent to an entirely separate pool of servers hosting the service in a manner optimised for high demand scenarios.

Based upon business priority, the number of server resources, the priority, and dynamic changes to the configuration to support automated change can be done seamlessly, with the service and network working together through more network intelligence and control.

To support a SOA, the key ingredient is a network device that is highly intelligent, able to understand SOA service flows, and speak the same language as the applications.

When considering how you can design a SON to support your SOA, look for highly intelligent network devices that understand the unique needs of Web services traffic, provide Web service native APIs to help automate configuration, and have a thriving user community developing and sharing best practices for deployment and support.

About the Author:

Jeff Browning is director of product management for integration tools and technology at F5 Networks. Browning is responsible for driving the product and marketing strategy for F5's iControl API/SDK, iRules, and technical community development. He is also co-creator of DevCentral, an online community enabling intelligent integration between F5 customers, partners, and developers.