A Business Model for Dynamic Composition of Telecommunication Web Services

Transcription

1 WEB SERVICES IN TELECOMMUNICATIONS A Business Model for Dynamic Composition of Telecommunication Web Services Rajesh Karunamurthy and Ferhat Khendek, Concordia University Roch H. Glitho, Ericsson and Concordia University This article is an extended version of the article presented at IEEE SCC 2006, under the title A Novel Business Model for Web Service Composition. ABSTRACT composition is a mechanism for creating new s from existing Web services. composition enables rapid service creation by reusing existing services. Dynamic composition is composition at runtime. A business model defines the different parties involved in service provisioning and their relationships. However, the existing business models are not suitable for composition. This article proposes a novel business model for dynamic composition that is an extension of the standard business model. The proposed model is demand-driven, where services can be dynamically composed based on the demand for them. We introduce new business roles and new interactions. We have provided a UDDI-based implementation of our new model by proposing extensions to the subscription API of UDDI. We have developed a proof-of-concept prototype, and have made some preliminary performance measurements. The performance analysis shows that the UDDI extensions incur acceptable performance penalization. INTRODUCTION A is a software system designed to support interoperable machine-to-machine interactions over a network. It has an interface described in a machine-processable format, specifically Web Service Description Language (WSDL). Other systems interact with the Web service in a manner prescribed by its description using Simple Object Access Protocol (SOAP) messages, typically conveyed through HTTP [1]. For tutorial level information on s the reader can consult reference [2]. composition is a technique by which new services can be created by reusing available services. A potential example of a composed telecommunication is a dating service. The semantics of the dating service could be used to create a call between near-by willing users with matching profiles; the service could also send pictures of partners using Multimedia Messaging Service (MMS). A presence can be used to determine the willingness of users, and users location information can be obtained from a location. An MMS could be used to send the pictures using multimedia messaging. Finally, a call control would be used to create the actual call between the users. Depending on when the composition occurs, composition can be broadly classified as static (proactive) or dynamic (reactive). In static composition, the basic services to be composed are chosen at design time. The services to be composed are selected at runtime in dynamic composition, and the composition logic is also created at runtime. Dynamic composition is particularly challenging because the environment changes frequently: when new services appear, old services retire, and other services evolve. It should be noted that all compositions can be classified as either static or dynamic. Several solutions have been proposed for these two types of composition. For instance, Business Process Execution Language (BPEL), an XML-based language that supports businessprocess based service composition, is a popular static composition solution [3]. References [4, 5] discuss other solutions for composition. According to the Telecommunication Information Networking Architecture Consortium (TINA-C), a business model describes the different parties involved in service provisioning and their relationships [6]. Business models are very important because they are usually used as the starting point for standardization. Telecommunication and business models have been proposed and are currently in use. However, the existing business models do not support composition. This article proposes a novel business model for dynamic composition. The proposed model is an extension of the standard business model of s and is inspired by the TINA business model. The model is demand-driven, where services can be dynami /07/$ IEEE IEEE Communications Magazine July 2007

