Are you having trouble making robust legacy applications talk to hot, new Web applications? Trying to manage business transactions with your partners when everyone is running their proprietary software on different platforms? Simple, flexible interoperability is the “Holy Grail” behind Web services. However, simplicity does not come without cost. This article will introduce you to Web services, provide an introduction to the key performance issues that characterize Web services-based applications, and help you begin to explore the possibilities for performance monitoring such complex, distributed applications.
What exactly are Web services? They are programs that are accessed over the Web, independent of the tools used to create them and independent of the operating system on which they run. Web services are interesting because they offer a way to provide programs that are platform-independent.
A Web service supplies “discovery” information about itself, which means that you can query a Web service and have it tell you the names of the functions it provides, the arguments accepted by each function, and the return values for the functions. In other words, to be able to use a Web service as part of your programs, you don’t have to know much other than it exists!
Simply stated, a Web service offers a method(s) you can invoke, using open standards (including HTTP and XML) for communication. For those readers who are not up to speed on object-oriented programming, a method is just a function or procedure that is associated with an object. In other words, when a method is invoked, it simply executes an action of some kind.
The driving force behind Web services is to provide components that can communicate with each other regardless of the language they were written in or the operating system on which they run. Web services make their methods available for use or consumption by other programs. To consume a Web service, a program makes a request running over HTTP to use the methods available via HTTP GET and HTTP POST—or more commonly— Simple Object Access Protocol (SOAP). Given that this article is an introduction to Web services and performance, I refer to Microsoft’s .NET environment, primarily because .NET “insulates” the Web service developer from the coding details of SOAP—which is particularly comfortable for the newcomer. However, the SOAP “transaction” that .NET constructs is always available for viewing, as it is in other Web services development environments.
With respect to the universal discovery mechanism provided by Web services, .NET also automatically creates a Web Services Discovery Language (WSDL) document, which other applications (or users) can read to understand how to use the Web service. In addition to .NET hiding the SOAP coding details from the new Web services developer, .NET also insulates the developer from the details of creating the WSDL document; again, it is important to know that it exists in any case.
Web services also use universal description, discovery, and integration (UDDI). UDDI is a kind of Yellow Pages for Web services you can use to find a Web service or to ensure that your Web service can be found.
The SOAP standard is overseen by the World Wide Web Consortium (W3C) and is based on XML. The standard consists of three parts:
- An envelope that defines rules for describing a message and how to process it
- A set of encoding rules for instances of the application-defined data types
- A convention for representing remote procedure calls and responses.
If you think that hand coding a Web service following the SOAP standard sounds complex and fairly tedious, you’re right! Again, the .NET environment insulates the developer from those details. If you are interested in learning more about the SOAP specification, go to www.w3.org/TR/soap12-part0/.