Web services networks are rapidly evolving technology architectures allowing applications to tap into a variety of services in an extremely efficient and cost effective manner. Web services enable cost-effective and efficient collaboration among entities within an enterprise or across enterprises. Web services are URL or IP addressable resources that exchange data and execute processes. Essentially, Web services are applications exposed as services over a computer network and employed by other applications using Internet standard technologies, such as XML, SOAP, WSDL, etc. Accordingly, Web applications can be quickly and efficiently assembled with services available within an enterprise WAN or external services available over open computer networks, such as the Internet.
The interface to web services are typically defined in an interface definition document. The Interface Definition Language (IDL) was introduced in the early 1990s by a consortium of large corporations known as the Object Management Group (OMG). The purpose of IDL was to provide a standard platform- and language-independent grammar by which the interfaces used to connect software components are described. IDL became one of the cornerstones of CORBA technology, and variants such as MIDL (developed by Microsoft® Corporation) have been used to describe the interfaces employed by a number of other component architectures. The emergence of Web services spurred the creation of a conceptually and syntactically similar interface description language, Web Services Description Language (WSDL), intended to address the unique issues associated with Web-based protocols. WSDL has been widely adopted and is currently the de facto industry-wide standard for Web service interface definition.
The increasing adoption of web services, however, poses certain problems for network devices that classify network traffic, such as application traffic monitoring devices (e.g., PacketSeeker™ application traffic monitoring appliance offered by Packeteer®, Inc. of Cupertino, Calif.), and application traffic management devices (e.g., PacketShaper® application traffic management appliance offered by Packeteer®, Inc.). Such network devices are typically deployed at strategic points in enterprise networks to monitor data flows traversing, for example, a WAN link. Many such network devices typically classify network traffic based on attributes within IP and TCP headers of the packets corresponding to a data flow. For example, HTTP traffic can often be classified based on the port number (port 80) in the TCP packet header. As discussed in the above-identified patents and patent applications, some traffic classification mechanisms employ rich Layer 7 traffic classification mechanisms. For example, as discussed more fully below, identification of traffic types-associated with data flows traversing a WAN link, for example, typically involves the application of matching criteria or rules to the attributes of individual packets against an application signature which may comprise a one to a combination of attributes, such as a protocol identifier (e.g., TCP, HTTP, UDP, MIME types, etc.), a port number, and even an application-specific string of text in the payload of a packet.
The increasing use of Web services makes granular classification of network traffic more difficult, since the data flows corresponding to a variety of different web services applications all use the same standard web services and other network protocols, such as HTTP, SMTP, NNTP, SOAP, XML and the like. For example, a Web service typically allows a consuming application to access the service using one to a plurality of different bindings based on standard network protocols, such as HTTP and SMTP. Accordingly, the packet headers in the messages transmitted to the web service, as well as the packet headers associated with any response, across a wide variety of web services will typically include less meaningful information in the lower layers of the headers associated with the network communication protocol stack. For example, as discussed above, a well-formed SOAP message using an HTTP binding will typically identify port number 80, the well-known port number for HTTP traffic. As a result of this standardization, it will become increasingly difficult to ensure that critical network services are protected and rogue services, that also employ Web service networking protocols, are restricted as the differentiation between services and applications moves up the network communications protocol stack. Moreover, as the information that distinguishes one Web service from another moves up the protocol stack, it becomes more difficult to configure the matching attributes required to classify each Web service.
With the increasing adoption of Web services, as well as other network applications utilizing standard Internet transport protocols for inter-application communication, a more granular identification mechanism is needed to be able to differentiate one application from another and/or differentiate different components (methods/functions) within an application. For example, a stock information Web service might provide methods to 1) get a real-time quote, 2) find a ticker symbol based on a search string, and 3) enter a buy/sell request. Being able to differentiate the network traffic for each of these operations would allow for finer grained data collection and control of this traffic. With a more granular traffic classification mechanism, traffic policies can be configured, for example, to prioritize buy/sell requests so that they are pushed through the network faster than ticker symbol searches.
In addition, changes to web services also present certain technical challenges. Each time a web service of interest is added, removed, or altered may require some intervention to ensure that the classification device is configured appropriately. Manual intervention, where a network administrator manually initiates the re-configuration, can both increase IT expenses and create a lag time in which the matching rules in the classification device do not match the specifics of the current web services network traffic, resulting in misclassification.
In light of the foregoing, a need in the art exists for methods, apparatuses and systems that facilitate the classification of web services network traffic for purposes such as monitoring and control of application performance, network utilization, and the like. In addition, a need in the art exists for a mechanism that facilitates synchronization of a network traffic classification device with the current versions of web services network traffic. Embodiments of the present invention substantially fulfill this need.
USPTO Backgrounds
USPTO Backgrounds