2 Consumer (a) Broker Retailer Communication Figure 1. Telecommunication business models: a) TINA; b) Parlay. cally composed based on their demand from the requesters. We introduce new business roles in this model, and also bring in new interactions between the different roles. We have provided a Universal Description Discovery and Integration (UDDI)-based implementation, and extensions to the subscription application programming interface (API) of UDDI for this implementation. We built a proof-of-concept prototype, and have also made some preliminary performance measurements. In the next section, the state-of-the-art business models are presented and evaluated. The proposed business model is discussed in detail in the third section, followed by implementation of the model, its prototype, and performance analysis. The last section contains our conclusions. THE STATE OF THE ART IN BUSINESS MODELS In this section we first derive requirements for the business models to support composition. We present the different existing business models, and then analyze the business models with respect to the derived requirements. REQUIREMENTS FOR BUSINESS MODELS TO SUPPORT WEB SERVICE COMPOSITION Third party service Static composition support The first requirement is that the business model should support static composition. Static composition will give service s an opportunity to create (design) composed services offline and provide them for the requesters. Dynamic composition support The next requirement is that dynamic composition should also be supported. This gives a demand-based service provisioning aspect to s. Both static and dynamic compositions should be supported because they are functionally different and have different goals. Allows requests for services not found in the The third requirement stipulates that the business model should allow the requester to ask for services, describing the type of service they need, which they did not find in the. We assume that the service the requester needs has no prestored descriptions in the, nor have they been published in the earlier. This requirement is necessary Subscriber in TINA Enterprise operator Client application End user in TINA (b) Service subscription Service usage Retailer in TINA Framework operator because service s cannot create and store descriptions of all the potential services the requesters might require in the. Some requested services can be created by composition only when they are requested. Shows who does the composition and where Because composition is an essential activity, clearly showing which role performs the composition and where the actual composition is done in the business model is the fourth requirement. Currently, for instance, some assume that the composition is done by the requesters, and others assume it to be the responsibility of the s or the. Allows new players The final requirement is that since composition has the potential for new business opportunities, the business model should allow extensions to accommodate new players. For example, there can be some entities that do not have the capability to compose services, but they should be able to contribute by providing (basic) services for composition. EXISTING BUSINESS MODELS We classify business models into two categories: telecommunication and business models, which are presented next. Telecommunications Business Models TINA and Parlay are the two main business models in the telecommunication community. TINA is a set of specifications, developed between the telecommunication and information technology industries, for defining a common architecture and also provisioning telecom and information services [7]. TINA uses the business model as a starting point for other specifications by defining the roles and interfaces. A simplified business model without the interactions of the business roles is shown in Fig. 1a. It defines five business roles: consumer, retailer, broker, third party service, and communications. The interactions that take place between the roles are called reference points, and consist of a set of interfaces. The consumer is the service user (end user) or an entity that has an agreement for service usage (subscriber). Note that the end user is not necessarily the subscriber. For example, the enterprise can be the subscriber and the employees the end users. The retailer is the entity that provides the services, and it also has an agreement with the subscriber TINA is a set of specifications, developed between telecommunication and information technology industries, for defining a common architecture, and also for provisioning telecom and information services. IEEE Communications Magazine July

