QoS-Reconfigurable Web Services and Compositions for High-Assurance Systems

Reconfigurability is an important feature of many modern adaptive application sys-tems, especially high-assurance systems. For example, intelligent vehicle control systems, avionic systems, space systems, and intelli-

gent video networks frequently require dynamic adapt-ability for failure of system components, reduced power levels, unexpected operating conditions, and so forth. Also, some systems are multiple-mission or mission-specific—that is, they must handle a class of missions that have similar system requirements but also require adaptations to satisfy mission-specific needs.

A service-oriented architecture (SOA) is an ideal vehi-cle for achieving reconfigurable systems that can select and compose services statically or dynamically to satisfy changing system requirements.

Much research has addressed service selection based on quality-of-service (QoS) criteria, such as reliability, real-time constraints, and accuracy.1,2 However, most system development processes specify QoS require-ments at the overall system level, and it is not clear how to derive the QoS goals for individual services. While researchers have explored the effective composition of a

group of services satisfying overall system QoS require-ments,3-7 many real-world applications have a limited set of alternative services to choose from. This is especially true for specialized application domains.

Reconfigurable services provide an alternative approach that can complement service selection techniques to sat-isfy static or changing system QoS requirements.3,8,9 For example, an image encoding service can process an image at different resolutions and compression ratios to offer time/space and quality tradeoffs. A decision service can compute the best solutions within a large solution space with computation-time and solution-accuracy tradeoffs. Reconfigurable services can increase the selection space and significantly help with QoS assurance.

We have developed a rule-based parameterization technique to convert components into reconfigurable services. Furthermore, we have developed QoS analysis and decision-making techniques to select reconfigurable as well as regular services to compose the system.

ReconfiguRable SeRviceS A QoS-reconfigurable service has externally visible,

configurable parameters that invokers can adjust. When

a service-oriented architecture (Soa) is an ideal vehicle for achieving reconfigurable systems

that can select and compose services statically or dynamically to satisfy changing system

requirements. The authors have developed a rule-based parameterization technique to convert

components into reconfigurable services.

I-Ling Yen, University of Texas at Dallas

Hui Ma, Cisco Systems

Farokh B. Bastani, University of Texas at Dallas

Hong Mei, Peking University

C o v e r f e a t u r e

48 Computer Published by the IEEE Computer Society 0018-9162/08/$25.00©2008IEEE

August 2008 49

adjusted, these parameters impact the service’s QoS.5 For example, if a service uses a relaxation algorithm to compute some result, the error margin can be a configu-rable parameter to control the tradeoffs between time and computation precision. Also, an image-processing service can adjust the image resolution to achieve image quality, computation, and communication tradeoffs. A security service can choose different encryption-key sizes to achieve computation and confidentiality protec-tion tradeoffs.

Facilitating the configuration of QoS-reconfigurable services requires specifying its QoS behaviors—that is, the

set of QoS attributes of interest, configurable parameters in the service, and QoS measures for different settings of the configu-rable parameters.

Existing SOA languages and their extensions do not support the specification of reconfigurable services. We define an XML-based extension to Web Services Description Language for the specification of the QoS attributes, configurable parameters, and QoS measure-ments of a reconfigurable service. Figure 1 shows the specification language schema.

The <QoS_attribute> and <configurable_parameter> tags define the set of QoS attributes and configurable parameters and their ranges. The <environment_param-eter> tag defines the parameters that need to be specified for measurement. For example, measuring time on dif-ferent CPUs might yield different results, so it is neces-sary to specify the CPU used for the measurement. The <measurement> tag specifies the actual measurement of the QoS behavior by attribute, unit of measurement, configurable parameters (or variables), and measurement data. Measurement data can be expressed as a single data item, a function, or an array in which the raw data is kept, depending on what is most appropriate.

•••

Reconfigurable service exampleWe use the Secure Real-Time Protocol (SRTP) service

