OPENSTREAM SERVICES ARCHITECTURE 1.0

Transcription

1 OPENSTREAM SERVICES ARCHITECTURE Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

2 TABLE OF CONTENTS 1 INTRODUCTION PURPOSE SCOPE AUDIENCE ORGANIZATION REFERENCES ACRONYMS OSA STANDARDS AND CONVENTIONS DESIGN STANDARDS Software Design Patterns Rational Unified Process SOFTWARE DEVELOPMENT TOOLS OSA OBJECT MODEL Distributed Object Technology CORBA Services ARCHITECTURE OVERVIEW DETAILED ARCHITECTURE OSA FRAMEWORK OSA Framework Model ServantBase ServantFactory ServantBaseIterator OSA Event Defines ServantBase Exceptions Component Lifecycle Actor Model Framework Usage Scenarios and Sequence Diagrams APPLICATION OBJECTS APPLICATION CLASS DIAGRAMS SERVICE OBJECTS OFFERING OBJECTS APPLICATION ELEMENTS APPLICATION SEQUENCE DIAGRAMS PROVIDER COMPONENT...57 PROVIDER CLASS DIAGRAM...57 Provider-Defined Exceptions...60 Provider Sequence Diagrams PACKAGE COMPONENT PACKAGE CLASS DIAGRAMS Package Elements PACKAGE USAGE SCENARIOS AND SEQUENCE DIAGRAMS ASSET COMPONENT...79 Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

3 7.1 ASSET CLASS DIAGRAMS Asset Elements MetadataList Elements ASSET SEQUENCE DIAGRAMS CONTENT COMPONENT CONTENT CLASS DIAGRAMS Content Elements CONTENT USAGE SCENARIOS AND SEQUENCE DIAGRAMS CUSTOMER COMPONENT CUSTOMER CLASS DIAGRAMS Customer Elements PURCHASE COMPONENT PURCHASE CLASS DIAGRAMS Purchase Elements PURCHASE SEQUENCE DIAGRAMS AND USAGE SCENARIOS EQUIPMENT COMPONENT EQUIPMENT SEQUENCE DIAGRAMS AND USAGE SCENARIOS SESSION COMPONENT Session Messaging Session Architecture SESSION CLASS DIAGRAMS Session Elements SESSION SEQUENCE DIAGRAMS SESSION RESOURCES DSM COMPONENT DSM CLASS DIAGRAMS DSM Elements SERVICEGATEWAY COMPONENT SERVICEGATEWAY CLASS DIAGRAMS ServiceGateway Elements STREAM COMPONENT STREAM CLASS DIAGRAMS Stream Elements STREAM USAGE SCENARIOS AND SEQUENCE DIAGRAMS...170

4 TABLE OF FIGURES Figure 1: OSA CORBA Naming Service Context Hierarchy 7 Figure 2: Publish Event 12 Figure 3: Consume Event 13 Figure 4. Software Categories 15 Figure 5. Detailed OSA Architecture Overview 17 Figure 6: Basic OSA Framework Class Diagram 19 Figure 7: OSA Event Constants 26 Figure 8: Basic OSA Exceptions 27 Figure 9: State Transition Diagram for OSA Servant Objects 28 Figure 10: OSA Actor Taxonomy 30 Figure 11: Create a Servant 31 Figure 12: Provision a Servant 33 Figure 15: Stop a ServantFactory Object 38 Figure 16. Component Diagram: Application Component 40 Figure 17. Simple Application Object 40 Figure 18: OSA 1.0 Class Diagram: Application Component 42 Figure 19. OSA 1.0 Class Diagram: Application Relationship Model 43 Figure 20. Class Diagram: Offering Relationship Model 44 Figure 21: Application-Defined Exceptions 51 Figure 22: Sequence Diagram: Application Creates and Provision Service 52 Figure 24: Sequence Diagram: Application Retires a Service 55 Figure 25. OSA 1.0 Class Diagram: Provider Component 58 Figure 26: Provider-Defined Exceptions 61 Figure 27: Register a Provider 62 Figure 28: Retire Provider 63 Figure 29. Example of a Package 65 Figure 30. Component Diagram: Package Component 65 Figure 31: OSA 1.00 Class Diagram: Package Component 66 Figure 32: Package-Defined Exceptions 69 Figure 33. OSA 1.00 Class Diagram: Package Relationship Model 70 Figure 34: Sequence Diagram: Initial Installation of a Non-Application Package 73 Figure 35: Sequence Diagram: Install App Package 77 Figure 36. Component Diagram: Asset Component 79 Figure 37. Title Asset Structure 81 Figure 38: OSA 1.00 Class Diagram: Asset Component 84 Figure 39. OSA 1.00 Class Diagram: Metadata and MetadataList Objects 87 Figure 40. OSA 1.00 Class Diagram: Asset Relationship Model 89 Figure 41: Asset-Defined Exceptions 89 Figure 42: Sequence Diagram: A Service Delivers an Asset 91 Figure 43. Component Diagram: Content Component 93 Figure 44: OSA 1.00 Class Diagram: Content Component 94 Figure 45. OSA 1.00 Class Diagram: Content Relationship Model 95 Figure 46: Content-Defined Exceptions 98 Figure 47. Component Diagram: Customer Component 99 Figure 48: OSA 1.00 Class Diagram: Customer Object 100 Figure 49: OSA 1.00 Class Diagram: Customer, Purchase and Equipment Relationship 101 Figure 50. Component Diagram: Purchase Component 104 Figure 51: OSA 1.00 Class Diagram: Purchase Object 105 Figure 52: Class Diagram: Purchase-Defined Exceptions 108 Figure 53: OSA 1.00 Class Diagram: Customer, Purchase and Equipment Relationship 108 Figure 54: Sequence Diagram: Subscription Purchase 110 Figure 55:Sequence Diagram: Per-Use Purchase 113 Figure 58: Class Diagram: Equipment-Defined Exceptions 118

