The growth of applications using the .NET platform has generated an increased emphasis on performance measurement and analysis. Distributed applications, while much more flexible and potentially more scalable than monolithic ones, have characteristics that make it more difficult to achieve the goals of high performance and scalability. In such applications, performance issues may not manifest themselves in the individual components, but rather in the integrated application.
The problem arises both in the individual components within the Service-Oriented Architecture (SOA) and in their interactions with one another. Individual components, such as the application client or the web service, may include computationally expensive code and bottlenecks that don't manifest themselves during unit testing, because the functionality is correct. And if they're not tested together, these issues may live on until the application is in production. Once separately developed components are integrated into the full application, performance bottlenecks may result from interactions between them.
These problems are especially common in distributed applications employing an SOA. In the case of traditional distributed components utilizing COM or CORBA, processing tended to be more synchronous, or at least more tightly coupled, which in turn can result in performance more in line with that of the individual components. In the case of asynchronous and loosely coupled web services, there could well be significant differences in the ability of the SOA to provide the performance and scalability required by the application. This is true whether the front-end is a web page or a WinForms-rich client.
Developers who have worked primarily on stand-alone applications or tightly coupled clients may lack direct experience in theperformance considerations needed by web-based distributed applications using services as a part of an SOA. In fact, many application developers may be surprised at the need to analyze performance and tune individual components, including web services in a .NET application.
This doesn't represent a deficiency or limitation of .NET, but rather the reality of the trade-offs required to obtain the flexibility inherent in an SOA. Application developers simply assume that the web services comprising the SOA will meet the performance needs of the client application, and typically measure performance only from the standpoint of that client.
In reality, individual web services may themselves have performance problems or other limitations that prevent them from providing a rapid response to client applications. Even if the web service has been fully tuned, interaction with other web services within the context of the SOA, and with multiple client applications, may reveal problems that were hidden when testing the individual service.
Web services adapt the traditional web programming model for use from all sorts of applications, not just browser-based ones. These applications are loosely coupled and remarkably interoperable because they can be called from any location that is reachable with a URL or URI, and are not limited by the calling conventions of a specific language. So performance problems within collections of web services may extend beyond web applications to include any application that makes use of the SOA.
Microsoft positions ASP.NET as a natural technology for implementing web services based on the Microsoft .NET Framework. The ASP.NET web services infrastructure provides an API for web services based on mapping SOAP messages to method invocations. ASP.NET web services support requests from clients using SOAP over HTTP, as well as with HTTP GET or POST operations. ASP.NET web services automatically generate WSDL files for web services development efforts. Developers can also use ASP.NET web services to implement a web service SOAP listener that waits for service requests and accesses a business facade implemented as a COM component or as a managed code class.
Even though web services using the .NET platform are straightforward to implement, they haven't been proven to stand up to the performance requirements of a wide variety of production uses. That's not to say that they won't or can't, but rather that this type of application model represents a significant unknown in practice. And clearly, this is critical from the standpoint of designing and implementing an enterprise SOA. Understanding the performance strengths and limitations of the web services model in general, and of individual web services implementations in particular, is necessary in order to rely upon them as the backbone of an enterprise architecture.
