QoS-Aware Component Frameworks

Download PDF
27 downloads 118002 Views 409KB Size Report
Comment
application business software. This makes more complex the software architectures and the software development process. A problem is the implicit software ...
QoS-Aware Component Frameworks Miguel A. de Miguel E.T.S.I. Telecomunicación Ciudad Universitaria, 28040 Madrid Spain +34 913 367 366 560 [email protected] Abstract Developers of QoS (Quality of Service) applications need component frameworks that support QoS to improve their development process. We propose to use the component infrastructure level for the integration of QoS facilities to avoid the problems of QoS infrastructures dependencies, and to simplify the development process of applications. This paper introduces our model of QoSaware component, and describes its relevant entities. In our support of the model, the component descriptor provides facilities for the configuration of QoS attributes, and the component container isolates the QoS business component from the basic QoS infrastructures, which are supported in QoS-aware networks, OS and middleware. In this paper we include some practical results based on QoS-aware components that include support to guarantee the response times, jitters and resource consumption based on resource reservation services.

Keywords QoS frameworks, QoS-component programming, realtime component systems, component containers.

1. Introduction In the last decade the increase need of timely and dependable execution and communication support have established and improved the QoS facilities (e.g. QoS specification, QoS negotiation algorithms, reservation protocols, resource brokers). They have been integrated in protocol stacks, operating systems kernels and middleware systems. These facilities provide support for the development of multimedia, real-time and complex systems in general. But to put in practice QoS facilities is a complex process, and they must be integrated with the application business software. This makes more complex the software architectures and the software development process. A problem is the implicit software infrastructure dependencies. Currently, most QoS-aware software architectures and implementations are based on specific QoS Infrastructure Services (e.g. Intserv and Diffserv in QoS IP, Resource Managers in OS); these services are

used to achieve the non-functional requirements of these systems (e.g. latency, throughput, reliability, and security). The maintenance and portability of these implementations are complex because the infrastructure dependencies are spread around most of software elements and the software architectures are infrastructure dependent [6], and this makes complex the adaptation of these applications to new QoS frameworks. This problem lead to the following rule of thumb: Separate business parts of QoS parts to attain better time to market and better future evolution. We believe that this objective can be achieved applying solutions based on component container structures. Software component frameworks such as Microsoft COM+ [18] and .NET [10], Sun EJB (Enterprise Java Beans) [7], and OMG CCM (CORBA Component Model) [16] integrate services in the container structures and run-time support thereby limiting the scope of infrastructure dependencies. Software component frameworks introduce concepts to ease the assembly of business components together and the usage of middleware and OS services. Among the most important novelties are introduction of required interfaces, attribute-based programming, combination of middleware services, packaging, and assembly. More precisely, attribute-based programming provides a powerful and easy way to bind services to software components without affecting their internals. It allows for example semi-transparent configuration of QoS and middleware services in a declarative way. Attribute-based programming can be done through: i) XML configuration files associated to software component, ii) metainformation directly associated to the software components in the source files and integrated within the byte-code as meta-data, iii) and conceptual models that provide support to represent QoS and other nonfunctional specifications. Attribute-based solution makes possible the rapid and easy development of new QoS applications and do not require a detailed knowledge of QoS facilities. Currently, the component infrastructures are based on four basic types of services: persistence, transactions, events and security. They include component models to provide support of e-commerce and general-purpose business applications, but they do not

support QoS-aware applications like real-time and multimedia systems. The goal of our work was to make an exploratory research into solutions for the extension of component models to integrate QoS support. QoS component models and attribute-based programming is easier to use and rapid to apply than other QoS-aware frameworks (QoSaware middleware, QoS IP and networks, and QoS operating systems). This adaptation requires the integration of QoS facilities in the architecture of component containers, and identifies infrastructureindependent interfaces and component models to provide the access to these services. The more specific objective of this exploration is identify solutions for the integration of QoS IP services [5][25] (resource reservation services), QoS negotiation [1] in the component container architecture, and study the container architecture to make it adaptable to other types of QoS supports (e.g. dependability services). We have based our studies in some prototypes, where we have adapted current implementations of EJB and RMI to introduce a new component type that will support business component with QoS IP requirements (specially temporal requirements like jitters and latencies). Section 2 introduces the related work. Section 3 introduces the new model of component that we have developed. Section 4 introduces some experimental examples and benchmarks, and Section 5 includes some conclusions.