5 Figure 59: OSA 1.0 Class Diagram: Customer, Equipment and Equipment Relationship 119 Figure 60. Component Diagram: Session Component 120 Figure 61. Messaging Domains 122 Figure 62. DSM-CC Message Flow 124 Figure 63: OSA Session Architecture 126 Figure 64: OSA 1.0 Class Diagram: Session Component 127 Figure 65: Session-Defined Exceptions 128 Figure 66: Sequence Diagram: Create A Session 138 Figure 67: Sequence Diagram: Session Resource Negotiation Failure 143 Figure 68: Sequence Diagram: Tear Down a Session 144 Figure 69. DSM-CC Message Formats 146 Figure 70. OSA 1.0 Listing of Class Diagrams in the Resource Model 147 Figure 71: Resource Model: Resource Data Model 148 Figure 72. Resource Model: Resource Value Type 150 Figure 73. Class Diagram: Resource Allocation Structure 152 Figure 74. Class Diagram: MpegProgram Model 153 Figure 75. Class Diagram: TsDownstreamBandwidth Model 153 Figure 76. Class Diagram: ClientConditionalAccess Model 154 Figure 77. Class Diagram: HeadendId Model 154 Figure 78. Class Diagram: Ip Model 155 Figure 79. Class Diagram: AtscModulationMode Model 155 Figure 80. Class Diagram: PhysicalChannel Model 155 Figure 81. Class Diagram: ServerConditionalAccess Model 156 Figure 82. Component Diagram: DSM Component 157 Figure 83: OSA 1.0 Class Diagram: DSM Object 158 Figure 84. Component Diagram: ServiceGateway Component 160 Figure 85: OSA 1.0 Class Diagram: ServiceGateway Object 161 Figure 86. Component Diagram: Stream Component 163 Figure 87: OSA 1.0 Class Diagram: Stream Component 165 Figure 88: Stream-Defined Exception 166 Figure 89: Sequence Diagram: Create a Stream 172

6 1 Introduction 1.1 Purpose This document describes the OpenStream Services Architecture (OSA). Application developers must use this architecture to implement OSA-compliant software applications. 1.2 Scope The OpenStream Services Architecture (OSA) specification defines server side interfaces required for an application developer to implement an OSA-compliant Service. This specification document defines a technical architecture; it does not describe business policies. This specification does not describe client interfaces (interfaces located on a customer s set-top converter or PC). The OSA specification does not describe specific Services, but it may reference specific Services as examples. 1.3 Audience The primary audiences for this specification document are: Application developers Suppliers of Pegasus software components 1.4 Organization This specification document provides a comprehensive overview of the OpenStream Services Architecture. The actual OSA specification consists of: A Unified Modeling Language (UML) object model A set of Interface Definition Language (IDL) files that contain the interface definitions required by the OSA specification. 1.5 References The following documents are applicable to this specification: 1. CableLabs Video-on-Demand Content Specification, Version CableLabs Asset Distribution Interface Specification, Version OMG Unified Modeling Language Specification, September 2001, Version CORBAServices: Common Object Services Specification, Naming Specification, September 2002, Version of 180 Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

7 5. DSM-CC Specification (ISO/IEC ) 1.6 Acronyms The following acronyms are used throughout this specification document. Acronym ADI ADS AMS API ATSC BMS BOSS CORBA CSSR DHCT DSM-CC FTP HFC IDL IOR IIOP IP LSCP MPEG NSAP OSA SMS SRM Definition Asset Distribution Interface Asset Distribution System Asset Management System Application Program Interface. Advanced Television Systems Committee Business Management System Business and Operations Support System Interface Common Objects Request Broker Architecture Client Session Setup Request Digital Home Communications Terminal Digital Storage Media Command and Control File Transfer Protocol Hybrid Fiber Coaxial Interface Definition Language Interoperable Object Reference Internet Inter-Operability Protocol Internet Protocol Lightweight Stream Control Protocol Moving Picture Experts Group Network Service Access Point OpenStream Services Architecture Subscriber Management System Session and Resource Manager 2 of 180 Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

