Osa class diagram metadata and metadatalist objects figure

OPENSTREAM SERVICES

TABLE OF CONTENTS

1.4 ORGANIZATION................................................................................................................................1

1.5 REFERENCES ..................................................................................................................................1

2.1.2 Rational Unified Process.......................................................................................................3

2.2 SOFTWARE DEVELOPMENT TOOLS ...................................................................................................3

3.1 OVERVIEW ....................................................................................................................................14

3.2 DETAILED ARCHITECTURE..............................................................................................................15

3.3.4 ServantBaseIterator ............................................................................................................26

3.3.5 OSA Event Defines .............................................................................................................26

4 APPLICATION OBJECTS..................................................................................................................39

4.1 APPLICATION CLASS DIAGRAMS .....................................................................................................41

5 PROVIDER COMPONENT.................................................................................................................57

PROVIDER CLASS DIAGRAM.......................................................................................................................57

© Ericsson Television Inc. All rights reserved.

TABLE OF FIGURES

Figure 1: OSA CORBA Naming Service Context Hierarchy 7

Figure 6: Basic OSA Framework Class Diagram 19

Figure 7: OSA Event Constants 26

Figure 12: Provision a Servant 33

Figure 15: Stop a ServantFactory Object 38

Figure 20. Class Diagram: Offering Relationship Model 44

Figure 21: Application-Defined Exceptions 51

Figure 27: Register a Provider 62

Figure 28: Retire Provider 63

Figure 33. OSA 1.00 Class Diagram: Package Relationship Model 70

Figure 34: Sequence Diagram: Initial Installation of a Non-Application Package 73

Figure 39. OSA 1.00 Class Diagram: Metadata and MetadataList Objects 87

Figure 40. OSA 1.00 Class Diagram: Asset Relationship Model 89

Figure 45. OSA 1.00 Class Diagram: Content Relationship Model 95

Figure 46: Content-Defined Exceptions 98

Figure 51: OSA 1.00 Class Diagram: Purchase Object 105

Figure 52: Class Diagram: Purchase-Defined Exceptions 108

the specifications without prior notice

OpenStream Services Architecture 1.0

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

the specifications without prior notice

This document describes the OpenStream™ Services Architecture (OSA). Application developers must use this architecture to implement OSA-compliant software applications.

1.2 Scope

• Application developers

• Suppliers of Pegasus software components

1.5 References

The following documents are applicable to this specification:

2 of 180 © Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify

the specifications without prior notice.

© Ericsson Television Inc. All rights reserved. Ericsson maintains a policy of product improvement and reserves the right to modify

the specifications without prior notice.

OpenStream Services Architecture 1.0

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.

2.2.1.1 Unified Modeling Language (UML) Notation

The following definition is taken from the Object Management Group’s (OMG) UML specification document:

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

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.

• Interface Design Language (IDL)

• JAVA 2.0

the specifications without prior notice

OpenStream Services Architecture 1.0

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.

• Operating System Independence—Clients invoking CORBA objects do not need to know the operating system on which a Server object is implemented.

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

• 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.

2.3.2.1.1 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.

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

the specifications without prior notice

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

OpenStream Services Architecture 1.0

OSA Standards and Conventions

• 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:

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.

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

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.

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

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/98-01-01, 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.

•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.

•OperationalStateChange:

OSA Standards and Conventions

The filterable-data section of the ProvisioningStateChange event will conform to the following table:

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.

© Ericsson Television Inc. All rights reserved.Ericsson maintains a policy of product improvement and reserves the right to modify

Figure 2: Publish Event

OSA Standards and Conventions

3 Architecture

3.1 Overview

Management Operations personnel use a management Component to interact with Customers and Service Providers.

Content 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.

Bus Components of the network communicate with

(OSB) each other for purposes of provisioning and

the specifications without prior notice.