2. Related Work The integration of QoS facilities into middleware systems has been identified as a future challenge for the middleware infrastructures [12][19]. QoS-aware middleware systems define general QoS frameworks to support QoS facilities: i) QoS specification, ii) QoS negotiation and adaptation, iii) resource reservation and admission control, iv) access to basic services for the configuration of some quality attributes (e.g. dependability, security, mobility), and v) QoS monitoring. General middleware architectures [13][15][20] introduce the five general facilities, but their architectures are not dependent of communication middleware facilities. In some solutions [13][15], QoS middleware cooperates with existing solutions at OS and network levels, and proposes the middleware layer to support other facilities (e.g. adaptation). The architecture introduced in [20] pays special attention to the quality dependencies between components. The quality level of a component depends on the quality levels provided by other components and the resources available. Examples of QoS-aware middleware systems based on specific middleware are: i) BBN’s QuO project [26] is a well-known framework for the integration of QoS management in CORBA. It provides support for the

specification of QoS, negotiation and adaptation facilities, and resource reservation; ii) the solutions proposed in [8] integrate the resource reservation and QoS IP in Java RMI classes; and iii) the combination of reservation protocols and Berkley Sockets and CORBA IIOP [24] is another example of practical application of QoS facilities in middleware based applications. Some proposals study the integration of QoS facilities in CCM [23]. This integration pays special attention to the QoS-enabled location transparency, reflective configuration of component server and container, and the strategies to reconfigure the component server. This paper describes the solutions, but is not supported on a real CCM implementation. Lusceta [4] is a component model environment based on formal techniques, which can be simulated and analyzed component models. Lusceta provides support for the specification of QoS management, which can be used to synthesize (dynamic) QoS management components. The execution framework is a general QoS-aware reflective middleware. Another component modeling environment is presented in [17]. It proposes solutions for the description of component architectures and for evaluation of response times. This is an architectural environment not supported by execution environments.

2. QoS Component Model In this section we will introduce our QoS component model that has been designed to avoid the implicit software infrastructure problems and to support nonfunctional requirements in general [6]. The particular implementation included in this section supports the execution of business components that provide a predictable response communication time, based on reservation services.

2.1. QoS Component Meta-Model The basis element of this QoS model is the resourceconsuming component (RCC). This is a processing entity that includes a group of concurrent units of execution, which cooperate in the execution of a certain activity and share common budgets. The budget is an assigned and guaranteed share of certain resources. A RCC has associated: i) facets (interfaces provided and synchronously used by RCC´s clients), ii) receptacles (interfaces synchronously used by this RCC), iii) event sinks (event queues supported by this RCC and asynchronously used by RCC’s clients), and iv) event sources (event queues asynchronously used by this RCC). Qualities level express the quantifiable level of satisfaction of a non-functional property. An RCC can associate quality levels to its facets and event sinks. These quality levels are the RCC’s quality provided contracts. To support the quality provided contracts, the RCC can