8 Introduction Acronym SSP SSSI SSSR TCP UML U-N U-U Definition Session Setup Protocol Server Session Setup Indication Server Session Setup Response Transmission Control Protocol Unified Modeling Language User-to-Network User-to-User

9 2 OSA Standards and Conventions 2.1 Design Standards This section of the OSA specification document briefly describes the objectoriented methodology and software design tools used to design and develop the OSA 1.0 object model Software Design Patterns The OSA architects and system designers wanted to develop an efficient system that made the best of use software engineering practices such as code reuse and rapid code development. With these goals in mind, they chose to use and adapt proven software design patterns for OSA components. The OSA design team chose the Factory pattern to implement key aspects of the OSA design. Refer to the book, Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides for more information about software design patterns. The design team also decided to expedite the design process by using Rational Rose software engineering tools and the Rational Corporation s software engineering process called the Rational Unified Process Rational Unified Process The Rational Unified Process is a software engineering framework that uses the Rational Rose design tool to create object models of complex object-oriented systems. Using this tool to create the OSA object model allowed OSA architects to create and modify the design online before coding the system. This design tool also allowed architects to refine the OSA design and create online models that reflected real world scenarios in which the architecture would function. A key component in this design methodology is a software modeling language called the Unified Modeling Language (UML). 2.2 Software Development Tools This section of the specification gives a brief synopsis of the software development tools and environment in which the OSA was designed and implemented Unified Modeling Language (UML) Notation The following definition is taken from the Object Management Group s (OMG) UML specification document: 2 of 180 Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

10 OSA Standards and Conventions The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. 1 The OSA design team wrote the OSA1.0 object model using UML using the following types of diagrams: Component Diagrams Component diagrams show the structure of the code itself. A component diagram consists of components such as objects, source code files, binary code files, executable files, or dynamic-link libraries (DLLs). Usually, each component in a component diagram is detailed in a class diagram. Class Diagrams A type of static diagram that shows parts of software entities. In a class diagram, the parts are classes, attributes and associations. A class diagram also shows operations, methods, and interfaces and entity relationships. Relationship Diagrams A special type of class diagram that shows how classes work together in a software system. Sequence Diagrams A type of interaction diagram that shows actors, objects and events that make up an interaction arranged in a numbered sequence. Sequence diagrams in OSA 1.0 are often pictorial representations of usage scenarios that illustrate how OSA components work together to perform system tasks. State Diagrams A representation of a state machine. A state machine is a graph of states that illustrate an object s response to outside influences. The OSA 1.0 used the following software in its implementation: Common Object Request Broker Architecture (CORBA) 2.0 Interface Design Language (IDL) JAVA 2.0 Extensible Markup Language (XML) Internet Inter-ORB Protocol (IIOP) as the basic Interoperability Protocol 1 OMG Unified Modeling Language Specification, September 2001, Version 1.4, formal/ , Retrieved December 2, 2002, from

11 OSA Standards and Conventions 2.3 OSA Object Model Distributed Object Technology Designing and implementing scalable, robust, distributed object oriented systems is never an easy task. Widespread industry adoption of the CORBA 2.0 (Common Object Request Broker Architecture) specification has made the process much easier in recent years. CORBA provides a distributed object framework and a set of standard services that make it much easier to design large systems composed of heterogeneous hardware and software systems from many different vendors. Some of CORBA s key features make it an ideal choice to implement OSA-compliant systems: Object Oriented Capability CORBA is an object oriented technology that allows application developers to use best practice software engineering techniques throughout a software project s development, implementation and maintenance lifecycle. Location Independence CORBA is location independent. This means that a client wishing to access a CORBA object does not need to know where the object resides. The object can exist locally, on the same machine, or it can be located on a machine half way across the world. This location independence gives system architects a great deal of flexibility and scalability when designing large-scale distributed software systems. Language Independence Clients and servers in CORBA systems are language independent. Application developers can write client and server components in any language for which CORBA mapping exists. For example, a Java client making a call to a CORBA object implemented in C++ or COBOL does not need to know, or care, what language the application developer used to write the CORBA object. Implementation Independence A CORBA object s underlying implementation is completely hidden from clients that request it. This implementation independence means the system architects and application developers can change the implementation at any time to address issues such as scalability, performance, memory consumption, etc. Hardware Architecture Independence A CORBA object s underlying hardware architecture is hidden from clients who call it. Internal data representation formats and other issues such as byte ordering are also hidden from clients that call CORBA objects. Operating System Independence Clients invoking CORBA objects do not need to know the operating system on which a Server object is implemented.