to illustrate the concept of reconfigurable services and their respective QoS specifications.9 The service is built on an open source SRTP library—libSRTP—developed by Cisco (http://srtp.sourceforge.net/srtp.html). SRTP provides security, including confidentiality protection and data authentication, for both the SRTP sender and receiver. Since they are very similar, we only consider the SRTP sender here.

configurable parametersWe analyzed libSRTP and identified configurable

parameters for each SRTP session, the possible choices of which are given as follows:

Encryption algorithms for confidentiality protec-tion (EC): Null or AES_128_ICMEncryption key size (EKS): 128 bits or 256 bits Authentication algorithms (AU): Null or HMAC_SHA1 Authentication key size (AKS): 80 bits or 160 bits Authentication tag length (TL): 80 bits or 160 bits

(The parameter choices are simplified in this example, whereas the actual software can support more choices.) Both the encryption and authentication protocols have algorithm-selection and key-size parameters. For each of the two algorithm-selection parameters, we only con-sider two choices—one is a specific encryption/authen-tication algorithm and the other is Null (without any encryption/authentication). The authentication protocol also supports different authentication tag lengths (80 or 160 bits) for space overhead and security tradeoffs.

The SRTP service has additional configurable param-eters. Since it can support multiple sessions in parallel, different sessions can have different security settings. As Table 1 shows, with all the choices given there are 15 session types, each with a different security setting.

•

••

••

Figure 1. XML-based extension to WSDL for the specification of the QoS attributes, configurable parameters, and QoS measurements of a reconfigurable service.

QoS_behavior.DTD:<!ELEMENT QoS_behavior ( QoS_attribute, environment_parameter, configurable_parameter, measurement )> <!ELEMENT QoS_attribute (#PCDATA)> <!ELEMENT environment_parameter (#PCDATA)> <!ELEMENT configurable_parameter (#PCDATA)> <!ELEMENT measurement ( attribute+, unit, variables, (data | function | array) )> <!ELEMENT attribute (#PCDATA)> <!ELEMENT unit (#PCDATA)> <!ELEMENT variables (#PCDATA)> <!ELEMENT data (#PCDATA)> <!ELEMENT function (#PCDATA)> <!ELEMENT array (array_index, array_data)> <!ELEMENT array_index (#PCDATA)> <!ELEMENT array_data (#PCDATA)>

50 Computer

System performance, such as latency, can be con-trolled by setting an upper bound on the ratio of each session type. We consider two configurable parameters, REC2 and RAU22, which are the upper bounds for NEC2-*/NT and N*-AU22/NT, respectively. NT is the total number of sessions, and Nx is the number of sessions of type x. We use * as a wildcard symbol in the subscript (session type name). For example, NEC2-* is the number of ses-sions using the AES_128_ICM encryption algorithm regardless of which authentication algorithm is used.

QoS attributes. The basic QoS attributes for the SRTP service include the execution time (ET), the packet over-head (PO) for authentication, and processing latency as the packet reaches and leaves the SRTP server.

QoS behaviors. We measure SRTP service QoS behav-iors and maintain the data for analysis at composition time. First, we measure the execution time in CPU cycles for each type of session. The results are given in the last column of Table 1.

As Figure 2 shows, the XML specification file captures the SRTP’s QoS behavior. The PO is measured as the average overhead, average-PO. Also, all the subscripts are switched to array indices in the XML specification.

Rule-baSed ReconfiguRable SeRvice TRanSfoRmaTion

Though some services are designed to be QoS-recon-figurable, most are not. Frequently, a service could be reconfigurable, but its configurable parameters are not identified or well defined so that they cannot be exter-nally configured. This can greatly diminish the potential of achieving high assurance in adaptive systems when using these services. Thus, it is desirable to convert exist-

ing services into QoS-reconfigu-rable ones.

Adapting software for QoS tradeoffs has been an impor-tant research area for many application domains, but most techniques are manual-based, generally require extensive expe-rience, and are highly time- consuming.

We have developed a rule-based approach for automatic trans-formation of programs to make them QoS-reconfigurable. A rule base can capture a diverse range of expert knowledge and meth-ods that are flexible and easily extensible.

Reconfigurable service transformation

Generally, a Web service is a system consisting of service soft-

ware and server hardware. Here we consider a software system’s configurability, which is composed of compo-nents of various granularities. We focus on the method for parameterizing components to make them reconfigu-rable.10 Figure 3 shows the framework’s architecture.

Parameter identification. Parameter identification is the most challenging process in the service transformation framework. We use an expert knowledge base to analyze code segments and recognize identifiers that can be used as configurable parameters. Compiler techniques extract axioms about a code segment’s identifiers, statements, and program flow. Then, an inference engine with predefined rules identifies potential configurable code parameters. However, these identifiers might or might not have an impact on QoS. Thus, selected identifiers and their poten-tial impact on QoS are presented to the user, and the user can decide whether to consider each as a configurable parameter based on its QoS tradeoffs. Generally, it is not possible to identify a complete set of rules a priori for con-figurable parameter identification since each expert might possess a partial set of expertise. The rule-based approach can provide a repository of knowledge accumulated from multiple experts, and new rules can be easily added.

Program conversion. Once we determine which iden-tifiers are configurable parameters, we transform the code to accommodate them. The component converter invokes specific transformation routines preassociated with the rules to generate the parameterized component. The service converter replaces the original components with the parameterized components to form the new ver-sion of the service program. The specifications for the new configurable parameters are provided at this time and stored with the service.

Table 1. Configurable security parameters and session types for the SRTP

service.

Sessionsecuritysettings ET(CPU

Sessions EC EKS AU AKS TL #Sessions cycles)

NULL-NULL Null Null NNULL-NULL 14253NULL-AU11

80 80 NNULL-AU11 41962

NULL-AU12 HMAC 160 NNULL-AU12 42539NULL-AU21 _SHA1 80 NNULL-AU21 41939NULL-AU22

160 160 NNULL-AU22 42247

EC1-NULL AES 128 Null NEC1-NULL 34516EC2-NULL _128 256 Null NEC2-NULL 37213EC1-AU11 _ICM

80 80 NEC1-AU11 61835

EC1-AU12 HMAC 160 NEC1-AU12 61475EC1-AU21 128 _SHA1

80 80 NEC1-AU21 61505

EC1-AU22 160 NEC1-AU22 62589EC2-AU11 80 NEC2-AU11 63117EC2-AU12 256 HMAC

80 160 NEC2-AU12 63457

EC2-AU21 _SHA1 80 NEC2-AU21 63035EC2-AU22

160 160 NEC2-AU22 63656

August 2008 51

QoS data collection. When a QoS-reconfigurable service is used, its configurable parameter settings depend on the execution environment (static as well as dynamic), the composed system’s QoS requirements, and the parameter settings of other services. We use the parameter analyzer to analyze a service’s configurable parameters and generate different test settings. We then use a test data generator to input test cases for the ser-vice. Subsequently, we collect the service’s QoS behavior data and store it with the service.

configurable parameter identification rules We use two examples, Newton’s root-computation algo-

rithm and the factorial computation algorithm, to illustrate the configurable parameter-identification process.

newton’s algorithm. Newton’s algorithm is a relax-ation approach for finding the roots of a given polyno-mial f(x). The algorithm starts with an initial guess x0 and repeatedly computes xn+1 = xn – f(xn)/f, (xn) until xn+1

– xn is within an error margin ε. The error margin ε can control the tradeoffs between the execution time and the output precision.

The general rules for identifying configurable param-eters for time and output precision tradeoffs are as

follows. We identify a loop statement L with guard condition G. G should be a comparison operation with two operands Oc and Oe (in either order). Oc should be a constant in L, whereas Oe can be an arithmetic expres-sion with its value changed in L. In other words, at least

Use

r int

erac

tion

QoS test

QoS measurements

Parameter identification

Programconversion

QoS datacollection

Parameteridentifier

Serviceconverter

Test datagenerator

Parameteranalyzer

ComponentconverterRule base

Newversion ofthe service

Originalservice and itscomponents

Configurableparameters

QoSdata

Figure 3. Service transformation framework.

Figure 2. XML specification file. The file captures QoS behavior.

<?xml version=”1.0”?> <!DOCTYPE QoS_behavior SYSTEM “QoS_behavior.dtd”> <QoS_behavior> <QoS_attribute>ET</QoS_attribute> <QoS_attribute>average-PO</QoS_attribute> <QoS_attribute>PL</QoS_attribute> <environment_parameter>OS = LINUX</environment_parameter> <configurable_parameter>EC = (NULL, AES_128_ICM)</configurable_parameter> <configurable_parameter>EKS = (128 bits, 256 bits)</configurable_parameter> <configurable_parameter>AU = (NULL, HMAC_SHA1)</configurable_parameter> <configurable_parameter>AKS = (80 bits, 160 bits)</configurable_parameter> <configurable_parameter>TL = (80 bits, 160 bits)</configurable_parameter> <configurable_parameter># Sessions (N(T))</configurable_parameter> <configurable_parameter>N(NULL-NULL)</configurable_parameter> ………… <configurable_parameter>N(EC2-AU22)</configurable_parameter> <measurement> <attribute>average-PO</attribute> <unit>bits</unit> <variables>N(T), N(NULL-NULL), …, N(EC2-AU22)</variables> <function>average-PO = 80*(N(*-AU11) + N(*-AU21)/N(T) + 160*(N(*-AU12) + N(*-AU22)/N(T)</function> </measurement> <measurement> <attribute>ET</attribute> <unit>CPU Cycles</unit> <variables>EC, EKS, AU, AKS, TL</variables> <array> <array_index>EC = (NULL, AES_128_ICM), EKS = (128 bits, 256 bits), AU = (NULL, HMAC_SHA1), AKS = (80 bits, 160 bits), TL = (80 bits, 160 bits)</array_index> <array_data>ET = (14253, 41962, 42539, 41939, … …)</array_data> </array> </measurement> </QoS_behavior>

52 Computer

one of the variables in Oe should be on the left side of an assignment statement in L.

These rules can be formally expressed in Prolog or other logical programming languages and can be applied to many relaxation algorithms.

factorial computation. For factorial computation, function F computes the factorial of a given input n using recursion. If a program needs to repetitively invoke F, then some temporary results from F can be stored to reduce the computation time of future invocations of F. If all the temporary results are stored, the space require-ment can be excessive. Thus, a configurable parameter δ can be used to control the space and time tradeoffs—that is, only Fkδ is stored. For example, if δ = 100, we store F100, F200, F300, …, and F290 can be computed from F200. (Note that F can be a common recursive function instead of the specific factorial function.) When a service detects that F is frequently called (other than due to recursion), the parameter identification process can be used to determine whether F is such a recursive function and subsequently convert it to a reconfigurable component. The general conceptual rules to identify such functions are given as follows:

A function F(n1, n2, …, nk) calls itself m times in the form F(n1

1, n21, …, nk

1), F(n12, n2

2, …, nk2), …, F(n1

m, n2

m, …, nkm).

For all i, j, nij is an integer and the computation of

nij depends only on ni and a fixed set of constants or

variables with constant values in F.

implementation. We have implemented the component parameterization framework and applied it to the adap-tive multirate (AMR) speech codec library (www.3gpp.org/ftp/Specs/html-info/26071.htm), which contains 112 components. From a manual inspection, we identified 23 configurable parameters. Our parameterization tool iden-

•

•

tified 26 configurable parameters, including all 23 manu-ally identified parameters and three additional parameters that we determined to be undesirable. This implies a 100 percent recall rate with 88 percent precision.10

QoS analySiS foR SeRvice comPoSiTion wiTh ReconfiguRable SeRviceS

QoS analysis in service composition involves the selec-tion of services such that the QoS behaviors of the com-posite system satisfy QoS requirements. To achieve a certain task, we can decompose it into a set of abstract services—each possibly having multiple choices of dif-ferent concrete Web services. Concrete Web services can be selected to instantiate abstract services so that the composed system will best satisfy the overall QoS requirements. Various algorithms have been proposed for service selection.3,6,7

Reconfigurable services provide additional selection space for the satisfaction of QoS requirements. During QoS analysis for service composition, we need to also decide the parameter settings in the reconfigurable ser-vices. Due to the large search space (potentially infinite when continuous configurable parameters are involved), we have developed a modified genetic algorithm for effi-cient decision making.9 Figure 4 illustrates the general analysis process based on the genetic algorithm concept.

In this QoS analysis process, we first determine a set of candidate configurations, which include specific choices of concrete Web services for the abstract services and their parameter settings (if any).

To compare the selected configurations, we derive the composed system’s QoS behaviors from the QoS behav-iors of the individual concrete services for each configu-ration. Such derivation is highly dependent on the QoS attributes being considered. For system reliability analy-sis, for example, we must consider the testing profiles in addition to the reliabilities of the individual services. For timing analysis, we must consider the response latency of the individual services as well as the communication costs among them.5 Thus, we develop a repository of QoS-behavior-derivation algorithms for different QoS attributes. The inputs to these algorithms are the XML specifications describing QoS behaviors of individual candidate services.

The best candidate configurations are selected using the genetic algorithm. GA operators, such as mutation and crossover, are used to modify the candidates to avoid local-optimal solutions.11 After a prespecified number of iterations, the best selections of services and their con-figurable parameter settings are determined.

caSe STudy We present a media security gateway case study to

validate the concept of reconfigurable services and QoS-based composition analysis.9 The media security gateway (MSG) provides security and media transcoding for VoIP

For a fixed number of iterations

Determine a group of candidate configurations

Select the set of Webservices for grounding

Determine theparameter settings for

reconfigurable services

Use genetic algorithm to select and generate a new group of candidate configurations

Derive the QoS behaviors of the configurations

Final configurations that determinethe selections of services and parameter

settings of selected reconfigurable services

Figure 4. The process of QoS analysis in service composition.

August 2008 53

sessions. Four services are needed to compose the sender MSG. The packet accepting (PA) service receives audio packets from the clients and per-forms admission control. The AMR encoder (AE) service takes the audio packets from the PA and compresses the audio frames in the audio packets to dif-ferent bit rates. After the compression by the AE, the RTP packetization service (PS) packs the data from multiple frames into packets and passes the packets to the SRTP sender. SRTP-S encrypts and signs each packet if needed and sends it out using the real-time protocol. The MSG for the receiver side also consists of four services, and the processing sequence is the reverse of the sender side.

QoS Specification of the Reconfigurable Services

In the AMR speech encoder, the encoding mode is a configurable parameter that controls QoS tradeoffs between three QoS attributes: data rates, execution time, and voice quality. Table 2 summarizes the QoS information.

The data rate is measured in bits per second and impacts communication cost. The execution time is measured in million CPU cycles per frame. The voice quality factor considered here is the loss-impairment fac-tor (Ie),

12,13 which has values between 1 through 100 (1 being the best).

The AMR encoder serves many sessions, each of which can have a different encoding mode. Nmi is the number of sessions that are in the encoding mode i. The bounds for Nmi, 1 ≤ i ≤ 8, are configurable parameters in the AMR encoder service.

The packetization service considers four QoS attri-butes: execution time, frame delay, packet overhead, and actual packet loss probability. This service packs frames into larger packets and thus induces a delay in the deliv-ery of some frames. The packet overhead includes the RTP header (96 bits per packet) and the payload header. The actual packet loss probability differs from the net-work-packet loss probability, which is solely determined by the physical media, in that it factors in compensation mechanisms such as retransmission.

This service has seven configuration parameters. We can pad media frames in one of two ways: octet-aligned mode (OA = 1) or with the entire packet (OA = 0). The latter results in smaller audio packets, but requires more execution time relative to the former. N is the number of frames per packet. A larger N results in a lower band-width requirement, but longer frame delays.

The forward error correction (FEC) mode can be set to 1 (with FEC) or 0 (without FEC). Fn and Fm,

representing the number of packets and the number of media packets in the FEC block, are configurable parameters with integer values. The retransmission sliding window (RSW), robust sorting (RS), and cyclic redundancy check (CRC) flags can also be set to 1 (with) or 0 (without). Using them can increase packet overhead, execution time, and transmission time, but it reduces the actual packet loss probability. (Note that we consider packets not delivered on time or containing errors to be lost packets.)

QoS attributes and requirements for the composed mSg

We consider two system-level QoS attributes for the MSG: the voice quality and bandwidth require-ments. The rating factor R represents each session’s voice quality.13 R is determined by loss impairment (Ie), delay impairment (Id), and configurable param-eters for encoding mode (AMR encoding) and actual packet loss rate (packetization). Id is determined by the total delay including total execution time of all services and transmission latency. The configurable parameters—encoding mode, actual packet loss rate, and packet overhead from SRTP, AMR encoding, and packetization, respectively—impact the bandwidth (BW) requirement.

The system QoS requirements include two objec-tives—maximize R and minimize BW—and two con-straints—REC2 ≥ 70 percent and RAU22 ≥ 60 percent.

experimental resultsWe mapped the QoS analysis problem for the case study

to the genetic algorithm and computed the solutions using our modified NSGA-II algorithm. Figure 5 shows the Pareto-optimal solutions satisfying the constraints and tradeoffs between the two-system-level QoS attributes.

T he experimental results confirm the effectiveness of the reconfigurable services and the QoS analysis process. Different parameter settings of the recon-

figurable services can offer system QoS tradeoffs. The QoS analysis process can effectively select the preferred solutions. Note that each solution is a configuration and has corresponding parameter settings for each recon-figurable service. We pick, for example, solution 10 as

Table 2. QoS information.

Encodingmode Values

0 1 2 3 4 5 6 7Data rates 4.75 5.15 5.90 6.70 7.40 7.95 10.2 12.2Execution time 6.78 5.45 6.06 7.26 6.93 7.24 7.14 7.41Ie 43.3 40.6 36.5 34.4 30.2 27.1 27.1 25.0

54 Computer

a final solution and its configurable parameter settings are specified as follows:

Packetization service: OA=1; N=24; FEC=0; Fn=5; Fm=1; RSW=1; RS=0; CRC=0 AMD encoder: Nm0/NT=0.58; Nm1/NT=0.39; Nm2/NT=0.01; Nm3/NT=0.00; Nm4/NT=0.01; Nm5/NT=0.00; Nm6/NT=0.01; Nm7/NT=0.00; SRTP sender: Actual REC2 = 0.72; Actual RAU22 = 0.65

The media security gateway case study provides exam-ples of concrete reconfigurable services and validates the QoS analysis process for best determining service selec-tions and configurable parameter settings for achiev-ing overall system objectives and constraints. Further research will include the highly challenging composi-tional analysis of important QoS attributes such as reli-ability and security. ■

References 1. S. Rao, “A Model for Web Services Discovery with QoS,”

ACM SIGecom Exchanges, vol. 4, no. 1, 2003, pp. 1-10. 2. M.A. Serhani et al., “A QoS Broker-Based Architecture for

Efficient Web Services Selection,” Proc. IEEE Int’l Conf. Web Services (ICWS 05), IEEE Press, 2005, pp. 112-120.

3. T. Gao et al., “Toward QoS Analysis of Adaptive Service-Oriented Architecture,” Proc. IEEE Int’l Workshop Service-Oriented System Engineering (SOSE 05), IEEE Press, 2005, pp. 227-236.

4. D. Thissen and P. Wesnarat, “Considering QoS Aspects in Web Service Composition,” Proc. IEEE Symp. Computers

•

•

•

and Communications (ISCC 06), IEEE Press, 2006, pp. 371-377. 5. I-L. Yen, T. Gao, and H. Ma, “A Genetic Algorithm-Based QoS Analy- sis Tool for Reconfigurable Service- Oriented Systems,” Advances in Machine Learning Application in Software Engineering, D. Zhang and J. Tsai, eds., IDEA Group Publishing, 2006. 6. T. Yu, Y. Zhang, and K-J. Lin, “Effi- cient Algorithms for Web Services Selection with End-to-End QoS Con- straints,” ACM Trans. on the Web, May 2007. 7. L. Zeng et al., “QoS-Aware Middle- ware for Web Services Composition,” IEEE Trans. Software Engineering, May 2004, pp. 311-327. 8. “Real-Time Transport Protocol (RTP) Payload Format and File Storage For- mat for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate

Wideband (AMR-WB) Audio Codecs”; www.faqs.org/rfcs/ rfc3627.html.

9. H. Ma, “QoS-Driven Composition Analysis for Component-Based System Development,” PhD dissertation, Univ. of Texas at Dallas, 2007.

10. J. Zhou et al., “On the Customization of Components: A Rule-Based Approach,” IEEE Trans. Knowledge and Data Eng., Sept. 2007, pp. 1262-1275.

11. H. Ma et al., “QoS Analysis for Component-Based Embed-ded Software: Model and Methodology,” J. Systems and Soft-ware, June 2006, pp. 859-870.

12. Y. Huang, J. Korhonen, and Y. Wang, “Optimization of Source and Channel Coding for Voice over IP,” Proc. IEEE Conf. Multimedia and Expo (ICME 05), IEEE Press, 2005.

13. ITU Telecommunication Standardization Sector, “The E-Model, A Computational Model for Use in Transmission Planning,” Recommendation G.107; www.itu.int/itudoc/itu-t/ aap/sg12aap/history/g107/g107.html

I-Ling Yen is a professor of computer science at the Uni-versity of Texas at Dallas. Her research interests include fault-tolerant computing, secure and survivable systems, parallel and distributed systems, grid and peer-to-peer computing, and component-based design of distributed adaptive systems. Yen received a PhD in computer science from the University of Houston. She is a member of the IEEE. Contact her at ilyen@utdallas.edu.

Hui Ma is a software engineer at Cisco Systems. His research interests include embedded systems develop-ment techniques and tools, component-based design of embedded systems, and quality-of-service-driven compo-sition. Ma received a PhD in computer science from the

78 82 86 90 94

2 3 4 5 6 7 8 9 1011

12131415

161718

1920

2e4

8e4

14e4

20e4

26e4

Voice quality

Band

wid

th re

quire

men

t (by

tes/

s)

1

Figure 5. Pareto optimal solutions for the case study system.

August 2008 55

University of Texas at Dallas. Contact him at huima@cisco.com.

Farokh B. Bastani is a professor of computer science at the University of Texas at Dallas. His research interests include various aspects of the ultrahigh dependable sys-tems, especially automated software synthesis and testing, embedded real-time process-control and telecommunica-tions systems, and high-assurance systems engineering. He received a PhD in computer science from the Univer-

sity of California, Berkeley. He is a member of the IEEE and the ACM. Contact him at bastani@utdallas.edu.

Hong Mei is a professor of computer science at Peking University, China. His research interests include software engineering environments, software reuse and software component technology, distributed object technology, and programming languages. Mei received a PhD in com-puter science from the Shanghai Jiao Tong University. Contact him at meih@pku.edu.cn.