Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 2. | 4

Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 2.

13.5.3 Monitor and respond to changes in the service hosting environments

“Be responsive to increased infrastructure requirements.”

When Web services represent the endpoints to existing or new integration channels, they can easily become the busiest parts of an integrated environment. This can tax the underlying areas of the infrastructure supporting those services. To avoid performance bottlenecks, it’s a good idea to survey your existing infrastructure and identify any part that may need to be upgraded.

In preparing for any new application, there will be obvious areas where upgrades will be required. New servers, more memory, and strategically located routers are all typical requirements needed to support incoming application hosting environments.

To achieve an optimized environment designed to host Web services, though, you frequently need to see them in action first. The communications framework introduced by Web services brings with it new protocols, different types of runtime processing, and an overall shift in where this processing can physically occur.

It is difficult to predict exactly where and to what extent processing requirements will change. Therefore, it is often best not to fully upgrade your infrastructure until you have a good idea of what the actual performance requirements will be. One way of determining this prior to making your Web services available for production use is to perform a series of stress and volume tests.

Another approach is to measure and respond to performance requirements by carefully monitoring production usage. For instance:

1. Phase in the production release of your application.

2. Closely monitor performance and study usage patterns.

3. Respond quickly with hardware upgrades where required.

13.5.4 Test for the unknown

“…but they said that if we build a service-oriented architecture, we’d be freed from the problems involved with connecting disparate technology platforms…” Sure, but you still need to build your Web services framework using a vendor-specific development platform, along with a vendor-manufactured SOAP server.

Products used to establish an environment for service-oriented data exchange may provide various levels of support for various (mostly second-generation) Web services specifications. This can lead to some discrepancies in areas such as WSDL document interpretation and SOAP message header processing.

“To guarantee the level of interoperability promised by Web services, incorporate a multi-client test phase. This precaution is especially important when working with second-generation specifications.”

The simplest way to address this issue is to increase the amount of testing each newly created Web service will be subjected to. Your test strategy should require that services be tested with a range of clients representative of potential service requestors.

For instance, you may have one project team creating an application using J2EE, while the other is basing theirs on .NET. Even though neither team needs their application to integrate with the other’s, their respective testing phases should still include client requestors based on both J2EE and .NET.

This issue is comparable to the age-old presentation-related problems Web page designers faced when having to accommodate Netscape and Microsoft browsers. There were a number of discrepancies in how HTML was rendered and in how client-side script was processed. Conditional logic often had to be used in order to output different page content.

When first developing a Web service, the effort to fix processing discrepancies is generally negligible. However, if these problems remain undetected until after services have been deployed, then you’ve got yourself a redevelopment project on hand.

Created: March 27, 2003
Revised: February 21, 2004

URL: http://webreference.com/programming/soa2/1