12 OSA Standards and Conventions Protocol Independence Clients invoking CORBA objects do not need to know the underlying communications protocols used by a Server object. Transport Independence Clients invoking CORBA objects do not need to understand the underlying physical transport media or data link layer used to communicate with a Server object. The OSA 1.0 specification includes a set of Rational Rose diagrams and a set of IDL files CORBA Services CORBA offers a number of pre-defined services that provide basic functionality commonly required by many different types of software systems. The following sections discuss the standard CORBA services used by the OSA and provide details on how each service is used in the context of the OSA. Naming Service Description In any distributed object system, one of the key problems that must be solved is how to obtain a reference to an object whose location may not be known. Object location transparency is a major feature of CORBA and the CORBA specification provides a standard service that clients can use to obtain object references while maintaining location transparency. This service is known as the CORBA Naming Service. The CORBA Naming Service provides a hierarchical distributed naming service that clients may use to resolve object references. When a server object begins execution, it registers itself with the CORBA Naming Service under some particular name. Clients then simply present a request to the naming server for an object with that name, and the name server returns an object reference that the client can use to invoke the requested object s methods. In order for clients to effectively use the naming service, a standard naming hierarchy is defined by the OSA so that clients know the standard names of the objects that they wish to use. The following section details the naming structure hierarchy that the OSA uses Naming Structure The CORBA Naming Service stores object references in a tree-structured hierarchical naming structure similar to the nested folders in Windows or the UNIX file system structure. The hierarchy consists of naming contexts, which may contain references to objects, or other naming contexts. The naming context at the root of the naming hierarchy is the root naming context. The following diagram shows the standard naming contexts and object names defined by OSA:

13 OSA Standards and Conventions / Applications Services Factories Service Gateways Mod Application RollerSteam Hockey Application Provider Factory Product Factory Package Factory Asset Factory BMS Service Gateway ModService RollerSteam Hockey Service Stream Service Metadata Factory Application Factory Customer Factory Purchase Factory Equipment Factory Session Gateway Stream Service VodContent StoreFactory Vod Content Store CORBANamingSvc_140.vsd Figure 1: OSA CORBA Naming Service Context Hierarchy OSA Application of the Naming Service This architecture (OSA) adopts a very specific policy for using the CORBA Naming Service and determining the types of objects registered with the naming service. As a general policy, OSA only publishes Factory Object References in the naming service. A factory object is an object that creates other objects. Registering only factory objects avoids cluttering the naming service with thousands of small objects. This substantially reduces name server storage requirements and potential performance degradation. Registering and storing references to factory objects in the naming service permits object factories to act as entry points to individual system components. Notification Service In any distributed system, it is frequently necessary to inform one or more system components when an occurrence (event) of interest to that component happens. The CORBA Notification Service provides a framework for sending asynchronous communication messages (notifications) to objects informing them that specific events have occurred. The CORBA Notification Service (also called the Event Service) uses a supplier/consumer distribution model. The OSA event model primarily consists of the following components.

14 OSA Standards and Conventions Push Supplier An OSA component interested in publishing events to the event channel. A push supplier connects to the proxy push consumer (StructuredProxyPushConsumer if StructuredEvents are being pushed or SequenceProxyPushConsumer if Sequence of StructuredEvents are being used) and transmits the event data to the consumer by invoking the appropriate push method (push_structured_event for StructuredEvent or push_structured_events for sequence of StructuredEvents). Proxy Push Consumer An interface supported by the event channel which acts on behalf of all the registered push consumers on the event channel. A proxy push consumer object consumes events published by suppliers and passes them to actual consumers. Suppliers use a connect method to attach themselves to a proxy push consumer object. Appropriate proxy push consumers have to be used depending upon the type of the events used. Push Consumer An OSA component that registers interest in consuming events from an event channel. Push consumers connect to proxy push supplier on the event channel to receive events from the suppliers. Push consumers must inherit functionality from an appropriate push consumer (under the CosNotifyChannelAdmin module) and implement the appropriate push and disconnect operations. If a component cannot directly inherit from the push consumer, they can use a servant which actually inherits from the push consumer and provides implementation for the push and disconnect operations (tie mechanism). Proxy Push Supplier An interface supported by the even channel which acts on behalf of consumers. A proxy push supplier works on the consumer side of the event channel. Consumers connect to proxy push suppliers and these proxy suppliers behave as actual suppliers. The Notification Service supports the delivery of events in one of three ways: In CORBA::Any A CosNotification::StructuredEvent A sequence of Structured Events. Based on the type of event communication used, appropriate proxy consumers and suppliers must be used on the supplier and the consumer side respectively. Event notifications are sent to components over an event channel. An event channel is a CORBA object that allows other objects to communicate with each other without knowing about each other. Suppliers are objects that supply events to an event channel. Consumers are objects that receive events from an event channel. The process of supplying events is sometimes called publishing events.