require some minimum budgets and quality levels in its receptacles and event sources. These quality levels are expressed in the quality-required contracts. Quality contracts are expressed in terms of the attributes associated to quality types. A quality type includes a set of quality attributes that are the dimensions to express a quality satisfaction. An example of quality type to express latency constraints could include the following attributes: i) arrival patterns, the values of this enumerated attribute are: periodic, irregular, bounded, busty, unbounded, ii) minimum period, iii) maximum period, iv) jitter, v) burst interval, vi) burst size, vii) requirement type, the values of this enumerated attribute are: hard, soft, firm, viii) deadline hard, ix) deadline soft, and x) output jitter. The facets, receptacles, event sinks and event sources interconnect the group of RCC, which collaborate to provide support of qualified functionalities. They support qualified functionalities transforming input data and events into output data and events. The qualified functionalities are the external QoS system operations, which have associated a quality utility that express the degree of satisfaction of the operation from the user or external system point of view. The quality utility is express in terms of quality types, and quality constraints. The grouped RCC are not quality independent in the sense that their configuration and quality provided in its facets and event sink may limit the quality behavior of another RCC. The end-to-end quality of a qualified functionality depends on the sequence of transformations developed along the RCC sequence. For example, the end-to-end latency of a video signal transformation depends on the latency of all RCC involved in the transformation operation. Two QoS entities are the Resource Manager and the QoS Manager. The Resource Manager is responsible for the coordinating the reservation, admission control and scheduling of physical resources. The Resource Manager does not know what a qualified functionality is. The QoS Manager is in charge of the allocation of system resources among competing qualified functionalities. To provide a quality utility in a qualified functionality, collaborating RCCs must negotiate their budgets with the Resource Manager, and the quality contracts associated to facets, receptacles, event sink, and event sources with their client and server RCCs. Figure 1 represents an example of five RCC that provide support for a multitarget radar system. This military radar controls a limited number of targets, and it represents a hypothetical trajectory of each target, given the antenna samples. Examples of qualities of qualified functionalities are: i) the maximum latencies to compute and represent any target trajectory, ii) the accuracy of the trajectory provided, and iii) the maximum number of target supported. These qualified functionalities are quantifiable with quality attributes like end-to-end worst-

case response time, maximum error of trajectory computation, and the number of targets currently supported. The quality levels depend on the functional and quality properties of the RCCs. The quality contracts are expressed in terms of the quality types associated to the different facets and receptacles. Some quality types included in the figure are the antennaCapacity (it represents the number of samples per second provided for each target), and the trajectoryAccuracy (this quality is evaluated by two attributes: i) the maximum error in the computation of a single trajectory, and ii) the probability to associate samples to an incorrect target). The five components require some budgets of CPU and network to guarantee the latency constraints. Each RCC must negotiate the budgets with its Resource Manager and the quality constraints with the other RCC associated with him. The receptacles of Multitarget Radar RCC provide access to the antennas, and it provides facets connected to receptacles of Radar Humane Interface. The quality contract provided by Multitarget Radar depends on the quality contract provided by the antennas (i.e. the accuracy depends on the samples capacities). The quality provided constraints of Multitarget Radar depends on the antennas’ quality provided constraints of latency and accuracy. AntennaCapacity numOfSamples

AntennaLatency dataArrivalPeriod maxDeadline

Antenna1

Multitarget Radar Antenna2 Antenna3 Radar Human Interface

targetScalability maxNumberOfTargets

tajectoryLatency maxUpdateDelay minUpdateDelay

trajectoryAccuracy singleTrajectoryAccuracy wholeSpaceAvailability mixingDifferentTrajectories availabilityOfAllSpaces

Figure 1. Multitarget radar logical component model.

2.1. Support for the QoS Component Model In this section we introduce some practical solutions to support the logical model introduced in previous subsection. The solutions introduced in [8] provide the framework to introduce QoS IP into Java programs, but the process will become more complex when multiple

components appear, the negotiation algorithms are complex, and the QoS provided depends on the QoS provided by other servers. Manually programming these facilities can tightly couple business component to specific QoS facilities. The model capacities that we present have been implemented in EJB 1.1 [7] and RMI [22] specifications. EJB 1.1 specification introduces some component types like session and entity that CCM includes too. QoSBean is a new component designed to provide support for the RCC. This component type defines semantics and configuration attributes based on the QoS capabilities and entities equivalent to the semantic of session and entity types based on transaction, persistence, event, and security services.

Component Descriptor Editor

Component Descriptor Generator

XML Component Descriptor

