Project Report Technology Assessment of Middleware for Telecommunications Telecommunication Application Domains Editor: Peter Loosemore, BT British Telecommunications plc Abstract This document details the results from Task 7 of EURESCOM P910 Technology Assessment of Middleware for Telecommunications. The task is entitled Telecommunication Application Domains and covers two main areas of work. These are the Technology Issues to be considered when using middleware for specific application domains, and the design and implementation of the Project demonstrator. This report gives an account of the work done in the investigation of technology issues such as those related to Network Services Control, Service Provisioning Applications and E-commerce Applications. It also describes the design, specification and implementation of the P910 demonstrator, which offers a realistic simulation of a middlewarebased e-commerce platform. EDIN 0094-0910 Project P910 For full publication April 2001
EURESCOM PARTICIPANTS in Project P910 are: BT British Telecommunications plc Deutsche Telecom AG France Télécom Telenor AS Hellenic Telecommunications Organisation S.A. (OTE) eircom plc Koninklijke KPN N.V. (until January 2000) [Project title] Technology Assessment of Middleware for Telecommunications [Document title] Report on Telecommunication Application Domains Editor: Peter Loosemore, BT British Telecommunications plc Project leader: Oddvar Risnes, Telenor AS Project supervisor: Anastasius Gavras, EURESCOM GmbH EURESCOM published project result; EDIN 0094-0910 2001 EURESCOM Participants in Project P910 Disclaimer This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders.
EURESCOM Project Report page 3 (33) Preface The EURESCOM Project on Technology Assessment of Middleware for Telecommunications (P910) investigates different middleware products and technologies in order to provide EURESCOM Shareholders with information on the maturity and the suitability of these products and technologies for telecommunications application areas. The Project focuses on the management functions, methods and procedures, for determining the tools needed for the management of middleware platforms and services. Furthermore the Project investigates via experiments non-functional aspects of middleware platforms, such as scalability, dependability and security. The Project started in March 1999 and will end in March 2001. It is a partially funded Project with an overall budget of 314 man-months and other costs of 33 KEuro. The Participants in the Project are BT - British Telecommunications plc, Deutsche Telecom AG, France Télécom, Telenor AS, Hellenic Telecommunications Organisation S.A. (OTE), eircom plc, and Koninklijke KPN N.V. (until January 2000). Mr. Oddvar Risnes from Telenor AS leads the Project. This is the seventh of eight planned Deliverables of the Project and is titled: "Report on Telecommunication Application Domains" and consists of a single volume. Other Deliverables are: D1 "Technology and Product Life Cycle ratings" D2 "Mid-term Project Demonstrations", D3 "Report on Management Middleware Applications", D4 "Report on Platforms Scalability", D5 "Report on Platforms Dependability", D6 "Report on Platforms Security" and D8 "Report on Project Conclusions". This Deliverable describes the design, specification and implementation of the project demonstrator, which was chosen as a realistic case study for the application of middleware in a telecommunications environment. 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 4 (33) EURESCOM Project Report Executive Summary The EURESCOM Project P910 "Technology Assessment of Middleware for Telecommunications" set out to provide EURESCOM Shareholders with a perspective on how middleware technologies can be exploited to provide value-added services on top of bit transport and basic services to the customer. Our challenge was to show how middleware can provide the means for rapid development and deployment of services, allow more efficient operation by using load balancing techniques, and more reliable operation by using replication techniques to enable fault-tolerant systems. The mission of the task on Telecommunication Application Domains was to provide some answers, based not only on study and investigation, but also on practical experience and demonstration. The task has studied three application domains to identify the technical issues for implementation of middleware. These are Network Services Control, Service Provisioning Applications and E- commerce Applications. In order to get a deeper understanding of the issues involved, this task has been responsible for the design, specification and implementation of a project demonstrator, based on the theme of e-commerce. The project as a whole has addressed the following issues of middleware: Management of distributed applications Scalability Dependability Security In order to bring these issues together and to demonstrate the benefit of middleware to telecommunication applications, the task has defined the Project Demonstrator. This is an integration of work on management, scalability, dependability and security aspects of middleware based on an application framework designed and built within the project. This document describes the work carried out in this task and the results achieved. These results show that there are real benefits from the use of middleware, especially in the areas of scalability and dependability. However, although the chosen technology (CORBA) is now quite mature and the standards well established, there are still problems when attempting to bridge between CORBA and other technologies. Also there are still occasional discrepancies between the interpretation of the CORBA specifications between different ORB vendors. The key message is that Middleware is here to stay, but for industrial-strength solutions using a range of different products, there is still a little way to go. EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 5 (33) List of Authors Peter Loosemore (editor) BT British Telecommunications plc Bertrand Mathieu France Télécom Christian Egelhaaf GMD Fokus/Deutsche Telekom AG Jürgen Dittrich GMD Fokus/Deutsche Telekom AG Olaf Kath Humbold University Berlin/Deutsche Telekom AG Frank Stoinski Humbold University Berlin/Deutsche Telekom AG Erik Peeters Koninklijke KPN N.V. (until January 2000) Maarten Wegdam Koninklijke KPN N.V. (until January 2000) Fofy Setaki INTRACOM S.A./Hellenic Telecommunications Organisation S.A. Erik Berg Telenor AS Sune Jakobsson Telenor AS Haldor Samset Telenor AS Peter FitzPatrick Broadcom/eircom plc Niamh Quinn Broadcom/eircom plc 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 6 (33) EURESCOM Project Report Table of Contents Preface...3 Executive Summary...4 List of Authors...5 Table of Contents...6 Abbreviations...7 1 Introduction...8 2 Technology issues...9 2.1 Network Services Control...9 2.1.1 Investigation of requirements for a CORBA-based multicast demonstrator...9 2.1.2 Application of ADSL as a transport network...10 2.1.3 Study of connectivity infrastructure for P910 demonstrator...10 2.1.4 IP multicast connectivity infrastructure...10 2.1.5 Concluding remarks...11 2.2 Service Provisioning...11 2.2.1 Market scan and investigation of CORBA-COM bridge products...11 2.2.2 State of the Art of QoS Frameworks and Architectures for P910...11 2.2.3 Basic Infrastructure for P910...12 2.2.4 Comparison of relevant Service Architectures...12 2.2.5 Experiments with Fault Tolerant Naming Services...13 2.2.6 Study on Mobile Phone Integration for P910...13 2.2.7 Technological Assessment of SOAP...14 2.2.8 XML to HTML, WML transcoder...14 2.2.9 Concluding remarks...14 2.3 Electronic Commerce...15 2.3.1 Study on E-commerce tools and solutions...15 2.3.2 Selection Design and Requirement capture for an E-commerce Application...15 2.3.3 Development of an IP Multicast demonstrator...16 2.3.4 Implementation of an On-line Shopping server for the P910 demonstrator...16 2.3.5 Implementation of a Travel Agent server for the P910 demonstrator...16 2.3.6 Specification and Implementation of Image Distribution for Online Auctions...17 2.3.7 Concluding remarks...17 2.4 Summary...17 3 Project demonstrator...19 3.1 Introduction...19 3.2 Architecture and Technology...19 3.2.1 Top level design of the P910 demonstrator...19 3.2.2 Overview of technology used for the P910 demonstrator...20 3.3 Facilitating servers...21 3.3.1 Design and specification of the facilitating servers to be used in the P910 demonstrator...21 3.4 End-user services...22 3.4.1 Design and specification of the End-user servers to be used in the P910 demonstrator...22 3.5 Integration...22 3.5.1 Implementation and Integration of the eportal server...22 3.5.2 Implementation of the Access server...24 3.5.3 Implementation of the User-Profile server...25 3.5.4 Implementation of an On-line Shopping service...26 3.5.5 Implementation of an On-line Auction service...27 3.5.6 Implementation of a Travel Agent service...28 3.5.7 Implementation of a Network server...29 3.6 Summary...30 4 Conclusions...32 5 Further reading...33 EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 7 (33) Abbreviations ADSL ATM CORBA DPE DOT DSP ESP GIOP GUI HTTP IDL IIOP IOR IP ISDN IT KTN LAN NS OCI OMG OS OTM OTS PNO PPP PSTN QoS RFI RSVP SOAP SSL TCP TINA WWW Asymmetric Digital Subscriber Line Asynchronous Transfer Mode Common Object Request Broker Architecture Distributed Processing Environment Distributed Object Technology Digital Signal Processing EURESCOM Service Management Platform General Inter ORB Protocol Graphical User Interface Hyper Text Transport Protocol Interface Definition Language Interner Inter ORB Protocol Interoperable Object Reference Internet Protocol Integrated Services Digital Network Information Technology Kernel Transport Network Local Area Network Naming Service Open Communication Interface Object Management Group Operating System Object Transaction Management Object Transaction Service Public Network Operator Point to Point Protocol Public Switched Telephone Network Quality of Service Request for information Reservation Protocol Simple Object Access Protocol Secure Sockets Layer Transmission Control Protocol Telecommunications Information Network Architecture World Wide Web 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 8 (33) EURESCOM Project Report 1 Introduction This document details the results from Task 7 of EURESCOM P910 Technology Assessment of Middleware for Telecommunications. The purpose of the task was to investigate the requirements on the middleware layer to allow support for a range of end-user services in different telecommunication application domains. This was to be achieved not only by study and investigation, but also from the experience of designing and implementing a middleware based platform. This implementation would then enable the demonstration of realistic scenarios to prove the value of the technology. The work was therefore divided into two phases; Phase 1 was investigation of the Technology Issues to be considered when using middleware for a number of specific application domains, and Phase 2 was the design and implementation of the Project demonstrator. The Application Domains to be considered by the task were Network Service Control, Service Provisioning and Electronic Commerce applications. A study was therefore made of the technology issues to be considered when providing a middleware-based platform to support applications in these three areas. The Project Demonstrator has been the main focus of the P910 project, and is the culmination of a major part of the work. It involves the integration of work from other tasks with the implementation carried out in Task 7. The demonstrator allows us to show how middleware performs in a real-life situation, and how various mechanisms can be used to improve the functionality of currently available technology. The structure of the deliverable is as follows: In Section 2, the Technology issues studied in Task 7 are described with reference to the Telecommunication application domains. In Section 3, there is a detailed description of the Project Demonstrator. In Section 4, the conclusions from the work are discussed. Section 5 contains a list of documents available as Task 7 Technical reports. EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 9 (33) 2 Technology issues Technology issues are the issues that need to be considered when installing a middleware layer to support a range of applications running on different platforms and using different network technologies. P910 has studied a range of issues including network requirements, multicast, bridging between middleware technologies, frameworks and architectures, basic infrastructure and e-commerce applications. One of the main objectives of the project and of Task 7 was to produce a working demonstrator to show the value of middleware using realistic scenarios. However, before the demonstrator could be designed, a study of the underlying technologies, their requirements and shortcomings needed to be made. In accordance with the Project Plan, this work was divided into a number of Application Domains as described in the previous section. The investigations carried out in each application domain are described in the following sections. 2.1 Network Services Control This application domain covers the underlying network technology which the middleware needs to interface with to allow applications to communicate. Issues such as audio/video stream control, ADSL and use of the public Internet to link geographically distributed platforms have been studied. A brief review of the experiments undertaken is given in the following sections. 2.1.1 Investigation of requirements for a CORBA-based multicast demonstrator The purpose of this work was to investigate the possibility of building a multicast platform which could be used to build experimental prototypes of a multicast network which can be managed and controlled with CORBA-based technology. Much of the network technology described could also be used with alternative middleware technologies such as Microsoft s DCOM. A previous EURESCOM project, P715, designed and built a demonstrator based on the OMG specification for the Control and Management of Audio/Video Streams. The investigation by P910 extended this work by considering two technical areas, Platform aspects and Network aspects. Platform aspects An evaluation was carried out to find if the OMG A/V streams specification would support multicast techniques, followed by a brief investigation of general requirements for ORBs and applications using multicast. Some remarks on the choice of ORB(s) to be used for the implementation are given in the report, and client software is also considered. For a CORBA platform to support multicast technology, (e.g. for management of multicast connections) a means to support multicast stream bindings must be found. Also, there is the question of what characteristics are important for an ORB to support multicast stream-binding. Network aspects An investigation was made of the hardware required to set up a basic test facility, including nodes, routers etc., and a guide provided on the available technology. The report explores a range of possibilities for setting up a multicast demonstrator. These include network requirements, network design, protocols, client software, etc. and takes into account the requirement for using CORBA-based middleware to manage certain aspects such as QoS. Conclusion There are two primary considerations for building a middleware-controlled multicast platform; the suitability of the middleware specification and the compatibility of the components used in the network. In the report we studied the applicability of the OMG specification for control and management of A/V streams. The conclusion from this is that whilst the specification fully supports the use of multicast stream binding, there is a question mark over the future of this 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 10 (33) EURESCOM Project Report specification (it may be phased out within a short time). However, there being no obvious alternative for CORBA-based stream-binding, it may be the only available solution. In view of this uncertainty, consideration must be given to using alternative middleware technologies which may provide a more stable solution for integration of multicast services. Network technologies were also reviewed, and a number of possibilities identified for implementation of a multicast network. A range of issues that anyone wishing to implement a test network should consider have been highlighted: network architectures; choice of hardware and software; low-cost solutions based on emerging technology; choice of clients and protocols. A solution is proposed to integrate CORBA and RSVP in a multicast situation, and a brief study on the use of the Internet MBONE for linking remote sites is also included. 2.1.2 Application of ADSL as a transport network Asymmetric Digital Subscriber Line (ADSL), a new modem technology, converts existing twistedpair telephone lines into access paths for multimedia and high speed data communications. ADSL can literally transform the existing public information network from one limited to voice, text and low resolution graphics to a powerful, ubiquitous system capable of bringing multimedia, including full motion video, to everyone s home. By bringing movies, television, video catalogues, remote CD-ROMs, corporate LANs, and the Internet into homes and small businesses, ADSL will make these markets viable, and profitable, for telephone companies and application suppliers alike. In P910 an experiment was conducted to examine and evaluate the current status of deployment of ADSL in each partners domain. This experiment was executed at the very beginning of the project, and at this time ADSL deployment had just started, so effective usage and testing of this network was not possible. During the project s lifetime many telecommunication operators succeeded in the broad provision of ADSL access for business and private customers. The experiences that were gained outside of any experiment during the project s runtime confirmed the project s conclusion: that ADSL is the technology of choice for delivering middleware-based high-speed telecommunication services to customers. 2.1.3 Study of connectivity infrastructure for P910 demonstrator This experiment investigated and studied the connectivity status between EURESCOM P910 partners. Inter-connectivity formed the basis for further experiments and is a crucial requirement. Because almost all Middleware software is based upon use of Internet Protocols this experiment concentrated on investigation of IP inter-connectivity. The public Internet was considered as a potential candidate for inter-connectivity of future P910 experiments which would be carried out between several project partners. The main characteristics of delay and bandwidth vary quite strongly, depending upon network load on the public Internet. The delay appears to be comparable or worse than N-ISDN, while the bandwidth appears to be comparable or better than N-ISDN. Application requirements decide whether the variation in the connectivity parameters delay and bandwidth of the public Internet in comparison to N-ISDN as a potential alternative are sufficient. Further experiments to investigate this were suggested before major applications in Task 7 were considered. 2.1.4 IP multicast connectivity infrastructure The previous section describes an investigation of point-to-point connectivity between EURESCOM project partners using the public Internet. The objective of the follow-on experiment was to study how far the current public Internet is capable of supporting IP multicast (Mbone) using various multicast experiments among project partners of P910. It was found that the public internet is a potential candidate for multicast inter-connectivity of P910 experiments which are carried out among two or more project partners. For testing multicast connectivity, a simple java test application and mtrace were used. EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 11 (33) Unfortunately, only two of five partner sites could exchange multicast messages via our java test application. As a solution it was proposed for the March 2000 workshop in Dublin that external multicast links to one or two (TI) external sites would be sufficient for an upcoming multicast demonstrator. A local demonstration was always possible as a fallback solution, but the recommendation was to proceed with provision of external multicast connectivity in a continuation experiment. 2.1.5 Concluding remarks P910 has investigated a number of network technologies for the purposes of interfacing to middleware based systems. The work focused on using the Internet as a means for interconnection of middleware platforms. ADSL was also considered, but at the time of the investigation (early in the project) this was not generally available. Tests using the Internet, however, showed that this provided a good medium for both point-to-point connectivity and multicast applications. Although rather variable, bandwidth was found to be as good or better than N-ISDN, but delay was comparable or worse. In general, however the Internet was acceptable for this application. 2.2 Service Provisioning This application domain is concerned with the middleware architectures and technologies which can be used to support distributed applications and services. This work includes a study of some alternative architectures and technologies; bridging between different middleware technologies, and setting up a distributed processing platform with basic platform services. A brief review of the experiments undertaken is given in the following sections. 2.2.1 Market scan and investigation of CORBA-COM bridge products The project conducted some investigations of commercially available products for providing interoperability at the protocol and interface level between COM and CORBA. A set of criteria regarding conformance with the COM/CORBA standard, security, dependability, scalability, platform independence, language independence, openness, configuration, bundling with other products and price were defined. A template was created before the products were investigated. Products from BEA, Brokat, O3sis IT AG, ExperSoft, ICL, Inprise, Hitachi, Rogue Wave, Visual Edge and IONA were surveyed. A number of these were selected for practical tests, but the tests showed that in general, getting code to work that was developed for other bridges proved to be very difficult. Compiler compatibility issues, problems locating COM objects, poor quality documentation and technical support all contributed to the problem. It can be said that the development cycle is long and complex, and the error messages are few and cryptic. Overall the experiments, which were run during 1999, showed that the technology at the time was still quite immature. The overall conclusion from this experiment was that bridging is not a trivial and straightforward task. Unfortunately there were no resources available on this project to revisit this area at a later date, but it is likely that significant advances will have been made since our evaluation was concluded. 2.2.2 State of the Art of QoS Frameworks and Architectures for P910 This experiment investigated and reported on current and relevant background work related to Quality of Service (QoS) appropriate for the P910 project. This would provide a common basis of terms and views on QoS for the project. An overview of major QoS frameworks and architectures was given. A few examples are: the ITU QoS Framework, the ODP Reference Model on QoS, the QoS Architecture, and Generic QoS Architecture for Open Systems (Trinity College Dublin). Particular attention was given to support for Multimedia streams. Work from other groups such as OMG as well as work on Quality Modelling Language (QML) from HP Labs was also studied and summarised. 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 12 (33) EURESCOM Project Report The works we studied form a solid basis of terminology and techniques regarding handling of QoS. Concepts and terms as introduced by the ITU QoS Framework are gaining increased acceptance and would be used within the P910 EURESCOM project. For notation of QoS and contracts in particular, QML appears to be a very promising candidate. An architecture very similar to Frank Siqueira s generic QoS architecture, where a QoS agent and corresponding QoS Translation and Mapping components play a major role were kept in mind for further QoS work in P910. We foresee that results from ongoing IETF activities such as Internet2/QBone will be used as underlying technology deployed in future implementations. To address this requirement and support for QoS in Middleware in general, we investigated how far current, and in particular Internet, technologies like Int- and DiffServ, Qbone, etc. could be used in order to get an assesment of their suitability for P910. 2.2.3 Basic Infrastructure for P910 In P910, partners were required to develop distributed application components, which had to interoperate with components created by other partners to form one distributed application. For this reason, P910 executed an experiment to build a common basic infrastructure that included the most often needed CORBA Common Object Services. Such an infrastructure would help with developing, testing and demonstrating distributed applications in P910. A Naming Service accessible to all partners and providing a uniform view of parts of its database to the partners, was a premise for easy exchange of CORBA object references between partners. Including the Trading Object Service and the Notification Service, the basic infrastructure was able to provide three of the most essential services for use in a telecommunication DPE. An Interface Repository, added to the basic infrastructure, supported applications dealing with unknown data types, for instance in conjunction with typed event channels. To ease concurrent development of software for the project, a CVS server was also introduced. This server was able to manage programming sources in different versions that were accessible and changeable by different partners concurrently. With this server, partners also got a central location for retrieval of programs and sources for the different experiments undertaken by the project. All these parts established a basic infrastructure that P910 experiments could rely on, and helped partners to develop, debug and test distributed applications during the project lifetime. 2.2.4 Comparison of relevant Service Architectures In this experiment two major service architectures (SA) are described and compared. The TINA SA covers all ODP viewpoints and defines a complete model. The concepts have been established for several years, although the specifications are still not yet complete. There are some implementations of the complete specification and some of just parts. A very important point is that TINA defines a business model which corresponds to the enterprise viewpoint. This business model describes a lot of real-world scenarios, in particular the customer - retailer - provider chain, which is also relevant in many e-commerce applications. However, for more complex business relations the business model may not be sufficient, so e.g. the aspects of accounting and billing are not covered in detail. Parlay is still under development and covers the interworking between a retailer and a service provider. The standard is formulated as an API, which is composed of two major parts: Framework and Services. In contrast to TINA, Parlay defines an API between two business domains, typically a kind of retailer and a service provider. The retailer may e.g. be a company which manages a call centre, while the service provider is a telecommunication operator which gives access to its network infrastructure. Parlay defines no comparable architecture to TINA, but uses similar mechanisms in its framework interfaces to access the provider domain. In both TINA Ret and Parlay framework it is possible to EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 13 (33) establish a first contact and use an authentication mechanism, and there is the possibility to start a service (a service session in TINA terms). While TINA has a much broader scope, Parlay is restricted to special kind of services. Even if the TINA ideas are not sufficient for all kinds of services, the model behind TINA is still very valuable and allows finding a common understanding between all participating parties. A subset of the Retailer Reference Point has been used successfully in the Eurescom Project P715 and a variant would still be useful for P910, although it may be too heavy-weight for the user to business relationship. The OMG activities for unifying parts of both standards could improve the value of TINA and Parlay. Note that this experiment reflects the situation at the end of 1999. Whilst the TINA activities have been stopped, Parlay has continued to make some improvements. 2.2.5 Experiments with Fault Tolerant Naming Services This experiment studied the fault tolerance mechanism that was introduced in Visibroker 4.0 for the Naming Service. The previous version of Visibroker Naming Service relied on the object references stored in memory, with an additional log on a file. If the machine that hosted the Naming Service failed, then all applications that depended on the Naming Service for object location also failed. The Naming Service was thereby a single point of failure. The new mechanism introduced with version 4.0 moved the object references to a persistent database storage. The experiment was a practical test on how well this mechanism works under different operating systems, different databases and different system failures. Databases from VisiBroker (JdataStore), Microsoft (SQL and Access), and Oracle were tested, running under Windows NT and Solaris operating systems. The VisiBroker Naming Service is a complete implementation of the Interoperable Naming Specification document (orbos/98-10-11) from the OMG. The conclusion from the experiments was that the fault tolerance of the Naming Service only partly worked as advertised. It performs well under controlled failure conditions, but when temporary partitioning of the network occurs, the behavior is not acceptable. There were notable differences with the various operating systems used. NT s Object Location Service service recovers well from restoring the original network, whereas VisiBroker s Naming Service must be restarted after a failure in order to continue. 2.2.6 Study on Mobile Phone Integration for P910 In P910, demonstration applications or services in the domain of e-commerce, namely On-line Shopping and On-line Auction, illustrate the beneficial potential of assessed middleware. Details of their design and implementation are covered in companion experiments. One enhancement of these applications is integration and access using a mobile phone. This report described and studied the various toolkits and technical solutions available for integration of mobile phones into the e-commerce oriented example applications of the P910 project. For e-commerce applications, the WebSIM approach and toolkit is suitable, but at present time its availability is very limited in practice. This is due to the fact that for production of WebSIM capable SIM cards, the exchange of a specific secret key between a mobile network operator and the card producer is necessary. At the time of this report, we were not successful in obtaining a functional WebSIM card. We look forward to obtaining a WebSIM card to continue our study. The WAP approach is also feasible for implementation of our e-commerce applications. It is fully sufficient for On-line Shopping, but due to the interaction requirements of On-line Auction, we have to test current WAP toolkits to see how far they support the WAP 1.2 push function (for distribution of information from auctioneer to (mobile phone auction) participants). WAP will therefore be used with the On-line Shopping server and the eportal server to enable WAP mobile phone access to this service. To enable WAP access, it is necessary to have a WAP gateway. The WAP gateway was developed and integrated into the Access. 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 14 (33) 2.2.7 Technological Assessment of SOAP EURESCOM Project Report This experiment examined the Simple Object Access Protocol (SOAP standard as specified in the IETF & W3C, and originally designed by Microsoft), and evaluated its use in relation to middleware technologies. SOAP was examined to see if it could be usefully included in the P910 demonstrator, and to investigate its possible use in bridging between different middleware products. Products supporting SOAP and currently available SOAP tools were examined. SOAP is a standard to allow heterogeneous systems to exchange data in a standard XML format. It can be used for everything from message passing systems to RPC. The focus of our work was on its use to create request/reply pairs for lightweight RPC. SOAP allows users to make remote calls to objects/procedure calls using an XML encoding for the remote procedure calls. XML is lightweight and requires only some form of connection supporting string passing to make a connection. The report descibes the XML format of SOAP messages, the encodings used and the defined http headers for SOAP. The experiment also examined the level of industry uptake and declared support for the SOAP standard. A large number of companies including major players from Microsoft to Sun, HP and IONA have all expressed their support for the standard. The experiment also included an evaluation of the IBM SOAP for Java product and includes a number of advantages and disadvantages of that product. Finally the experiment looked at SOAP-CORBA interworking and proposes a set of CORBA IDL SOAP XML translations and mappings. 2.2.8 XML to HTML, WML transcoder Middleware is a part of an architecture that is independant of any kind of platform, servers or clients. In the P910 project, the demonstrator aims to prove that middleware is independent of the kinds of terminal used to access Internet servers. To highlight this feature, access from two types of terminal is shown in the demonstrator: access from a PC and access from a WAP enabled cell phone. Instead of providing two different web sites, (one in HTML for the PC, the other in WML for the mobile phone), it was decided to use XML as the language descriptor of the Web site and to use a transcoder to adapt the content according to the type of terminal. A state-of-the-art study of public transcoders (paper study based on the available information) has been done in P910. One product was chosen and has been implemented in several components of the demonstrator to adapt the XML content to HTML content (PC-client) or WML content (WAP phone client) according to the type of the terminal. 2.2.9 Concluding remarks P910 has investigated a number of service provisioning applications for the purposes of deployment of middleware based systems. P910 has focused on OMG s CORBA technology, but has considered other middleware technologies too. The project also looked at Service Architectures, including TINA and Parlay. A basic infrastructure for a distributed processing environment has been established for P910 to provide the services middleware needs to allow interoperation of components. This included the development of a fault-tolerant naming service. An investigation of the alternative middleware technologies SOAP and XML was made, and bridging between COM and CORBA products was studied. In general, CORBA was found to be very stable, but at the time the bridging products were evaluated (early in the project) these were found to be immature and difficult to use. EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 15 (33) 2.3 Electronic Commerce This application domain was chosen as it is seen as highly relevant to the Telecommunications industry today. It is the theme for the P910 demonstrator, which models a real-life middlewarebased distributed e-commerce platform. Most of the work on this application domain concerned the design and implementation of components for the project demonstrator, but some preparatory investigation work was carried out. A brief review of the experiments undertaken is given in the following sections. 2.3.1 Study on E-commerce tools and solutions This experiment investigated and studied the currently available telecom services that can be classified as E-commerce activities among the participating partners. A questionaire was distributed and the results were collected and analysed. In addition, commercially available E- commerce tools which create solutions using middleware technology were surveyed. Conclusions from the experiment were that Inter-terminal services are still very immature, and surprisingly few standards are used for conducting E-commerce. All the E-commerce solutions surveyed gave few or no details regarding security, dependability, scalability and management. However their suppliers have consultants that could assist customers with special needs, as they tend to advertise. So the critical questions to ask are: Is it secure? Can it support all my users? Will it run all the time? Can my staff manage it?, before choosing a particular E-commerce solution. 2.3.2 Selection Design and Requirement capture for an E-commerce Application Project P910 focused on three application domains, and Task 7 was responsible for producing demonstrators to show the functionality that middleware can provide in each of these domains. In order to build a demonstrator, one or more applications were required, a) to provide a tangible example with a representative set of operational requirements which the middleware must support, and b) to allow a visual means to present the middleware functionality to a target audience. This experiment described a specification for an example application to represent the theme of e- commerce, which would be used for a working implementation. Producing a specification enabled the evaluation of requirements that the application puts on the supporting middleware. The process involved selection of a simple e-commerce application (the selected one was On-Line Shopping, with additional features to support Auctions), and produced a first stage design and requirements specification which would be used in later experiments to build a working demonstrator. The specification was based on a step-by-step use-case approach to analyse the required component parts. The application scenario is not intended to be a full-blown working application, but a relatively simple scenario to highlight the usefulness of middleware and to ensure that the benefits offered by middleware (e.g. distribution and use of heterogeneous platforms) are fully exploited. As such, it needed to fulfil a number of requirements: It should be representative of a current e-commerce application It should demonstrate a number of fundamental e-business functions It should allow maximum use of middleware for integration of software, distribution of functionality and support for heterogeneous systems etc. It should provide a visual means to appreciate the middleware functionality A full specification for the demonstrator was produced by analysis of the application scenario. This was done by studying a number of Use Cases which collectively make up the application scenario. The demonstrator had to show the benefits/limitations of middleware for the specific application. For On-line Shopping these included scalability, fault tolerance, security and open architecture to allow easy interworking between heterogeneous applications (this would include manageability). 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 16 (33) EURESCOM Project Report Each use-case considered these factors and how they might be demonstrated. The key factor was to consider how the middleware could support the use-case, what limitations there might be, and how could they be overcome. 2.3.3 Development of an IP Multicast demonstrator The purpose of this experiment was to develop a simple prototype of an online auction in order to demonstrate the use of IP multicast in P910. In addition to establishing and testing of an IP multicast infrastructure, an appropriate Middleware (orb) was selected which supports IP multicast for inter-object communication (e.g. Jonathan Java orb). A simple auction prototype was described and implemented using the multicast capable Middleware. The prototype was deployed and tested. This prototype was demonstrated successfully at the IS&N 2000 Workshop in Athens and the EURESCOM P910 Mid-term Workshop in Dublin. 2.3.4 Implementation of an On-line Shopping server for the P910 demonstrator This server contains the business logic for an On-line Shopping service. The design of the server is broadly in line with the design and specification detailed in Section 3.3.3, and the User can register with the service, log-on, browse products, select products and pay for the products. For the purposes of the demonstrator, dummy products are used and the payment process is a simulation, with credit card details checked against information stored in a database. The databases used for the customer and product information could be based on legacy systems. Clients running a browser such as Netscape 4.6 or IE4 may access the server using HTML, but the server also provides information in XML format to allow transcoding for WAP or other terminals. The online shopping application consists of a number of web pages held on a web server which has a database containing details of the products on offer, and a further database containing details of the customers orders and personal information. The communication between the web server and the databases is realised through CORBA. The implementation therefore consists of two parts, the client side and the server side. In the client side, the customer uses a browser which can interact with the server side. The browser receives HTML web pages sent by servlets from web server. Thus, a customer can fill in a form to register on the system or to pay for chosen products. In this case, the communication system is only the HTML protocol. 2.3.5 Implementation of a Travel Agent server for the P910 demonstrator Project P910 plans to demonstrate the functionality and benefits of middleware by means of an integrated middleware-based demo system, which incorporates a number of servers providing a range of service scenarios. A travel agent is one such scenario. The implementation consists of a server that offers typical travel agent services, e.g. the reservation (and purchasing) of tickets, rooms and rental cars. For the purposes of the P910 implementation (i.e. it is a demonstration), only a limited part of this functionality was actually implemented, namely the reservation of airline tickets. The implementation demonstrates that a typical travel agent service can be integrated into a CORBA environment with relative ease, i.e. the easy integration of this service with the basic (architectural) components of the system (eportal, User Profile and Network servers) through welldefined CORBA interfaces despite the differences in operating systems, programming languages and middleware platforms. EDIN 0094-0910 2001 EURESCOM Participants in Project P910
EURESCOM Project Report page 17 (33) 2.3.6 Specification and Implementation of Image Distribution for Online Auctions The purpose of this experiment was to augment the prototype of the online auction demonstrator with an image distribution of the item to be auctioned off. In the prototype only the asking price (offers) to auction participants uses IP multicast. Provision of further information beyond the basic asking price requires an additional distribution of images. This experiment specified such an addition from the user perspective in text and in the form of IDL definitions. A prototype image distribution implementation illustrated and verified that specification as well as augmenting the online auction towards the P910 demonstrator. This prototype was demonstrated successfully at the EURESCOM P910 Workshop in Lannion. 2.3.7 Concluding remarks P910 has investigated the application domain of e-commerce, which puts many demands on the design of middleware platforms. The work has included evaluation of e-commerce tools, designing and specifying e-commerce applications, and implementing these on middleware-based platforms. The experience has shown that middleware-based applications can be designed and built in a modular fashion relatively easily using well-defined interfaces for the component parts to interoperate. This has a number of advantages managability, scalability, dependability, and security. Systems can be built or expanded rapidly making use of existing components. The selection of the On-line Shopping application included the possibility to show that legacy systems (e.g. databases) could also be integrated to offer enhanced functionality. 2.4 Summary The project has identified a number of middleware technologies, including OMG s CORBA, Microsoft s DCOM, EJB, SOAP and XML. CORBA was selected as the preferred technology for the demonstrator as the project partners had more experience with CORBA products. Investigations were made on all of the others, including bridging techniques between COM and CORBA. XML was also used to a limited extent in the demonstrator. The findings of the work on technology issues may be summarised as follows: 1. CORBA is a mature technology which when used with common object services such as Naming and Trading can provide a scalable and reliable environment for the support of distributed applications. 2. Microsoft s COM is the ubiquitous technology for client terminals, but bridging technology between COM and CORBA is still relatively immature, and raises many problems. 3. The performance of the public Internet in Europe has improved sufficiently to allow acceptable results for distributed platform connectivity, with available bandwidth comparable or better than N-ISDN. Throughput varies from country to country, but in general is comparable to or better than N-ISDN. 4. There has been poor support for OMG s specification for control and management of audio/video streams, resulting in no products becoming available. 5. CORBA products are becoming available which support multicast of CORBA requests. These are much more efficient when an application needs to send the same request to multiple servers. At present, interworking between these extended ORBs is an open issue that needs to be resolved. 6. Although lightweight interworking is possible between SOAP and CORBA, interworking of CORBA applications with SOAP applications yields a significant limitation of the power and flexibility of CORBA. With this limitation, SOAP can only play a minor role in distributed applications that produce heavy operational traffic. However, for simple access to objects, where services are accessed sporadically and delay is not important, SOAP could be used as an access protocol, e.g. for web browser object access. 2001 EURESCOM Participants in Project P910 EDIN 0094-0910
page 18 (33) EURESCOM Project Report 7. Middleware platforms can bring a range of benefits to e-commerce applications. Distribution of functionality, replication etc. allows for scalability and dependability. The fact that the middleware interfaces to all components in the system allows for centralised management, and interoperability with other systems enhances the possibility for interworking relationships between different business domains (e.g. retailer-wholesaler). Middleware provides the software layer which sits between different parts of distributed applications and shields these parts from the heterogeneity of the underlying communication networks. P910 has studied a range of technology issues for the use of middleware in a number of application domains. Issues such as how middleware can interface to different network topologies (e.g. IP networks, ADSL) have been studied. Requirements on the use of middleware have also been investigated, e.g. service architectures, the need for a distributed processing environment and bridging between various middleware technologies. Finally, the specific application of middleware to the high-growth area of e-commerce has allowed the project to demonstrate the benefits of middleware in a real-life situation. The following section describes how this was affected by implementation of the project demonstrator. EDIN 0094-0910 2001 EURESCOM Participants in Project P910