15 OSA Standards and Conventions The Notification Service provides quality of service (QOS) settings that allow applications to control what quality of service is necessary for event message delivery. It is acceptable for a consumer to miss some types of event messages, but in some cases, it is essential to guarantee that a consumer receives an event message. For example, it might not be catastrophic if an informational event message intended for a human operator gets dropped, but it is unacceptable to drop event notifications involved in processing customer payments. The OSA event model uses the Notification Service s push event model of communication. In this model, each individual Notify (or Event) channel provides a proxy consumer. A proxy consumer receives event communication from the suppliers and then uses a proxy supplier to pass event data to the actual consumer. In simple terms, a supplier calls an interface on the consumer to push the event Event Filtering The Notification Service supports event filtering, which gives event consumers the ability to filter events. Event consumers can define filters that encapsulate a set of constraints on notifications and add them to the proxy or the admin. Filters contain constraint expressions that define the filtering criteria. Each constraint expression consists of a sequence of event types to which the constraint applies and an expression in the constraint language (default constraint language used is EXTENDED_TCL ) that defines the constraints on events of this type. Constraint expressions can refer to variables that are parts of the notification event. In OSA, since the actual event data is carried in the filterable_data part of the body of an event, consumers can define filters with constraints including some or all the parts of the actual event. For example, for an event carrying the AdministrativeStateChange information of a servant object, the constraint expression in the filter can include event_name, timestamp, servantior (stringified IOR of the servant that changed), the new administrative state, and/or any other attribute of the event. Within a filter, individual constraints are applied with an OR semantics, so the event goes through even if one of the constraints is satisfied. The same OR semantics apply to the combination of filters added to an admin or a proxy. But, when the results of the filters associated with an admin and a proxy are combined, the semantics depend upon the value of the MyOperator attribute in the admin object that can be set during the creation of the admin object. For the default admin object its value is OR OSA Application of the Notification Service

16 OSA Standards and Conventions As mentioned earlier, the Notification Service supports events of type CORBA::Any, CosNotification::StructuredEvent, and sequence of Structured Events. The Structured Event has a fixed header (containing the EventType and Event Name), a variable header (containing a sequence of zero or more name and value pairs to define the standard event quality properties like priority, reliability, timeout, etc defined in the Notification Service: Joint Revised Submission document, OMG Document Number telecom/ , January 1998), a filterable body (containing a sequence of zero or more name and value pairs to define the event data on which event consumers are most likely to base event filter decisions) and finally a non-filterable/fixed body (containing the actual event data). OSA defines Event Channels on a per-component basis. All events for a particular Component are sent to that Component s Event Channel. The EventType information is used by the event consumer to decide on the specific action needed to be taken in response to the occurrence of the event. Right now there are three EventTypes defined to identify the basic OSA events. They are AdministrativeStateChange, OperationalStateChange, and ProvisioningStateChange. The domain_name for all the three EventTypes is OSA. The domain name and the event type names are defined in the OSA idl as const strings. The basic OSA events (or any other events defined by an OSA compliant application) occupy the filterable_data part of the body portion of the StructuredEvent. Event consumers use this filterable data to define filters to receive only desired events and they also grab the actual event data from the name and value pairs in the filterable_data. The EventType of the StructuredEvent defines the type of the actual event data that the StructuredEvent is carrying. The following events shall be published by OSA Servant objects: AdministrativeStateChange: This event is published whenever a Servant object s AdministrativeState is changed, generally by a system operator using a Provisioning GUI. The event contains a reference to the Servant object that published the event, and a copy of the AdministrativeState of that object. The filterable-data section of the AdministrativeStateChange event will conform to the following table: Timestamp servantior Name theadministrativestate time stamp as a long Value stringified IOR of the object that is changing the new administrative state (ServerModule::AdministrativeState)

17 OSA Standards and Conventions OperationalStateChange: This event is published whenever a Servant object s OperationalState changes. This can result from a change in the object s AdministrativeState or from a change in the ability of the object to deliver its functionality. The event contains a reference to the Servant object that published the event, and a copy of the OperationalState of that object. The filterable-data section of the OperationalStateChange event will conform to the following table: timestamp servantior Name theoperationalstate time stamp as a long Value stringified IOR of the object that is changing the new operational state (ServerModule::OperationalState) ProvisioningStateChange: This event is published whenever a Servant object is provisioned, either through its own provisioning interface, or through attributes it derives from other Components. The event contains a reference to the Servant object that published the event. The filterable-data section of the ProvisioningStateChange event will conform to the following table: timestamp servantior Name time stamp as a long Value stringified IOR of the object that is changing Individual Components may optionally define additional events, which shall be published to the Component s Event Channel Event Usage Scenarios The following scenarios illustrate the basic usage of the Notification Service. In general, for economy of expression, scenario diagrams will show events as messages being sent to the appropriate Event Channel. This is only a shorthand notation, however. All events should be sent and consumed using the scenarios in this section.

18 OSA Standards and Conventions Publish Event Figure 2: Publish Event Consume Event

19 OSA Standards and Conventions Figure 3: Consume Event