common interface for all QoSBean components. EJBQoSObject interface includes methods for the negotiation and adaptation of QoS provided by the component, and other general methods. The Business interface provides support for the specification of the RCC facets. 2. Component Descriptor. This XML file includes the identification of the component type and its attribute values. QoSBean includes attributes for the identification of the default negotiation algorithm, the exclusive or non-exclusive execution of business methods and the types of QoS levels provided (hard, soft, and firm). The component descriptor types defines some basic quality types and their attributes. 3. Component Descriptor Generators. We use two methods to provide the component descriptor. The first approach represent the QoS attributes with DTD types that are extensions of the DTDs included into the EJB 1.1 standard. The QoSBean type is represented as the other EJB 1.1 component types (session and entity). A customized tool provides support for the description of these types of descriptors. The second solutions is based on an UML descriptor that uses an UML profile for specification of QoS requirements of components. The QoS component properties are represented in UML models. The UML component descriptor generator analyzes the component’s UML context and extensions1 used for the description of QoS properties. 4. Container. The container supports the type of component specified in the Component Descriptor, for the Business interface. It guarantees the exclusion or non-exclusion of business methods, it accesses the QoS capabilities and entities to provide the QoS support of the component, it implements the default negotiation algorithm and implements the services provided to the business component. The Generator of Container has as inputs the component descriptor and the Business interface, and generates automatically the container of this component. This new type of container requires a specific architecture [9]. 5. QoSContext. This interface includes the internal services provided by the container to the business component. It provides methods to implement customized negotiation algorithms and methods to configure some negotiation algorithms (e.g. amount of bytes required for the serialization of method invocation and return) and other general component services. 6. QoSNegotiation and QoSBean. The business component must implement the QoSBean interface and can implement the interface QoSNegotiation to do the customization of the negotiation process. QoSBean includes general-purpose methods (e.g. provide the

UML QoS Model

Generator of Container

Home C l i e n t

Business Component Business Interface

QoSNegotiation QoSBean

Container QoSContext EJBQoSObject

Java RMI

QoS Capabilities and Entities

Figure 2. QoSBean component model.

Figure 2 includes the main blocks of this framework. The blocks are: 1. External Interfaces. The external interface of the component includes the Business interface that identifies the business methods of the interface, the Home interface that includes the factory methods of the component, and the EJBQoSObject interface that is a

1

The UML extensions are stereotypes and tagged values.

reference to the context and notify reservation events like errors and correct reservations). When the component implement QoSNegotiation, the container does not provide the negotiation support and delegates it to the business component.

2.1 Types of Container Examples of containers are the containers that support soft quality levels (it is based on Control Load traffic control algorithms and reservations); we use two different containers to support this type of QoS depending on the execution platform. In this type of component the traffic is treated better than the traffic without reservation (faster handling, more bandwidth on average, lower loss rate on average). This is a statistical preference, not a hard and fast guarantee. This type of traffic control and reservation is supported with different API depending on the operating systems (RAPI API in Solaris and Linux and GQoS in Windows 2000 [3]), and these APIs require different container implementations and architectures. Another type of container supports the hard quality levels (it is based on QoS Guarantee traffic control and reservations), which guarantees an absolute reservation of network resources. As previous component type, it requires two different implementations. In our model, client and component server must agree on the load that component can support and the amount of resources that they will use in their communications. A client must negotiate with the component the number of invocations per second that it will invoke each component method. The component can do the reservation that the client requests, it can reject it or it can provide a reservation with a lower bandwidth capacity (the number of invocations accepted will be less that the number required). A problem is that often, the component will invoke methods of other components to service the client invocation, and it will require the negotiation with its new servers to guarantee the client’s request. In this case the component requires the client’s information before it can negotiate with its servers. The server can use two strategies to negotiate with its servers, it can compute global resources for all its clients’ invocations and make a single reservation, or it can make specific reservations for each client. The negotiation process depends on the algorithms to be used [1][20]. We have developed and prototyped two simple negotiation algorithms: • Direct Reservation. In a first algorithm the server provides the negotiation requested when there are enough resources available. If there are not, the negotiation is rejected. This algorithm uses two methods for the specification of load requested: i) ‘bare bandwidth’ reservation, the negotiation parameters include the bandwidth reservation specification of invocation and return flows, and this bandwidths will be used for all