3 The enterprise operator is an entity that subscribes to the Parlay services by having a business agreement for service usage with the framework operator. The initial contact point for service discovery is the framework operator, which also handles subscriptions. Find requester End user in TINA Client application in Parlay Broker in TINA Framework operator in Parlay Bind (a) Publish Retailer in TINA No direct mapping in Parlay Figure 2. business models: a) standard ; b) CPXe. for service usage. The broker provides information to find other parties and services. A third party service supports retailers or other third parties with services. It has a business agreement with the retailer and no direct agreement with the subscriber. A specialized role is a special category of an existing business role, and it has a specific set of responsibilities that are quite different from the responsibilities of its generalized role. In TINA, content is a specialized role. Content is a specialization of the third party service business role that is exclusively focused on content generation (e.g., movie production companies). A communication owns or manages the network. An entity can be in two different but related business roles at the same time. For more details, refer to [6]. Parlay is a set of open technology-independent APIs for accessing telecommunication capabilities, and it simplifies development of telecom-based applications [8]. The Parlay business model, inspired by the TINA business model, treats services as service capability features (SCFs). Parlay s business model is presented in Fig. 1b. It describes three business roles: client application, enterprise operator, and framework operator. The client application consumes or uses Parlay s SCFs. In Parlay, functionalities offered by service capabilities such as call control and presence are called SCFs. The SCFs can be accessed using standard APIs. The enterprise operator is an entity that subscribes to the Parlay services by having a business agreement for service usage with the framework operator. The initial contact point for service discovery is the framework operator, which also handles subscriptions. The Third Generation Partnership Project (3GPP) uses the Parlay business model for providing service capability features for applications, where it is called Open Service Access (OSA) architecture [9]. In 3GPP concepts like service capabilities and SCFs are used as defined by Parlay. Note that in Fig. 1b, for each business role in Parlay, the corresponding business role in TINA is provided. Reference [10] provides more information on the Parlay business model. Find requester Service locator Bind (b) Publish Catalog Web Service Business Models architecture [1] can also be considered a business model, as it clearly describes the different roles and their interactions in providing Web services. What we refer to as the standard Web service business model is shown in Fig. 2a. The three business roles in the domain are requester,, and. The requester is an entity that wishes to use the s owned or offered by the. The puts the s and requesters in contact. The business roles use agents to communicate with each other, and use publish, find, and bind interactions. The publish interaction is used by s to publish s in the, and requesters use the find interaction to discover the s from the. The bind interaction is used by requesters to access the s offered by the s. It should be noted from Fig. 2a that for each role in the business model, the corresponding business role in the TINA and Parlay business models is specified. We present an illustrative scenario using the business model. Suppose that there are three service s, A, B, and C, where A provides a simple credit card authorization service. We assume that B provides a conferencing, and C a dating. All three service s use the publish interaction to publish their services in D, which we presume to be a service. The Web service business model assumes that the s and requesters have the necessary information to interact with the. Now, if a service requester E wants a dating, it will use the find interaction to search D for the service. Consequently, service requester E will discover dating service C. Using the information obtained from D, requester E will bind to the dating service offered by C. The standard business model has been extended for specific purposes. For instance, Common Picture exchange environment (CPXe) [11] extends the standard Web service business model to provide and search for low-level (fine-grained) information that cannot be provided by service registries like UDDI. Information like where to get a t-shirt printed with my vacation picture that is one 38 IEEE Communications Magazine July 2007

4 Requirement Table 1. Comparative analysis of existing business models. kilometer from my home and open at some specific hours cannot be offered by UDDI, because its data structure does not support this type of fine-grained information. CPXe is an initiative by the digital photography industry that leverages the s paradigm for the automation of manipulating, printing, and sharing digital images. The business model of CPXe is shown in Fig. 2b. The business model describes two new entities: the service locator and the catalog. The service locator interacts with the (UDDI) and the catalogs to find specific services. The catalogs provide a standard way to obtain detailed information about products and services for locators and requesters. The locators and catalogs can be accessed using standard APIs. ANALYSIS OF THE BUSINESS MODELS The business models are analyzed in Table 1 with respect to the five proposed requirements. It is clear from the table that telecommunication business models (TINA and Parlay) satisfy only one requirement. Although TINA uses the concept of composition, it does not support providing composed services statically or dynamically in the business model, as it does not realize the potential of composition at the business model level. For the same reason, it does not show clearly who does the composition and where it is done. TINA also does not allow the requesting of services that are not found in the. On the other hand, Parlay does not support the concepts of composition and at all, so it does not support the first four requirements. As CPXe is an extension of the standard Web service business model, it clearly satisfies the same two requirements as the standard model. The standard business model does not support dynamic service composition. However, it should be mentioned that service s can offer statically composed services to requesters using the standard model. The standard model does not allow non-existing services in the to be sought by requesters, nor does it show clearly who does the composition and where it is done. To conclude, the current business models do not support many of our requirements. They are only offer-based models, while a demand-driven extension will be required to handle both static and dynamic composition. Telecommunication business models Static composition support No Yes Dynamic composition support No No Allows requests for services not found in the No No Shows who does the composition and where No No Allows new players Yes Yes business models THE PROPOSED BUSINESS MODEL In this section the proposed business model along with the business roles are discussed first, and then the interactions of the business roles are presented. THE BUSINESS ROLES The TINA-inspired business model we propose introduces three new roles and six new interactions. TINA was selected because it has sound business model concepts, such as third party service and role specializations, that are applicable to the telecommunication and information technology industries, specifically in the domain. We propose two specialized roles and one new role. The specialized roles are the composer and composition, and the new role is the third party. The proposed business model is shown in Fig. 3, where the three new business roles and six new interactions are shown using italics and dotted lines. Note that in Fig. 3 the specialized roles are contained within their generalized roles. A particular specialization of the business role is that of composer, which is exclusively focused on composing services, both proactively (statically) and reactively (dynamically). Composers do not necessarily own any services. It should be noted that this role is similar to the role of content in the TINA business model. We propose a new business role called the third party service, whose main aim is to support the composer business role with Web services that can be used to compose complex services. This role is similar to and inspired by the role of third party service in the TINA business model. Generally, third party services are primitive services that are typically used in the composition of complex services, rather than directly used by requesters. However, third parties can also provide requesterusable simple services for composition. For example, a presence service can be provided as a third party service, which can also be used by requesters. It should be noted that any service that could be built with two or more simple services can qualify as a complex service. For example, a presence-based call forwarding service composed of call forwarding and a presence service can be called a complex service. TINA was selected because it has sound business model concepts, such as third party service and role specializations, that are applicable to the telecommunication and information technology industries, specifically in the domain. IEEE Communications Magazine July