20 3 Architecture 3.1 Overview OSA represents individual system concepts as Components. A Component is a collection of individual CORBA interfaces that work together to manage the lifecycle of a system concept. The OSA specification does not specify the implementation of these interfaces. Application developers can implement these CORBA interfaces together in a single executable or they can implement them separately, in multiple executables distributed across a network. Figure 4. shows a high-level organization of software Components in the OpenStream Services Architecture. This graphic includes OSA software Components grouped into categories that roughly correspond to their functionality and the external entities that interact with the software (Customers and Operations personnel). Customers are service providers who originate applications and associated content. Operations personnel include Marketing personnel, Customer Service Representatives (CSRs) and Technical Operators. The major categories of software included in Figure 4. are: Management Content Access Networks Interactive Services Bus (OSB) Operations personnel use a management Component to interact with Customers and Service Providers. Content systems maintain and deliver applications and content to customers. Broadcast file systems, video on demand servers, and web servers are examples of content systems. Access networks are considered Services and they are also used to deliver Services. Access Networks include broadband and cable modem networks. Movies on Demand, e-commerce, e- mail, and Internet access are examples of Services. The OSB is the software bus by which the Components of the network communicate with each other for purposes of provisioning and maintaining the services offered on the network. Note: The ISB does not move content. 2 of 180 Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify.

21 Architecture Operations Customers Customers Customers Management Services Provider Provider Service Providers OSB Content Access Networks Figure 4. Software Categories 3.2 Detailed Architecture OSA exists in the server and is proxied to set-top Components. The system has additional interfaces that are not part of OSA such as the: Asset Distribution Interface (ADI) Session Setup Protocol (SSP) Lightweight Stream Control Protocol (LSCP) Business and Operations Support System Interface (BOSS) The OSA 1.0 specification adheres to the following principles:

22 Architecture There can be multiple instances of any objects. The exception is certain objects in the management category. Marketing, CSR, and other User Interface objects are applications. Other applications may provide services such as customer self-provisioning. The CORBA bus architecture allows connections between any objects. Access control is not part of the OSA Model. A product must implement every object s functionality. A product s the method of implementation does not drive the OpenStream Services Architecture. Products that provide Services (Applications) implement Application, Service, and Offering objects. Network product such as the DNCS, implement Authorization, Entitlement, and Terminal objects. The Business Management System (BMS) product implements CORBA services (name, event, etc.) and Asset, Package, and Provider objects. Products such as VOD servers, web servers, or data carousels implement Content, Session, and Stream objects. Figure 5. shows a detailed view of the OSA Architecture.

23 Architecture Services Legend: CSR, Mktg, Ops SMS UI Mgmt UIs Management CSR, Mktg, Ops UI app SMS application Customer Customer Applicat n Service Service application Application Service App server App client Interfaces black oval Products -- black rectangle Subscriber Management (Billing) System BBI Purchase Equipment Asset Purchase Equip t Asset Offering Authorizt Offering Access Network Authorizati on BOSS DNCS or CMTS SSP Categories of Objects dotted line rectangle OSB red line Asset Distribution System ADI Package Provider Package Provider Entitlemn t Terminal Entitlement Terminal LSC BFS OSA Object Component (Interface) blue oval BOSS Session Naming Session Naming Content Store Content Content Store VOD server or web server or carousel OSA Object Component (A set of functions or behavior) blue rectangle Notification Notificatio n Stream Stream Small Applications green rectangle. FTP Figure 5. Detailed OSA Architecture Overview

24 Architecture An application makes calls to OSA object Components but it does not implement OSA objects. Some applications are part of a product that provides a service to customers. Other applications may be part of other products 3.3 OSA Framework The OpenStream Services Architecture Framework describes the minimum features and functionality that OSA-compliant Components must provide. This section of the OSA specification describes this framework. The OSA framework defines the simplest possible context that application developers can use to create and introduce new OSA-compliant Components into an OSAcompliant system. The most common examples of such Components are applications provided by third-party application developers. The OSA framework also defines a required set of Components that provide basic system capability to new OSA-compliant Components. To fully support new Components such as applications, new Components must have access to existing functionality within the greater system. For example: Customer account Billing support Equipment support Network control, including session Asset delivery, installation and retrieval OSA defines specific Components to support each of these functional categories. For detailed information about each OSA Component, refer to the Component s section in this document. This specification makes the fundamental assumption that Components exist in any OSA-compliant system. This specification also adheres to the fundamental requirement that: Components in an OSA-compliant system must conform to the OSA Component Framework without exception OSA Framework Model Every OSA Component must publish interfaces derived from the following CORBA interfaces: ServantBase ServantFactory

25 Architecture These basic interfaces require other interfaces, data structure, and events supported by the Component. The next sections describe these entities in detail. Figure 6 provides the Unified Methodology Language (UML) class diagram for the basic OSA Component Framework. <<CORBAEnum>> AdministrativeState as_unprovisioned as_outofservice as_inservice <<CORBAEnum>> OperationalState os_inservice os_outofservice os_created os_destroyed ServantFactory createservant() list()... ServantBase name : string provisioninggui() statusgui() setadminstate() getadminstate() getopstate() destroy()... Manager 0..n +sb Osa Event Defines Exceptions ServantBaseIterator next_one() next_n()... <<CORBATypedef>> ServantBaseList <<CORBATypedef>> OctetSequence Figure 6: Basic OSA Framework Class Diagram