method invocation from this client to this component, and ii) ‘invocation description’ reservation, the client specifies the number of invocations per second for each component method, and the algorithm computes the reservation required. • Reservation with Private References. In this algorithm the client-server component specifies its server components, the methods of its servers that invokes for each of its methods, and the amount of invocations per method. The algorithm associates a private remote reference to each component server for each client in the negotiation process, computes the invocation frequency of each server component, and negotiates with the servers before to make the reservation that the client requests. If in any reservation process there are not enough resources the reservation is rejected and this frees the reservations done in the negotiation process. The algorithm establishes a private reservation for each component server, and will use the private reservation, when a new invocation arrives. This is supported automatically by the container, which updates the remote reference to be used when a new invocation arrives, before delegating the invocation to the business method. This algorithm can create race conditions when we execute two reservations in parallel and two reservations compete for the bandwidth of different interfaces, none of the reservation is admitted but the resources available would be enough for one of them.

2.2 Reservation Solutions Communication Methods

for

the

Component infrastructures use two types of middleware communication technologies: remote method invocation and message oriented services. The remote method invocation provides support for the facetreceptacle based communication and the message oriented services for the event sink-event source communication. Message oriented services provides support for the event driven computing, which is a good solution to support loosely coupled architectures. In these types of architectures, often, sender and receiver do not know anything about their receiver and sender; they only need to know the message format and the destination. Remote methods invocation is a good solution to support object-oriented distributed architectures. In tightly coupled technologies based on remote method invocations the application must know the remote application’s methods. Message oriented communication provides a good support for asynchronous communication, and remote method invocation for synchronous communication. In both technologies we must extend the remote references, connections and sessions concepts to provide QoS IP support. The structure of the communication middleware encapsulates

the IP socket and connection, which are the basic structures of QoS IP configurations; we must have access to the sockets and connections to do QoS IP configurations. The component container is the responsible to access to the reservation services associated to remote references, sessions and connections. Another problem of both techniques is the computation of the argument sizes (but when we use the bare bandwidth reservation introduced in this Section 2.1), which is required to do the reservation of flows (method invocation and return, or message sends). But both techniques have associated some particular adaptations. Remote method invocation requires a double reservation. The reservations of the invocation and return flows have associated different loads, which depends on the arguments sizes of methods. Both flows are associated to the same connection. In message communication we must take into account the reservations for the message provider (a messaging system that implements messaging services in addition to the other administrative and control functionality required of a fullfeatured messaging services). Our current implementations only support synchronous remote method invocations. EJB 1.1 does not include support of event communication, but new versions (EJB 2.0) support it. We are working in the extension of Java messaging services to support QoS IP facilities.

3. Examples of Component Executions with QoS support The examples that we are going to introduce have been executed in Windows 2000 and Solaris environments. The environment of Solaris 2.6 is two machines and one switch of 3Gb; the first is a Sun Ultra 1, 188MB of memory, 1 CPU UltraSparc, and one 10Mb/s Ethernet Interface; the second is a Sun Ultra 10, 248MB of memory, 1 CPU UltraSparc-II at 269Mhz, and one 10Mb/s Ethernet Interface. The configuration files of RSVP daemons divide the interface networks bandwidth in 70% (7Mb/s) for the reservation sessions and 30% (3Mb/s) for non-reservation sessions (the default session). The RSVP implementation used is RSVP0.5.2 [21]; we have modified this version to avoid the bandwidth borrow between reservations. Windows 2000 environment includes two machines and one switch of 3Gb; the first includes one Pentium III 600Mhz, Windows 2000 Professional, 260 MB main memory, 3Com 3C918 Fast Ethernet 100 Mb/s; the second includes 2 Pentium III 600Mhz, Windows 2000 Advanced Server, 260 MB, 3Com 3C920 Fast Ethernet 100 Mb/s. The QoS support is based on GQoS C library [2][3]. In both environments,

J2SE platform is jdk1.2.2 and EJB 1.1 is based on JOnAS [11].