5 requester Find Register Inform Publish Get Give Bind composition Locate composer Figure 3. The proposed business model for composition. Put Third party Bind The main difference between the and the third party service is that the third party service does not provide s for requesters, and cannot have any business agreements with the requester business role. However, third parties do provide s for composers and can have business agreements with them. We also propose a specialization of the Web service business role as a composition, which is focused on allowing third parties to publish their s and assisting composers in discovering published s. Similar to all business models, one entity can play several roles at the same time. For example, a third party service can also play the role of. INTERACTIONS OF THE BUSINESS ROLES The six new proposed interactions are register, inform, get, give, put, and locate. We also reuse some of the interactions proposed in the standard business model, without changing the semantics, to support some of the new business roles. Dynamic Web Service Composition Using Interactions The scenario of dynamic Web service composition in the business model can be explained using interactions. We assume that the requester wants a presence-based call forwarding service that is not in the. We discuss the set of steps to allow the requester to receive the dynamically composed service. We assume that one third party service publishes a call forwarding service, and another third party publishes a presence service in the composition using the put interaction. We also assume that the composer uses the register interaction to register with the, and to be informed about the services sought by requesters but not listed in the. When the requester tries to find the presence-based call forwarding service from the, it gets a response no available services, but the requester can provide an endpoint where the composer may contact it. Subsequently, the uses the inform interaction to notify the composer about the requester s endpoint and its need for the presence-based call forwarding service. At this stage, the composer only knows that a requester needs a presence-based call forwarding service, but this information is not sufficient to compose the service. Therefore, the composer uses the get interaction to communicate with the requester, which provides the complete service request using the give interaction. Now the composer knows the exact specification of the presence-based call forwarding service, so the composer uses its composition technique to compose the service using the third party services that can be found using the locate interaction. Finally, the composed service is provided to the requester. The Register and Inform Interactions The main motivation behind the register and inform interactions is to alert the composer about the possibility of performing dynamic service composition. The composer uses the register interaction to tell the that it is a composer and would like to be informed about services that requesters are unable to find in the. This gives the composer an opportunity to create the services the requesters are looking for on the fly. To provide notification to the composer about missing services that requesters are seeking but are not present in the, the inform interaction is defined between the and the composer business role. The Get and Give Interactions The get and give interactions are used to transfer composition-specific information from the requester to the composer in order to compose the exact services the requester needs. After the composer receives notification about the missing services sought by the requester(s) using the inform interaction, the composer has only limited information about the service the requester needs. This information is not sufficient to compose services, so the composer uses the get interaction to query the requester for the complete information needed to perform the composition. The requester then uses the give interaction to specify the details of the composition request. The Put and Locate Interactions The main motivation behind the put and locate interactions is to enable third party services to be published and found. The third party service publishes its s using the put interaction in the composition. Composers find the services of third party service s from the composition using the locate interaction. It should be noted that these interactions have been developed to keep the semantics of the find and publish interactions unchanged, although the new interactions are inspired by and similar to the old ones. Reused Interactions from the Standard Web Service Business Model The composer business role interacts with the and the requester business roles using the standard publish and bind interactions, like the. Composers bind to the third party service s using the bind interaction, 40 IEEE Communications Magazine July 2007