26 Architecture Table 1. Application Defined Types Type Name Description Interface ServantFactory The ServantFactory is a factory object that derives from the ServantBase class. This class inherits methods from the ServantBase class and extends to include the following methods: createservant This operation creates a Servant object of whatever type is managed by the Factory object. list This operation find This operation maps an object name to an IOR. removeservant This operation retires an object. This method performs the same function as the ServantBase object s destroy method. Interface ServantBase The Service is the base class from which every object in the OSA Model derives. This class includes the following methods: provisioninggui This operation returns a URL to a GUI that someone uses to provision an object. The URL is passed to a web browser, so the GUI must be implemented using web-based technologies. StatusGui This operation returns a URL to a GUI that displays an object s general status. At a minimum, the status GUI must display an object s operational and administrative states. It may also display anything else the object s developer of the object considers pertinent. The URL is passed to a web browser, so the GUI must be implemented using web-based technologies. setadminstate This operation allows a developer to an object s adminstate without using the object s provisioning structure. getadminstate This operation return s an object s administrative state. getopstate This operation return s an object s operational state.

27 Architecture Type Name Description Interface Manager *** TBD*** destroy This operation retires an object. A destroyed object may be immediately removed from persistent storage, or it may persist in persistent storage for some time after its destruction. If a destroyed object remains in persistent storage, the object may remain in the ServantFactory, and its OperationalState must be set to os_destroyed. A destroyed object cannot be restored to functionality. getcreatetime This operation returns the time an object was created. getlastmodifiedtime This operation returns the time an object was last modified. Interface ServantBaseIterator The ServantBaseIterator class is modeled after the iterator specified in the Common Object Services (COS) Naming Service. Refer to the OMG document, CORBAServices: Common Object Services Specification, for detailed information about the CORBA Naming Service. The OSA implementation of this Iterator includes the following methods: next_one This operation returns the next binding. It returns true if it is returning a binding, false if there are no more bindings to retrieve. If next_one returns false, the returned Binding is indeterminate. Further calls to next_one after it has returned false have undefined behavior. 2 next_n This operation returns, in the parameter bl, bindings not yet retrieved with list or previous calls to next_n or next_one. It returns true if bl is a non-zero length sequence; it returns false if there are no more bindings and bl is a zero-length sequence. The how_many parameter determines the 2 CORBAServices: Common Object Services Specification, Naming Specification, September 2002, Version 1.2, formal/ , Retrieved December 6, 2002, from

28 Architecture Type Name Description maximum number of bindings to return in the parameter bl: 3 Typedef OctetSequence ***TBD*** A non-zero value of how_many guarantees that bl contains at most how_many elements. The implementation is free to return fewer than the number of bindings requested by how_many. However, it may not return a bl sequence with zero elements unless there are no bindings to retrieve. A zero value of how_many is illegal and raises a BAD_PARAM system exception. get_n This operation returns specific bindings in the bl parameter. These bindings are specified by the start and how many parameters. destroy This operation destroys its iterator. If a client invokes any operation on an iterator after calling destroy, the operation raises OBJECT_NOT_EXIST. 4 Typedef ServantBaseList This typedef can contain a collection of objects of any type within an OSA-compliant system. Constant OSADomain This constant string is an EventType used by the OSA implementation of the CORBA Event Notification Service. This constant has the value of OSA. Constant Constant administrativestate Change operationalstatechan ge Refer to the Standard and Conventions section of this document to learn more about how OSA implements the CORBA Event Notification Service. This constant string is an EventType used by the OSA implementation of the CORBA Event Notification Service. This constant s value is AdministrativeStateChange. This constant string is an EventType used by the OSA implementation of the CORBA Event 3 Ibid, p Ibid, p32.

29 Architecture Type Name Description Notification Service. This constant s value is OperationalStateChange. Constant provisioningstate Change This constant string is an EventType used by the OSA implementation of the CORBA Event Notification Service. This constant s value is ProvisioningStateChange. Enum AdministrativeState This enum denotes an object s administrative state, which is set by the Operator. Enum OperationalState This enum denotes an object s Operational State, which is an object s current operational status, or real state. Exception ProvisioningFailed The ProvisioningFailed exception is intended to be returned by any operation that could affect the provisioning of an object. This includes explicit provisioning calls, as well as such things as setadminstate(). Exception ServantCreateFailed This exception is raised whenever the createservant operation fails. Exception Unimplemented The Unimplemented exception is intended to be raosable from any operation that has yet to be implemented. At present it is only specified for a few operations. Exception UnspecifiedException UnspecifiedException can be returned from any method call. The intention is that this exception covers any unspecified error condition an implementation of a method may encounter. Exception OutOfService When an object is not explicitly in the os_inservice state, it is not permitted to deliver its functionality. This includes servicing a method that would require some explicit functionality on the part of the object. Since provisioning-related methods are allowed when not in service, they cannot return this exception Exception NoGuiProvisioned This exception is raised when any of the provisioning or status GUIs cannot be located for any reason. Exception InvalidStateChange InvalidStateChange is raised when a provisioning call attempts a transition to an illegal state. For example, an as_inservice object cannot be transitioned into the as_provisioned state. This

