1 - LUT
LAPPEENRANTA UNIVERSITY OF TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
OBJECT ORIENTED ARCHITECTURE FOR INTERNET SERVICES
The subject of this Master’s Thesis was approved by the Department of Information Technology, Lappeenranta University of Technology on 14.06.1999.
The work was supervised by Professor Jorma Jormakka and instructed by Professor Henryka Jormakka.
In Lappeenranta, Finland, 19.07.1999
Marko Kelovesi
Ollikantie 40 B 6
33960 Pirkkala, Finland
040 505 6993
TIIVISTELMÄ
Tekijä: Kelovesi, Marko Petteri
Aihe: Objekti orientoitunut Internet-palveluarkkitehtuuri
Osasto: Tietotekniikan osasto
Vuosi: 1999
Paikka: Lappeenranta
Diplomityö. Lappeenrannan teknillinen korkeakoulu.
87 sivua 33 kuvaa
Valvoja: prof. Jorma Jormakka
Ohjaaja: prof. Henryka Jormakka
Avainsanat: Internet-palvelut, palvelun käyttäjien liikkuvuus, käyttäjien ja palveluiden väliset rajapinnat.
Työ liittyy TEKES projektiin Liikkuvuus ja Palvelut (MOSES). Työn tarkoituksena on määritellä MOSES-referenssiarkkitehtuuri projekti-tehtävässä 1 tehtyjen raporttien pohjalta. Siihen liittyen tutkitaan erilaisia Internet-verkossa tarjottavaksi tarkoitettuja palveluideoita ja niiden toteutuksen taloudellista kannattavuutta. Lisäksi tutkimuksen kohteena ovat erilaiset palveluinteraktioon osallistuvien osapuolten väliset rajapinnat sekä Internet-palveluiden tarjoamiseen käytettävät palvelintyypit. Liikkuvuuden saralla tutkitaan erilaisia liikkuvuuden mahdollistavia arkkitehtuureja.
Tämän työn käytännön osuudessa tutustutaan CORBA-pohjaiseen testipalveluun.
ABSTRACT
Author: Kelovesi, Marko Petteri
Subject: Object Oriented Architecture for Internet Services
Department: Information Technology
Year: 1999
Place: Lappeenranta
Master’s Thesis. Lappeenranta University of Technology.
87 pages, 33 figures.
Supervisor: Professor Jorma Jormakka
Instructor: Professor Henryka Jormakka
Keywords: Internet services, mobility of the service users, interfaces between users and services.
This work is related to TEKES project Mobility and Services (MOSES). The purpose of this work is to define MOSES Reference Architecture according to reports made in project Task 1. Under the research are different business ideas to be provided in Internet and economical viability issues related to them. In addition under the research are interfaces between different parties participating the service, and servers related to Internet services. In the area of mobility is studied different architectures which makes possible users mobility.
In the practical part of this thesis a CORBA based test service is examined.
FOREWORD
This thesis was written in Telecommunications Laboratory of Lappeenranta University of Technology.
I would like to thank Henryka and Jorma Jormakka for supervision of this work and also all MOSES partners for co-operation in MOSES project. My greatest thanks go to my parents, my wife Mervi, and of course, our children for giving support during my studies.
Table of Contents
1. INTRODUCTION 1
1.1 Background of Moses project 1
1.2 Background of the Internet 3
1.3 Structure of This Document 4
2. REVIEW FROM EXISTING SYSTEM ARCHITECTURES 6
2.1 CORBA 6
2.1.1 OMG Reference Model Architecture 7
2.1.2 CORBA ORB Architecture 8
2.2 TINA 9
2.3 ODP 11
2.3.1 Viewpoints 12
2.3.2 ODP Functions 13
2.3.3 Transparencies 14
2.4 WAP 14
2.4.1 The WAP Model 14
2.4.2 Components of the WAP Architecture 16
2.5 UMTS 18
3. MOSES REFERENCE ARCHITECTURE 22
3.1 MOSES Overall Model 22
3.2 Generic Business Model 23
3.2.1 Business Model Examples 26
3.3 Functional Model 46
3.3.1 Class Diagram of the MOSES-model 46
3.3.2 Interfaces 49
3.3.2.1 Stream Interface 49
3.3.2.2 Operational Interfaces 52
3.4 Physical Model 66
3.4.1 Content Servers, Proxy Servers and Caching 66
3.4.2 Replication server 68
4. MOSES MOBILITY SUPPORT 71
4.1 IPv6 Mobility Support – Mobile IP 71
4.2 DPE Support for Mobile Environments 74
5. MOSES EXAMPLE SERVICE 77
References 83
Abbreviations
ARPA Advanced Research Project Agency
ATM Asynchronous Transfer Mode
A/V Audio/Video
BOA Basic Object Adapter
BTS Basic Time Service
CGI Common Gateway Interface
CN Core Network
CORBA Common Object Request Broker Architecture
DII Dynamic Invocation Interface
DSI Dynamic Skeleton Interface
DOLMEN Service Machine Development for an Open Long-
term Mobile and Fixed Network Environment
DPE Distributed Processing Environment
DSI Dynamic Skeleton Interface
DVD Digital Versatile Disc
ESIOP Environmet Specific Inter-ORB Protocol
FDBR Fixed DPE Bridge
FPLMTS Future Public Land Mobile Telecommunication
System
GIOP General Inter-ORB Protocol
GSM Global System for Mobile Telecommunications
IDL Interface Definition Language
IETF Internet Engineering Task Force
IIOP Internet Inter-Orb Protocol
IOR Interoperable Object Reference
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ITU International Telecommunication Union
IWU Interworking Unit
LAI Location Area Identifier
LR Location Register
MDBR Mobile DPE Bridge
ME Mobile Equipment
MOSES Mobility and Services
OA Object Adapter
ORB Object Request Broker
ODP Open Distributed Processing
OMA Object Management Architecture
OMG Object Management Group
OSAM Open Service Architecture for Mobile and Fixed
Environments
PCS Personal Communication System
QoS Quality of Service
RFP Request for Proposal
SII Static Invocation Interface
TES Timer Event Service
TINA Telecommunications Information Networking
Architecture
TIO Time Interval Object
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunication System
URAN UMTS Radio Access Network
URI Uniform Resource Identifier
URL Uniform Resource Locator
USIM User and Services Identity Module
UTO Universal Time Object
VCR Video Cassette Recorder
VoD Video-on-Demand
WAE Wireless Application Environment
WCDMA Wideband Code Division Multiple Access
WDP Wireless Datagram Protocol
WSP Wireless Session Protocol
WTA Wireless Telephony Application
WTLS Wireless Transport Layer Security
WTP Wireless Transport Protocol
WWW World-Wide Web
1. INTRODUCTION
1.1 Background of Moses project
Telecommunications as a business domain is going through a revolution which is achieved by liberation of competition and evolution of technologies. Changes in the future service production environments influence powerfully business domain environment.
Commercial utilization of Internet will get more verve when security and mode of payments develop to product in the next couple of years. The broadening and increasing of usage of Internet create qualifications to build broadband and flexible information network, which supports the next generation of interactive applications.
The new trend in telecommunications is increase of mobility. This consists of personal mobility and availability of services.
MOSES (Mobility and Services) project investigates how mobile users can efficiently find and use various services in communication networks. In addition under the research are some key-components (Traders), problems related to new environments for example giving sufficient bandwidth to user and location issues.
The MOSES-project is divided into tasks. This thesis is based on Task 1, which designs an architecture for future networks, paying attention to personal mobility. Figure 1.2 depicts the scope of MOSES.
The authors of Task 1 report are Timo Kyntäjä (VTT), Juha Koivisto (VTT), Jorma Jormakka (LUT) and Petri Heinilä (LUT). This document is based on the contributions of the authors.
MOSES architecture defines rules, concepts and interfaces for the design and implementation of telecommunication services. The architecture attempts to take into account new requirements and technical means. Related progress in ODP, TINA, CORBA, UMTS, Internet, WWW and WAP was investigated.
Personal mobility and ubiquitous personal multimedia services are getting increasingly popular. Hence, the architecture must be compatible with mobile and fixed terminals and networks. Flexibility is needed to make it easy and fast to create new services, and get ready for emerging real-time and interactive services with response time requirements.
Compatibility with wealth of current and future TCP/IP services is essential. Object-oriented design and middleware-based service enabling environments attempt to make the development and maintainance of complex systems easier. New software technologies, for instance Java and mobile agents, make it possible to dynamically move processing to the most efficient place, and reduce the need for complex, static interface specifications. Users, or software agents, will choose not only the service, but also the most suitable network and operator, based on the quality and cost. Brokers and traders assist users in finding and choosing services. Flexible applications can adapt to different kinds of communication networks and terminals.
The MOSES architecture is based on CORBA. Most interactions take place through CORBA. CORBA services, like naming, life cycle, trader and security service, will be used when applicable. This does not exclude the possibility of using other than CORBA communications services – for example streams – for service specific purposes.
1.2 Background of the Internet
The Internet is a worldwide system of computer networks - a network of networks in which users at any one computer can, if they have permission, get information from any other computer. It was conceived by the Advanced Research Projects Agency (ARPA) of the U.S. government in 1969 and was first known as the ARPANet. The original aim was to create a network that would allow users of a research computer at one university to be able to "talk to" research computers at other universities. A side benefit of ARPANet's design was that, because messages could be routed or rerouted in more than one direction, the network could continue to function even if parts of it were destroyed in the event of a military attack or other disaster. By 1972, there were 37 host computers connected to ARPANET. Also in this year, ARPA's name was changed to DARPA (Defense Advanced Research Projects Agency). In 1973, ARPANET went beyond the boundaries of the United States by making its first international connections to England and Norway.
Today, the Internet is a public, cooperative, and self-sustaining facility accessible to hundreds of millions of people worldwide. Physically, the Internet uses a portion of the total resources of the currently existing public telecommunication networks. Technically, what distinguishes the Internet is its use of a set of protocols called TCP/IP (Transmission Control Protocol/Internet Protocol).
The World Wide Web (WWW) has brought an explosion of content to the Internet and has guaranteed the success of growth. It will provide a quite useful platform for distributed services in the near future.
1.3 Structure of This Document
This document summarizes the findings of Task 1 of the MOSES-project.
Mobility is a quite wide concept; Chapter 2 gives a very brief introduction to different architectures, which are used for service and user mobility. In the MOSES architecture, to be presented in chapter 3, some aspects of many of these architectures were used. MOSES architecture consists of a business model, a functional model and a physical model.
The Business Model determines the generic business model from which different business participants can be derived for a certain business case. Some use cases of different business ideas with viability arguments are also provided here.
The Functional model deals only with the MOSES-model (subchapter 3.3.1) and its interfaces (subchapter 3.3.2); stream interface and operational interfaces (access, startService and MOSES CORBA interfaces). These are the basic interfaces when implemented Internet services.
The Physical model describes different server types to be used for service provision: Content server, Proxy server and Replication server. Services are generally assumed to be initially based on the Internet, this view was adapted in MOSES, so the physical architecture is on top of an IP-network.
MOSES Mobility Support in Chapter 4 gives a brief introduction from two techniques, which makes users mobility possible. These are Mobile IPv6 [25] and DOLMEN’s [27] DPE Mobility Support. Mobile IPv6, a successor of Mobile IPv4, is yet a quite unfinished protocol for the terminal mobility if it is compered to DOLMEN’s DPE Mobility Support. That’s why mobility support was largely adopted from the DOLMEN. DPE Mobility Support of DOLMEN is probably the most suitable working method for mobile users’ terminals, and servers used by them.
Chapter 5 presents the CORBA based test service. Meaning of this service was to introduce and illustrate CORBA ORB based programming and especially showing how messages are passed from the client to the server.
2. REVIEW FROM EXISTING SYSTEM ARCHITECTURES
This chapter introduces main features of architectures, which make possible service distribution in networks (CORBA, TINA, ODP) as well as service and user mobility (WAP, UMTS). CORBA is a middleware supporting distribution in object-oriented manner. It can be seen as a tool, which implements the means how the client can make requests to the objects and how the server fulfills the client’s needs. TINA is a common reference architecture, which make possible to provide versatile multimedia and information services. ODP enables the construction of distributed systems in a multi-vendor environment through the provision of a general architectural framework that such systems must conform to. WAP is considered as a technique, which brings Internet content in wireless terminals. UMTS is a third generation architecture, which extends the capability of todays mobile technologies (e.g. GSM) by providing increased capacity.
2.1 CORBA
The Common Object Request Broker Architecture (CORBA) [1] is an emerging open distributed object-computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and operation dispatching.
2.1.1 OMG Reference Model Architecture
OMG’s Object Management Architecture (OMA) is composed of the Object Model and the Reference Model. The Object Model defines how objects distributed across a heterogeneous environment can be described, while the Reference Model characterizes interactions between those objects.
Figure 2.1 shows the components of the OMA Reference Model.
The ORB components are divided in four object interface categories:
1. Object Services: a collection of services (interfaces and objects) that support basic functions for using and implementing objects (e.g. Naming Service and Trading Service).
2. Common Facilities: a collection of services that many applications may share, but which are not as fundamental as the Object Services.
3. Domain Interfaces: these are domain-specific interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation.
4. Application Interfaces: objects specific to particular commercial products or end user systems. Application Objects correspond to the traditional notion of applications, so they are not standardized by the OMG.
2.1.2 CORBA ORB Architecture
The core of the OMA Reference Model is the Object Request Broker (ORB). ORBs allow clients to invoke operations on target object implementations without knowing what is the location of the object, what programming language the object is written in, what OS/hardware platform is used, or the type of communication protocols and networks used to interconnect distributed objects.
The following Figure 2.2 illustrates the primary components of the CORBA ORB architecture with explanations below.
• Object Implementation: This defines operations that implement a CORBA IDL interface. Object implementations can be written in a variety of programming languages.
• Client: This is the program entity that invokes an operation on an object implementation.
• Object Request Broker (ORB): The ORB provides a mechanism for transparently communicating client requests to target object implementations. It can be seen as a proxy which decouples objects from their clients.
• ORB Interface: This interface is used to decouple applications from implementation details. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface.
• Stub: The implementation code that the IDL compiler produces for the client-side of an object.
• Skeleton: The server-side code output by the IDL compiler that has no implementation when produced.
• Dynamic Invocation Interface (DII): The dynamic counterpart of the static IDL making runtime requests on interfaces.
• Dynamic Skeleton Interface (DSI): This is a runtime interpreter for skeleton code.
• Object Adapter: A component of the CORBA architecture that supports specific styles of implementation.
2.2 TINA
To define the common reference architecture, more than forty international members, including leading network operators, telecommunications equipment manufacturers and computer manufacturers, formed the Telecommunications Information Networking Architecture Consortium (TINA-C) at the end of 1992. TINA has three major goals. The first goal was to make it possible to provide versatile multimedia and information services. The second goal was to make it easy to create new services and to manage services and networks. The third goal was to create an open telecommunications and information software component marketplace.
Basic Principles of TINA
TINA is intended to apply to all parts of telecommunications and information systems: for example, terminals, transport servers, service servers and management servers. Reference Points are defined to specify conformance requirements for TINA products. The architecture is based on four principles:
1. Object-oriented analysis
2. Distribution
3. Decoupling of software components
4. Separation of concern
Separation of concern deals with different aspects of a problem separately. TINA provides two major separations of concern (Figure 2.3). The first separation is between applications and the environment (i.e., Distributed Processing Environment DPE) on which they run. The second is separation of applications into the service-specific part and the generic management and control part. The latter interacts with transport and other elements. According to the separation principles, TINA is divided into the following four sub-architectures:
• Computing Architecture defines modeling concepts and the DPE.
• Service Architecture defines a set of principles for providing services.
• Network Architecture describes a generic, technology-independent model for setting up connections and managing telecommunication networks.
• Management Architecture provides the concepts and principles to build management systems that can manage the entities in TINA systems.
For further information see [3].
2.3 ODP
ODP (Open Distributed Processing) is the attempt to standardise OSI application layer communications architecture. ODP is a natural progression from OSI, broadening the target of standardisation from the point of interconnection to the end system behaviour. The objective of ODP is to enable the construction of distributed systems in a multi-vendor environment through the provision of a general architectural framework that such systems must conform to. One of the cornerstones of this framework is a model of multiple viewpoints, which enables different participants to observe a system from a suitable perspective and a suitable level of abstraction.
ISO and ITU-T have developed a Reference Model of Open Distributed Processing (RM-ODP) [5] to provide coordinating framework for the standardisation of ODP by creating an architecture, which supports distribution, interworking, interoperability and portability.
2.3.1 Viewpoints
RM-ODP describes a framework using viewpoints [6] from which to abstract or view ODP systems. A set of concepts, structures and rules is given for each of the viewpoints, providing a “language” for specifying ODP systems in that viewpoint.
RM-ODP defines the following viewpoints:
• Enterprise Viewpoint is used to organizational requirements and structure.
• Information Viewpoint is used to describe the information required by an ODP application through the use of schemas, which describe the state and structure of an object.
• Computational Viewpoint is used to specify the functionality of an ODP application in a distribution-transparent manner.
• Engineering Viewpoint is used to describe the design of distribution-oriented aspects of an ODP system.
• Technology Viewpoint is used to select particular technologies for implementation, maintenance and testing of an ODP system.
Specifying an ODP system using each of the viewpoint languages allows an otherwise large and complex specification of ODP system to be separated into manageable pieces, each focused on the issues relevant to different members of the development team. For example, the information analyst works with the information specification while the systems programmer is concerned with engineering viewpoint. Figure 2.4 shows how RM-ODP viewpoints can be used in software engineering process.
2.3.2 ODP Functions
The ODP functions are required in ODP systems to support the needs of the computational language and the engineering language. These are:
• Management functions: manages engineering structures
• Coordination functions: coordinates actions of objects, clusters or capsules
• Repository functions: maintains a database of specialised classes of information. These are:
1. Type repository: a registry for interface types - maintains a type hierarcy and other relationships between types.
2. Trader: “a dating service for objects” – supports dynamic binding by allowing services to be discovered at run-time.
3. Relocator: repository of interface locations.
• Security functions: e.g. access control, authentication.
2.3.3 Transparencies
The refinement of a computational object involves the identification of its transparency requirements, i.e.:
• access transparency: hides differencies in data representation and calling mechanism,
• location transparency: hides the location (and changes of location) of objects,
• failure transparency: recovers failed objects,
• replication transparency: keeps replicated objects consistent.
The aim of the transparencies is to hide complexity from the application programmer.
2.4 WAP
The Wireless Application Protocol [7] is IETF de-facto standard for wireless information and telephony services on digital mobile phones and other wireless terminals. WAP specifies an application framework and network protocols for wireless devices.
2.4.1 The WAP Model
The WAP programming model (Figure 2.5) is quite similar to WWW programming model [7]. This provides benefits to the application developer community, including a familiar programming model, a proven architecture and the ability to leverage existing tools.
WAP content and applications are specified in a well-known content formats based on the familiar WWW content formats. Content is transported with standard communication protocols based on the WWW communication protocols. A micro browser in the wireless terminal co-ordinates the user interface and is corresponding to a standard web browser.
WAP defines a set of standard components that enables communication between mobile terminals and network servers, including:
• Standard naming model: WWW-standard URLs are used to identify WAP content on origin servers. WWW-standard URIs are used to identify local resources in a device.
• Content typing: All WAP content is given a specific type consistent with WWW typing.
• Standard content formats: WAP content formats are based on WWW technology and include display markup, calender information, electronic business card objects, images and scripting language.
• Standard communication protocols: WAP communication protocols enable the communication of browser requests from the mobile terminal to the network web server.
WAP utilises proxy technology to connect between the wireless domain and the WWW. The WAP proxy typically comprises of the following functionality:
• Protocol Gateway: translates requests from the WAP protocol stack to the WWW protocol stack.
• Content Encoders and Decoders: The content encodes translate WAP content into compact encoded formats to reduce the size of data over the network.
The WAP proxy allows content and applications to be hosted on standard WWW servers and to be developed using proven WWW technologies such as CGI scripting.
2.4.2 Components of the WAP Architecture
The WAP layered architecture enables other services and applications to utilise the features of the WAP stack through a set of well-defined interfaces. Each of the layers is accessible by the layers above, as well as by other services and applications.
Wireless Application Environment (WAE) [8] is a general-purpose application environment based on a combination of WWW and Mobile Telephony technologies. WAE includes a micro-browser environment, which consists of Wireless Markup Language (WML), WMLScripting language, Wireless Telephony Applications (WTA) and Content Formats.
Wireless Session Protocol (WSP) [9] provides the applications protocol layer of WAP with a consistent interface for two session services. The first is a connection-oriented service that operates above the transaction layer protocol WTP. The second is a connectionless service that operates above a secure or non-secure datagram service (WDP).
Wireless Transaction Protocol (WTP) [10] runs on top of a datagram service and provides as a lightweight transaction-oriented protocol that is suitable for implementation in “thin” clients (mobile stations).
Wireless Transport Layer Security (WTLS) [11] is a security protocol based upon industry-standard Transport Layer Security (TLS) protocol, formerly known SSL. WTLS is intended for use with the WAP transport protocols and has been optimised for use over narrow-band communication channels.
Wireless Datagram Protocol (WDP) [12] is related to the Transport layer protocol of the WAP architecture. WDP layer operates above the data capable bearer services supported by the various network types. As a general transport service, WDP offers a consistent service to the upper layer protocols of WAP and communicate transparently over one of the available bearer services.
The WAP protocols are designed to operate over a variety of different network level services, referred to as bearer services in WAP, including short message, circuit-switched data and packet data. The bearers offer differing levels of quality of service with respect to throughtput, error rate and delays.
2.5 UMTS
UMTS (Universal Mobile Telecommunications System) is one of the major new third generation mobile communications systems being developed within the framework which has been defined by ETSI.
UMTS is very close to the framework for future mobile systems standardization effort of ITU under the name of FPLMTS (Future Public Land Mobile Telecommunication System) lately renamed to IMT-2000 (International Mobile Telecommunication 2000). It is expected that UMTS and IMT-2000 will be compatible, for instance it will provide global roaming, but it is too early yet to say whether full compatibility will eventually be achieved.
The subject of intense worldwide efforts on research and development throughout the present decade, UMTS has the support of many major telecommunications operators and manufacturers because it represents a unique opportunity to create a mass market for highly personalised and user-friendly mobile access to tomorrow's "Information Society".
UMTS will build on and extend the capability of todays mobile technologies (like digital cellular and cordless) by providing increased capacity, data capability and a far greater range of services using an innovative radio access scheme and an enhanced, evolving core network.
The launch of UMTS services from the year 2002 will see the evolution of a new, "open" communications universe, with players from many sectors coming together harmoniously to deliver new communications services characterised by mobility and advanced multimedia capabilities.
The following features are required from UMTS:
• To support existing mobile services and fixed telecommunications services up to 2Mbit/s.
• To support unique mobile services such as navigation, vehicle location, and road traffic information services, which will become increasingly important in a pan-European market.
• To allow the UMTS terminal to be used anywhere, in the home, the office, and in the public environment, both in rural areas and city centres.
• To offer a range of mobile terminals from a low cost pocket telephone (to be used by almost anyone anywhere) to sophisticated terminals to provide advanced video and data services.
UMTS supports different cell sizes from pico cells to satellite cells. Pico cells are used inside the buildings and satellite cells cover whole planet. The cells between them are called macro and micro cells. Figure 2.7 illustrates this cell division.
Data transfer rate depends on used cell-size and speed of the terminal. The lowest rate in transfer is planned to be 384 kps when terminal can move at 500 km/h. In the cover of pico cells, when terminal almost stands still, the data transfer rate can be even 2 Mbps.
The UMTS network architecture is not precisely defined. What we know in this moment are the main components. These are:
• User and Services Identity Module (USIM):
• Corresponds GSM’s SIM-card.
• Compatible with current SIM-cards.
• Includes several services like security, ecash, SIM…
• Mobile Equipment (ME): Terminal device.
• UMTS Radio Access Network (URAN): In Europe it will based on WCDMA (Wideband CDMA).
• Interworking Unit (IWU): Establishes the interface between CN (Core Network) and URAN.
• Core Network (CN): Comprises the user database, adaption services and the connections to the external networks.
A trend towards multimedia services can be seen in the wireless systems. However at this moment it can not be precisely known what these mobile services will be. Current mobile systems, like GSM, are speech-oriented and thereby they can not support requiring multimedia services. Althought users have needs to use same services regardless of their location. The purpose of UMTS is make possible to provide this kind of service.
Wireless multimedia services can be classified in many ways, for example in accordance with demanded bandwidth, level of interactivity or operation environment. When criteria is based on operation environment services are divided into three category:
• Personal multimedia comprises services which are used in work or free time. This kind of services could be ”traditional” speech, videophoning or electric newspapers. The common factor with these services is that the services require interactivity.
• Home multimedia comprises services operated from home. The goal is to get rid of traditional cable connections and that way increase mobility. This kind of services could be electric newspapers, subscription video, electric libraries and ”shopping channels”. The common factor with these services is that the bandwidth is high and the range is short.
• Vehicle multimedia comprises services which are used in vehicles when they are in move. This kind of services could be road maps, navigation and location services. The common factor with these services is that the mobile vehicle must receive information in high-speed.
Althought UMTS-services will not be standardised, they have great influence UMTS-standards because the services represent demands of markets and thus they set demands to transport network itself. In fact UMTS service features will rather be standardised instead of services.
3. MOSES REFERENCE ARCHITECTURE
3.1 MOSES Overall Model
MOSES reference architecture comprises three complementary models. These are:
• Business model
• Functional model
• Physical model
The Business model (chapter 3.2) presents different kind of business ideas or scenarios which could be provided in Internet. The generic MOSES business model represents the basic actors participating to make business in Internet. The additional actors can be inherited from these basic actors. Quality and quantity analyzes of the scenarios proves whether they are satisfactory enough in reality or not.
The Functional model concentrates in the class structure of the MOSES-model (chapter 3.3.1), stream interface and operational interfaces (chapter 3.3.2). Operational interfaces consist of access interface, startService interface and MOSES CORBA interfaces.
The Physical model (chapter 3.5) concentrates different server types used for service providing in Internet; Content server, Proxy server and Replication server.
3.2 Generic Business Model
Generic MOSES Business Model is a model of an Internet service and the environment with which the service interacts. It is a conceptual, non-prescriptive framework, which makes no requirements on how things are actually implemented. It covers the role of the service in the business, the roles of all stakeholders and business policies related to the service. At the same time it presents the qualitative requirements focusing on performance of the service as well as quantitative estimations of the possible profits allowing the different parties to make decision on the involvement in the service.
The Generic MOSES Business Model specifies:
• An generic set of actors representing the partners interworking during the service,
• A common business framework for all the players,
• Set of most common use cases,
• Qualitative analyzes of the scenario described by the framework,
• Quantitative estimations of profits of the stakeholders.
A generic set of actors consists of user, service provider, technology provider and broker (Figure 3.2).
• User: a stakeholder, which takes advantages of services, provided by the investigated system and may be charged for usage of them.
• Service provider: a stakeholder offering to users value added services, teleservices and the providing the content of the services.
• Technology provider: a stakeholder that provides and manages means that enable other stakeholders to reach their goals and fulfill their obligations. The technology provider offers bearer services, equipment and software enabling services of service provider.
• Broker: a stakeholder that searches services and other stakeholders from the network behalf of user with the given properties.
From the generic set of actors, other players are derived. The following roles are derived from user:
• Customer: a stakeholder who wants to use some service
• Internet abuser: a stakeholder who tries to use the service without charging or somehow to make damage to the system.
To the roles derived from service provider belong:
• Content provider: a stakeholder producing goods offered to the user e.g. publisher or software house implementing computer games.
• Seller: a stakeholder making profit on providing products to users.
To the roles derived from technology provider belong:
• Authority: a stakeholder that mandates some aspects of certain technology and supervises its usage.
• Software provider: a stakeholder providing software enabling execution of the services, but not the content of the services.
• Network equipment vendor: a stakeholder providing equipment for operating a network.
• Connectivity provider: a stakeholder that owns or manages a network.
To the role derived broker belongs:
• Locator: a stakeholder that provide other actors with information that enables them to find other stakeholders and services involved in the system.
More roles can be derived from above mentioned generic roles if necessary.
To allow the roles interact with each other, the Generic MOSES Business Model must contain a business framework; a detailed description of the actors’ role, the relationship between the actors, the resources used, services offered, or restrictions imposed.
The business framework should be illustrated by a set of use cases of the investigated scenario described by the framework. The use cases would present the most common situations that can take place during the execution phase.
Qualitative analyzes of the scenario should contain the motivation for adapting the scenario, market analyzes, possible alternative solutions, or directives for future development. The goal of this phase is to investigate if the proposed design will prove to be satisfactory in reality and to find possible weak points of the scenario. To this part of the model could contribute teams engaged in network planning and marketing.
As the goals of different stakeholders differ and can be even contradictory, both qualitative and quantitative analyzes should be made from the point of view of one stakeholder, taking however into account the interests of other players.
Finally, the model should contain quantitative estimations of profits of the stakeholder interested in implementation of the scenario. The estimations, based on qualitative analyzes and investigation of the potential market, should help to modify the business framework to find optimal solution for service provision investigated in the scenario.
3.2.1 Business Model Examples
In the following are described three business scenarios which can be used via network. Library service can be seen as a new scenario which offers newspapers in electronical format, movies and book reservation services for the customer without going physically to the library or video store. The news service presents today’s needs for people who wants to be aware of real-time incidents in the world. Medical applications cannot only be seen as a profit making service but a service which can save human lives.
Business Case: Library
Library service could offer several services e.g. book reservations, electronical newspapers, and video services to the customer.
In the library service scenario is included the following roles (see Figure 3.3):
• Library content provider: Inherited from the Service Provider role. Provides library service to the customers.
• Customer: Inherited from the User role. Abstraction from participant who wants to use a certain library service.
• Abuser: Inherited from the User role. Participant who tries to use service without charging or somehow make damage to the system.
• Network Operator. Inherited from the Technology Provider role. Provides the transport media for service.
• Security Provider: Inherited from the Technology Provider role. Offers secured connection to avoid misusing the service by the abuser (this is handled by e.g. software).
• Broker: Searches services and other library services from the network behalf of user with the given properties
The broker role is quite useful in the case when the customer wants to use some service which is not available in the library in which her or she is connected. Library content provider (inherited from Service Provider role) can adopt the User role. User (ex-service provider) contacts the broker and gives the characters of the desired service to it. Broker searches from the network the service by given characters on behalf of the user. When the service provider, which hold this kind of service is found the broker passes the reference to the user.
In order to get services from other service provider (or third party provider), service providers must have some pre-determined contract to do so. It can be some kind of federation in which different service providers have access to each other’s service content.
When the customer connects to the library service, the authorisation and authentication will be verified. After that the library server sends to the customer the list that includes the offered services. These services could be electronical newspapers, video movie service, book reservations etc. The customer chooses the desired service. Library register records the information of the choosen service for charging. Charging type can include credit card charging, afterwards or beforehand charging (customer has some kind of account).
Before the customer can use the library services he or she must be registered. The customer pays the fixed fee in registering and this is payed only once.
The following use cases are assumed to generate most traffic and be most relevant in the Library Service from business point of view:
• Use case: Movie service – Customer downloads the desired movie from library.
• Use case: E-newspaper – Customer chooses the electronical newspaper from the library.
• Use case: Book reservation – Customer reserves and borrows the book from the library.
Use case: Movie service
In quantitative analysis of the movie service from library content provider point of view several factors must be considered. These are for example:
• capacity: network resources, needed bandwidth,
• costs: equipment costs, communications costs,
• traffic: number of users, amount of usage,
• service classes: priorities, COS, security.
Service payments could depend on how much the customer loads the network resources. For example in video delivering the charging could be based on monetary unit/megabytes. The charging consists mainly from the service content itself and the use of the network resources. More usually the connection charging is fixed and so the charging methods must be organised in some other way.
Video on demand [13] is nowdays a quite interesting service scenario. It requires very wide bandwidth. For this service ATM-technique or some alternative high capacity technique will be the most appropriate.
VoD service is a pull mode service. Pull mode refers to the delivery method in which the subscriber demands and receives data from the provider. The consumer decides what to watch and when to watch it from a range of alternatives and then retrieves the selection. VoD includes VCR controls such as rewind, pause, and fast forward.
In a pull mode environment, no two subscribers are likely to be watching the same movie or using the same trick modes at any given moment. Therefore, separate data flows are established, one for each viewer.
Royalty payments for content make up about half of the cost associated with VoD.
The measure of the success of a VoD offering is the take rate. The take rate is the number of movies rented per month divided by the subscriber base. If a subscriber base has 1,000 consumers, and 2,000 movies were rented in a month, the take rate is 200 percent. Take rates of 200 percent or more are necessary to make VoD financially viable.
Library movie service scenario differs from VoD so that the customer downloads the chosen movie from library server for example to the hard disk through Internet. This way the customer buys rights to the movie in the same way if she or he buys this movie in a VHS cassette from the supermarket. Nowdays the hard disk capacities are not enough if the customer wants to establish some kind of movie library onto the hard disk, because one movie takes at least 3 GB of hard disk space. In the near future high capacity hard disks will come in the markets so this scenario could come true. The other alternative is to burn movies to the DVD disk when hard disk space begins to fill up.
The charging from the library content provider’s point of view can be calculated by the following:
if,
x = royalty cost and taxes per one movie divided by estimated amount of subscribers. Royalty holder decides the fixed price for a certain movie when it sells the movie to the library.
y = fixed cost per one movie copy. Fixed costs are divided by annually selled movie copies e.g.
y = w * (all fixed costs) / (total amount of yearly sold copies)
where w is a factor for certain amount of fixed costs which are shared to the movie service (e.g. 80%) according to network resource usage of this service. The rest of the fixed costs are due to the other services available in the library. Fixed costs comprises of;
• salaries of personnel including the social security costs,
• insurances,
• rent of the library flat,
• connection charging of the connection provider (fixed payment per year or traffic-based),
• refund costs with annuity of the equipments (servers, PCs, softwares, hubs, cabels, costs of the security)
The total costs per one movie copy Ctot can be formulated by;
Ctot = x + y
The required price V from one video payed by a customer can be formulated by:
V = (x + y)z
where,
z is a factor for required profit and it must take into account competitors.
Message sequent chart (MSC) in Figure 3.4 shows interactions when the customer connects to the library service and wants to choose the wished movie.
1. The customer (or user application) connects to the library server. Authentication information (user name and password), customer reference and request ID is passed as parameters. Req ID is unique per message pair and is checked with the original one every time when the other party gets a response message.
2. The register manager (RM) checks customer’s authentication. In this phase RM creates session ID for this session. If authentication fails the error message is sent to the customer.
3. RM responses to the customer and gives the reference to the service database (SD).
4. The customer asks service list from the SD. This list contains all services available in the library.
5. SD sends the service list to the customer.
6. The customer chooses the desired service from the list. In this case the customer wants to download a certain movie.
7. SD checks from RM whether the customer is subscribing this service.
8. RM sends the subscription response to SD. In this case the customer has subscribed to this service. If the customer has not subscribed to this service error message is sent to SD and to the customer.
9. SD sends movie list to the customer, which contains all movies available in the library.
10. The customer chooses the movie called ”Xmovie”
11. SD sends the to the customer movieReadyForDownloadRequest message.
12. The customer confirms when she/he is ready to download the chosen movie (she/he presses download button) with movieReady-ForDownloadResponse.
13. SD sends information concerning this movie (for charging) to RM.
14. RM adds the charging info in the register.
15. RM sends the adding response to the SD and with that way confirms to SD that adding was succeed.
16. SD sends the movie to the customer.
Use case: Book reservation
The book reservation service also requires the beforehand registering from the customer. The fee may depend on whether the book is old or brand new. In the case of older books the fee would be cheaper than for newest books. Charging contains both fees, reservation and borrowing.
In order for this service to be successful the book base have to be competative. In the county libraries the newest bestsellers are not always available or even exist when customer wants to borrow them. That is why this service is competative over county libraries because the offering would be considerably larger and newer.
When the customer connects over the network to the book reservation service, for example from home, the authentication and authorization is verified. The server asks from the customer name of the writer and the book. If such book exists, server confirms that customer wishes to borrow this book and makes necessary annotations to the register. The book will be send to the customer by mail or if the library offers home-delivery, then with this way.
The reservation and borrowing fee must be quite reasonable. It depends on the price and life span of the book. If one book costs for the library content provider is 15 $ and life span is approximately 30 borrowing times, the fee must be at least 1/2 $. To this must be added shared costs (as in the movie service use case), refund costs with annuity, costs of bookbase (repairing of broken books etc.) and profit.
Message sequent chart in Figure 3.5 shows interactions when the customer connects to the library service and wants to reserve/borrow a certain book.
1. Customer (or user application) connects to the library server. Authentication information (user name and password), customer reference and request ID is passed as parameters. Req ID is unique per message pair and is checked with the original one every time customer gets a response message.
2. Register manager (RM) checks customer’s authentication. In this phase RM creates session ID for this session. If authentication fails the error message is sent to the customer.
3. RM responses to the customer and gives the reference to the service database (SD).
4. Customer asks service list from the SD. This list contains all services available in the library.
5. SD sends the service list to the customer.
6. Customer chooses the desired service from the list. In this case customer wants to make a book reservation.
7. SD checks from the RM whether the customer has subscribed to the book reservation service.
8. RM sends the answer to the SD. In this case the customer is a subscriber. If she/he is not, the error message is sent to the customer and SD.
9. SD sends booklist to the customer which contains all books available in the library.
10. Customer chooses the book called ”Xbook”
11. SD checks availability of this book (free/borrowed or reserved by some other customer).
12. SD sends the availability message to the customer.
13. Customer decides whether she/he wants to reserve/borrow this book and sends the response to the SD. In this case customer wants to reserve the book. Customer can also reject the option if, for example, the wished book is already reserved or borrowed by someone else and customer does not want to wait it becomes available.
14. SD sends the addingRequest to RM for charging.
15. RM writes charging info in the register for charging.
16. RM sends the addingResponse to the SD.
17. SD informs the customer that the chosen book is reserved and it will be delivered to her/him later.
Use case: E-newspaper
To get rid of waste of paper and thereby waste of forests in the newspapers markets, the considerable solution is electronical newspaper. In addition the costs of printing the newspaper is a great expense for the publisher. Most readers want still to read the newspaper in a paper format. In order to get people familiar with a e-newspaper the charging must be considerably lower than a newspaper in paper format. However changing the reading habits of people from paper format towards the electronical format will be the most demanding problem.
Nowdays there are several free of charge newspaper services available in the Internet. However the news content of these Internet newspapers is not so large as in a corresponding paper format. Thereby these services do not compete with the service in which the customer can get the whole newspaper in an electronical format and with an identical layout than in a paper format.
In the e-newspaper service the charging period can be the same as for the normal newspaper, for example 3 months. Charging can be also fee-per-newspaper where the customer pays separately for every newspaper which she/he wishes to read.
The customer can download the freshiest e-newspaper early in the morning from library server instantly when it is published. Depending what the customer has suscribed he or she can choose from different assortment of newspapers.
Message sequent chart in Figure 3.6 shows interactions when the customer connects to the library service and wants to choose a certain e-newspaper.
1. Customer (or user application e.g. applet) connects to the library server. Authentication information (user name and password), customer reference and request ID is passed as parameters. Req ID is unique per message pair and is checked with the original one every time customer gets a response message.
2. Register manager (RM) checks customer’s authentication. In this phase RM creates session ID for this session. If authentication fails the error message is sent to the customer.
3. RM responses to the customer and gives the reference to the service database (SD).
4. Customer asks service list from the SD. This list contains all services available in the library.
5. SD sends the service list to the customer.
6. Customer chooses the wished service from the list. In this case the customer wants to read electronical newspaper (enp).
7. SD checks from the RM whether the customer has subscribed enp-service.
8. RM sends the answer to the SD. In this case the customer is a subscriber. If she/he is not the subscriber to the error message is sent to the customer and SD.
9. SD sends list to the customer which contains all electronical newspapers (and magazines) available in the library.
10. Customer chooses the ENP called ”Xmag”
11. SD checks from the RM whether the customer has suscribed to this magazine (in this case she/he is the subscriber). If she/he is not the subscriber to the error message is sent to the customer and SD.
12. RM sends the response to the SD (in this case the customer has suscribed to this magazine). If the customer has not subscribed to this magazine error message is sent to SD and the customer.
13. SD sends the chosen magazine to the customer.
If the charging method would be fee-per-newspaper, cases 11 and 12 would only be charge-adding request and response respectively.
Viability of the Library Service
Total profit of the Library Service must be by the following to be viable:
P(m) + P(b) + P(enp) + P(reg) > C(fix) + C(r) + C(n) + C(publ)
where,
P( ) = profit per service
C( ) = cost per unit
m = movie service profit
b = book reservation profit
enp = e-newspaper profit
reg = user’s registering fees
fix = all fixed costs of library
r = royalty payments of movies
n = costs of new books and bookbase maintaining
publ = payments to newspaper publishers
Business Case: News Service
The news service is quite similar to the library service. Customer (user) must subscribe to the service beforehand until he or she can use the service. News service can be such that the news headlines are free and after choosing the certain news, customer will be charged. Charging method can be beforehand charging (user has a some kind of account), afterwards billing (the bill will be sent to customers home) or credit card. When the customer subscribes to this service he or she pays the registering fee; this fee is payed only once.
It is often thought that the news should be real-time news because customers are not ready to pay for old news which can be heard and watched from radio and TV with delay.
What sort of news could be provided in the news service? It can provide special news which are not normally provided in media. These are for instance sport news especially hints for trotting-race and other gambling games, or some sort of gossips from personal life of famous people (which are normally provided by the so-called ”yellow press”).
The following derived roles are participated in news service business case (see Figure 3.7):
• Customer: Inherited from the User role. A participant who wants to read news.
• Abuser: Inherited from the User role. A participant who tries to use service without charging.
• News content provider: Inherited from the Service Provider role. A participant who provides news to customers.
• Retailer: Inherited from the Service Provider role. A participant who buys news from different news agencies (e.g. from abroad) and sells them to news distribution services.
• Network operator: Inherited from the Technology Provider role A participant who provides the transport media for service.
• Security provider: Inherited from the Technology Provider role. A participant who offers secured connection to avoid misusing the service by Internet abuser (this is handled by e.g. software).
• Correspondent: Inherited from the Service Provider role. A participant who makes news on the spot they happen.
• News agency: Inherited from the Service Provider role. A participant who collects and edits the news.
The financial profit per month for the news service content provider could be formulated by following:
P = NA( - T(N)
where,
P = profit with taxes.
N = average number of registered customers.
A = average amount of news red by customers per month.
( = average prize of one news.
T(N) = Total service offering costs per month for service provider,
which comprises of service maintaining costs, buying news from retailer or producer, connection cost of technology provider etc.
Message sequent chart in Figure 3.8 shows interactions when the customer
connects to the news service and wishes to get a certain news.
1. The customer (or user application e.g. applet) connects to the News Manager (NM) of the news service. Authentication information (user name and password), customer reference and request ID is passed as parameters. Req ID is unique per message pair and is checked with the original one every time customer gets a response message.
2. (NM) checks customer’s authentication. In this phase NM creates session ID for this session. If authentication fails the error message is sent to the customer.
3. NM responses to the customer and gives the reference to the News Repository (NR).
4. The customer sends the getHeadlines message to the NR to get the list of the news.
5. NR responses to message with sendHeadlines message.
6. The customer chooses the wished news from the headline list and sends the chooseNews message to NR.
7. NR sends to NM chargingRequest message.
8. NM adds the charging information to the register for this customer.
9. NM sends the chargingResponse message to NR. Argument ”state” means whether charging was succeed. If it was not the error message is sent to NR and to the customer (for example in the case where the charging method is beforehand charging and the account is empty).
10. NR sends the wished news to customer.
Business Case: Medical Applications
Telemedicine is the transfer of electronic medical data (i.e. high resolution images, sounds, live video, and patient records) from one location to another [14]. Worldwide, people living in rural and remote areas struggle to access timely, quality specialty medical care. Residents of these areas also often have restricted access to specialist health care, primarily because specialist physicians are more likely to be located in areas of concentrated population. That is why telemedicine is currently seen a very promising application of the Internet for communities.
One of the newest application scenario can be seen a surgery over the network. In this business case can be seen the following roles (Figure 3.9):
• Patient: Inherited from the User role; person who needs immediate surgery.
• Not fully-qualified surgeon: Inherited from the User role; a common medical surgeon who is not fully-qualified in the pertinent areas of the surgery.
• Fully-qualified surgeon: Inherited from the User role; medical surgeon who is advanced in the particular surgery area.
• Network Operator: Inherited from the Technology Provider role; a participant who provides the connection.
In hospitals where there are no available special surgeons (e.g. a brain surgeon) in the case of emergency, surgery could be done over the network with assistance of the not fully-qualified surgeon or medical doctor on the spot, and with supervision of some qualified and specialised surgeon in some other hospital. Video image producing can be done using video camera coupled in the Internet.
Surgery over the network is meant only for the case of emergency surgery because of its risks, which are - for example - network congestions or total connection breakdown during the surgery. The connection requires wide bandwidth for high quality real-time video delivering. To secure the transmission, two parallel connections can be used. This means double transmission costs, but in case of emergency the costs are of secondary meaning and have to be borne.
3.3 Functional Model
The Functional model of the MOSES reference architecture contains the MOSES-model class structure as well as the stream interface and operational interfaces. Operational interfaces consist of Access interface, Start Service interface and MOSES CORBA interfaces.
3.3.1 Class Diagram of the MOSES-model
The meaning of the class diagrams is to provide a picture or view of some or all of the classes in the model, in this case of the MOSES-model.
Figure 3.10 presents the elements of the MOSES-model in the main class diagram.
[pic]
Address (class) expresses location information of the network entity in the network. It can be implemented or adapted by the network it belongs to and by the addressing scheme used in the Addressing resolution use case.
Classifier (class) classifies users profile in building network Group Profiles.
Group Profile (class) can be used to predict the network traffic load and QoS parameters. Group Profile can be input information for a Service Replication Manager.
Network (class) inheritance structure makes a adaptation from existing network implementations like for example #SS7, ATM or IP(LAN) to get a generic interface for network operations, enabling porting of the platform to different systems. If an implementation system has a functionality for selecting a particular network, this functionality also can be used in the Network Selection use case.
Peer (class) is a abstraction of the user and service endpoints. Considering the network routing and quality issues there is not need to make differentation of user and service endpoints. Peer has a role, that contain connection initiating or setup information. Role is derived to the User, that is a service initiating part, and Service, that is responding in Service Use use case transactions.
Profile (class) holds information parameters that can be used in user mobility and for users classification by a Classifier in building the network Group Profile.
Role (class) contains connection initiating or setup information. Role is derived to the User, that is the session initiating part, and Service, that is responding in Service Use use case transactions.
Route (class) is a sequence of addresses, which defines a path in a network. Specific Route implementation is factored in a Route Selection process by the Locator. The Route has a specialisation implementation of the Static Route and Dynamic Route. Static route is a path in a network where the location of the Peers, the User or the Service, does not change. Instead in the Dynamic route the locations the peer can change providing for example, user mobility or service replicating.
QoS (concept) Quality of Service.
QoS/GOSMonitor (Quality of Service/Grade of Service Monitor) can be used for traffic trace collection purposes.
QoS Routing Manager (class) measures traffic parameters and traffic variables and interacts with the Locator and with a User Agent.
Service Replication Manager (class) can manage the service replication or caching, for example in the case of http-proxies, based on user groups demand.
Session (class) is the life-time of the Route initiated by the User Agent. The Session can hold network specific information usable for the peer, like for example quality of the route, charging variables or broker transaction information.
3.3.2 Interfaces
Interface is an abstraction from connection contact point between two objects via which they interact.
This chapter introduces the stream interface and the operational interfaces. The stream interface takes care of stream management when stream is transferred over the network. Operational interfaces consist of Access Interface, Start Service Interface and generic MOSES CORBA Interfaces.
3.3.2.1 Stream Interface
The OMG A/V streams specification [16] presents an architectural model and OMG IDL interfaces for building distributed multimedia streaming frameworks. The goals of this model are:
• standardized stream establishment and control mechanism
• support of multiple transport protocols
• support of various types of sources and sinks
In OMG A/V streams specification, control and management operations is handled through GIOP/IIOP path of the ORB (Figure 3.11 dashed box). Data streams uses out-of-band streams, which can be implemented using protocols that are more suitable for multimedia streaming than IIOP. Each stream endpoint consist of three logical entities:
• a stream interface control object, which exports an IDL interface,
• a data source and sink,
• a stream adaptor, which is responsible for sending and receiving frames over a network
Traditional CORBA middleware is well suited for objects that need to communicate with each other using request/response style semantics. An increasing range of applications, e.g., multimedia applications, requires the transfer of a continous stream of information between objects. The CORBA streaming framework [17] is an A/V streaming application that is based on the OMG A/V specification.
Figure 3.12 depicts the main components of CORBA streaming framework, which are explained below. The corresponding OMG interface name is given in brackets.
Multimedia Device Factory (MMDevice)
The MMDevice component abstracts the concept of a multimedia device. Multimedia device can be physical (video camera) or logical (video clip file red by program). The MMDevice creates new endpoints for new streams when requested. The endpoint consists of a Virtual device (VDev), and StreamEndpoint. The MMDevice handles also the policies for governing the creation of The VDev and StreamEndpoint objects.
Virtual Device (VDev)
The Virtual Device represents the device-specific parameters of a stream endpoint. It accomplishes the encapsulation of device-specific parameters of the connection. For example, a particular device can only support “MPEG-1” compression. The stream establishment phase provides for negotiation regarding these parameters.
Stream Controller (StreamCtrl)
The Stream Controller StreamCtrl is an abstraction, which is used to bind the supplier and consumer of a stream. It also providers a standard mechanish to access stream controls, such as stop, pause and play. In addition, the Stream Controller abstraction allows the specification of the QoS parameters associated with the stream.
Stream Endpoint (StreamEndpoint)
The StreamEndpoint is an abstraction that encapsulates transport-specific parameters of a stream. It accomplishes the transport-specific parameters of the connection. For example, a stream that uses UDP as the transport protocol will use the host name and the port number to identify hostnames.
Figure 3.13 illustrates components of CORBA streaming framework. An additional component compared above listing is Multicast Config Interface (MCastConfigIf) which is used in the case of stream multicasting.
3.3.2.2 Operational Interfaces
This subchapter introduces operational-specific interfaces, which are Access Interface, Start Service Interface and MOSES CORBA interfaces.
Access Interface
Access Interface defines the access interface components and signalling between them. These components provide a framework for offering secure and personalized access to services in the network where several parties of different business roles are connected together. Its main purpose is to offer means for user or application to interact with service provider and perform requests to establish an access session and further in access session select and start services.
Access Interface main components are (see Figure 3.14):
• Access related User Application (a-UAP). User interface to access session.
• Service related User Application (s-UAP). A-UAP can launch s-UAP.
• User Connector (UCON). User domain’s end-point in access session.
• Initiator (IT). Service provider’s initial contact point for the UCON desiring to interact with the service provider.
• Servant of User (SoU). Service provider domain’s end-point with a user.
Access Interface includes access related user application (a-UAP), which provides the interface for the user to interact with the UCON.
IT is the initial contact point for the UCON for user wishing to interact with the service provider. IT obtains an access session with the SoU.
The UCON and SoU components support authorization, authentication and customization of the user’s service access and provide a secure mechanism for starting sessions. The user domain represents access user role and the provider domain represents access provider role. The provider can also represent access user role when it wishes access to 3pty (3th party provider) services.
Figure 3.15 illustrates general description of access protocol method calls between UCON, IT and SoU when the user wishes to interact with the provider. Meaning of the messages are explained below.
1. UCON calls IT::login
• Arguments: authentication info, UCON reference, parameter list, request ID.
• If UCON authentication info is correct a new SoU is initialized for UCON and loginResponse message is sent to the UCON. SoU is initialized with UCON reference and serviceList.
• If authentication info is incorrect IT does not initialize a new UA and error message is sent to the UCON.
• IT generates a new session ID for the rst of the session between UCON and SoU.
2. IT calls UCON::loginResponse
• Arguments: SoU reference, parameter list, request ID, session ID.
• UCON gets SoU reference.
• Request ID in message 1 is sent back in this message. Request ID is unique per message pair and is checked with original one every time UCON gets a response message.
• If request ID is correct status is set to corresponding value. Status is used with UAP.
3. IT calls UCON::error
• Arguments: N/A
• Authentication info was incorrect and status is set to corresponding value. No SoU was made and access session ends.
4. UCON calls SoU::userContext
• Arguments: parameter list, request ID, session ID.
• SoU resolves the service execution environment of the user, allowing them to use services from many different types of terminals. This requires resource configuration information of the user system.
• SoU sends userContextResponse message to UCON.
5. SoU calls UCON::userContextResponse
• Arguments: request ID, session ID.
• This message does not contain any special information.
6. UCON calls SoU::listSubscribedServices
• Arguments: parameter list, request ID, session ID.
• SoU sends listSubscribedServicesResponse message to UCON with servicelist.
7. SoU calls UCON::listSubscribedServicesResponse
• Arguments: serviceList, parameter list, request ID, session ID.
• Service list includes information about service’s ID, name and sUAPclassName (service specific user application class name). User selects a service by name and selected service’s ID is sent with startService message to SoU.
8. UCON calls SoU::startService
• Arguments: serviceID, parameter list, request ID, session ID.
• SoU sends the service reference that corresponds service ID to UCON with startServiceResponse message.
9. SoU calls UCON::startServiceResponse
• Arguments: service reference, request ID, session ID.
• Service reference is matched sUAPclassName that was get with message 7. It is up to UAP how it handles the case.
Start Service Interface
Start Service Interface [20] is provided by Service Provider, and use by other Service Providers, User Connectors or User Applications. Start Service interface is meant to be used after when access session ends.
Start Service Interface offers only one operation, startService(). The operation returns the service specific address of a new service instance capable of serving a new user. It may create a new service instance, use an existing, shared server instance, or let the user create the server using the returned string.
Servant of User (SoU) running in a Service Provider calls startService() at the end of the access session, during the execution of SoU’s startService operation. The return value is returned to the user via UCON::startServiceResponse(). It is also possible that User Applications use the Start Service interface directly, without any access session, for example if no authentication is required.
A Service Provider can invoke startService() of another Service Provider directly. Service Provider can also start other services indirectly through the access session, by adopting the consumer role.
MOSES CORBA Interfaces
CORBA interfaces comprises of three things: operations, attributes and exceptions. An operation is similar to a function call, process call or method invocation. It passes a message to an object to perform some request. An attribute is some visible information (state or data) that an object possesses. As it happens, there are read-write and read-only attributes (in the IDL language). Exceptions are possible failure conditions that one may generate when some unexpected condition occurs. Exceptional conditions notify a client of a fault occuring. An operational error is user or programmer error. A fault is a system failure of some sort.
Figure 3.16 illustrates CORBA components: Basic, Services and Facilities. Basic components (or CORBA components) consist of CORBA ORB architecture components. Services (or CORBAservices) are a collection of services (interfaces and objects) that support basic functions for using and implementing objects. Facilities (or CORBAfacilities) are a collection of services that are used together in related ways toward common goals. These are frameworks that appear consistently within applications without regard to their domain.
Basic:
• Object Requests Broker (ORB): A proxy that decouples objects from their clients.
• Interface Definition Language (IDL): The syntax and semantic specification of a language specific to defining CORBA objects’ interfaces.
• Interoperable Object Reference (IOR): The CORBA interoperability specification defines an information structure for IORs which describes a general-purpose IOR format. This IOR structure is used in specializations of GIOP and in Environment Specific Inter-ORB Protocols (ESIOPS), such as DCE Common Inter-ORB Protocol.
• Static Invocation Interface (SII): dispatching through stubs and skeletons is called static invocation, which involves the SII. In this case, since stubs and skeletons are built directly into the client application and the object implementation, all the methods are specified in advance and are known to the client and the server via proxies.
• Object Adapter (OA): is a component of the CORBA architecture that supports specific styles of implementation.
• Dynamic Invocation Interface (DII): is the dynamic counterpart of static IDL for making runtime requests on interfaces.
• Interface Repository: is a registry of fully qualified interface definitions.
• IDL C++ Mapping: includes definition of the language-specific data types and procedure interfaces to access objects through the ORB. It includes the structure of the client stub, the dynamic invocation interface, the implementation skeleton, the object adapters, and the direct ORB interface.
Services:
• Naming Service: identifies objects by name when presented with an object reference and vice versa.
• Event Service: A notification service that interested objects may register for in order to receive a notification of an event.
• Object Query Service: provides predicate-based query capability for ORB objects.
• Time Service: enables the user to obtain current time together with an error estimate associated with it. Time service is a set of two services: Basic Time Service (BTS) and Timer Event Service (TES). BTS has three interfaces: Universal Time Object (UTO), Time Interval Object (TIO) and Time Service.
• Concurrency Control Service: mediates multiple client interactions on a resource.
• Licencing Service (LS): provides a mechanism for producers to control the use of their intellectual property. They can implement the LS according to their own needs, and the needs of their customers.
• Security Service: The security functionality comprises:
• Identification and authentication verify that the users or the objects are who they claim to be.
• Authorization and access control: protect resources from abusage.
• Security auditing to make users accountable for their security related actions.
• Security of communication between objects, which is often over insecure lower layer communications.
• Non-repudiation provides irrefutable evidence of actions
• Administration of security information (for example, security policy) is also needed.
• Relationship Service: allows entities and relationships to be explicitly represented.
• Life Cycle Service: An object service providing life cycle services-create, copy, move, delete-for objects.
• Properties Service: provides a way to associate objects with typed Name-Value pairs.
• Transaction Service: supports multiple transaction models, including the flat and nested models. The Object Transaction Service (OTS) supports interoperability between different programming models.
• Persistent Object Service (POS): provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects.
• Externalization Service: provides a means to stream out an objects’s state (externalize) and later, to stream it back in (internalize).
• Trading Service: holds a mapping between object IDs, locations and their properties.
Facilities:
• User Interface Facilities: makes an information system accessible to its users and responsive to their needs.
• Information Management Facilities: covers the modeling, definition, storage, retrieval, management, and interchange of information.
• System Management Facilities: include the management of all components of the information system, including databases. System management of these components includes, operational control, movement, access control, quality of service, measurement (performance and storage capacity) and capacity planning.
• Task Management Facilities: contain information management components. Task Management needs information architecture describing the principle control flows, control models, rules defining constraints, operational policies and quality of services.
RFPs (Request for Proposals)
• Stream Control and Management Facility: provides a set of interfaces to implement a distributed media streaming framework.
Figure 3.17 illustrates basic ORB structure with interfaces and methods.
Selected classes in Figure 3.17 are explained in the following sections.
ORB interface:
ORB interface may expand over time if additional operations appear to require pervasive presence. Operations that are part of the CORBA 2.0 specification are:
• Operations that convert object references to strings and back
• An operation to create a Named Value List
• An operation to create a Named Value List for a specific operation
• An operation to get the default Context
• An operation to initialize the OA (BOA)
• Two operations for resolving initial references
• TypeCode constructors for all major types
Context:
When performing operations on a context object, properties are represented as named value lists. Each property value corresponds to a named value item in the list. A property name is represented by a string of characters. Property names are stored preserving their case, however names cannot differ simply by their case.
Domain Manager and Policy:
A policy domain is a set of objects to which the policy(ies) associated with that domain applies. The objects are the domain members. The policy(ies) represent(s) the rules and criteria that constrain activities of the objects which belong to the domain.
A policy domain includes a unique object, one per policy domain, called the domain manager, which has associated with it the policy objects for that domain. The domain manager also records the membership of the domain and provides the means to add and remove members. The domain manager is itself a member of a domain, possibly the domain it manages.
Current:
ORB and CORBA services may wish to provide access to information (context) associated with the thread of execution in which they are running. This information is accessed in a structured manner using interfaces derived from the Current interface defined in the CORBA module. Each ORB or CORBA service that needs its own context derives an interface from the CORBA module's Current. Users of the service can obtain an instance of the appropriate Current interface by invoking ORB::resolve_initial_references.
NVList:
NVList is a list of NamedValues. A new NVList is constructed using the ORB::create_list operation.
DynAny:
Any values can be dynamically interpreted (traversed) and constructed through DynAny objects. A DynAny object is associated with a data value, which may correspond to a copy of the value inserted into an any. The DynAny object may be seen as owning a pointer to an external buffer, which holds some representation of the data value. A constructed DynAny object is a DynAny object associated with a constructed type.
There is a different interface, inheriting from the DynAny interface, associated with each kind of constructed type in IDL (struct, sequence, union, or array). A constructed DynAny object exports operations that enable the creation of new DynAny objects, each of them associated with a component of the constructed data value. As an example, a DynStruct is associated with a struct value. This means that the object may be seen as owning a pointer to a external buffer which holds a representation of struct. The DynStruct object exports operations that enable the creation of new DynAny objects, each of them associated with a member of the struct.
3.4 Physical Model
The MOSES physical architecture consists basically of servers running OMG CORBA applications (see Figure 1.2 in the introduction chapter). The network layer is IP-network consisting of routers and links. The Physical model of MOSES contains only different server for Internet service providing. These are Content server, Proxy server, and Replication server. Caching relates closely to the concept of the Proxy server.
Proxy servers and caching is a solution to reduce traffic in the most congested content servers (subchapter 3.4.1).
New server type was defined in the MOSES-architecture: Replication server. It is described in chapter 3.4.2.
3.4.1 Content Servers, Proxy Servers and Caching
Content server is a server where the service content, wished by user, resides. Service content is usually Web services containing personal home pages, chat services, applets etc. (free-of-charge services) and e-newspaper services, movie services etc. (chargeable services).
Proxy server is a server which acts as intermediary between local clients and remote content servers. Initially, scientists developed proxy servers to function as firewalls for security reasons. Today proxy servers may function as caching mechanisms as well as firewalls. A proxy server is a machine (or collection of machines) through which all traffic must pass.
When a user asks a client for a certain web page, the client heads out to the Internet. If there is a caching proxy, client requests entry to the proxy server, not to the remote web page. The proxy checks to see if it has already cached the requested page on the proxy server. If the server has a cached copy of the web page, the server returns the page to the client directly (see Figure 3.18).
Returning cached information to clients occurs rapidly because it requires reduced Internet activity. In addition to helping individual clients and networks with proxy servers, caching also helps the remote web page server. Caching reduces the computational load on the remote content server and makes it possible for that server to supply data to more machines. However, caching data always results to the problem of consistency of data, i.e. the cached data may be old. There is also a problem with access rights.
If the server does not have a cached copy of the requested document, the server goes out to the remote web page server, finds the original, and passes the data back to the client at the same time keeping a copy on its cache (see Figure 3.19). [22]
3.4.2 Replication server
The explosive growth of the Internet services has led research workers to invent new techniques for service replication. The main goal of service replication is to decrease the traffic load on the most used portions of the network. In replication, the original service content is transferred to the replicator servers which are situated near the great amount of users. Replication is fully transparent to the clients.
In [23] services are replicated by installing agents on one or more host servers and have them bind to the same set of TCP or UDP ports as the service on the origin host. Here the host servers are hosts that act as server-of-servers. They can host IP services, each of which may be known to the outside world under a different IP address. Typically such services are replicas of the service running on the origin host. The location of the host servers is known to the redirectors, specially equipped routers that maintain information about the host servers and the services installed on them. Redirectors detect requests for replicated services, and redirect the request to the ”nearest” available host server with a replica running.
An appropriate protocol allows dynamical installation of services or removing them, depending on the load in the network and on the servers. This protocol helps servers, redirectors and host servers to collaborate for bringing services near to the customers by installing replica agents on the right host servers.
The following Figure 3.20 shows an example of the Web server replication.
In Figure 3.20 Host 128.142.222.80 represents a host server. The Web service on origin host 195.20.225.20 realized by httpd daemon is replicated on the host server where it is realized by a_httpd daemon. The HTTP requests from Client A are routed to the origin host. The same requests from Client B are intercepted by Redirector R, which happens to be on their route, and which was informed earlier that the nearest Web port for host 195.20.225.20 is located on the host server 128.142.222.80. The requests are route accordingly. Client B’s requests for the telnet service are not rerouted by R, but are forwarded to the origin host.
How to select the servers where the data to be replicated? Service Replication Scheme in [24] uses a User Group Profile and a Service content as input information for the Classifier object. Each user has a Profile, which holds information parameters about services used by this user. Classifier classifies users according to these parameters and built network Group Profiles based on them. User's Group Profile can be used to forecast network traffic load and QoS parameters. The Classifier tries to find common classes or groups between the User profiles and the Service contents. It uses also a history information made by other Classifier objects. With this information the Classifier produces a Decision Matrix (Figure 3.21), where the rows are the User classes and columns are the Service content types. On the matrix cells exits a probability for a particular User Group to request the Service content in the future. Service Replication Manager makes a decision for the best location where to replicate the data based on this matrix.
4. MOSES MOBILITY SUPPORT
The revolution of the Internet, which has occurred near past, will not be restricted in fixed networks in the future. Different parties in this research domain have studied scenarios in which portable computer could act like a client or a server in the wireless distributed environment.
The Mobile IP Working Group of the Internet Engineering Task Force (IETF) [25] is chartered to develop or adopt architectures and protocols to support mobility within the Internet.
OSAM’s [26] (Open Service Architecture for Mobile and Fixed Environments) DPE mobility support is a specific enchancement to a standard DPE to incorporate terminal mobility requirements. OSAM is specified by DOLMEN [27] and it is adopted to MOSES architecture.
This chapter introduces the main parts of Mobile IPv6 and DOLMEN’s DPE mobility support, intented to provide mobility in the MOSES-architecture.
4.1 IPv6 Mobility Support – Mobile IP
IPv6 [28] is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4). Mobile IPv6 [29] is a proposed standard protocol based on IPv6. The goal of Mobile IPv6 is to support and provide transparent mobility to users, applications and higher level protocols such as TCP.
Main Principles of Mobile IPv6
There are two addresses in Mobile IP system: home address which is static and used to identify TCP connections and care-of address which changes at every new point of attachment and can be considered as mobile node’s topologically significant address. The association between a mobile node’s home address and care-of address is known as a binding for the mobile node. Mobile IP requires the home agent, which resides in the home network. The main functions of home agent are to maintain binding cache of a mobile node and redirect data packet to it.
The node communicating with a mobile node is called as a correspondent node (see Figure 4.1) and may be stationary or mobile. When the correspondent node sends packet to the mobile node it checks its cached bindings for an entry for the packet’s destination address. If a cached binding for this destination address is found, the node uses an IPv6 Routing header (instead of IPv6 encapsulation [30]) to route the packet to the mobile node according to care-of address indicated in this binding. If the sending node has no cached binding for this destination address, the node sends the packet normally (encapsulated, with no Routing header) and the packet is subsequently intercepted and tunneled by the mobile node’s home agent.
When a mobile node changes its point of attachment, it sends a packet called Binding Update to its home agent. This message indicates to the home agent the new location of a mobile node. The home agent replies to the mobile node by returning a packet containing Binding Acknowledgement. The care-of address in this binding is known as the mobile node’s primary care-of address. A mobile node obtains its care-of address through stateless [31] or stateful [32] address autoconfiguration, according to the methods of IPv6 Neighbor Discovery [33].
Thereafter the home agent uses the proxy Neighbor Discovery to intercept any IPv6 packets addressed to the mobile node’s home address on the home link, and tunnels them to the mobile node’s primary care-of address. To tunnel each intercepted packet, the home agent encapsulates the packet using IPv6 encapsulation.
Binding Request is used to request a mobile node to send to the requesting node a Binding Update containing mobile node’s current binding.
Any packet that includes Binding Update or Binding Acknowledgement must also include either Authentication Header [34] or Encapsulating Security Payload [35] providing sender authentication, data integrity protection and replay protection. No authentication is required for the Binding Request option.
In the case when a mobile node is away from home and in this moment the home link is under reconfiguration, the mobile node may loose its home agent’s IP address. For such of cases Mobile IPv6 provides a mechanism, known as dynamic home agent address discovery, that allows a mobile node dynamically to discover the IP address of a home agent on its home link with which it may register its care-of address while away from home.
4.2 DPE Support for Mobile Environments
In OSAM [36] architecture, specified by DOLMEN, it is defined how to handle the relations of mobile terminal, and thus mobile objects, and fixed network. In OSAM terminal mobility is based on either GSM or wireless LAN techniques, object mobility is handled by CORBA object referencing mechanisms and tunneling using TCP/IP connections.
In OSAM, two DPE domains are recognised: fixed network DPE domain and mobile terminal DPE domain. To interconnect these domains a wireless bridge can be used. Wireless bridge splits domains in two half bridges, the fixed DPE bridge (FDBR) and the mobile DPE bridge (MDBR).
In OSAM mediated bridging is used to interconnect two half bridges. This means that the bridge can be tailored to meet the characteristics of a wireless network. This is done based on CORBA Environment Specific Inter-ORB Protocol (ESIOP).
When MDBR moves it can change its point of attachment from one FDBR to another. This requires additional capabilities from mobility management. These are e.g. initial access, location updates, signalling handover events and routing updates. Maintaining the interface/object references are handled by enchanced CORBA Naming Service, which enables reference retrieval, based on an object’s name and the use of the Location Forward Mechanism defined in CORBA’s GIOP (General Inter-ORB Protocol).
The reference of any object, which is registered in the naming service, can be found by resolving the object’s unique name. The naming service can be global [37] or local. Maintaining the global naming service, which spans for example the whole world, is very challeging because of its large size, performance etc. issues. In the case of the global naming service it is necessary to be able to access naming systems of another stakeholders. This can be achieved using naming federation [38] between different stakeholders. The mobile terminal’s DPE domain and the fixed network’s DPE domain have their own local naming services.
Maintaining object references on a mobile terminal is very challenging because these references may change when the terminal moves. For these cases a Location Register (LR) is defined. LR maintains the dynamic relationship between the terminal and the CORBA node and thereby it maintains information about the reference of the FDBR and the global location of the terminal. The reference of FDBR is needed to access mobile objects within a mobile terminal because a mobile object can only be reached through the FDBR-MDBR binding. When the mobile terminal hosting the object moves from one area to another FDBR-MDBR binding update has to be accomplished.
There are two binding types for retrieval of object references for mobile objects, constant binding and temporary binding.
In the case of constant binding the FDBR and MDBR are constantly aware of each other’s correct reference. When the MDBR enters the coverage area of a new FDBR, the new FDBR must be made aware of this fact. This type of binding demands a significant amount of signalling information. On the other hand the DPE domain of FDBR is constantly aware about the correct location of MDBR. Location register contains object names coupled to FDBR references.
In the case of temporary binding the MDBR has to be located only if object invocation designated for that MDBR arrives. That means that FDBR does not constantly have to know the right reference of the MDBR. In this case LR contains object names coupled to a location area identifier (LAI). LAI is used to identify different location areas from each other. Binding update in LR is made only when MDBR moves from one location area to another and not for movement within the same location area.
5. MOSES EXAMPLE SERVICE
This chapter introduces the test service, which is based on CORBA Orbix. The following tools were used during the implementation phase:
• Orbix 2.3 of Iona Technologies
• Solaris 2.6 environment
• SunPro C++ 4.1
• CVS 1.9
The main purpose of this work was to get familiar with CORBA Orbix. Implementation of a simple telephone catalogue was selected as an easy example. The implementation was made in the MOSES-project during autumn 1998.
In order to make the application easy to understand, in the IDL interface description was defined only one interface “Catalogue” and in the server description only one class “p_number”. A linked list was used to record the given information in the server side. In the client side there was implemented a simple user interface with traditional while-switch-case structure.
Files
The Catalogue service consists of the following files:
MOSES.idl IDL interface definition
Client side implementation
Moses_Srv.h Server side header file
Moses_ Server side implementation
Moses_ Server application object (exports the service to the network)
In the compiling phase the IDL-compiler creates files which presents so-called client stub and which presents so-called server skeleton. The meaning of these files is to serve as “glue” between the client and server applications.
IDL description
Below is described the IDL interface definition (file MOSES.idl):
struct getInfo{
string surname;
string firstname;
string phonenum;
unsigned short end_of_list;
};
interface Catalogue{
readonly attribute string phonenum;
readonly attribute string surname;
readonly attribute string firstname;
exception reject {string reason;};
void addNumber(in string surname,
in string firstname,
in string phonenum)
raises(reject);
void giveNumber(inout getInfo p);
unsigned short deleteNumber(in string surname,
in string firstname,
in string phonenum);
void listPerson(inout getInfo p);
};
Functions
Client side functions are (file ):
• addNum (); Adds the name and the phone number to the server side linked list.
• searchNum (); Searches the number related to the particular person from the server side linked list.
• delNum (); Removes the particular person and his/her phone number from the server side linked list.
• printAll (); Prints the content of the whole server side linked list.
Server side functions are (file Moses_):
addNumber(CORBA::Char *surname,
CORBA::Char *firstname,
CORBA::Char *surname
CORBA::Environment&);
The function addNumber() sets the Catalogue_ptr type pointer to assign the given name and the phone number.
record(Catalogue_ptr p);
This function is called from addNumber() function. It creates a new node to the linked list and records Catalogue_ptr type pointer to it.
giveNumber(getInfo &persons, CORBA::Environment&);
The principle of this function is that there might be several numbers related to the particular person. Surname and firstname are put to the getInfo structure, which is passed to the server. Server adds the phone number related to the surname and firstname to the structure and passes it back to the client. This is implemented with the IDL parameter “inout”.
deleteNumber(CORBA::Char *surname,
CORBA::Char *firstname,
CORBA::Char *surname
CORBA::Environment&);
Function deleteNumber () removes the given number and the name related to it from the server’s linked list. The return value is “1” if the operation succeeded and “0” if it failed (there was no number related to the given name in the linked list).
listPerson(getInfo &persons, CORBA::Environment&);
Function listPerson () passes the whole content of the linked list node by the node from the server to the client to be printed.
Environmental Settings
The environmental settings, service registration and setting up the daemon have to be done before the service could be used. This procedure is presented below:
1. Environment variables must be set in the following way:
setenv PATH ${PATH}: [full_path_name_to_Orbix_binary_directory]
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:
[full_path_name_to_Orbix_library_directory]
setenv IT_CONFIG_PATH [full_path_name_to_Orbix_cfg_directory]
2. Orbix daemon in the server (orbixd) has to be running:
[full_path_name_to_Orbix_binary_directory]/orbixd &
3. Server registration:
With the procedure below, the service is made available in the Implementation Repository.
[full_path_name_to_Orbix_binary_directory]/putit -h hostname Catalogue [full_path_name_to_server_directory]/server
4. Running the program
./client
The collaboration diagram of the catalogue service is described below.
1. The orbixd-daemon is set on.
2. Service registering is accomplished with putit-command.
1. Service is stored in the Implementation Repository.
3. The client makes the first request to the orbixd.
3.1 The orbixd instantiates the Catalogue service.
4. The client can do the requests directly to the Catalogue service.
5. The client abandons the object identification when it wants to end using the Catalogue service.
References
[1] “Common Object Request Broker Architecture: Architecture and Specification 2.0”. OMG July 1995.
[2] “Overview of CORBA” Douglas C. Schmidt,
URL:
(referred 15.6.99)
[3] “Overall Concepts and Principles of TINA” Version 1.0, February 1995, TINA-C Architecture Documents.
URL:
(referred 15.6.99)
[4] “Basic Principles of TINA” 06.05.99
(referred 15.6.99)
[5] ISO 10746/ITU-T X.900 Series of Recommendations
[6] ISO/IEC DIS 10746-3, “Basic Reference Model of Open Distributed Processing-Part 3: Prescriptive Model”, February 1994.
[7] “Wireless Application Protocol Architecture Specification” WAP Forum April 30 1998.
URL:
(referred 13.7.99)
[8] “Wireless Application Environment Overview” WAP Forum, April 30, 1998. URL:
(referred 13.7.99)
[9] “Wireless Session Protocol” WAP Forum, April 30, 1998. URL:
(referred 13.7.99)
[10] “Wireless Transaction Protocol Specification” WAP Forum, April 30, 1998. URL: (referred 13.7.99)
[11] “Wireless Transport Layer Security Protocol” WAP Forum April 30 1998. URL: (referred 13.7.99)
[12] “Wireless Datagram Protocol Specification” WAP Forum April 30 1998. URL: (referred 13.7.99)
[13]
(referred 15.6.99)
[14] “What is telemedicine” Telemedicine Information Exchange
25.05.1999 URL:
(referred 15.6.99)
[15] “MOSES Model” Petri Heinilä, Mobility and Services
(MOSES) project, Lappeenranta University of Technology, December 1998.
[16] “Control and Management of A/V Streams specification”, OMG Document telecom/97-05-07, October 1997.
URL: (referred 15.6.99)
[17] “The Design and Performance of a CORBA A/V Streaming Service” Sumedh Mungee, Nagarajan Surendran, Douglas C. Schmidt. URL: (referred 15.6.99)
[18] “Control and Management of Audio/Video Streams and
Realtime ORB Protocols”
URL: (referred 15.6.99)
[19] “MOSES A/V Stream” Petri Heinilä, Mobility and Services (MOSES) project, Lappeenranta University of Technology, December 1998.
[20] ”StartService Interface; Software Requirements Specification”
Version 1.1 (proposal), MOSES Project 7.12.1998.
[21] “MOSES CORBA Interfaces” Petri Heinilä, Mobility and Services
(MOSES) project, Lappeenranta University of Technology, December 1998.
[22] ”Caching on the Internet” Lisa Sanger, Spring 1996, Externship
Final Paper UCLA Law Spring 1996,
URL: (referred 15.6.99)
[23] ”Replicating IP Services” Technical Report 97-008. Hamesh Chawla, Riccardo Bettati, Department of Computer Science Texas A&M University.
URL:
(referred 15.6.99)
[24] “Push-caching as a Method of Reducing and Smoothening Traffic
on a Service Enabling Platform” Jorma Jormakka, Petri Heinilä, IFIP Workshop SmartNet 199, 17-19 February 1999 Moscow.
[25] IETF Mobile IP Working Group
URL:
(referred 15.6.99)
[26] “Open Service Architecture for Mobile and Fixed Network Environment (OSAM)”, Final Release, August 28 1998.
URL:
[27] “AC036 Project “Service Machine Development for an Open Long-term Mobile and Fixed Network Environment (DOLMEN)” Home Page, URL: (referred 15.6.99)
[28] “Internet Protocol version 6 (IPv6) Specification” Stephen E. Deering and Robert M. Hinden. IETF RFC, December 1998.
URL: . (referred 15.6.99)
[29] “Mobility support in IPv6” INTERNET-DRAFT, IETF Mobile IP
Working Group, David B. Johnson, Charles Perkins 18 November 1998. URL: (referred 15.6.99)
[30] “Generic Packet Tunneling in IPv6 Specification”A. Conta and S. Deering. IETF RFC, December 1998.
URL: (referred 15.6.99)
[31] ”IPv6 Stateless address autoconfiguration”. Susan Thomson and Thomas Narten, IETF RFC, December 1998.
URL: (referred 15.6.99)
[32] “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”. Jim
Bound and Charles Perkins, INTERNET-DRAFT, February 1999. URL: (referred 15.6.99)
[33] “Neighbor Discovery for IP version 6” T. Narten, E. Nordmark and W. Simpson. IETF RFC, December 1998.
URL: (referred 15.6.99)
[34] “IP Authentication header”. Stephen Kent and Randall Atkinson. INTERNET-DRAFT, November 1998.
URL: (referred 15.6.99)
[35] “IP Encapsulating Security Payload (ESP)”. Stephen Kent and Randall Atkinson. INTERNET-DRAFT, October 1997.
URL: (referred 15.6.99)
[36] “Open Service Architecture for Mobile and Fixed Network
Environment (OSAM)”, Final Release, August 28 1998, p.79-126. URL: (referred 15.6.99)
[37] “Open Service Architecture for Mobile and Fixed Network Environment (OSAM)”, Final Release, August 28 1998, p.85-88
URL: (referred 15.6.99)
[38] “Open Service Architecture for Mobile and Fixed Network Environment (OSAM)”, Final Release, August 28 1998, p. 88-90
URL: (referred 15.6.99)
-----------------------
Figure 2.1: OMA Reference Model Interface Categories [2]
Figure 2.2: CORBA ORB Architecture [2]
Figure 2.3: Layering [4]
Figure 2.5: WAP Programming Model [7]
[pic]
Figure 2.4: RM-ODP Viewpoints and Software Engineering
Implementation
Design
Functional Specification
Requirements Analysis
P o l i c y
Technology
Engineering
Information
Computational
Enterprice
Figure 2.6: WAP Architecture [7]
[pic]
Figure 2.7: UMTS cells
[pic]
Figure 1.1: The Business Environment of Telecommunications
7. checkSubscriptionReq(serviceID = enp, reqID, sessionID)
8. checkSubscriptionResp(serviceID = enp,
resp=positive, reqID, sessionID) / error
Figure 3.9: Over the network surgery
3. loginResp(reqID, sessionID, databaseRef) / error
Figure 3.2: Generic Business Model
Figure 4.2: Wireless bridging
Figure 4.1: The communication between the correspondent node and the mobile node.
Care-of
Address
Correspondent Node
Home Address
Binding Cache
Mobile Node
Router
Mobile terminal
Wireless Bridge
Home Agent
Home Network
Fixed network
Fixed
DPE
Bridge
Mobile
DPE
Bridge
DPE
local Naming
Server
Object
Implementation
DPE
local Naming
Server
Client
Figure 5.1: The Collaboration Diagram of the Catalogue service
5. abandon object ID
4. request
3.1 service instantiation
3. service request
2. register service (putit)
1. start server
Catalogue
Imlementation
Repository
orbixd
Client
2.1 store service
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
Figure 3.13: A/V Stream interface [19]
Figure 3.12: CORBA streaming framework components [18]
Figure 3.11: OMG Streams Architecture [16]
Multimedia Stream (out-of-band stream)
ORB CORE
Control and
Management
Object
Stream
Interface
Control
Object
Stream
Interface
Control
Object
BOA
BOA
Stream
Adaptor
Stream
Adaptor
Flow data
End-point (sink)
Flow data
End-point (source)
5. sendserviceList(serviceList, reqID, sessionID)
4. getserviceList(reqID, sessionID)
13. sendchosenENP(xmagRef, reqID, sessionID)
10. chooseENP(enpID= xmag, reqID, sessionID)
Figure 3.15: Access Session Interface MSC
9. startServiceResponse (serviceRef, reqID, sessionID)
8. startService (serviceID, paramList, reqID, sessionID)
7. listSubscribedServicesResponse (serviceList, paramList, reqID, sessionID)
6. listSubscribedServices (paramList, reqID, sessionID)
5. userContextResponse (reqID, sessionID)
4. userContext (paramList, reqID sessionID)
3. loginResponse (SoUref, paramList, reqID, sessionID / error
2. (create)
1. login (authInfo, UCONref, paramList, reqID
a-UAP
UCON
9. sendENPlist(enplistRef, reqID, sessionID)
6. chooseService(serviceID=enp, reqID, sessionID)
11. confirmSubscriptionReq(enpID = xmag, reqID, sessionID)
2. checkAuth(authInfo)
1. login(authInfo, customerRef, reqID)
SoU
IT
Service
Database
Register
Manager
Figure 3.1: Moses overall model
Figure 1.2: The scope of Moses architecture
Figure 3.3: Library Service
Figure 3.7: Use Case: News Service
IT creates new SoU for each session
Service Provider Domain
SoU
IT
User Domain
UCON
Figure 3.14: Access components and their relations
Customer
16. Data Stream
12. movieReadyForDownloadResponse(option=download, reqID, sessionID)
11. movieReadyForDownloadRequest(xmovieRef, reqID, sessionID)
15. addingResponse(succeedMsg, reqID, sessionID)
13. addingRequest(movieID=xmovie, charge, reqID, sessionID)
14. addCharge(movieID=xmovie, charge, sessionID)
3. loginResp(reqID, sessionID, databaseRef) / error
5. sendserviceList(serviceList, reqID, sessionID)
4. getserviceList(reqID, sessionID)
10. chooseMovie(movieID=xmovie, reqID, sessionID)
9. sendMovieList(movieListRef, reqID, sessionID)
6. chooseService(serviceID=movieService, reqID, sessionID)
7. checkSubscriptionReq(serviceID = movieService, reqID, sessionID)
2. checkAuth(authInfo)
1. login(authInfo, customerRef, reqID)
Service
Database
16. addingResponse(bookID=xbook, succeedMsg, reqID, sessionID)
14. addingRequest(bookID=xbook, charge, reqID, sessionID)
13. bookAvailabilityResp(bookID=xbook, option=reserve/reject, sessionID)
12. bookAvailabilityMsg(bookID=xbook, availabilityMsg, reqID, sessionID)
11. checkReservation(bookID=xbook, sessionID)
15. makeReservation(bookID=xbook, charge, sessionID)
17. bookReservationConfirm(bookID=xbook, reservationMsg, sessionID)
3. loginResp(reqID, sessionID, databaseRef) / error
5. sendserviceList(serviceList, reqID, sessionID)
4. getserviceList(reqID, sessionID)
10. chooseBook(bookID= xbook, reqID, sessionID)
9. sendBookList(bookListRef, reqID, sessionID)
6. chooseService(serviceID=bookReservation, reqID, sessionID)
7. checkSubscriptionReq(serviceID = bookReserv, reqID, sessionID)
2. checkAuth(authInfo)
1. login(authInfo, customerRef, reqID)
Register
Manager
Customer
Service
Database
Register
Manager
Customer
8. checkSubscriptionResp(serviceID = bookReserv,
resp=positive, reqID, sessionID) / error
Figure 3.5 Book reservation service MSC
8. checkSubscriptionResp(serviceID = movieService,
resp=positive, reqID, sessionID) / error
Figure 3.4 Movie service MSC
12. confirmSubscriptionResp(enpID = xmag, reqID, sessionID) / error
Figure 3.6 E-newspaper MSC
9. chargingResponse(state, reqID, sessionID) / error
8. performCharging(charge, reqID, sessionID)
3. loginResp(reqID, sessionID, databaseRef) / error
5. sendHeadlines(headlineRef, reqID, sessionID)
4. getHeadlines(reqID, sessionID)
10. sendNews(newsRef, reqID, sessionID)
6. chooseNews(certainNews, reqID, sessionID)
7. chargingRequest(charge, reqID, sessionID)
2. checkAuth(authInfo)
1. login(authInfo, customerRef, reqID)
News
Repository
News
Manager
Customer
Figure 3.8: News service MSC
…
Figure 3.10: MOSES-model class diagram [15]
Figure 3.17: Basic ORB Interfaces [21]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
…
128.142.222.80
128.142.222.80
…
…
128.32.33.109:80
195.20.225.20:80
host server
service (ip-addr:port)
redirector table for R
Figure 3.20: Replicating a Web Server [23]
origin host
195.20.225.20
internetwork
redirector
Client B
”get object from
195.20.225.20”
”telnet to
195.20.225.20”
Client A
”get object from 195.20.225.20”
replicated IP address
replicated service
host server
128.142.222.80
128.32.33.109
195.20.225.20
80
80
…
a_httpd
a_httpd
R
telnetd
Figure 3.21: Data Replication Scheme [24]
Service
Replication
Manager
Decision
Matrix
profile
content
Other
Classifiers with history information
Classifier
Service
content
User Group profile
httpd
Figure 3.18: Getting the document from the cache
Remote
Server
Cache
Proxy
Server
Client
Figure 3.19: Getting the document from the remote server
and keeping a copy in cache
Remote
Server
Cache
Proxy
Server
Client
Figure 3.16: CORBA Components
Facilities
Services
RFPs
Stream Control and Management
Facility
Task Management
Facilities
System Management
Facilities
Information Management
Facilities
User Interface
Facilities
Externalization
Service
Trading
Service
Persistent
Object
Service
Transaction
Service
Properties
Service
Life Cycle
Service
Relationship
Service
Security
Service
Licencing
Service
Concurrency
Control
Service
Time
Service
Object Query
Service
Event
Service
Naming
Service
Basic
IDL C++ Mapping
Interface Repository
Dynamic Invocation Interface (DII)
Object Adapter (OA)
Static Invocation Interface (SII)
Interoperable Object Reference (IOR)
Interface Definition Language (IDL)
Object Request Broker (ORB)
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- 1 or 2 374 374 1 0 0 0 1 168 1 1 default username and password
- 1 or 3 374 374 1 0 0 0 1 168 1 1 default username and password
- 1 or 2 711 711 1 0 0 0 1 168 1 1 default username and password
- 1 or 3 711 711 1 0 0 0 1 168 1 1 default username and password
- 1 or 2 693 693 1 0 0 0 1 168 1 1 default username and password
- 1 or 3 693 693 1 0 0 0 1 168 1 1 default username and password
- 1 or 2 593 593 1 0 0 0 1 or 2dvchrbu 168 1 1 default username and password
- 1 or 3 593 593 1 0 0 0 1 or 2dvchrbu 168 1 1 default username and password
- 1 or 2 910 910 1 0 0 0 1 168 1 1 default username and password
- 1 or 3 910 910 1 0 0 0 1 168 1 1 default username and password
- 192 1 or 2 33 33 1 0 0 0 1 1 1 default username and password
- 1 or 2 364 364 1 0 0 0 1 168 1 1 admin username and password