3.3 Examples Description and Execution Results The Solaris example includes a QoSBean with an empty business method and the negotiation is the bare bandwidth reservation and the reservation is soft. Four clients make reservations of 200KB (c200), 100KB (c100), 50KB (c50) and 25KB (c25) and invokes the server method ten times every second with an argument of 20KB. The behavior of the clients is: date0 = current date () for second 0 to second 39 delay until date0 + second start = current date () for i=1 to 10 do invocation of server method (20KB) result[second] = current date () – start print result

Each client requites a bandwidth of 200KB to access to the server on time (the reservation for three clients is not enough). Figure 3 includes the execution results. The average response time of c200 is 0.6. The other clients have an average higer than 1 second (often, they cannot execute ten invocations in 1 second). Close to the instant 31 second there is a critical instant; the four clients try to execute their invocations at the same time. Control load policies of QoSBean and reservation negotiations improve the response time of clients with high reservations levels. Invocation latency (seconds)

2

1.8 1.6 1.4 1.2 1 0.8 0.6 0.4

5

10

30 25 20 15 instants of method invocation (second)

Figure 3. Control load response times.

35

40

Windows 2000 example is based on the class ‘AudioDevice’ of Java jdk1.2 library. Figure 4 represents the systems. AudioDevice class reads periodically audio data from an input stream and then it reproduces this data. If there is not data available the execution is delayed and the audio is reproduced noisily. Another thread (we will name it reader) must write the data in the stream (the data must be available before the ’AudioDevice’ thread requests it). In this example, both threads are executed in the same Windows 2000 system, and in the same JVM. The reader thread makes the remote method invocations to read the data located in another computer, which executes the EJB QoSBean component that provides access to remote files. This component provides methods to open a file and read a certain amount of bytes. reader writes the data into the stream in blocks of 4000Bytes. For the type of audio data that we use, the reproduction of this data block takes around 0.5sec. In this example, the reader calls to the QoSBean and writes in the stream until there is no more audio data available. The thread in ‘AudioDevice’ reads around 4000Bytes with a period of 0.5sec. Smaller quantities have a non-regular period. Each execution of this test is 40sec (320Kbytes).

64, 50, 40, 20, 16, 10, 4, and 2; these numbers of calls provides a global bandwidth of 8000Bytes/sec for all sizes. With scale 2 the reservation will be two times the bandwidth required for scale 1, for scale 5 is 5 times, and for scale 10 is 10 times. ‘invocations_description’ includes as reservation parameters the list of methods invoked, the number of invocations per second and a reservation scale factor. In this example the list includes a single method (read), the number of invocations per second, and scale factor that we have presented. The algorithms of reservation included into the service ‘invocations_description’, compute the bandwidth required to transmit the heads of RMI call and return streams, the arguments and the return data, the RMI protocol streams, and the TCP ACK packets. The bandwidth depends on the number of packets to transmit per second and the size of packets. In the example that we present, Window 2000 adds to the reservation requested the size of heads of TCP packets. The next Figure represents the time average required to read 4000Bytes of data for each argument size, and for the four scale factors. 600 500 400

latency of 300 200 4000B read

100 0

Switch 3Gb

reader

QoSBean 12.5MB/s

12.5MB/s

scale 2 scale 10

argument size

scale AudioDevice

scale 10 scale 2

scale 5 scale 1

Figure 4. Playing remote audio data.

Figure 5. Average of response times.

In this example the negotiation is based on ‘invocations_description’ negotiation algorithm. The reader thread has two configuration parameters. The first is the size of the arguments of the remote method invocation. A small argument size implies many more invocations. We have tested 10 argument sizes: 80, 100, 125, 160, 200, 400, 500, 800, 2000, and 4000 bytes. The number of invocations to read 4000Bytes for each size is 50, 40, 32, 25, 20, 10, 8, 5, 2, and 1. The second parameter is the scale of reservation factor that provides the support to make much more reservation than the amount required; bandwidth reservation associated to scale 1 is strictly the amount required to execute the remote invocations n times per second. The number of invocations per second for each argument size is 100, 80,