6 which is the same bind interaction (with the same semantics) used by the requester to interact with the. IMPLEMENTATION We have implemented a subset of our model. In this section we first discuss the UDDI-based implementation of the business model. We propose extensions to UDDI to implement the register and inform interactions. We then present the prototype. Finally, the prototype evaluation is discussed. The register and inform interactions are key because they are the initial two interactions that would typically happen in the business model during (dynamic) service composition. Moreover, the information acquired from these interactions is needed by the other interactions. THE PROPOSED EXTENSIONS TO UDDI VERSION 3 UDDI is the standard in the domain. UDDI version 3 [12] is the latest version of UDDI, with some significant new features like subscription using the subscription API. Generally, the subscription API is used for monitoring and notification of events that occur in the UDDI. The API supports both asynchronous notification and synchronous change tracking. Subscribers use the subscription API to receive notification about changes, additions, and deletions to the UDDI data structures. This API needs to be extended in our case, because the composers must be notified about services that requesters need and are not available in UDDI. We propose three new methods to the subscription API for realizing the register and inform interactions. Two methods support asynchronous communication and the other supports synchronous mode of communication. The methods are quite straightforward, and they are inspired from the subscription API methods. subscribe_seekedservices To subscribe, unsubscribe, and resubscribe for the data that the requesters are seeking and that are not found in the UDDI. It realizes the register interaction in asynchronous communication mode. The expiration value parameter of the method will determine whether the subscription request is for a new subscription, to renew (modify) an old subscription, or to delete an existing subscription. The method may return a structure with subscription-related values, depending on which values are changed from the requested values. If all the requested values are accepted, an empty message is returned as the response. notify_seekedservices To notify composers with information, such as services that requesters are unable to find in the. It realizes the inform interaction in asynchronous communication mode. The notifications are provided using the template specified in the subscribe_seeked- Services method. A successful notification will return an empty message. get_seekedservices To synchronously retrieve the services for which requesters are looking and are not found in the UDDI. This method realizes both register and inform interactions in synchronous communication mode. The message will return a structure that will have the information required by the composer to communicate with the requesters, along with the details of the requester queries that did not retrieve a result. We also propose to extend the find_service method of the inquiry API that is used by the requesters to find services from the UDDI. We extend its business logic to update the database with service requests that do not produce any results. We propose adding a new argument requesteraddress to the find_service method, which will be used by requesters to specify an endpoint where potential composers can communicate with them. Similarly, we would add a new attribute note to the response returned to the requester for the unavailable-service query. This attribute will provide information about the composers that may contact the requesters to help them to receive the requested service. PROTOTYPE We implemented the synchronous (get_seeked- Services) method of the extended subscription API, and the extensions to the find_service method. The proof-of-concept prototype is an extension of juddi. juddi [13] is an open source Java implementation of UDDI that currently supports UDDI version 2. However, it supports some of the data structures and classes needed for the subscription API of UDDI version 3. juddi is developed as a Java Web application, and it needs an external data store to manage the data. We also extended the juddi s JSP console (to support the new get_seekedservices method) that can be used as a client to test juddi. The reason for implementing only the get_seekedservices method is that juddi only supports synchronous communication at this time. The software architecture of the implemented extensions to juddi is presented in Fig. 4. The core module is the Subscription service (extensions) handling engine that handles the (get_seekedservices) request, implements the business logic to retrieve information about the sought-for services using database handlers, and creates the response using the data structures. The four types of data structures are used by XML and database (DB) handlers to hold the information required to process the request and to create the response. XML handlers marshal (encode) and unmarshal (decode) the XML data. The DB handlers communicate with the external database. The Subscription service servlet extends the HTTP servlet that receives the request from the Registry servlet and engine module, through which the request enters the UDDI after passing through the SOAP layer. The utilities and error handlers are used by all the other modules (not all links are shown in Fig. 4) for general assistance and to handle errors. Except for the Registry servlet and engine module, and the Utilities and error handler module, all other modules are extended with new classes and methods to support the extensions. It should be noted that the subscription service engine is implemented from scratch. We propose three new methods to the subscription API for realizing the register and inform interactions. Two methods support asynchronous communication and the other supports synchronous mode of communication. IEEE Communications Magazine July

