2087 Proling of Web Services a user and are a part of the QoR concept. Users’ feedback (assessment) understood • as their satisfaction from the returned result (not from the interface through which they communicate with a service) expressed in adenedscale.However,itwouldbevery difcult,ifnotimpossible,tocollectsuch information from users. They would rather provide an overall evaluation of both a service implementation and real service effects. The QoR concept is domain specific. In fact, it is very difficult, if not impossible, to define a measure that would hold for all possible services. It is not the case with QoE, which is independent of the domain and rather easy to compute. The quality of execution relates to the underlying technology (i.e., technical and network-related aspects). The following properties may be a part of the QoE model: • Response latency: Time needed for the control data to get to the service and back to the client. • Maximal throughput: How many re- quests a provider is able to process in a given time period. • Execution duration:Timeneededtofull a user request (time between sending a re- quest and receiving an answer). • Execution price: Amount of money a user needs to pay in order to use an interface to the service. • Service robustness: The ability of a ser- vice to act properly if some of the input pa- rameters are missing or incorrect (e.g., the wrong coordinates or incorrect data types, etc.). The following table summarizes our short discussion on the differences between the QoR and QoE concepts. Another aspect that needs to be mentioned is Table 3. RoutePlanning service example (Noll, 2004) Service name Route Planning Service Description Creates a route description for the customer’s coordinates and the given attraction. The route de- scription consists of a coloured high-resolution picture and a textual description. Nonfunctional Properties Service Name Map24RoutePlanningService Provider Name Map24.de Information Quality High Functional Properties Preconditions Location ls, Location lg Positive Effects RouteDescription rd, hasRoute (rd, r) Table 4. Comparison of QoR and QoE Quality of Result Quality of Execution Quality of a real service Quality of an interface (WS implementation) Domain specific Domain independent Very hard to measure and monitor Rather easy to measure and monitor In most cases has no impact on QoE May have an impact on QoR 2088 Proling of Web Services the difference between an execution price and a service price. A service price is the amount of money a user has to pay for a real service; for example, when using a route planning it is a price of the attraction ticket (e.g., ticket to the cinema) (it influences QoR). In this case, an execution price is the amount of money we have to pay for using the interface to book tickets, not a price of the ticket itself (it influences QoE). When buying a book at Amazon.com, the execution price is 0 (using the Amazon Web page to search and order is free), but the service price is the price of the book and the delivery costs. In case of informa- tion services (such services where output returned by a service is equal to the effect we wanted to obtain) it is rather unclear whether the price we have to pay for the information is a service price or execution price, and the classification may depend on many factors. Most of the current initiatives aiming at pro- viding definitions and descriptions of quality dimension address only some generic parameters (mostly network related), such as execution price and duration, availability and reliability, and so forth (Liu, Ngu, & Zeng, 2004; Menasce, 2002; Zeng, Benatallah, Dumas, Kalagnanam, & Sheng, 2003), and do not differentiate between the QoR and QoE concepts. More parameters, considering also QoR, are presented by O’Sullivan et al. (2002), but they are not widely used in practice. Moreover, QoR properties are not considered in most of the methods trying to compute the values of non- functional properties. Therefore, in the remaining part of this chapter, whenever a reference to QoS is made, it refers to those quality parameters of a service that are computable (therefore, in most cases they exclude QoR parameters). Whenever a clear differentiation needs to be made between quality of result and quality of execution, respec- tive terms are used. METHODS AND APPROACHES TO DERIVE VALUES OF NON- FUNCTIONAL PROPERTIES The simplest way to derive values of NFP is to rely on service providers advertising this information. However, taking directly the values advertised by a service provider is not advisable. It requires users to trust the accuracy of the values declared by service providers. However, service providers do have an interest in overestimating NFP of their services, so a solution allowing measurement of (programmatically) the values of NFP for verifi- cation purposes is needed. Moreover, values of non functional parameters are often assumed to be constant in time and space (service location), but they may change, depending on the details of the service request, execution environment, and so forth. For example, the response time of a Web service may be less than 5 minutes during the working days, but during the weekends, it may be less than 1 minute as the interest in the particular service decreases. To avoid the problems of accuracy of non- functional properties’ values given by service providers, some other methods to derive (or verify) their values are needed (Abramowicz et al., 2005). Ran (2003) proposes a QoS model using a QoS certifier to verify published QoS criteria. The approach requires all Web services providers to advertise their services with the QoS certifier. However, this approach does not take into account the dynamism of the environment and the fact that the values of a Web service change in time. The approach does not provide, for example, methods to update the QoS values automatically and it lacks the details regarding the verification process. Sheth, Cordoso, Miller, and Kochut (2002) propose a QoS middleware infrastructure that requires a built-in tool to monitor metrics of NFP automatically. Such an approach requires the willingness of service providers to give up some of their autonomy. It may also require service providers to cover execution costs. Moreover, if 2089 Proling of Web Services the polling interval is set to too long, the QoS will not be up-to-date. If the polling interval is set to too of a short time, it might incur a high perfor- mance overhead. A similar approach emphasizing a service reputation, is proposed by Maximilien and Singh (2002a, 2002b). Another approach obtains information on val- ues of QoS parameters from the users themselves. When collecting quality information from the users feedback, each user is required to evaluate QoS (and at the same time QoR) of the consumed service. The main advantage of this approach is that QoS values can be computed based on the real user experience (up-to-date runtime execu- tion data). The main disadvantage is the fact that a user judgment is not objective; users use dif- ferent definitions of quality, have different past experiences, and so forth. In other approaches called “a’posteriori ap- proach” (Casati, Castellanos, Dayal, & Shan, 2004) QoS values are solely collected through an active monitoring. The monitoring can be performed by a user, service broker or platform, dedicated QoS registry (Kuropka & Weske, 2006; Liu et al., 2004), or an already mentioned QoS certifier (Ran, 2003). The data are collected from the actual consumption of a service and therefore are accurate and objective. One avoids the necessity to install rather expensive middle- ware in order to constantly check large numbers of service providers. However, there is a high overhead since QoS must be constantly checked for a large number of Web services. On the other hand, the approach that relies on a third party to rate or endorse a particular service provider is expensive and static in nature. When the service related data collection is envi- sioned through, for example, workflow monitoring or user feedback, another important issue is how to compute the values of quality-related parameters from the collected data. There are a few initiatives to solve the problem. One of them (Maximilien & Singh, 2004) suggests performing an analysis of past executions of atomic and composite services by using data mining and workflow log mining techniques. Moreover, some statistical methods can be applied as well (Liu et al., 2004). Workflow management systems are a very important infrastructure for complex applications. They usually register the start and completion of activities as well as other events that occur during execution. This information is stored as workflow log files (Aalst, Zhang, Shanahas, & et al., 2003) that further are processed using work- flow and process mining techniques. The goal of workflow mining is to find a workflow model on a basis of a workflow log (Aalst et al., 2003). In turn, process mining is a method of distilling a structured process description from a set of real executions (Aalst et al., 2003). Many methods to perform these tasks were developed (e.g., proba- bilistic workflow mining, or Petri nets [Aalst et al., 2003]) and may be successfully applied also to the Web services area. In the next section, the Web services profiling, being an alternative method to derive the values of non-functional properties of a Web service, is presented. WEB SERVICE PROFILING, SERVICE PROFILE, AND ITS ELEMENTS Service profiling is a process of computation of values of non-functional properties. The main goal of service profiling is to create service profiles of atomic and composite services. A service profile may be defined as an up-to-date description of a selected subset of non-functional properties of a service. It not only characterizes a service but also allows for services comparison based on aggregated values of non-functional parameters and, in consequence, selection of a service most suited to the requirements of a user. In order to compute the values of non-func- tional properties, service profiling needs first to collect information on services executions, aggre- gate it, and then derive required information. The 2090 Proling of Web Services raw data may come from multiple data sources. Every source has its own specific purpose and provides different information. The following possible sources of information that further feed the profiling system with appropriate data may be distinguished: service registries, monitoring data, data coming from service level agreements (SLA) storing information on contracted QoS values, feedback from service consumers about obtained service quality, and so forth. The aim of the Web services profiling is to perform fair and open NFP computation. There- fore, as the service execution history data are the most objective and reliable source of information on the service, they are in fact the primary source of information. The Web services profiling does not perform only the core workflow mining. It analyses log files in order to obtain data needed for the profiling process, but, in addition, it takes advantage of the raw data collected from service properties defined in SLA, published by service providers, and obtained from users’ feedback. For instance, it compares contracted values from SLA against these from execution. In consequence, it is possible to check to what extent the agreement between a provider and a consumer is fulfilled. Moreover, appropriate algorithms may discover which values of particular parameters are, for example, likely to be guaranteed by providers. Service profiling is, in our opinion, a trust- worthy method of service quality measurement. It does not rely on providers’ declarations about quality of their services. Statistical procedures used to compute values, data coming from execution logs, and so forth, assure high reliability of results of service profiling. The information declared initially by a service provider might be verified by what is stated in SLA, being approved by its provider and then by the results of the analysis of execution data. This kind of verification increases the reliability of our mechanism and we do not need a third party to verify the correctness of the values of profile parameters as procedures are transparent and parameters precisely defined. In addition, a service profiling mechanism is generic (a number of parameters it operates on may be easy modified) and independent of the service description provided by a service provider. Service Profile As already stated, a service profile may be de- fined as an up-to-date description of a subset of non-functional properties of a service. It allows for services comparison based on non-functional parameters and selection of the service most suited to the requirements of a user. In order to create an adequate service descrip- tion one needs to consider that the collected or derived data, taken into account by a service profiling mechanism, may differ in terms of its stability in time. Regarding the type of informa- tion on services, we can distinguish three main categories: • Static Information: Values of service properties that do not change over time, such as name of the service, and are pro- vided by a service provider. • Semistatic information: Values of service properties that may change over time, such as quality of service and price. This infor- mation changes periodically, but not very often. • Dynamic Information: Values of service properties that may be (and usually are) different in every execution of the service. It relates mainly to the network related quality of service. From the profiling point of view, the most interesting parameters are the dynamic and semistatic ones. In addition, parameters that are estimated and finally included in a service profile may be simple reflections of service behaviour or adequately aggregated to show an overall quality of a service. Therefore, we consider two groups of non-functional properties: 2091 Proling of Web Services • Simple Properties: Values of service properties that can be monitored on an individual level. This is mostly informa- tion presented in service level agreements. Such properties may include, for example, latency time, execution cos,t and so on. • Derived Properties: Where additional manipulation is needed (performed by a serviceprolingsystem).Suchproperties may include reliability, availability, or, in our case, a synthetic indicator. Our belief is that a service profile should be easily interchanged between building blocks of SOA systems. In order to allow for simple mes- saging and processing of profiles, we decided to represent them as XML documents. The greatest advantage of this solution is that XML schema is easily verifiable and interpretable by machines. A standardized form of a service profile makes it easy to be adapted in industrial applications. Because of flexibility of service profiling, the set of parameters included in a profile may vary due to different quality parameters considered in different IT systems. The exemplary structure of a profile (as seen in Figure 1) was derived based on the requirements defined in the already men- tioned ASG project. The excerpt of a service profile schema is pre- sented in the Listing 1. Please note that for some parameters, average, minimal, and maximal values are determined. These values may be helpful when a user precisely expresses the user’s needs on qual- ity parameters. Therefore, a user may specify that the user is looking for a service where parameters meet accurately expressed criteria. Additionally, a service profiling system may offer provider profiles that show how, in gen- eral, services of a given provider behave. They may be useful to represent the overall quality of services provided by a concrete provider. These profiles are more quality-oriented, whereas service profiles are more performance-oriented. In this case, quality orientation means that time-related QoS parameters are less important than the fact whether a given service was accessible or produced expected results. Figure 1. Service profile structure - class diagram 2092 Proling of Web Services Service Profile Computation The most popular information sources for service profiling are execution logs. These log files usu- ally have a strictly defined structure (Aalst et al., 2003), so the automated processing of them is feasible and algorithms are rather straightforward. For example, the execution duration may be eas- ily counted as a difference between end time and start time of a service execution (these values are stored in the log file). Of course, to compute the values of other parameters other methods may be required. For instance, in order to compute the value of a reliability parameter, a profiling system needs to keep track of service execution states. In our approach, we consider the finite state machine of Web service transitions as shown in the Figure 3. Figure 2. Listing 1: Excerpt of exemplary service profile schema 2093 Proling of Web Services Therefore, it is possible to determine the num- ber of started services that were completed. Thus, the assessment of reliability parameter is not a problem. A similar approach is used for acces- sibility parameter computation. For more details please refer Kowalkiewicz, Ludwig, Kaczmarek, and Zyskowski (2005). In the Table 5 we present an exemplary set of non-functional properties and outline methods of their computation. When creating a service profile the time horizon is taken into account. A user may need a particular instance of a service only once in a given point of time or may need to use the service a few times in a given time period. Therefore, the horizon of the prognosis should be considered. In the first case, short-time information about a service is important, and in the second case, more attention should be paid to the long-term behaviour of a service, taking into account also more historical data. Another challenging issue is the set of non- functional parameters that should be used to describe composite services and the way to compute values of these parameters. The possible solutions may be found presented by Liu et al. (2004), Maximilien and Singh (2004), and Zeng et al. (2003). They suggest using a similar set of attributes, as for atomic services and computing their values using statistical methods. Composite service profiles are the aggregations of atomic service profiles. A description of a com- posite service profile is very similar to a service profile, because it treats a composite service like an atomic one. That is why the structure of its profile does not differ significantly from the profile of an atomic service. However, the values of some Figure 3. Types of Web services events. Based on Aalst et al. (2003) Table 5. Some parameters of service profile and their computation methods Parameter name Computation method Execution duration Difference between end and start time of service execution Accessibility Number of successful invocations divided by all the invocations in a given time period Reliability Number of successful executions divided by all of the executions in a given time period Price Average price in a given period of time Synthetic indicator Statistical aggregation of all considered parameters denoting an overall quality of a service 2094 Proling of Web Services parameters are computed as statistical measures based on characteristics of atomic services in- cluded in the composed service. Moreover, not all parameters that are computed for an atomic service profile are included in composite service profiles. For example, the response latency value is only computable for atomic services. In order to compute a value of quality pa- rameters of a composite service we can proceed twofold: The execution log mining may be per-• formed in order to compute values of pa- rameters using methods similar to these for atomic services; A composite service execution plan may • be used to compute hypothetical value of quality parameter. Such plans are usually described using business process execution language for Web services (BPEL4WS) language. First, the average values for each atomic service included in the composition are computed, then the plan is analysed, thecriticalpathisidentied,andthehy- pothetical value is computed. For instance, the execution duration of the composite service is computed as a sum of execution durations of services being on the critical path. Other calculations include analysis of workow patterns,determination ofhow many times services were executed (in case of loops), and so forth. Details about such computation are given by Kowalkiewicz et al. (2005). It can be very interesting to rank services ac- cording their quality. In order to do that, a method that would allow one to compare objects (in our case, services) with regard to different properties that describe these objects was defined. Our deci- sion was to take advantage of the multiple criteria analysis (MCA) that ideally fitted to our needs. We used the MCA method to rank services based on their quality attributes. This ranking was cre- ated by computing a synthetic indicator reflecting the overall service quality. Then, it was possible to compare the values of synthetic indicators of several services and make a choice between them. The detailed description of MCA and the procedure to compute the value of a synthetic indicator is described by Abramowicz, Haniewicz, Kaczmarek, and Zyskowski (2006b). Dynamic Service Profiling in the Adaptive Services Grid Project Taking into account the issues discussed in the previous section, the architecture of the service profiling system should consist of at least a few components. It should include the repository that will store the data gathered by the system and should have component(s) responsible for com- munication with the data sources. Moreover, it should provide interfaces that allow all interested parties to ask queries. Finally, it should have the profiling mechanism, responsible for analysing the data and deriving/computing the values of parameters, to be included in a service profile. As an example of the architecture of service profiling system, the dynamic service profiling component of the Adaptive Services Grid project, may be presented. The main goal of the ASG project (Kuropka & Weske, 2006) was to develop a proof-of-concept prototype of a platform for adaptive services discovery, creation, composi- tion, enactment, as well as negotiations and service profiling. In order to support the above-mentioned interactions, the ASG platform and mechanisms require the ability to differentiate and compare different services and service substitutes (services having the same functionality). There are some requirements that need to be met in order to make the service differentiation feasible. First, the non- functional parameters must be taken into account, as every customer perceives the service not only from the side of what functionality it gives, but is also interested in non-functional properties of the service. The next issue is to deliver a QoS model 2095 Proling of Web Services that everybody would accept. Such a standard- ized QoS model is the first step to the agreement on monitoring mechanisms, common SLAs, and other elements that should be a part of every ma- ture marketplace. The last challenge is to create adequate description of a service that will give a user hints about the distinctive features of service substitutes. Thanks to the monitoring, it should be possible to analyse the information coming from service executions, SLA violations, and so forth. Based on the execution data and users’ prefer- ences, it is reasonable to create a service profile which reflects QoS values of a given service in a considered time horizon. Moreover, the user should be capable of ranking these profiles and choosing the most suitable Web service. Such a mechanism is implemented in the Adaptive Services Grid platform (Kuropka & Weske, 2006) using a dynamic service profiling (DSP) mechanism. The ASG service delivery process is presented in the figure below. The architecture of a dynamic service profiling (see Figure 5) system, being a part of the entire ASG platform, consists of a few components (Abramowicz, Kaczmarek, Kowalkiewicz, & Zyskowski, 2006): • Data collector, which is responsible for collecting data (by either a push or a pull method) from different sources, process- ing them, and saving properly aggregated to the DSP repository. Service proler,which is responsiblefor• deriving QoS attributes to answer requests. TheServiceprolercreatesanup-to-date proleofaservice(oraprovider),when- ever it receives a query. Two types of que- ries may be distinguished: a request for a prole of composed service, taking time horizon into consideration; and a request forprolesandarankingofasetofatomic services, taking time horizon into consid- eration.Whencreatingproles,theservice prolerusesthefollowingdataaboutser- vices: data from the provider’s declaration (service registry), and values of service attributes form the past execution (DSP repository). In order to create a prole, the appropriate values of characteristics, depending on the prognosis horizon, are computed. Then, based on the computed values a synthetic indicator for a service is created. As an interaction with a user is not Figure 4. Service delivery process in the ASG. ©Krause, 2005 (used with permission) 2096 Proling of Web Services implemented, default user preferences are used. After computing the indicators for all of the services returned for the given que- ry, services can be compared and the best ofthemcanbeidentied. DSP repository, which is the internal per-• sistent data storage fed by the data collector and responsible for storing all data relevant toserviceproles.Onlythedatacollector can change information in the DSP reposi- tory. Other subsystems have read-only ac- cess to the repository. Event Manager, whichhandlesworkow• events. The event manager is the subcom- ponent responsible for processing work- oweventsandreceivingexecutionlogs. If any crucial information is included in such an event, it is passed to the data col- lector for further analysis. As verified in the prototype implementation within the ASG project, such an architecture ful- fils goals and requirements of a service profiling system. SUMMARY This chapter familiarizes users with the idea of Web services profiling. As a background, the current initiatives in the field of Web services description, especially non-functional properties and methods to derive the values of these proper- ties, were presented. Moreover, the readers were introduced to different approaches to the quality- of-service concept. The focus of the chapter was placed on Web service profiling successfully implemented within the ASG system. A service profile, in its final state, aggregates all measured values of quality parameters to give a user the holistic view on a service quality. Taking into account information from profiles, it is possible to select the most suitable service, with regard to the user-specific quality expectations. REFERENCES W3C. (2004). Owl-s: Semantic markup for Web services. Retrieved May 26, 2008, from http:// www.w3.org/Submission/OWL-S/ W3C. (2007). WSDL 2.0. Retrieved May 26, 2008, from http://www.w3.org/TR/wsdl20 Figure 5. Architecture of DSP system [...]... Collaud, G., & Jones, C ( 199 7) CZWeb: Fish-Eye Views for Visualizing the World-Wide Web In Proceeding of the 7th Int Conf on Human-Computer Interaction (HCI International 97 ) (pp 7 19- 722) Elsevier, Amsterdam Floyd, R., & Housel, B ( 199 8) Mobile Web Access Using eNetwork Web Express IEEE Personal Communications, 5(5), 47–52 doi:10.11 09/ 98.7 297 24 Fox, A., Gribble, S D., & Chawathe, Y ( 199 8) Adapting to Network... T9, T 19, receiver} T5 sender,T5 27 0 .90 4 { sender, T10, T20, T5} {T1, T2, T3, T4, T6, T7, T8, T9, T 19, T15, receiver} T4 sender,T4 27 0 .90 5 { sender, T10, T20, T5, T4} {T1, T2, T3, T6, T7, T8, T9, T 19, T15, receiver} T3 sender,T3 23 0.76 6 { sender, T10, T20, T5, T4, T3} {T1, T2, T6, T7, T8, T9, T 19, T15, T14, receiver} T2 sender,T2 23 0.76 7 { sender, T10, T20, T5, T4, T3, T2} {T1, T6, T7, T8, T9,... Using Infrastructural Proxies: Lessons and Perspectives ( 199 8) [Springer Berlin/Heidelberg.] IEEE Personal Communications, 5(4), 10– 19 doi:10.11 09/ 98.7 093 65 Fox, A., Gribble, S D., Chawathe, Y., Brewer, E A., & Gauthier, P ( 199 7) Cluster-Based Scalable Network Services In Proceeding of the 16th ACM Symp On Operating Systems Principles (pp 78 91 ) Saint-Malo, France Ganek, A G., & Corbi, T A (2003) The... T7, T8, T9, T 19, T15, T14, T12, T13, receiver} T1 sender,T1 23 0.76 8 { sender, T10, T20, T5, T4, T3, T2, T1} {T6, T7, T8, T9, T 19, T15, T14, T12, T13, T11, receiver} T11 sender,T1, T11 23 0.76 9 { sender, T10, T20, T5, T4, T3, T2, T1, T11} {T6, T7, T8, T9, T 19, T15, T14, T12, T13, receiver} T13 sender,T2, T13 23 0.76 10 { sender, T10, T20, T5, T4, T3, T2, T1, T11, T13} {T6, T7, T8, T9, T 19, T15, T14,... {T6, T7, T8, T9, T 19, T15, T14, receiver} T14 sender,T3, T14 23 0.76 12 { sender, T10, T20, T5, T4, T3, T2, T1, T11, T13, T12, T14} {T6, T7, T8, T9, T 19, T15, receiver} T8 sender, T8 20 0.66 13 { sender, T10, T20, T5, T4, T3, T2, T1, T11, T13, T12, T14, T8} {T6, T7, T9, T 19, T15, receiver} T7 sender, T7 20 0.66 14 { sender, T10, T20, T5, T4, T3, T2, T1, T11, T13, T12, T14, T8, T7} {T6, T9, T 19, T15, receiver}... ( 199 9) WEST: a Web browser for small terminals Proceedings of the 12th annual ACM symposium on User interface software and technology (pp.187 196 ) Asheville, North Carolina, United States Chandra, S., Ellis, C., & Vahdat, A (2000) Application-Level Differentiated Multimedia Web Services Using Quality Aware Transcoding IEEE Journal on Selected Areas in Communications, 18(12), 2265–2544 doi:10.11 09/ 49. 898 736... Quality Aware Transcoding IEEE Journal on Selected Areas in Communications, 18(12), 2265–2544 doi:10.11 09/ 49. 898 736 Chandra, S., & Ellis, C S ( 199 9) JPEG Compression Metric as a Quality Aware Image Transcoding Second Usenix Symposium on Internet Technologies and Systems (USITS 99 ) (pp 81 92 ) Boulder, CO Chang, C Y., & Chen, M S (2002) Exploring Aggregate Effect with Weighted Transcoding Graphs for... & Gauthier, 199 7) For the purpose of content adaptation, the profile of an intermediary would usually include a description of all the adaptation services that an intermediary can provide These services can be described using any service description language such as the JINI network technology (JINI, 199 8), the Service Location Protocol (Guttman, Perkins, Veizades, & Day, 199 9), or the Web Service Description... the device to be dropped during trans-coding The third adaptation approach is the proxybased approach (Chandra & Ellis, 199 9, Chandra, Ellis, & Vahdat, 2000, Floyd & Housel, 199 8, 2101 On the Use of Web Services in Content Adaptation Fox, A., Gribble, Chawathe, Brewer, & Gauthier, 199 7), where an intermediary computational entity can carry out content adaptation on the fly, on behalf of the server or... 5(6) JINI network technology (TM) ( 199 8) Http:// java.sun.com/product/JINI Katchabaw, M., Lutfiyya, H., & Bauer, M ( 199 8) Driving resource management with applicationlevel quality of service specifications, (pp 83 -91 ) ACM Press Lei, Z., & Georganas, N D (2001) Context-based Media Adaptation in Pervasive Computing On Proceeding Can.Conf on Electr and Comp Engg (pp 91 3 -91 8) Toronto, Canada Lum, W Y., & . Ellis, 199 9, Chandra, Ellis, & Vahdat, 2000, Floyd & Housel, 199 8, 2102 On the Use of Web Services in Content Adaptation Fox, A., Gribble, Chawathe, Brewer, & Gauthier, 199 7), where. language such as the JINI network technology (JINI, 199 8), the Service Location Protocol (Guttman, Perkins, Veizades, & Day, 199 9), or the Web Service Description Language (WSDL, 2002). A. data making trans-coding a computationally very expensive task (Chandra & Ellis, 199 9, Han et al., 199 8). To address this challenge, some trans-coding services have been implemented in hardware