Problem solve Get help with specific problems with your technologies, process and projects.

The effects of SOA and mashups on the WAN

Service-oriented architecture (SOA) and application mashups offer enterprises the flexibility and efficiency they need, but they can have unforeseen effects on the network. Learn about the application performance and traffic issues that SOA and mashups can introduce so you can mitigate them on your WAN.

Service-oriented architecture (SOA) and application mashups offer enterprises the flexibility and efficiency they need, but they can have unforeseen effects on the network. Knowing in advance about the application performance and traffic issues that SOA and mashups can introduce will allow you to plan for and mitigate them on your WAN.

The idea that the next IT revolution will be based on the use of service-oriented architecture (SOA) and mashups has been around for most of this decade. Software vendors have been pushing their plans for orchestrating custom user views of information based on these new tools, so most users today have some SOA applications. Interestingly, even though enterprises believe that SOA and mashups will affect their wide area networks (WANs), they don't seem to be getting much guidance from vendors on how to address the impact.

SOA and mashups are really two pieces of a common capability set, componentization and orchestration of applications. The basic idea is that applications are divided into small functional components ("services"), and these components are then combined or orchestrated to create a worker-specific view of information. The components of a given worker's view can be created from services of any number of applications. In short, it's a kind of "virtual application" process, and it's this componentization/orchestration approach that affects the network.

There are several negative effects that users can experience as a result of using the componentization/orchestration model over the network. The first is in the performance of the virtual application. With normal application access, the user gets all of the data on a screen from the same place, and at roughly the same time. When a virtual application is mashed up from various services, each of the services may be obtained from a different server over a different part of the WAN. On top of that, there may be a business-process language run to synchronize the services that make up a single view and coordinate them based on a common reference to a customer, an order, or some other business element. Any network performance problem will be multiplied in such a situation.

Some enterprises have also reported that mashed up applications are more vulnerable to network outages. The benefit of mashups lies in their ability to give workers exactly what they need, and so workers must be trained to use the new mashup screens. What happens when parts of the screen are missing because a part of the network is down or seriously impaired? The answer is "coffee break," which defeats the productivity benefits claimed for mashups. It's true that this kind of network failure would affect any application, but workers who are trained to use several different applications in succession may be able to work with the others while one is down. Workers trained on mashups tend to view the mashup as one application that is either functioning or not.

Componentization/orchestration can also have a negative effect on traffic. This is highly variable depending on exactly how the mashup is constructed. If a series of applications is truly and effectively componentized, the total traffic to a given worker may be lower when mashups are used because some of the data the worker didn't need is now absent from the mashup. Even then, the fact that traffic from several applications is now concurrent rather than consecutive is likely to create more bursty traffic, which means higher peak loads on the network. If the mashup is obtained by "screen scraping" or pulling data elements from full application screens to create a composite view, the traffic peaks may be so pronounced that the network would be overloaded.

Mashup-generated traffic bursts can also create congestion at specific points in the network where traffic from several server sources collides on its way to the user. Branch networks are particularly vulnerable to this kind of collision because they typically offer no alternate routes with little overflow capacity. It may be necessary to rethink the service-level agreements for branch connectivity to effectively support SOA and mashups.

Perhaps the most significant impact of SOA and mashups is the variability of traffic load and traffic patterns that the two permit and often demand. Application development cycles traditionally have been long, giving network operators time to accommodate expected changes in network traffic. With mashups and SOA, traffic could change radically as a result of something that took days -- not months or years -- to plan and execute. As a practical matter, this means that either the network must be designed with more headroom to accommodate changes, or network operations must be involved in mashup application planning and changes to ensure that there are not unexpected and unfavorable traffic consequences.

The justification for mashups and SOA projects is typically productivity enhancement, but nothing is more destructive to productivity than an application (virtual or otherwise) that fails to deliver information when it is needed. Without proper network planning, every new SOA or mashup application is at risk of creating congestion, performance problems and even application failures. It's smart to begin SOA and mashup network planning when the application planning process begins.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, Telemanagement Forum, and the IPsphere Forum, and he is the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies.

This was last published in March 2009

Dig Deeper on WAN technologies and services

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.