7 PRELIMINARY PERFORMANCE ANALYSIS As mentioned before, we have implemented only a part of the business model, so we were not able to perform experiments where services are composed on the fly. To date, we have implemented the register and inform interactions, but we need to implement the other four interactions to create the services dynamically. The experiments we carried out were to find services that do not exist in UDDI (with and without the extended operation). We also did experiments where the composer synchronously retrieves information about services sought by the requesters that do not exist in UDDI. The performance measurements were taken with the extended juddi running on an Apache Tomcat 5.5 Web server. The juddi used MySQL Server 5.0 as a DB. The whole system ran on a Pentium GHz machine with 1 Gbyte of RAM and the Windows XP platform. The extended JSP console of juddi was used as the client. We used another machine with exactly the same configuration (2.99 GHz P4 with 1 Gbyte RAM running XP) to run the client remotely from the same LAN. The console used SOAP over HTTP for communication with the Functionality Response time (ms) Network load (kb) find_service without extended operation find_service with extended operation Registry servlet and engine XML handlers get_seekedservices operation Table 2. Network load and response time of the extended (juddi). Subscription service servlet Subscription DS Helper DS Data structures Request DS Response DS Database handlers Utilities and error handlers Subscription service (extensions) handling engine Figure 4. Software architecture of the extended (juddi). juddi. Table 2 shows the response time and network load of the find_service method with and without extended operation, and also for the get_seekedservice method. These values are average measurements over 15 trials. These measurements were not taken immediately after the Web server was (re) started, as this incurs more response time because of the Java virtual machine initializations. From analysis of the measurements it is clear that the extended function of find_ service penalizes the response time (increased by 44.8 ms), but not the network load (increased only by 0.1 kbyte). The get_seekedservices method incurs an acceptable response time and network load, which is comparable (with an increase of just 2.8 ms response time and 0.1 kbyte of network load) to the values of the find_service method without extended operation. It is clear from this preliminary analysis that the extensions to the UDDI are indeed very useful from the service requester s perspective, with acceptable penalization to the s performance when the synchronous communication mode is used. CONCLUSION composition is emerging as a mechanism for rapid s creation by reusing available services. Business models define business roles and their interactions in providing these (composed) services. Based on a set of proposed requirements to support Web service composition, we have assessed the stateof-the-art business models and pinpointed their shortcomings. We have proposed a novel business model for dynamic composition with new roles and new interactions. This model is an extension of the standard business model. We proposed extensions to the subscription API of UDDI to implement (a part of) the business model, and we prototyped some of the proposed UDDI extensions. The preliminary performance analysis shows that the extended UDDI operations impose acceptable performance degradation in synchronous communication mode. In the future, we will work on implementation schemes for the get, give, put, and locate interactions, and prototype them. Performance analysis of these prototypes will aid in further and more thorough evaluations of the business model. Extension of the current prototype with the asynchronous mode of communication is also planned. ACKNOWLEDGMENTS This work was partially supported by the Natural Sciences and Engineering Research Council (NSERC) of Canada and Ericsson Canada. REFERENCES [1] Web Services Architecture Specification, W3C Working Group Note, Feb. 2004, last accessed 7 June [2] E. Newcomer, Understanding Web Services: XML, WSDL, SOAP, and UDDI, Addison Wesley Professional, [3] J. Pasley, How BPEL and SOA Are Changing Web Services Development, IEEE Internet Comp., vol. 09, no. 3, May/June, 2005, pp IEEE Communications Magazine July 2007

