with QoS properties and QoS classes,. ⢠enabling an efficient service offer selection in order to accelerate the overall lookup process for the client,. ⢠providing a ...
Efficient Selection and Monitoring of QoS-aware Web services with the WS-QoS Framework M. Tian, A. Gramm, H. Ritter, J. Schiller Freie Universität Berlin, Institut für Informatik Takustr. 9, D-14195 Berlin, Germany {tian, gramm, hritter, schiller}@inf.fu-berlin.de Abstract While the concept of UDDI supports the automatic discovery of services implementing a common public tModel interface, there have been only few attempts to find a standardized form to describe the quality of service (QoS) properties of Web services. In this paper, we introduce our approach “Web service QoS (WS-QoS)” that enables an efficient, dynamic, and QoS-aware selection and monitoring of Web services. The prototype of our approach is implemented with the .NET technology, including the following components: a WS-QoS Editor for the specification of QoS properties, a WS-QoS Requirement Manager for retrieving QoS requirements specified by client applications, a Web service broker for an efficient and QoS-aware selection of Web service offers, and a WS-QoS Monitor for checking the compliance of the service offers.
1. Introduction Web Services are becoming more and more popular these days and more and more businesses are planning to build their future solutions on Web service technology. By now, SOAP and WSDL have become reliable standards in the field of Web service execution. While the concept of UDDI allows for automatic discovery of services implementing a common public tModel interface, there have been only few attempts to find a standardized form to describe the quality of service (QoS) with which services are executed. The need for QoS specifications in Web services is driven by two demands. Clients aim to experience a good service performance, e.g. low waiting time, high reliability, and availability to successfully use the service whenever the need arises. On the other hand, when it comes to e-business, service providers need to formulate QoS-aware offers in order to gain the highest possible profit from their business. Examples are high throughput guarantees and low response time through dynamic capacity allocation, resource allocation, and load balancing in order to serve a high number of clients with assured QoS. Moreover, crucial transactions such as payment should experience prioritized execution realized
by transaction differentiation. Service providers will strive to find an optimal relation between user satisfaction and system utilization. There are sophisticated technologies to actively differentiate between various QoS levels both on the transport level (DiffServ, IPQoS, classes of services in UMTS and ATM, etc.) and on the server level (load balancing, transaction differentiation, HTTP request differentiation, etc.), yet there are no standardized means to describe the desired QoS on the application level. In terms of the Internet model, the Web services can be placed between the application and network layer. To close the gap between the Web Services layer and the underlying QoS-aware transport technologies, we have developed the Web services-QoS architecture (WS-QoS). The main motivations of our work are • designing an architecture that allows both service clients and service providers to specify requests and offers with QoS properties and QoS classes, • enabling an efficient service offer selection in order to accelerate the overall lookup process for the client, • providing a flexible way for service providers to publish and update their service offers with different QoS aspects as well as • mapping the QoS requirements regarding the underlying transport network from the higher (Web service and application) layer onto the actual underlying network technology at runtime in order to achieve an overall QoS support through the different layers in terms of the Internet model. Therefore, we implemented a WS-QoS framework with the following functionalities: • Application developers can state QoS properties associated with Web services by applying an API or using a graphic user interface (GUI) • Requirement Manager for retrieving and updating client application QoS requirements • Web service broker for dynamic and efficient service selection • WS-QoS Monitor for checking the compliance of service offers • QoS proxies that map the QoS requirements from the higher layer onto the actual QoS-enabling transport
technology at runtime (This point is not described in this paper due to the lack of space. It is introduced in [1]). The main contributions of this paper are the WS-QoS architecture that enables QoS-aware service specifications as well as the broker based Web service selection model that enables an efficient QoS-aware service selection. The remainder of this paper is outlined as follows: After discussing some related work, we introduce the WSQoS XML schema, since it is important to understand the main idea of WS-QoS architecture. (A more detailed description of the WS-QoS architecture is given in [1].) In section 4, we introduce the implemented framework including the WS-QoS Editor, the Requirement Manager, the Web service Broker, and the WS-QoS Monitor. We conclude with an outlook of future work.
2. Related Work To enable standardized QoS specification for Web Services three sophisticated approaches for QoS specification within Service Level Agreement (SLA) for Web Services have been developed simultaneously. They are IBM’s Web Service Level Agreement (WSLA) framework [2], HP’s Open View Internet Services [3], and the Web service Offering Language [4] developed at Carleton University in Canada. IBM’s WSLA framework was designed to enable the specification and monitoring of QoS-aware Web services by applying an electronic SLA. While the form of a SLA specification is provided by the XML-based WSLA language [5] the aspect of monitoring the compliance with an associated SLA is implemented in the SLA Compliance Monitor which is part of IBM’s Web Services Toolkit [6]. HP’s Open View Internet Services product enables a business to manage services with respect to a SLA with the emphasis on instant reporting when SLA violations occur. They describe a theoretic Web Services QoS parameter specification model and introduce a Web Service SLA in the form of the XML based Web Service Management Language (WSML) [7]. Automated SLA compliance monitoring has been realized with the Business Management Platform Agent. Furthermore, QoS aware service choice is achieved through dynamic service ranking according to the different effects that the SLAs in question will have on a composite business process, which are simulated in HP’s Business Process Simulation Environment on the basis of Service Level Information (SLI) provided by service providers. While both WSLA and WSML foster a concept of individually negotiated customized SLAs, a research group from the Carleton University in Canada has developed the notion of providing various classes of service for one and the same functional service specification. The classes of service differ in QoS level and management efforts provided as well as related prices.
Distinct service offerings are formally described in the XML-based Web Service Offerings Language (WSOL). Distinguishing between different service levels will influence the strategies to which a business designs its business processes with the usage of Web Services. With this in mind, it is not surprising, that features related to QoS such as security, message reliability and transactional QoS are also issues in business process management (BPM) standards. So far, the most influential standards have been IBM’s Web Services Flow Language [8] and Microsoft’s XLANG [9]. As the most recent development the Business Process Execution Language for Web Services (BPEL4WS) [10] is designed to realize a convergence of the XLANG and WSFL to endorse further standardization with “a common model shared by leading organizations”. High level QoS support might also be addressed during the work on the WS-Integration specifications. Our approach supports not only the specification of various QoS aspects including server performance, network performance, security, transaction, and their dynamic matching at runtime, but also the mapping of QoS requirements regarding network performance onto the actual transport technology at runtime. We call it cross layer communication. The communication between different layers ensures an efficient utilization of the underlying resources as well as a better support of application-dependent requirements.
3. The WS-QoS XML Schema In this section, we introduce the Web services QoS (WSQoS) approach based on our WS-QoS XML schema. The implementation of the proposed WS-QoS architecture is based on that XML schema.
Figure 1. Different kinds of WS-QoS documents As Figure 1 shows, there are three different kinds of WS-QoS XML documents: The WSQoSRequirementDefinition element specifies client QoS requirements. These are minimal requirements which must not be violated by underperformance. The WSQoSOfferDefinition element contains one or more specifications of QoS offers that a service provider is willing to deliver at a price related to a certain QoS level. Both WSQoSRequirementDefinition and WSQoSOfferDefinition are of the type tQoSDefinition, which is introduced in section 3.3. Each of the
WSQoSOfferDefinition and WSQoSRequirementDefinition elements contain one or more qosInfo elements (section 3.1) that hold information on different aspects of QoS properties. Finally, a WSQoSOntology element holds definitions of custom QoS parameters and protocol references.
3.1. QoSInfo A QoSInfo element holds information on the level of QoS regarding the server performance, transport QoS support and protocols required for providing security and transaction support. We have predefined the following QoS aspects with different parameters (Figure 2): serverQoSMetrics, transportQoSPriorities, securityAndTransaction, and extensibilityElement. In a serverQoSMetrics element, values for the standard parameters processing time, requests per second, reliability and availability can be set. Moreover, custom server QoS metrics can be declared in a customMetric element as a child node of the serverQoSMetrics element. Absolute values are set for the parameters of the serverQoSMetrics element.
for the four standard transport parameters delay, jitter, throughput, and packet loss rate. Like with the server QoS metrics, custom transport QoS priorities can be declared in a customPriority element added to the transportQoSPriorities element. Security and transaction management for Web Services are realized by a variety of protocols. Most of them already have sophisticated mechanisms of negotiating key and session information. Therefore, security and transaction support at this level is restricted to listing protocols needed for a successful service execution. The securityAndTransaction element can hold several protocol elements, each referencing a specific protocol.
3.2. WS-QoS Ontology Custom metrics, priority, and protocol support statements all have an attribute ontology, which references a file containing a WS-QoS Ontology (Figure 3) where the referenced types are defined respectively. By using the combination of the ontology’s URL and the parameter name, a reference is unique. A custom transport QoS priority is defined by a distinct name and a human readable definition of what metric the priority refers to in a priorityDefinition element.
Figure 3. Structure of a WS-QoSOntology element
Figure 2. Structure of a qosInfo element In most cases, neither the client nor the service provider knows over what kind of network technology the data will be exchanged. Therefore, it does not seem appropriate to declare explicit values of the transportQoSPriorities element. Thus, we have decided to declare transport QoS priorities, which are to be interpreted by a special component (the WS-QoS proxy) located between the Web service layer and network layer. This component maps the priority-based QoS requirements from the higher layer onto the specific metrics of the actual transport technology at runtime. In a transportQoSPriorities element, priorities can be declared
A custom server QoS metric defined in a metricDefinition element also has a name and a human readable description of what is measured, but it also includes information on the standardized unit of the measurement and the scope of service invocations the metric is aggregated on, that is, whether the value is valid for the (WSDL) port on which the service is invoked, the whole service or even all services of the provider. Furthermore, it has to be stated whether the value is valid for all service executions or for executions requested by the user only. Finally, the direction of how values are to be compared is declared, which is essential for an automated check of whether an offer fulfills a set of requirements. Accordingly, in a protocolDefinition element, a protocol is defined by its name, a human readable description of the purposes of the protocol, the URL of an
overview document, and the protocol specification if available.
•
3.3. QoS Definition
•
An element of the type tQoSDefinition holds one or more QoSInfo elements plus the specification of the contract and the management support and a price. The default QoS properties of a service are defined in the defaultQoSInfo element. But one can also define QoS properties in the operationQoSInfo element which is assigned to specific operations of a service. That means operationQoSInfo overwrites the values defined in defaultQoSInfo. Both the defaultQoSInfo and operationQoSInfo elements are of the type tQoSInfo as explained above. The contractAndMonitoring node can hold references to protocols needed for service management and/or QoS monitoring and entries of third parties that one side would be willing to trust. Finally, the price element relates the specified QoS level to the cost of service usage. Elements of the type tQoSDefinition are either instantiated as a WSQoSRequirementDefinition element expressing a client’s QoS requirements or as a WSQoSOfferDefinition (Figure 4) representing a minimal QoS level a service provider guarantees to supply. The WSQoSOfferDefinition element is extended by an attribute expires which denotes a point in time until which the offer will be valid.
•
Figure 4. Structure of a WSQoSOfferDefinition element Each WSDL file contains a reference to a file defining WSQoSOfferDefinition, allowing the dynamic adjustment of offers without changing the WSDL file. Furthermore, an offer could be referenced from multiple WSDL files and thus be reused for different services.
4. The WS-QoS Implementation In the last section, we have introduced our WS-QoS specification based on our XML schema. In this section, we describe our implementation based on the WS-QoS specification. We introduce the following functionalities:
• •
C# and ASP .NET application developers can define WS-QoS requirements for both client applications and Web Services offers. The WS-QoS Editor allows the editing of the QoS parameters through a GUI. The Requirement Manager is responsible for retrieving clients requirements. Web service brokers are responsible for the QoSaware service selection. WS-QoS Monitors are used for checking the compliance of offers.
4.1. A scenario for QoS-aware service selection From the client point of view, a client application can use one or more types (tModel) of Web Services. The interfaces (WSDL files) of the Web services are known at implementation time. A proxy class (in the context of the Microsoft Visual Studio.NET also known as a Web Reference) is generated from the tModel’s WSDL description for each service type. Static WS-QoS custom attributes or import attributes referencing dynamic requirements in a WS-QoS XML file can now be assigned to the newly created proxy class and its methods (known as web methods in Visual Studio.NET). Finally, the proxy class is handed over to an instance of the WS-QoS Requirement Manager, which will retrieve the attributes through the reflection technique and thus holds a representation of the current client requirements. One can also use the Requirement Manager to adjust the QoS requirements at runtime without recompiling any code. A possible scenario for a QoS aware dynamic service selection is depicted in Figure 5. On initialization, the client application creates an instance of a WS-QoS Requirement Manager and a WS-QoS Broker (WSB) each. Before service invocation, the client application will request its current QoS requirements from the requirement manager and then inquire the WSB for the most appropriate offer available that fulfills the requirements. The WSB selects the most appropriate offer on behalf of the client from the WSB’s local database. (Note we assume in this case that the WSB has already a local cache of the services the client is asking for. Therefore, the WSB needs not contact the UDDI and the service providers for searching the required service. This model ensures a fast response time.) Once the client gets the required offer from the WSB, the client will invoke the service with the desired QoS properties. The QoS properties are transmitted in the SOAP headers to the service provider that can treat the request based on the QoS properties. For example, it could set the thread priority or, as a load balancer, forward it to one of various possible application servers. Yet, the information is not only intended for the Web service provider: A WSQoS proxy is able to interprete the desired transport QoS
priorities and mark the outgoing packets accordingly so that the higher layer applications can take advantages of the QoS support that the underlying QoS-aware transport technologies provide. Furthermore, the information in the SOAP headers can be used to perform encryption or digital signatures. Requirement Manager
Client Application
Service Broker
Service update offers
update requirements get current offers update offers get current requirements update requirements get cheapest offer (requirements) update selected offer
check offers against requirements
invoke (selected offer) respond
Figure 5. A QoS-aware service selection scenario
4.2. Custom attributes representing WS-QoS elements WS-QoS elements can be declared with static custom attributes which are assigned to a service proxy class generated from a WSDL file. QoS elements for specific operations of a service can be assigned to the corresponding Web method. As Figure 9 in the Appendix depicts, all WS-QoS attributes inherit the abstract class WSQoSAttribute which provides a basic infrastructure for managing the WS-QoS information. In a concrete class the methods getInnerXML() has to be overridden in order to provide an XML representation of the attribute. The method updateProperties(XMLElement) has to be overridden as well in order to create attributes from an XML source. According to the WS-QoS XML schema, the WS-QoS API provides the following custom attributes: • ServerQoSMetricsAttribute and CustomServerQoSMetricAttribute, • TransportQoSPrioritiesAttribute and CustomTransportQoSPriorityAttribute, • SecurityAndTransactionAttribute and ProtocolSupportAttribute, • ContractAndMonitoringAttribute and ThirdPartyAttribute, • PriceAttribute. Furthermore, instances of the classes DefaultQoSInfo and OperationQoSInfo (both inheriting the class QoSInfo) and a QoSRequirements object (which is derived from the class QoSDefinition) are created to hold the attributes retrieved from the proxy class. Apart from holding the values for certain WS-QoS elements, these objects implement the functionality deciding whether one object
provides an equal or better QoS level. Their function Includes() is called from the Web service broker (WSB) when testing an offer against a client requirement definition. While the values of most WS-QoS elements can be compared in a simple way, the custom attribute PriceAttribute implements a function IsCheaper() which calls a currency converter object in case that two price statements are declared with distinct currencies. The WSQoS API defines the abstract class CurrencyConverter which holds a static property ActiveCurrencyConverter. This property has to be set to an instance of a class implementing this abstract class before the WSB can make use of the currency converter. The package WSQoSUtil provides the class WebServiceXCurrencyConverter which uses a Web Service from the service provider WebserviceX.NET [12] to obtain current exchange rates. Furthermore, the import attribute is defined to reference XML WS-QoS files containing further requirements, which can be changed dynamically at runtime. When an import attribute is initiated, the imported file is read and a corresponding QoS definition object is built using the attribute’s getInnerXML() method. Then a thread is initiated to perform regular checks on whether (the content of) the imported file has been changed. If so, the requirement manager is informed and the overall requirement object is rebuilt using the updated representation of the dynamic attributes.
click
Figure 6. Defining custom QoS properties
4.3. WS-QoS Editor The WS-QoS Editor allows both the service client and service provider to easily edit their QoS requirements or offers, respectively. They need not know the details of the WS-QoS XML schema or any programming skill. One or more XML-based .wsqos files are generated automatically. In case of a service offer, one or more references of the .wsqos files are added manually into the (normally automatically generated) WSDL file of the
service. In case of a service request, the Web servicesQoS Requirement Manager will retrieve the values defined in the .wsqos file. Figure 6 shows how a user defines custom QoS properties.
4.4. WS-QoS Requirement Manager On initialization, the WS-QoS Requirement Manager obtains a reference of the service proxy class to which either requirement attributes have been assigned or a reference to a .wsqos file is given. The Requirement Manager retrieves the QoS attributes either from the proxy class or from the file. It then collects all import attributes, builds WS-QoS definition objects and sets their parent property to receive update messages in case that a .wsqos file has been changed. Finally, the newly built WS-QoS definition objects are added to those retrieved from the static attributes.
4.5. WS-QoS Broker The WS-QoS Broker (WSB) holds up-to-date information on offers currently available for a group of services which have been requested recently. Offers are grouped by the interface (tModel) that the services providing them implement. The first time a Web service for a certain interface is requested, one or more UDDI registries associated with the WSB are inquired. The WSDL files for these services are then checked for WSQoS extensions and available offers are built. From then on this newly created offer list is consulted in order to find the best match for clients and their requirements, allowing an accelerated lookup process. To keep offer lists up-to-date, the WSB inquires the UDDI periodically regularly in order to check for new offers. Once an offer expires, it is deleted from the WSB’s local cache. If the validity of the offer is extended, it will be re-detected during the next check. test offers against client requirements 3
UDDI Registry
4
request services
service service service service
interface key
get services
info
1 publish
request service description
interface key
get service description
5 6
Service Provider
7
Service Broker
offers in WSDL
9 invoke service
WS-QoS SOAP header
8
2
get best service
request service
best offer/ service
interface key QoS requirements
Client Application
Figure 7. Interaction between the four participating roles
When a client application inquires the WSB for the cheapest available offer, it sends its QoS requirements as a part of the request. In the order of their price, the WSB then tests the available offers whether they fulfill the client’s requirements. The first compliant offer is returned to the client. It is worth noting that one can implement her own strategy for defining the QoS parameters and the selection of the appropriate services. We just give here a simple idea of how the selection could be done. There are two implementations of the WSB. One is a local object running within the application. This ensures a good performance of the service selection and detailed information on available offers, as needed for the WSQoS Monitor described below. The other implementation uses a remote Web Service to obtain the access point of the most appropriate service. This version is mainly intended as a light process for multiple client applications that use a single private WSB that runs as a Web service within their network domain. The WSB could well be used by any other WS-QoS compliant implementation. Figure 7 depicts the participating roles which are service providers, clients, UDDI registries, and the WSB and the interactions among them. Note that there are no service brokers in the standard Web service model [2]. We assume that in most cases service brokers are requested for services implementing interfaces that have been requested before. Therefore, service offers are normally analyzed in advance and testing against client requirements can be performed immediately on receiving a request. The interactions between the roles are as follows in case the WSB does not yet have any information about a required service: 1. Service providers publish their Web services to UDDI registries. Web services available in UDDI registries are identified uniquely by an interface key (tModel). 2. Clients ask the WSB for services that both implement a certain interface (tModel) and accomplish the required QoS requirements. 3. If the WSB does not already hold up-to-date information on offers that accomplish clients’ requirements, the WSB will request Web services according to the interface key from one or more UDDI registries. Note that we would prefer the model in which the WSB prefetches information of offers that clients could be interested in. This would accelerate the lookup phase significantly. 4. The UDDI registries return a list of services that implement the interface key. 5. The WSB asks the service providers for service descriptions, e.g. WSDL files. 6. The service providers return their service descriptions with QoS offers. The WSDL files of WSQoS compliant service offers contain an entry referencing further .wsqos files.
7. The WSB tests the offers against the clients’ requirements in the order of their costs. By using a cost hierarchy we make sure that the cheapest service fulfilling the client requirements is chosen to provide an optimal cost-performance ratio. Note, that a client will probably not be able to consume a QoS level better than it requires anyway. That is why the cheapest offer will do and testing more expensive offers becomes unnecessary. 8. The WSB returns the most appropriate service to the client. 9. The client directly invokes the service with the original QoS requirements. At this time, the QoS requirements regarding the network performance are actively mapped onto the underlying transport technology. Note that the WSB in step 7 tests the offers (step 6) against clients’ QoS requirements sent in step 2.
4.6. WS-QoS Monitor We have developed the WS-QoS Monitor which displays all available offers and the current client requirements, making it possible to check the compliance of offers. If no appropriate offer can be found, the overview of possible offers will help the user to evaluate what requirements might be inappropriate and could make the adjustments needed in order to make their application work again.
the lower right corner and a QoS-aware client application to the upper right.
5. Conclusions and Future Work The integration of various QoS aspects is important for the success of the Web service technology. In this paper, we have introduced our WS-QoS approach and its implementation. Based on the WS-QoS XML schema, both Web service offers and requests can be associated with QoS offers and requirements. Our approach allows an efficient and QoS-aware service selection in comparison to the UDDI concepts. Furthermore, the WSQoS Monitor helps users to check the compliance of service offers and to identify inappropriate definitions of QoS requirements. Our ongoing research includes the introduction of weighting factors associated with the different QoS aspects and parameters. We have built a testbed in order to conduct performance measurements of our architecture. We are interested, for example, in the performance of the WSB for selecting the most appropriate service in comparison to the standard lookup model and other approaches introduced in section 2. Another important issue is the support of mobile devices. The current Web service concept is designed for application to application (A2A) communication running on desktop computers or servers. The usage of small and mobile devices is increasing rapidly. It is well known that mobile devices are resource constrained. They do not have as much CPU power, memory, hard disk, bandwidth, and so on as desktop computers. Therefore, it is useful to analyze the behavior of mobile Web services in order to improve performance and Quality of Service support for this increasing group of users.
6. References
Figure 8. WS-QoS Minitor surveying the service selection of a sample client. Moreover, the WS-QoS Requirement Manager can be configured to log current requirements. Once this file is registered in the monitor, requirements can be viewed in the requirement watch window or directly in the offer window of the GUI. Finally, the package WS-QoS Util provides a SOAP extension attribute which can be assigned to the proxy’s web methods. The SOAP extension will log WS-QoS SOAP headers for all service requests and responses. One can register this file in the monitor as well use it to survey WS-QoS SOAP headers in the SOAP header watch window of the GUI. Figure 8 shows the main window with the two watch windows in
[1] M. Tian, A. Gramm, T. Naumowicz, H. Ritter, J. Schiller. "A Concept for QoS Integration in Web Services", 1st Web Services Quality Workshop (WQW 2003), in conjunction with IEEE Computer Society 4th International Conference on Web Information Systems Engineering (WISE 2003), Rome, Italy, December 2003, http://page.mi.fuberlin.de/~tian/ [2] A. Dan, A. R. Franck, A. Keller, R. King, H. Ludwig. (IBM) Web Service Level Agreement (WSLA) Language Specification, 2002, http://dwdemos.alphaworks.ibm.com/wstk/common/wstkdo c/services/utilities/wslaauthoring/WebServiceLevelAgreem entLanguage.html [3] HP Open View Internet Services,
http://www.openview.hp.com/products/ovis/. [4] V. Tosic, B. Pagurek, K. Patel, B. Esfandiari, W. Ma, "Management Applications of the Web Service Offerings Language (WSOL)", The 15th International Conference on
Advanced Information Systems Engineering(CAiSE'03), Velden, Austria, June 2003, http://www.sce.carleton.ca/~vladimir/publications.html [5] A. Keller, H. Ludwig (IBM), “The WSLA Framework: Specifying and Monitoring of Service Level Agreements for Web Services”, IBM research report RC22456, 2002, http://www.research.ibm.com/resources/paper_search.shtml [6] IBM Web Services Toolkit, http://www.alphaworks.ibm.com/tech/webservicestoolkit [7] A. Sahai, V. Machiraju, M. Sayal, L.Jie Jin, F. Casati (HP) Automated SLA Monitoring for Web Services, http://www.hpl.hp.com/techreports/2002/HPL-2002191.html [8] F. Leymann (IBM) Web Services Flow Language (WSFL), May 2001, http://ibm.com/software/solutions/webservices/pdf/WSFL.p df
[9] S.Thatte (Microsoft). XLANG - Web Services for Business Process Design, 2001, http://www.gotdotnet.com/team/xml_wsspecs/xlangc/default.htm [10] IBM, Microsoft, Bea, SAP Business Process Execution Language For Web Services 1.1, May 2003, http://www106.ibm.com/developerworks/webservices/library/ws-bpel [11] BPMI.org BPML / BPEL4WS - A Convergence Path toward a Standard BPM Stack, August 2002, http://www.bpmi.org/downloads/BPML-BPEL4WS.pdf [12] WebserviceX.net, http://www.webservicex.net
[13]Heather Kreger, IBM Software Group, “Web Service Conceptual Architecture (WSCA 1.0)”, May 2001, http://dwdemos.dfw.ibm.com/wstk/common/wstkdoc/ettk/w stk/doc/WebServicesArchitecture.pdf
7. Appendix
Figure 9. Classes of the WS-QoS API