The Figure 6 represents three types of results: i) the response times to read 4000Bytes for argument size 200bytes, with scales 1, 2, 5, and 10, ii) the instants when the ‘AudioDevice’ threads start to read a new block of 4000Bytes, (these instants are represented on top of the bars, and in general, they are 500ms. The time required to consume 4000Bytes), and iii) the amount of time required by the reader task to read 320Kbytes. When the scale is 1 the data read finished at instant 40916ms, the average to read 4000 bytes (block read average) is 511 ms. When the scale is 2 the last read finished at instant 20508ms, and the block read average 261ms; for scale 5 the task finish in 8311ms, and the block read average is 120ms; and for scale 10 the task finish in 4346ms and the block read average is 70ms. When the scale is 1, the stream finished practically at the same time that the audio finished to

reproduce the last data stream; because of this the quality of the reproduction is not good enough. For the other scales the data is available earlier and it is accumulated in the stream. These tests have been executed in parallel with ttcp program (ttcp –l400 –n100000) that creates noise, and the responses are the same when the test is executed alone. ttcp is a tool, which can be used to measure end-to-end network transmission time. ttcp sends a sequence of test packets through a network then reports on the delay experienced by each packet. latency of 4000B read (ms)

1000 500 250 100 50 10 40200 1

20200

2 reservation factor

5 10

time

8200 4200

Figure 6. Impact of scale factor in response times.

3.3.1 Analysis of Execution Results In previous examples, we can see that QoSBean component type provides support for: 1. Reduce the interference of non-critical flows in the behavior of critical tasks. 2. Limit the network usage of some client’s flows. The server limits the number of invocations of it clients with the bandwidth reservation, if it makes a reservation less that the request of the client, the packet scheduler of the output interface in the client node will delay the output of the invocation packages. This strategy can be used in the server, when the resources available in the server are limited (e.g. it requires a high quantity of computation time for each method invocation, or it has too much access to a database). This limitation of the invocations not only limits the invocations in the server, it limits the traffic in the network too. 3. Reduce jitters of client’s invocation. The traffic control algorithms that support QoS Guarantee avoid the busty output of methods invocations. This property is useful to reduce the worst-case preemption times in other tasks. 4. The container based negotiation algorithms and the QoS specification facilities reduce the complexity of

business components. The container provides the support for the resource reservation and for the propagation of QoS requirements to other component servers. 5. The container limits the implicit software QoS infrastructure problems. The dependencies of protocols, OS and middleware QoS facilities are not well established yet, and they are in a continuous evolution, but this solution encapsulates it in the container.

4. Conclusions and future work Component infrastructures provide a good framework for the specification and support of QoS applications. These infrastructures make a clear separation of business and quality concerns, and limit the scope of the QoS infrastructure dependencies to the component container. It simplifies the QoS characterization of applications based on attribute-oriented configuration of component. We have shown practical solutions for the integration of QoS IP services into containers and examples for the support of jitter and latency qualities. Currently we study the introduction of CPU reservation and admission control in the container architectures and general methods for the definition of quality types and constraints in UML and their mapping into quality types supported by component descriptors. Finally we study how to extend the quality types description to provide automatic support for the generation of QoS monitoring.

5. References [1] T. Abdelzaher, E. Atkins and K. Shin. “QoS Negotiation in Real-Time Systems and Its Application to Automated Flight Control”. IEEE Transactions on Computers. Vol. 49, no. 11, November 2000.

[2] Y. Bernet. “Networking Quality of Service and Windows Operating Systems”. New Riders 2001.

[3] Y. Bernet, J. Stewart, R. Yavatkar, D. Andersen, C. Tai, B. Quinn and K. Lee. “Winsock Generic QoS Mapping (draft)”. ftp://ftp.microsoft.com/bussys/winsock/winsock2/gqos_spec.doc

[4] L. Blair, G. Blair, A. Andersen and T. Jones. “Formal Support for Dynamic QoS Management in the Development of Open Component-based Distributed Systems”. IEE Proceedings Software. Vol. 148 No. 3. June 2001.

[5] R. Braden, D. Clark, and S. Shenker “Integrated Services in the Internet Architecture: Overview”, Internet RFC 1633, June 1994.http://www.ietf.org/html.charters/OLD/intserv-charter.html