8 [4] N. Milanovic and M. Malek, Current Solutions for Web Service Composition, IEEE Internet Comp., vol. 08, no. 6, Nov./Dec., 2004, pp [5] J. Rao and X. Su, A Survey of Automated Web Service Composition Methods, Proc. 1st Int l. Semantic Web Services and Web Process Composition Wksp., LNCS 3387, Springer, 2004, pp [6] TINA Business Model and Reference Points, v. 4.0, May 1997, bm_rp.pdf, last accessed 7 June [7] H. Berndt, T. Hamada, and P. Graubmann, TINA: Its Achievements and Its Future Directions, IEEE Commun. Surveys & Tutorials, vol. 3, no. 1, 2000, pp [8] A. J. Moerdijk and L. Klostermann, Opening the Networks with Parlay/OSA: Standards and Aspects Behind the APIs, IEEE Network, vol. 17, no. 3, May/June 2003, pp [9] 3GPP TS , Open Service Access (OSA), June [10] ETSI ES Version 1.1.1, Parlay 5.0, Part 3: Framework, Apr [11] T. Thompson, R. Wiel, and M. D. Wood, CPXe: Web Services for Internet Imaging, IEEE Comp., vol. 36, no. 10, Oct 2003, pp [12] UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, Oct. 2004, last accessed 7 June [13] juddi Web Page, last accessed 7 June BIOGRAPHIES RAJESH KARUNAMURTHY (r_karuna@ece.concordia.ca) is a Ph.D. candidate in the Electrical and Computer Engineering Department of Concordia University and an intern at Ericsson Canada. He received his Master s degree from Concordia University in His research interests are service engineering, s, and 3G networks. He is working in the area of composition for his doctoral research. FERHAT KHENDEK received an engineering degree in computer engineering, option software, from the University of Tizi- Ouzou, Algeria, and M. Sc. and Ph.D. degrees in computer science from the University of Montréal, Canada. During his Ph.D. studies he held a research fellowship from the IBM Center for Advanced Studies, Toronto, Canada. He is currently an associate professor with the Electrical and Computer Engineering Department at Concordia University where he holds a research chair in telecommunication software engineering. From 2001 to 2002 he was a visiting researcher at Ericsson Research Canada in Montréal. He is on the program committees of several conferences and was co-chair of NOTERE 04 and IFIP TESTCOM 05. His research interests are mainly in the use of formal methods (SDL and MSC) and UML for the design and analysis of real-time systems, communications software, and service engineering techniques. ROCH H. GLITHO [SM] holds a Ph.D. (Tekn.Dr.) in tele-informatics from the Royal Institute of Technology, Stockholm, Sweden, and M.Sc. degrees in business economics (University of Grenoble, France), pure mathematics, and computer science (University of Geneva, Switzerland). He works in Montréal, Canada, as an expert in service engineering at Ericsson and an adjunct associate professor at Concordia University. In the past he worked as a senior specialist in network management for Ericsson Telecom, Stockholm, and an R&D engineer for a computer manufacturer in Oslo, Norway. His industrial experience includes research, international standards setting (e.g., contributions to ITU-T, ETSI, TMF, ANSI, TIA, and 3GPP), product management, project management, systems engineering, and software/ firmware design. He is an IEEE Distinguished Lecturer, a Senior Technical Editor for IEEE Communications Magazine, and a Technical Editor for the Journal of Network and Systems Management (Plenum/Kluwer). He has served as Editor-in-Chief of IEEE Communications Magazine and IEEE Communications Surveys & Tutorials. His research areas include service engineering, network management, signaling, and mobile code. In these areas he has authored approximately 60 peer-reviewed papers, more than 15 of which have been published in well-known refereed journals. He has also guest edited some 10 special issues of refereed journals and has more than 20 patents in the aforementioned areas. IEEE Communications Magazine July