30 Architecture Type Name Description exception may also be used by objects that provide additional state variables to reflect invalid transitions on that state. Exception NameNotFound This exception is raised when the find operation cannot locate a servant with the specified name. Exception DuplicateServant This exception is raised by a factory in response to the createservant call, when the new servant's name has already been allocated. Exception ServantNotFound The ServantNotFound exception indicates that an Object reference passed in to any operation was not found to reference a valid CORBA object. Exception ServantBase ServantNotProvisione d This exception is returned on any provisioningretrieval transaction, when the admin state is as_unprovisioned. The ServantBase object is the object in the Component that provides the Component s functionality. This class defines the interfaces that every OSA-compliant Component must provide. The ServantBase object defines methods that: Locate a Servant s associated provisioning and status graphical user interfaces (GUIs). The ServantBase class does not define a GUI s features and functionality. Set an object s administrative state Destroy an object and free its resources The ServantBase Class is an abstract base class from which every OSA Component derives. The derived interface may also provide any additional methods the Component requires. The ServantBase class does not depend on other modules, but every module depends on it for basic services and interfaces. CORBA uses the term Servant to refer to a concrete programming language entity that implements an abstract CORBA object s functionality. In other words, a Servant object does the actual work within a system. Every ServantBase object contains an administrative and an operational state. An entity using an object determines its administrative state, therefore, an object s administrative state denotes the state that an entity using it wants it to have. Possible administrative states include Unprovisioned, OutOfService, and InService. An object s operational state denotes its actual state.

31 Architecture When a servant object is created, it is in the Unprovisioned state and provisioningrelated operations are the only operations that can be used on it. After an object has been provisioned, its operational state must be updated to one of two states: InService or OutOfService. If an entity using an object wants to temporarily stop the object, it can set the object s administrative state to OutOfService. If an object s administrative state is Unprovisioned or OutOfService, the object cannot function. The InService state is the only state that allows the object to function. Note that it is possible for an object to have an administrative state of InService but still be unable to function, resulting in an operational state of OutOfService. Every concrete class that derives from the ServantBase class must provide a unique provisioning interface. Each provision() method updates items that are associated with the derived Servant object that contains it. For example, the OSA Package object provides the following provision method: void provision (in ServerModule::AdministrativeState TheAdministrativeState, in MetadataModule::MetadataList m, in string contenturl); ServantFactory The ServantFactory Component is another abstract base class that derives from the ServantBase object. CORBA uses the term Factory to refer to an object that creates other objects. All concrete factory objects in the Interactive Systems Architecture (PackageFactory, AssetFactory, and ProductFactory) derive from the ServantFactory abstract base class. The ServantFactory object extends the ServantBase object to include interfaces that manage a servant object s lifecycle. The ServantFactory defines methods that: Create servant objects Locate a particular instance of a servant Destroy a Servant object Typically, each concrete class derived from the ServantBase class has a corresponding Factory class. The Factory class has the same name as a corresponding derived ServantBase class, with the word Factory appended to it. For example, the Package object has a corresponding PackageFactory object that creates and manages Package objects. ServantFactory objects are responsible for the creation and location of associated Servant objects. Servant Factory objects also destroy Servant objects by using the removeservant method.

32 Architecture ServantBaseIterator The ServantBaseIterator Component allows clients to iterate through a list of Servants that are managed by a specific ServantFactory object. The list method in the ServantFactory object returns an iterator object which can step through the Servant objects that the corresponding ServantFactory object manages. This iterator object can step through the Servant objects at a rate of one at a time or N at a time OSA Event Defines This section contains the basic constants used by the OSA Notification system, which is based on the CORBA Notification Service. Figure 7. shows the UML diagram for OSA event constants: <<CORBAConstan... isadomain (from ServerModule) <<CORBAConstant>> administrativestatechange (f rom Serv ermodule) <<CORBAConstant>> operationalstatechange (from ServerModule) <<CORBAConstant>> provisioningstatechange (from ServerModule) Figure 7: OSA Event Constants ServantBase Exceptions This section describes the basic exceptions supported by all OSA-compliant interfaces. In general, every exception includes the CompletionCode attribute, modeled after CORBA system exception, and a message to provide a description of the failure. Message descriptions are written to a log, but they are not always shown to operators. Figure 8. shows the class diagram for basic OSA exceptions.