[6] D. Conan, E. Putrycz, N. Farcet and M. de Miguel, “Integration of Non-Functional Properties in Containers“. In Proceedings ECOOP’01 Workshop WCOP 2001. June 2001.

[7] L. DeMichiel, L. Yalinalp, and S. Krishnan. Java 2 Platform Enterprise Edition Specifications, v2.0. Sun Microsystems, 1999.

[8] M. de Miguel. “Solutions to Make Java-RMI Time

Predictable” In Proceedings of 4th International Symposium on Object-Oriented Real-Time Distributed Computing. ISORC’2001. IEEE, May 2001.

[9] M. de Miguel. “Integration of QoS Facilities into

Component Container Architectures” In Proceedings of 5th International Symposium on Object-Oriented Real-Time Distributed Computing. ISORC’2001. IEEE, May 2002.

[10] ECMA. Common Language Infrastructure (CLI). ECMA/TC39/TG3/2000/2 part 1, 2, 3, and 4. http://www.ecma.ch, October 2000. [11] Evidian. “Java Open Application Server (JOnAS)”. http://www.evidian.com/jonas. October 2001.

[12] K. Geibs. “Middleware Challenges Ahead” Computer IEEE. June 2001 [13] C. Hou, C. Han, and Y. Min. “Communication Middleware and Software for QoS Control in Distributed RealTime Environments“. In Proceedings Computer Software and Applications Conference. COMPSAC’97.IEEE 1997.

[14] V. Matena and B. Stearns. Applying Enterprise JavaBeans. Addison-Wesley, 2001.

[15] K. Nahrstedt, D. Xu, D. Wichadakul and B. Li. “QoSAware Middleware for Ubiquitous and Heterogeneous Environments“. IEEE Communications Magazine. Vol. 39, No. 11. Nov. 2001 [16] Object Management Group. CORBA Component Model Specifications,

July

1999.

http://www.omg.org/technology/

documents/ recent/ corba_iiop.htm

[17] U. Rastofer and F. Bellosa. “An Approach to Componentbased Software Engineering for Distributed Real-Time Systems“. In Proceedings SCI 2000 Invited Session on Generative and Component-based Software Engineering. IIIS 2000.

[18] R. Sessions. COM+ and the Battle for the Middle Tier. Wiley, 2000. [19] D. Schmidt, V. Kachroo, Y. Krishnamurthy and F. Kuhns. “Developing Next-generation Distributed Applications with QoS-enabled DPE Middleware”. IEEE Communications Magazine. Vol. 17, No. 10. October 2000.

[20] M. Shankar, M. de Miguel, and J. Liu. “An End-to-End QoS Management Architecture”. In Proceedings of Real-Time Application Symposium. RTAS’99. IEEE 1999. [21] Sun

Microsystems.

RSVP

Sources.

http://www-

nrg.ee.lbl.gov/cbq.html ftp://playground.sun.com/pub/rsvp

[22] Sun Microsystems. “Java Remote Method Invocation Specification” ftp://ftp.javasoft.com/jdk1.2/rmi-spec-JDK1.2.pdf [23] N. Wang, D. Schmidt, M. Kircher, and. K. Parameswaran. “Adaptative and Reflective Middleware for QoS-Enabled CCM Applications”. IEEE Distributed Systems Online Vol 2 No. 5. July 2001. [24] P.Wang, Y. Yemini, D. Florissi, P. Florissi and J. Zinky. “Application QoS Provisioning with Integrated Services“. IEEE Communications Magazine. September 1999. [25]Zhang, S. Berson, S. Herzog, and S. Jamin. “Resource ReSerVation Protocol (RSVP)- Version 1 Function Specification”. Internet RFC 2205. 1997. http://www.ietf.org/html.charters/rsvp-charter.html

[26] J. Zinky, D. Bakken, and R. Schantz. “Architecture Support for Quality of Service for CORBA Objects“. Theory and Practice of Object Systems. Vol. 3 No. 1. January 1997.