A key goal of the LAURA project is to facilitate interregional zones of adaptive electronic commerce using the ... service level agreement. These ... Organisations, Quality of Service and Service Level agreements ... chain with an emphasis on making these transparent ... analysed and some modules agree for what purpose,.
Towards Business Quality of Service in Virtual Organisations through Service Level Agreements and ebXML Adomas Svirskas, Dr. Bob Roberts
{a.svirskas,r.roberts}@kingston.ac.uk Centre for Applied Research in Information Systems (CARIS) Kingston University United Kingdom
ABSTRACT: As e-business becomes a common practice of conducting business activities, the importance of quality increases significantly. Companies need robust, predictable and efficient services that they can rely upon. This paper explores ways of how e-business quality can be established, monitored, reported and managed. The paper presents a review of the literature referring to the related work on business-level quality of service (QoS) and that on infrastructure QoS. As well as the more theoretical underpinnings introduced in the academic literature, the development activities in progress regarding QoS of Web Services are also discussed. The notion of Request Based Virtual Organisation (RBVO) is then introduced – a value network, which is dynamically formed upon demand to meet identified market demand. From a practical research perspective, the work within the framework of the EU-sponsored LAURA project is presented. A key goal of the LAURA project is to facilitate interregional zones of adaptive electronic commerce using the potential of the ebXML architecture as the chosen underlying technology. These zones have the potential to provide an environment for RBVOs, thus enabling the concept of RBVO to be available for utilisation by small and medium sized enterprises (SME). The ebXML framework supports SLA via Collaboration Partner Agreements (CPA), which business parties agree upon via a negotiation process. The potential to automate the process of reaching a bilateral or a multilateral CPA, referred to as e-negotiation, is also an important aspect discussed in this paper. Keywords: e-business, e-commerce, virtual organisation, service level agreement, quality of service, QoS, ebXML, Web Services
1 INTRODUCTION The original motivation of the research discussed in this paper was to ensure an adequate level of business services quality in Request-based Virtual Organisations. This task is very important for dynamic ad-hoc formations of enterprises, taking different roles in many different business processes at the same time. Quality of service needs to be specified, agreed upon, measured and monitored. Parties should be compensated for deviations from a service level agreement. These provisions promote trust between business parties and make e-business services predictable and manageable. The further organisation of this paper is as follows: Section 2 serves as a literature overview concerning Virtual Organisations, Quality of Service and Service Level
agreements, Section 3 introduces the LAURA project and explains QoS management within the proposed framework, Section 4 summarises the effort and outlines the future research. 2 REVIEW OF THE LITERATURE
2.1 Virtual Organisations There are various definitions of VO, which reflect different perceptions of the concept. Some broad definitions of VO’s are: A VO or company is one whose members are geographically apart, usually working by computer email and groupware while
appearing to others to be a single, unified organisation with a real physical location [1] A temporary network of independent companies that come together quickly to exploit fastchanging opportunities [2] An opportunistic alliance of core competencies distributed among a number of distinct operating entities within a single large company or among a group of independent companies [3] Less a discrete enterprise and more an ever varying cluster of common activities in the midst of a vast fabric of relationships [4] A VO is described in most cases as a network among organisations and/or individuals. Another opinion is that VO’s should not be viewed solely as networks among organisations or individuals but as a radical approach to management, or a strategic approach that leads to dynamically re-configurable enterprises [5]. In such cases, the inherent limitations of being able to plan in an uncertain environment are taken into account by creating high structural flexibility [6]. Because the term ‘VO’ is relatively new, it is understood that there is not any broadly accepted framework or description for it, but instead it is usually adjusted to suit each specific case. Manthou et al [7] have looked at the development of supply collaboration and the establishment of dynamic enetworks between enterprises to create VO’s. They believed that VO's are the result of an advanced stage in the evolution of supply chains, where sophisticated supply chain management concepts (e.g. CPFR – Collaborative Planning, Forecasting and Replenishment) are deliberately established between previously segregated business partners. These are expected to create shared resources and synergies that can be used collaboratively “to optimise the use of mutual assets, to reduce costs to a feasible minimum, and surpass consumer expectations” [7. -pp234]. In other words, these partners proactively integrate their supply & demand information and processes within a single value chain with an emphasis on making these transparent and facilitating real-time responses with the purpose of meeting shared aims and objectives. These may include: advanced planning and forecasting, enhanced inventory management, coordinated distribution management, etc., and can usually be used to gain long-lasting competitive advantages over firms that are outside the collaboration.
The above interpretation implies that there is a very strong link between the concepts of ‘collaboration’ and ‘VO's’, with the former supporting the latter. Generally, partners that intend to form a VO will negotiate a set of agreements on how they will allocate their relative resources, skills, and roles in the new set up. This is the essence of ‘ccommerce’ (i.e. ‘collaborative commerce’), and leads to a number of previously segregated firms that collaborate in trade as an apparent ‘single’ VO – i.e. the ‘extended enterprise’. The ‘virtualisation’ that has occurred is understood to mean that although the business partners remain physically discrete, they appear to all intents and purposes to behave in unison as a single encompassing business unit that stretches along much of a value chain. 2.1.1 Integrated model of VO’s First, in all types of VO's, there is a population of organisations, groups and individuals that could, at some point in the future, form a VO. Inside this population, it is assumed that some alliances and partnerships are likely to be formed from groups of potential allies. When such a group results in the formation of an alliance, this becomes the genesis of a VO. Figure 1 displays a model showing the possible states of organisation:
Universe of Modules
Dynamic Web
Dynamic Organisation
Figure 1 - Integrated Model of VOs
A Universe of Modules may contain organisations, groups, or individuals with similar or completely different objectives, strategies, competencies and resources. The possibility of a module to exploit a market opportunity depends heavily on its relative strength compared to other modules. All modules are potential participants of VO's that may be established at some point in the future based on market needs. A Dynamic Web is a form of alliance among modules that work together for the accomplishment of various tasks and the establishment of a potential VO. At this stage, specific market needs are analysed and some modules agree for what purpose, when and how they want to co-operate. A dynamic web might be, for example, a set of organisations and/or individuals that work in the food industry. Finally, a Dynamic VO is the co-operation within a subset of a dynamic web. Specific objectives and market needs trigger the establishment and operation of the dynamic organisation. It should be underlined
that organisations outside a dynamic web might participate in the VO in special cases. 2.1.2 VO Life-cycle model Apart from that, it is essential to investigate the life cycle of a VO in order to be able to decide on the necessary operations through each stage. The life cycle of a VO is divided in four distinct periods: Identification, Formation, Operation and Termination. Figure 2 provides a more detailed analysis of the periods:
Figure 2 - VO Life-cycle model (from [13])
1. Identification. At this stage, the identification of potential market opportunities and communication to all organisations takes place. Of course, each organisation has the ability to identify opportunities itself. 2. Formation. After the opportunity selection, an agreement is made about which organisations will participate and the role assignment is conducted. 3. Operation. At this stage, all participants work towards a common target. 4. Termination. At this stage, a report is composed. Asset dispersal takes place. Parties negotiate and accept certain SLAs during Formation stage, monitor compliance to the accepted obligations during Operation stage and reconcile according to the results during Termination stage. 2.2 Quality of Service Quality of Service can be referred as collective measure of the level of service a provider delivers to its customers or subscribers. In telecommunications, for example, QoS can be characterized by several basic performance criteria, including availability (low downtime), error performance, response time and throughput, lost calls or transmissions due to network congestion, connection set-up time, and speed of fault detection and correction. Service providers may guarantee subscribers a particular level of QoS as defined by a service agreement. Traditionally, QoS is measured by the degree to which applications, systems, networks, and all other
elements of the IT infrastructure support availability of services at a required level of performance under all access and load conditions. While traditional business metrics apply, the characteristics of e-business environments put specific and intense demands on organizations, which QoS must address. Business drivers, which reflect an organization’s objectives in terms of generating revenue, profit, and market share, and achieving desired levels of customer retention require greater attention because of the increased customer visibility and competitive pressures imposed by e-business [8], [16], [26]. The growing use of e-commerce is creating demand for SLAs with financial incentives in which service provider revenues are determined by the number of completed transactions and there are penalties for SLA violations (e.g., exceeding response time guarantees). Thus, situations are arising in which providers must make trade-offs between losing revenue (e.g., as a result of admission control that denies access to some customers) and incurring penalties (e.g., because admitted work cannot be completed within the SLAdictated response time). Making such choices is skill-intensive and time-consuming, and the decisions must be made in real time. This motivates the use of profit-oriented feedback control. [9], [10] A simple profit model in which: (A) the service provider receives revenues for each completed interaction (hereafter, transaction) and (B) a cost is incurred if response times are excessive is introduced in [9]. The profit model is described by three parameters: (1) r, the revenue received for each completed transaction; (2) W, the response time constraint; and (3) c, the cost incurred if a transaction’s response time exceeds W (offending transactions). Thus, profit is determined by the number of completed transactions and the number of offending transactions as follows: Revenue = r * (number of completed transactions) Cost
= c * (number of responses longer than W)
Profit
= Revenue - cost
Business-level QoS instrumentation often builds on top of the lower-layer QoS mechanisms. The closest layer in e-business architecture stack is application integration level, represented by Web Services, where QoS issues are quite intensively researched. For example, HP Laboratories carry out many Web Services service level modelling and quality research activities [17], [18], [22], [23]. In many cases, web services are exposed access points of business processes that are carried by service providers. Meanwhile, a business process could be composed of one or more web services that are provided by other business units or organizations. For example, in an E-procurement
system, the purchase-order input interface can be published as an entry of a web service. The backend business process that enables this procurement service may invoke web services from delivering business, public catalogue management service and financial services of involved business organizations. [18] Jin et al. introduce web service composition model in [18], which has two abstractions – a web service and a business process. Every web service is modelled as a set of operations. Each operation in turn is implemented through a business process. The business process defines a flow (sequencing) of activities (or nodes). Each of the activities is in turn implemented by executing an operation on another web service. A business process can be made of decision points or branches, joining points, and loops. When a web service is implemented by integrating a number of internal applications, the business process essentially captures the integration logic – how each operation is executed by invoking functionality on legacy applications. When a web service is implemented by composing other web services, the business process captures flow of logic from one provider to another. In a typical scenario, a business process is a combination of both. In this composition model, it can be noted that the overall process represents an operation of one web service (to minimize confusion, we call this as offered web service), while each of the activities represents an operation on supplier’s web services (with the additional note that a supplier can be the internal IT department). As a result, an SLA can be attached to each of the activities to represent supplier-side SLAs. Similarly, SLAs can be attached to the overall process to represent customer-side SLAs. An SLA itself is modelled as a simple distribution of a metric (for e.g., average response time). The distribution specifies the probability that the metric takes on a particular value. For example, if an SLA promises an average response time of 3 seconds for a certain operation with 95% probability, then the distribution is a normal distribution with a mean value of 3. Other distributions that are not normal can also be used to model SLAs. However, Jin et al [18] do not capture more complex SLAs that cannot be expressed as distributions, or other surrounding factors such as penalties into the SLA model. This is a topic for future research. QoS is also addressed at distributed object layer the one below the service layer in Service Oriented Architecture [22], [23], [24], [25]. Hewlett-Packard, for example developed general Quality of Service Modelling Language (QML) for defining multicategory QoS specifications for component interaction. [23]
2.3 Service Level Agreements In its most basic form, a service level agreement (SLA) is a contract or agreement that formalizes a business relationship, or part of the relationship, between two parties. Most often, it takes the form of a negotiated contract made between a service provider and a customer and defines a price paid in exchange for an entitlement to a product or service to be delivered under certain terms, conditions, and with certain financial guarantees. In many e-commerce contracts, the service provider agrees to guarantee a certain level of Quality of Service (QoS) for each class of service, and in return, each business agrees to pay the service provider for satisfying the QoS guarantees in serving its set of customers. Those contracts are based on a Service Level Agreement (SLA) between each business and the service provider that defines the QoS guarantees for a class of service, the cost model under which these guarantees will be satisfied, and the anticipated level of per-class requests from the customers of the e-business. The SLAs specified for the e-commerce sites define different classes characterized by specific Quality of Service (QoS) requirements. Most QoS guarantees are based on availability and throughput (delivery success), or, to a lesser extent, average delay measures. However, a critical issue for ecommerce applications and services concerns the efficiency with which the differentiated services are being provided, as delays experienced by customers of a business can result in lost revenue for that business. Per-class SLAs usually have clauses where the service provider gains revenue for each request satisfying the per-class SLA, and incurs a penalty for each request failing to do so. Hence, in order to maximize profits, one needs to pay attention to resource management issues, so that customers can be served according to the restrictions defined in the SLAs. In the telecommunications industry, SLAs are contracts that specify the performance parameters within which a service is provided. As such, the SLAs define such parameters as the type of service, data rate, and what the expected performance level is to be in terms of delay, error rate, port availability, and network uptime. Response to system repair and/or network restore procedures also can be incorporated into the SLA, as can penalties for noncompliance. Muller [15] suggests that a paper written SLA should contain the components listed below. Although Muller refers to these in the context of network management, they have wider applicability and relevance to SLAs in general.
• • • •
• •
•
•
•
•
•
Background: This section should contain enough information to acquaint a nontechnical reader with the application. Parties: This should include the responsible party within IT and within the business unit and/or application user group. Services: This section should quantify the volume of the service to be provided. Timeliness: This section should provide a qualitative measure of most applications to let end users know how fast they can expect to get their work accomplished. Availability: This section should describe when the service would be available to the end users. Limitations: This section should describe the limits of the service to be provided, for example during conditions of peak period demand, resource contention by other applications, and general overall application workload intensities. Compensation: This section should put teeth into the agreement for both parties using some form of compensation and/or penalties for non-compliance. Measurement: This section should describe the process by which actual service levels will be monitored and compared with the agreed upon service levels, as well as the frequency of monitoring. Optional services: Provides for any services that are not normally required by the user, but might be required as an exception. Administration: Describes the processes created in the SLA to meet and measure its objectives and defines organizational responsibility for overseeing each of those processes. Renegotiation: This section should describe how and under what circumstances the SLA could be changed to reflect changes in the environment.
Service Level Agreements (SLA’s) can detail the responsibilities of an IT services provider, the rights of the service provider’s users, and the penalties assessed when the service provider violates any element of the SLA. An SLA also identifies and defines the service offering itself, plus the supported products, evaluation criteria, and Quality of Service that customers should expect. There are 3 types of Service Level Agreements (SLAs) • In house: Those are agreements negotiated between the service provider, such as an IT department, and an in-house user department.
•
External: Those are agreements that any company purchasing services such as IT from an external provider cannot be without. This type of SLA is a legally binding contract. • Internal: Those are usually informal agreements within a department for achieving certain performance goals, and for measuring performance in achieving these goals. There are 3 main aspects of Service Level Agreements: • Legal: Provides for the negotiations between customer and service provider about the legal aspects of the contract. • Operational: Provides for the execution of the services under the SLA. • Financial: Provides an assessment of the financial implications in the SLA. SLAs can follow a life cycle, which includes the following phases: • Product/Service Development: Templates and entitlements are developed. • Negotiation & Sales: Contracts are negotiated and executed. • Implementation: Service orders are generated and provisioned, and SLAs are monitored. • Execution: SLA performance is monitored, operated and maintained. • Assessment: Performance is assessed and templates are reassessed. This final step may serve as an input to the first step (Product / Service Development) A company could decide to implement different levels of Service Level Agreements according to the needs of the customer and the financial gains. Those levels could be for example Platinum, Gold, Silver, Bronze, etc. The ebXML framework incorporates Service Level Agreements (SLAs). The minimum set of SLA properties that have to be defined is as follows [29]: • • • • • • • • •
Time to Acknowledge Receipt Time to Acknowledge Acceptance Time to Perform Authorization Required Non-Repudiation of Origin Non-Repudiation of Content Non-Repudiation of Receipt Retry Count Confidential Transport Required
Additional SLA properties for consideration include, but are not limited to: Authentication Required, Digital Signature, and Encryption. 3 QUALITY OF BUSINESS SERVICES IN PRACTICE
3.1 The LAURA project The authors of this paper are currently involved in a project sponsored by The Information Society Technologies (IST) Programme, a part of the Fifth Framework Programme for Research, Technological Development and Demonstration Activities. The project, called LAURA - “Adaptive Zones for Interregional Electronic Commerce based on the concepts of Request-Based Virtual Organizations and sector-specific Service Level Agreements” [12] is directly related to the issues of e-business Quality of Service. LAURA is a project that innovates in terms of focusing on a specific type of the Virtual Organization (VO) taxonomy that is the “RequestBased Virtual Organization” (henceforth: RBVO). This type of VO comprises a cluster of partnering organizations that have totally replaced their vertical integration into a virtual one. As Don Tapscott wrote: "Just as the walls within organizations are falling, so the walls among organizations are falling too. The result is what's been called the virtual corporation. Rather than staff up, you partner. You understand your core competencies and unite with companies having other talents. You forge a series of everchanging alliances to achieve competitive success." [11] The key features of RBVO as opposed to the “classic” VO are: • • •
A possibility for an enterprise to discover potential business partners upon demand and advertise itself in a standard way Short-lived ad-hoc virtual formations of collaborating partners Highly dynamic involvement of an enterprise in different e-business activities, serving different roles (those defined and advertised) at the same time, if needed
These alliances are built around horizontal networks between business partners, rather than vertical integration within an organization. The RBVO alliances still comprise the same business operations, but only some of these operations are within the original organization - the other operations are now within separate organizations,
which are linked to the original organization, to produce a new Virtual Organization. However, LAURA is not a project addressed to only “bricks-and-mortar” type of organizations. It also investigates the Dynamic Value Constellations for also invisible RBVO that lack of any physical structure. In this type of organization the concept of Service Level Agreements (SLA) is more explicitly automated. These types of VO exist only on the Internet, offering their products and services in electronic form, there is no physical product involved at all. Such an organisation actually represents the new era of conducting business and combines all the forms of virtuality, using alliances, displacement and invisibility to create a flexible enterprise capable of fast growth and rapid changes of direction. This type of VO uses alliances with its products suppliers, it is displaced in that one visits it from anywhere in the world, and it is (in) visible in that there is (no) physical structure exposed to the customer. Hence, managing and improving the service quality in both intra and inter-enterprise operations among collaborative network of enterprises, is virtually impossible in a reactive environment of a RBVO that doesn’t provide a method of monitoring performance and measuring against Service Level Agreements. A VO has several individual enterprises-suppliers communicating with one another, fulfilling customer requests and/or triggering e-services that carry out their parts of some complex workflow of transaction. Without the right tools a VO has no way of knowing if it meets commitments to the customer/user and supplier/user community. The LAURA project introduces an innovative approach, “any actor to any actor” Internet based seamless electronic commerce platform in which all request based business entities can act as one channel virtual enterprise. Specifically, in this project the concept of Dynamic Value Constellation focused on RBVO is taken as a basis to define reliable, accurate, dynamic Service Level Agreements (SLA) and outline the available service options along with the corresponding support responsibilities. The customers of the services therefore have freedom to select the best available options for their business. The LAURA project aims to: • •
Define the Dynamic Value Constellations issues specifically regarding RBVO and their potential SLAs. Identify all the ordering transactions, services and possible contract agreements complemented by Internet access to web sites for catalogue searching in order specify the e-contract agreement needed to provide to customer the end product and services.
•
•
• • •
Provide specific techniques (i.e. DBMS, models, DSS, intelligent agents) to aid in planning, implementing, administering and evaluating SLA’s between Virtual-Organizations and requests. Extend the SLA regarding contract documentation and shipment tracking in order to provide technologically innovative ad hoc methodologies regarding the former. Build a generic application - independent model, which gives an automated measurement of Service Levels. Develop customized versions of the generic model in the selected sectors, as described below. Evaluate possibilities of wider adoption of the project’s concept.
by humans and yet is precise enough for enforcement by computers. [29]
Figure 4 - CPA establishment procedure (from [29])
Therefore, it essential to provide adequate collaboration profiles in order to have efficient QoS management through protocol agreements. 4 CONLUSIONS
Figure 3 - The Laura project - a proposed framework
3.2 The Technology - ebXML The ebXML framework includes declarative, executable languages to express e-business collaborations (BPSS) and protocol profiles and agreements (CPP/CPA) in a non-proprietary, XMLbased format. These specification documents can be shared and ported between compliant implementations. The ebXML messaging services complements these by offering a very capable standards-based e-business messaging system [27], [28]. These features fit very well the LAURA project business requirements, so ebXML server as the basis for LAURA implementation. QoS is supported in ebXML framework through Collaboration Protocol Agreements, which are based on Collaboration Protocol Profiles of the parties. A CPA describes all the valid visible, and hence enforceable, interactions between the Parties and the way these interactions are carried out. It is independent of the internal processes executed at each Party. Each Party executes its own internal processes and interfaces them with the Business Collaboration described by the CPA and ProcessSpecification document. The CPA does not expose details of a Party's internal processes to the other Party. The intent of the CPA is to provide a highlevel specification that can be easily comprehended
This paper discussed the need for QoS management in the context of Virtual Organisations, the initial attempts to formalise business-level QoS and the early work of applying them in practice in the LAURA project. In general, there are ways to implement business level quality of service, however instrumentation and models need further elaboration as more parameters will be needed to support a realistic e-business SLA. The ebXML framework will play a key role in supporting QoS management through Collaboration Protocol Agreements. The LAURA project partners are already progressing towards a ‘proof of concept’ sector-specific SLA for monitoring business service compliance to the SLA and other related aspects of business level QoS. The concept of a Request Based Virtual Organisation implies close interdependence and SLAs will be a fundamental component in ensuring that contractual obligations are monitored and adhered to.
REFERENCES [1.] [2.] [3.]
[4.]
Virtual Organization – A whatis Definition http://whatis.techtarget.com/definition/0,,sid9_gci21330 1,00.html (4th Nov 2002) Byrne, J. A., (1993), The Virtual Corporation, Business Week, Feb 8, pp36-41 Goldman, S. L., Nagel, R. N., Preiss, K., (1995), Agile Competitors And Virtual Organizations: Strategies For Enriching The Customer, New York: Van Nostrand Reinhold, International Thomson Publishing Sieber, P., Griese, J., (1999), Virtual Organizations As Power Asymmetrical Networks, Organizational
[5.]
[6.]
[7.]
[8.]
[9.] [10.] [11.] [12.]
[13.] [14.]
[15.] [16.]
[17.]
[18.] [19.] [20.] [21.]
Virtualness And E-Commerce, 2nd International VoNet Workshop, Zurich Saabeel, W., Verduijn, T. M., Hagdorn, L., Kumar, K., (2002), A Model Of Virtual Orgasnization: A Structure And Process Perspective, Electronic Journal Of Organizational Virtualness, Vol. 4, No. 1 Davidow., D. H., Malone, M. S., (1993), The Virtual Corporation: Structuring And Revitalising The Corporation For The 21st Century, New York, HarperCollins Manthou, V., Vlachopoulou, M., Folinas, D., The Supply Chain Perspective Of E-Business Evolution, (2002), in Towards the Knowledge Society: eCommerce, eBusiness, and eGovernment, pp229-242, Monteiro, J., Swatman, P. M. C., L. Valadares Tavares (eds.), The Second IFIP Conference on E-Commerce, EBusiness, E-Government (I3E 2002), October 7-9, 2002, Lisbon, Portugal. IFIP Conference Proceedings 233 Kluwer 2002, 766pp, ISBN 1-4020-7239-2 Quality of Service for eBusiness: - The Impact of http://wwwInfrastructure, An IDC Brief 1.ibm.com/partnerworld/pwhome.nsf/vAssetsLookup/I DC_QOS.pdf/$File/IDC_QOS.pdf Diao, Y. et al., Using fuzzy control to maximize profits in service level management, IBM Systems Journal, Vol. 41. No 3, 2002, p.p. 403-420 Diao, Y. et al., A Business-Oriented Approach to the Design of Feedback Loops for Performance Management Tapscott, Don, 1996. The Digital Economy: The promise and peril in the age of networked intelligence. McGraw-Hill, 342 pp. ISBN 0-07-063341-8. The LAURA project on the IST Web site http://dbs.cordis.lu/fepcgi/srchidadb?ACTION=D&SESSION=129832003-313&DOC=7&TBL=EN_PROJ&RCN=EP_RCN_A:636 05&CALLER=PROJ_IST Strader, T. J., Lin, F., Shaw, M. J., (1998) Information Structure For Electronic Virtual Organization Management, Decision Support Systems, 23, pp75-94 Saabeel, W., Verduijn, T. M., Hagdorn, L., Kumar, K., (2002), A Model Of Virtual Orgasnization: A Structure And Process Perspective, Electronic Journal Of Organizational Virtualness, Vol. 4, No. 1 Muller Nathan J. (1999), “Managing service Level Agreements”, International Journal of Network Management, 9 Quality of service: Evolving to the next generation, IBM, October 2001, http://www1.ibm.com/partnerworld/pwhome.nsf/vAssetsLookup/Q OS.pdf/$File/QOS.pdf Sahai, A. et al., Specifying and Guaranteeing Quality of Service for Web Services through Real Time Measurement and Adaptive Control, E-Services Software Research Department, HP Laboratories Jin, L. et al., Analysis on Service Level Agreement of Web Services, Software Technology Laboratory, HP Laboratories, Palo Alto, HPL-2002-180, June 21st, 2002 Sabbouh, M. et al., The MITRE Corporation, World Wide Web Consortium Workshop on Web services, , 11-12 April 2001 San Jose, CA - USA XML Protocol (XMLP) Requirements, http://www.w3.org/TR/xmlp-reqs Brutzman, D. et al., Extensible Modeling and Simulation Framework (XMSF) Challenges for WebBased Modeling and Simulation FINDINGS AND RECOMMENDATIONS REPORT: TECHNICAL CHALLENGES WORKSHOP, STRATEGIC OPPORTUNITIES SYMPOSIUM 22 OCTOBER 2002,
[22.]
[23.]
[24.]
[25.]
[26.]
[27.] [28.] [29.]
http://www.movesinstitute.org/xmsf/XmsfWorkshopSy mposiumReportOctober2002.pdf Tunney, P., QML - Quality Meta Language from Hewlett Parkard Labs QoS for Enterprise Applications, WhiteView, QoS Taskforce: Paris April 2002 http://www.opengroup.org/public/member/q202/docum entation/forums/qos/tunney.pdf Frolund, S., Koistinen J. QML: A Language for Quality of Service Specification. Software Technology Laboratory, HP Laboratories, HPL-98-10, February, 1998 Asensio, J. I. et al., UML Profiles for the Specification and Instrumentation of QoS Management Information in Distributed Object-based Applications, http://jungla.dit.upm.es/~jlopez/publicaciones/sci01jase nsio.pdf Bergmans, L. et al. A QoS-Control Architecture for Object Middleware http://amidst.ctit.utwente.nl/publications/idms2000_berg mans.pdf Schmidt, H., Service Level Agreements based on Business Process Modelling, http://www.darmstadt.gmd.de/%7Ewombach/sem_proc _02/schmidt00service.pdf ebXML & OASIS (2000), “ebXML Business Process Methodology Guidelines” ebXML Technical Architecture Specification (refer to http://www.ebxml.org for latest version) ebXML Collaboration-Protocol Profile and Agreement Specification (refer to http://www.ebxml.org for latest version)
