JavaTV API Technical Overview

한글 요약 번역

Version 1.0

원문 : Sun Microsystems. November 14, 2000

요약번역 : 이세우 2001-12-27, rainmkr@hanmail.net

이 문서는 자바를 기반으로 interactive TV content를 제작하는 개발자를 위한 자바 플랫폼의 확장인 JavaTV API를 묘사하고 있다. JavaTV API는 Java programming 언어를 이용하여 TV 수신기와 Set-top box를 제어하는 프로그램을 제공한다.

JavaTV API의 가장 중요한 목적은 application 개발자들에게 broadcast network technology와 독립적인 application의 개발을 쉽게 하기 위해서 이다. 예를 들어, 많은 어플리케이션들은 service information database로부터 기본적인 정보를 필요로 한다(현재 가능한 서비스 이름의 리스트와 같은). JavaTV API는 어플리케이션이 정보를 획득함에 있어 어느 정도는 현재 사용하고 있는 service information protocol과 독립적일 수 있는 abstraction을 제공한다. 이것은 application이 한번 작성된 후 여러 서로 다른 네트웍 환경에서도 재사용될 수 있는 장점을 갖게 한다. JavaTV API는 하드웨어와 over-wire protocol로부터의 상당히 높은 수준의 abstraction이 되도록 설계되어 있다.

JavaTV API는 일반적인 목적을 어디서나 가능하게 제공하기 위해 어플리케이션 환경에 의존적이다(??). 예를 들어, 파일 저장 API와 network 통신 API는 어플리케이션 환경에 의해 제공된다. 어떤 경우에는, set-top box에서 가능할 것 같은 기능은 다른 Java extention에서 노출되어 있다. 예를 들어, telphone service를 제공하는 set-top box에서는 JavaPhone API가 사용되어 질 것이다.

아래 그림은 디지털 receiver에 구현되어진 JavaTV API와 application environment를 보여 주고 있다. 프로그래머는 application을 JavaTV API와 application environment에 작성하고, 그들이 작성한 application은 RTOS와 하드웨어의 자세한 사항들을 전혀 알아채지 못하게 하게한다.

[그림1] A Typical Television Receiver Implementation

이 문서는 JavaTV API를 형성하는 API 구성요소들과 javadoc으로 표현한 API와는 다른 form에서 보여주려는 것을 묘사하고 있다. 왜냐하면 JavaTV API는 여러 구현 가능성들을 망라해서 설계되어 있고, 이 문서는 최소한의 또는 성능과 관련된 하드웨어와 소프트웨어의 요구를 묘사하지 않기 때문이다.

Television receiver는 아날로그 신호, 디지털 신호 또는 둘 다를 처리한다. 신호는 일반적으로 지상, 케이블, 위성네트웍을 통해 receiver에게 방송되어 진다. 디지털 신호는 아날로그 신호에 비해 보다 다양한 content를 방송할 수 있다. 디지털 방송은 디지털화 된 audio-video와 함께 다양한 형태의 정보를 포함 할 수 있다. Television receiver는 광역의 기능과 수용을 가진다. JavaTV API는 이와 같은 일반적인 receiver에서 찾을 수 있는 기능과 서로 다른 여러 receiver의 구현에서의 기능의 접근을 제공한다.

서로 다른 기능을 갖는 다양한 receiver가 존재하지만, receiver가 제공하는 네트웍 connection을 기준으로 크게 세 가지의 종류로 나눌 수 있다. Enhanced broadcast receiver, interactive broadcast receivers, multi-network receivers. 각각의 receiver는 아래에 묘사 되어 있는 것처럼 이전 type의 능력을 발판으로 하고 있다.

1. Enhanced Broadcast Receivers

Enhanced Broadcast receiver는 강화된 그래픽, 이미지, 텍스트와 함께 전통적인 방송 TV를 제공할 수 있으며, 방송의 일부분으로서 자바언어를 기반으로 하는 프로그램에 의해 제어 될 수 있다. 이와 같은 receiver는 local viewer interaction, including input from a remoete control, on-screen graphical elements, multiple aoudio-video stream 중에서 선택, display간의 switching 등을 지원한다. Enhanced broadcast receiver는 head-end 또는 서버로부터, 때때로 broadcast file system을 통해 data를 수신한다. 하지만, enhanced broadcast receiver는 braodcaster로에게의 return channel을 갖지 못하며, 따라서 head-end 또는 서버와의 interaction을 수반할 수 없다.

2. Interactivie Broadcast Receivers

Interactive broadcast receivers는 head-end 또는 서버와의 통신을 할 수 있는 broadcaster로의 return channel을 포함한다. 이와 같은 receiver는 전자상거래, ��춤형 video(VOD), 이메일, 그리고 채팅 형식의 대화를 제공을 수용할 수 있다. Interactive broadcast receiver는 Enhanced broadcast receiver에서 찾을 수 있는 수용능력을 포함한다.

3. Multi-Network Receivers

JavaTV API는 television programs을 서비스로 간주한다. 이것은 방송환경에서 나타날 수 있는 다양한 content를 접근하는 공통적인 방법을 제공하는 추상화이다. 예를 들면, 서비스는 Video와 audio를 동기화한 일반적인 TV program을 참조하거나, audio와 video그리고 방송과 동기화된 Java Application을 포함하는 enhanced television broadcast를 참조할 수 있다. JavaTV API는 서비스선택(selectiong service), service information을 포함하는 데이터베이스의 접근, television-specific한 미디어 플레이어의 제어, 그리고 TV 시그날과 함께 방송되는 데이터에 대한 접근에 대한 수단을 제공한다.

컨텐트 개발자는 electronic program guides(EPGs), program specific application. Stand-alone Application, 광고와 같은 여러 가지 종류의 television-specific application 이나 서비스들을 작성할 수 있다. 이와 같은 종류의 application들의 몇몇 특징들은 아래에 묘사되어져 있다.

• Accessing Services and Service Information

• Selecting Services

• Controlling the Broadcast Pipeline

• Accessing Broadcast Data

• Managing Application Lifecycle

이 부분은 방송 수신기를 만드는 구성 요소들을 묘사한다. 이것은 Java TV API의 일부분인 개념적인 정의와 context를 제공하고 설명하기 위해 의도되어 져있다. 이 부분은 API를 위한 하드웨어의 특정 요구사항에 대한 언급은 하고 있지 않다.

TV 수신기는 video, audio, 그리고 data를 broadcast stream을 통하여 얻으며, broadcast media와 data pipeline을 통해 처리한다. 수신기는 protocol이라고 불리워지는 특정된 형식으로 media와 data를 얻으며, 프로토콜에 특정되어 있는 다양한 decoder를 이용해 decoding한다.

TV 수신기가 관련된 전형적인 컴퓨터 장치와 구별 되는 것은 수신기가 broadcast media pipeline을 전체적으로 모델링 하고 있는 것이다. Broadcast media pipeline은 전형적으로 Media 흐름을 통해 디지털 튜너, demultiplexer, conditional access module, media decoder 모음, 그리고 rendering subsystem,등과 같은 여러 하부시스템의 집합으로 구성되어 진다. Java TV API는 모든 하부 시스템의 표현을 요구하지는 않는다. 예를 들어, 수신기는 C/A subsystem이나 디지털 튜너를 가지고 있지 않아도 된다. JavaTV API는 어플리케이션 프로그래머가 잠재적인 하드웨어 환경의 세부적인 내용을 알지 않아도 되는 추상화를 제공한다. 하지만, Java TV API는 수신기가 broadcast pipeline의 한 종류인것으로 간주한다.

아래 그림은 전형적인 pipeline이 RF signal을 전달받아 디지털 수신기에 전달하는 절차를 단계별로 보여 주고 있다.(그림 2) (이 그림은 존재 가능한 특정 pipeline의 예를 보여 주고 있다. 많은 다른 pipeline의 환경이 있을 수 있다.)

1. RF 신호가 tune 된다.
2. tuned RF 신호가 digital signal로 demodulat되고 MPEG-2 transport stream을 운반한다.
3. transport stream이 demultiplexer를 통해 전달되고, multi stream으로 분리된다.(예: audio, video, data)
4. video, audio stream이 특권에 접근하는 것을 결정짓고 데이터를 해독하는 C/A subsystem을 통해 전달된다.
5. 해독된 audio, video stream은 audio, video 출력장치에 적절한 신호로 전환될 decoder에 전달 된다.

디지털 수신기의 s/w 환경은 전형적으로 자바 어플리케이션 환경, Java TV API, supporting 어플리케이션들로 이루어 진다. 또한, s/w 환경은 실시간 운영체제(RTOS)를 포함한다.

그림 3에서 보여지듯이, s/w환경의 최고층은 Application layer이며, 어플리케이션은 아래 계층인 Java Technololy Layer로부터 Java TV API와 Java package를 사용할 수 있다. 자바 어플리케이션은 가상머신 안에서 실행된다. Java TV API는 수신기의 h/w 운영을 제어 할수 있는 제일 아래 단계 librarie들에 의해 노출된 기능들을 추상화 하고 있다.

RTOS는 Java technology layer의 구현에 필요한 system level의 지원을 제공한다. 추가적으로, RTOS와 또, 그와 관련된 device-specific libraries는 장치 드라이버의 모음을 통해 수신기를 제어 한다.

어플리케이션은 broadcast receiver상에서 동작되도록 설계되어 있고, 이것은 JVM에 이미 있는 상태 뿐만 아니라, 어플리케이션 환경 API에 장점을 가져다 줄것이다. 이장은 JavaTV API와 별도로 어플리케이션 환경과 VM에 의해 제공되는 broadcast receiver 기능의 주요 양상에 대해 묘사하고 있다.

Java 어플리케이션 환경의 API는 "package"라고 불리우는 기능적 그룹으로 조직되어 있다. PersonalJava 어플리케이션 환경은 television recevier처럼 전형적으로 제한된 메모리와 같은 장치를 위해 사용 되어진다. PersonalJava 어플리케이션 환경은 몇몇 쓸만한 package들을 포함하고 있다.

• I/O

• Networking

• graphics toolkit

• system functions

• conditional Access

• secure Commnunication

• Virtual Machine

Service는 수신기에서 표현될 content의 모음이다. 이 모음은 Java TV API에서 하나의 유닛으로 취급된다. Service는 표현을 위해 선택될 수 있다. 텔레비전 시청자는 이와 같은 개념을 간혹"television channel"이라고 지칭한다. 오늘날의 advanced television receiver에서 Service는 단순히 single audio/video stream 이 아니라, data를 포함한 multiple audio/video일 것이다.

Service는 SI database에 저장되어 지는 service information(SI)라는 특징을 갖는다. SI는 MPEG-2 transport stream과 같이 layout과 audio/video/data stream content를 묘사한다.

Java TV API는 SI elements를 참조 하기 위해 Locator object를 사용한다. 주어진 locator는 네트웍에 독립적인 object로 표현될 수 있고, 네트웍 종속적인 locator에 대해 mutiple mapping을 갖는다. Java TV API는 주변상황을 조사하고, 네트웍 종속전인 locator로의 변형을 하는데 사용되는 method를 제공한다.

SI 전달을 위한 다양한 프로토콜은 오늘날 사용되고 표준화 되었다. 예를 들어, DVB-SI는 다양한 위성, 케이블, 지상파 시스템에서 사용된다. ATSC A56표준은 위성과 케이블 모두에 사용되며, 새로운 ATSC PSIP(A65)는 지상파와 케이블 DTV에 사용되어 진다. 그밖에도 너무나 다양한 사제 프로토콜들이 있다. JavaTV API는 SI protocol의 추상화를 제공한다. 따라서, Java TV 어플리케이션은 수신기에 전달되는 정보의 SI protocol을 알아 둘 필요가 없다. 결과적으로, 어플리케이션은 DVB-based, SCTE-based, ATSC-based sytem과 같은 다양한 환경에서 동작하기위한 특별한 코드를 필요치 않는다.

SI database 객체 모델은 application이 요구하는 다양한 SI의 view를 허락한다. 각각의 view는 Java TV SI API안에 있는 패키지로 표현된다. SI API 패키지는 Service, Navigation, Guide, 그리고 Transport이다.

• Service package : javax.tv.service

• Navigation package : javax.tv.service.navigation

• Guide package : javax.tv.service.guide

• Transport package : javax.tv.service.transport

• 다른 SI package에 의해 확정될 기본 클래스들
• transport stream에서 SI element 변화의 탐지를 위한 이벤트 통지 메커니즘과 비동기 요청에 대한 이벤트 전달.
• 예외(Exception)

• ServiceDetail object: 자신과 연결된 ServcieComponent object와 관련된 변화를 보고 한다.
• Trainsport object : TrainsportStream, NetWork, Bouquet 객체에 의해 표현되는 테이블과 관련된 전달된 서비스와 네트웍의 정의 변화를 보고한다.(??)
• ProgramSchedule object : 스케쥴에서의 어떤 하나의 PrgramEvent에 대한 탐지에 의한 변화를 보고한다.

guid 패키지는 EPGS를 지원하는 기능을 포함한다. 이 패키지는 EPGs와 관련된 두가지 정보 세트를 제공한다 : 채널 또는 program event와 관련된 각각의 채널에 프로그램 스케쥴과 등급 정보. ProgramSchedule 객체는 일반적으로 현재 Play되고 있는 프로그램, 바로 다음 program, 그리고 미래의 명확히 정해진 시간동안의 다른 얼마간의 이용 가능한 프로그램을 검색하는데 사용될 수 있다. 각 ProgramEvnet 객체는 이것의 이름, 시작시간, 그리고 끝나는 시간, 묘사, 등급, 그리고 기타 관련된 정보들이 요구될 수 있다.

등급(18세이상 시청가능과 같은)과 관련된 정보는 MPAA rating, FCC TV rating, DVB age-based rating, 그리고 broadcast-specific rating과 같이 각 지역이 여러 등급차원을 갖는 등급 영역(국가, 국가의 그룹이나 방대한 지리적 지역등과 같은)에 조직되어 진다. 각각의 차원은 여러 계층을 포함한다; 각 ProgramEvnet 객체는 모든 지원되는 등급지역을 위해 이들 계층들 중의 하나에 label되어 진다.

transport 패키지는 SI describe content를 전달하는 MPEG-2 transport와 같은 물리적 매체에 대한 정보를 포함한다. SI manager는 TransportStreamCollection에 의해 확장되어지는 MPEG case에서 MPEG-2 multiplex를 표현하기 위한 Transport 객체에 접근을 제공한다. 일반적인 Transport interface는 Internet Protocol(IP)와 같은 다른 형식의 전송 메커니즘을 지원하기 위해 확장되어 질 수 있다.

한번 service가 발견되고 나면, service Selection API는 application이 단순하고, 고수준의 방법으로 서비스의 표현을 제어할 수 있도록 해 준다. Service selection API는 튜닝 제어, service information, media playback, broadcast file transport, 그리고 application manager등을 호출하는 하나의 메서드로 결합된다. 특히, 이것은 대단히 콤포넌트의 본질을 service로 만드는 것을 은닉한다.

예를 들어, 어플리케이션은 서비를 표현하는데 있어서, audio component, video component 또는 subtitle component에 대해서 알 필요가 없다. 게다가, 어플리케이션은 서비스가 어플리케이션과의 연관을 가졌는지, 또는 이런 어플리케이션이 어떻게 착수되는지에 대해 전혀 알 필요가 없다.

service selection API의 목적은 표현을 위한 서비스들의 선택하는 메커니즘과 함께 어플리케이션을 제공하기 위함이다. 서비스가 표현되고 있는 환경을 표현하는 클래스는 ServiceContext 클래스이다. 수신기는 이들이 지원하는 클래스의 객체의 수에 제한을 둔다. ServiceContext는 이것과 연관된 디코딩 하드웨어, 상태, 튜너의 상위레벨의 표현이다. ServiceContext는 특정 서비스와 연관된 콤포넌트의 표현의 제어를 어플리케이션이 하게 해준다. SreviceContext의 select()메서드는 service context가 서비스를 표현하려는 시도의 원인이 된다. 이 selection은 비동적이고 완료는 event-listner 메커니즘에 따라 통지된다. 서비스 선택의 실패는 만약 select()가 호출된 시기에 결정된다면 exception을 통해 보고되고, 잠시후에 결정된다면 event를 통해 보고된다. 한번 service context가 서비스를 표현하면, 서비스 콤포넌트의 locator를 포함한 다양한 정보가 서비스와 관련되서 포함된다.

만약 select()메서드의 호출이 성공적으로 끝났다면, NormalContentEvent 혹은 AltenativeContentEvent가 생성되고 ServiceContext는 Presenting상태로 이동한다. 만약 서비스 service selection이 실패하면, SelectionFailedEvent가 생성된다. 만약 select 호출의 이전상태가 Not Presenting이면, ServiceContext는 그 상태로 돌아가게 되고, PresentationTerminatedEvent가 생성된다. 만약 select호출의 이전상태가 Presenting이면, ServiceContext는 NormalContentEvent 또는 AlternativeCContentEvent의 결과로 이전상태로 돌아가려고 시도하게 된다. 만약 불가능하다면, ServiceContext는 PresentationTerminatedEvent를 리턴한다.

Not Presenting 상태는 PresentationTerminatedEvent에 의해 보고된 service표현이 멈춰짐 때문에 들어가게 된다. service presentation의 중단은 application의 stop()메소드의 호출에 의해 초기화될수 있거나 동작환경에서 더 이상 계속진행하지 못하게 되는 무언가의 변화가 있기 때문이다.

Destryed상태는 destry()메서도의 호출에 의해 들어가게 된다. 한번 이상태에 들어오게 되면 ServiceContext는 ejdltkd 어떤 목적으로도 사용될 수가 없다. destroyed된 ServiceContext는 garbage collection의 후보가 된다.

TABLE 1 descriptions of the Service Context States

Java TV API는 breadcast media pipeline을 관리하기 위해 Java Media Framework(JMF)1.0 API를 이용한다. JMF API는 API세트와 전송메카니즘, 전송 프로토콜, media content type에 독립적인 time-based mdia display를 위한 framework의 정의로 Java TV API에 기반을 제공한다.

JMF는 time-based media data를 위한 MediaHandler를 확장하는 javax.media.Player를 정의한다. Player 객체는 time-based media streamd의 rendering관리와 자원획득을 위해 필요한 머신상태를 encapsulate한다. Player객체는 또한 다양한 rendering facilities(예, 볼륨, 화면조정) 제어를 제공한다. 마침내, 오디오/비디오 스트림을 위한 Player의 경우에는 stream의 video 부분을 포함하는 GUI component 객체가 Player로부터 포함될 수 있다. 이것은 통합을 쉽게하고 video 설치와 표현의 용이를 제공한다.

자세한 JMF에 대한 내용은 JMF1.0 specification을 보라.

JMF Control은 실행시간에 Plyaer로부터 포함되는 객체이다. javax.media.Control interface를 implements하는 이 Object는 Player가 관리하는 media의 특징위에서 제어를 제공하는 어떤 Interface를 하나이상 implements하게 될 것이다. 예를 들면, 많은 Player들은 Player의 audio 진행을 제어하게 해주는 javax.media.GainControl interface를 지원하는 Object를 제공한다.

JMF1.0 specification에서 정의하고 있는 control에 추가적으로, Java TV API는 javax.tv.media 패키지에서 정의하고 있는 다음과 같은 control들을 포함한다.

JavaTV API의 일부분으로 정의되고 있는 Control 세트는 Java TV implementation이 지원하게 될것이지만, 모든 Player가 모든 control을 항상 지원해야 하는 것은 아니다. Player instance가 Player의 getControl(String forName)메서드를 이용해서 특정 control을 지원한다면 application은 체크할수 있다. 만약 output이 Null이라면, forName에 의해 지정된 control은 지원되지 않는 것이다. 모든 control을 Player instance가 지원하기 위해서는 getControls()메서드를 사용한다. 만약 implementation이 지원한다면, 이 메서드는 특정 control의 생산자를 포함하여 Control object의 배열을 리턴하여 준다.

추가적으로 DAVIC 1.4(Digital Audio-Video Council)specification은 Java TV API의 구현에 쓰일만한 몇몇 유용한 JMF Control object를 포함한다. 이들 control들은 Table3에 나열되어있다.

JMF는 media를 표현을 위한 동기화 master로 서비스하는 clock과 media간의 동기화 관계의 specification을 허락한다. 동기화 기본의 상세한 내용은 JMF document에 묘사되어 있다. JMF Player는 현재의 media-time을 포함하기 위한 메서드를 제공하는 Colck class로부터 상속을 받는다. Clock은 time-base라고 불리우는 object를 포함하는 메서드를 또한 제공한다. time-base는 media-time과 time-base간의 관계를 제어하기 위한 기타 파라미터 뿐 아니라 media-time과 time-base간에 특정된 동기화 포인트를 위한 메서드를 갖는 Clock을 위한 동기화 마스터를 표현한다.

Java TV API에는 DAVIC에의해 정의된 특정 media-time에 이번트의 전달을 제공하는 새로운 메커니즘을 지원한다. 그와 같은 이벤트의 전달을 지원할 수 있는 Player는 MediaTimeEnetListener의 등록을 위해 제공되는 MediaTimeEvnetControl 인터페이스를 제공한다. MediaTimeEvent는 적절한 media-time이 발생될 때 MediaTimeEventListener에게 전달된다.

JMF는 javax.media.Player클래스의 객체와 함께 media playback을 제어 한다. 이것을 위해 생성되는 두 개의 구분되는 component가 있다: protocol hanler와 media handler. Player는 media handler의 한 종류이다. protocol handler는 데이터의 원천(source of data)이다 : media handler는 data의 소비자이다. protocol은 추상화되어 있고, 따라서 사용되는 전달 메카니즘에 완벽히 종속적이다. 예를 들어, IP 연결에 의해 전달되는 HTTP를 위한 것과 튜너로부터 전달되는 MPEG-2 transport를 위해서는 각각의 서로다른 protocol이 요구된다. JMF는 javax.media.protocol.DataSource라는 모든 protocol handler를 위한 기반이되는 추상화된 클래스를 정의 하고 있다. JMF는 모든 content handler를 위해 javax.media.MediaHandler interface를 정의하고 있다. javax.media.Player는 MediaHandler를 extends하고 있다.

대부분의 JMF의 구현은 새로운 media stream이 render 될때마다 완전한 decoding pipeline이 생성된다고 간주하고 있다. 데스크탑 환경에서는 타고난 표현법이다. 일반적으로 개별적인 network connection은 각각의 media strema을 요구한다. 각각의 connection은 완전히 구분된 pipeline의 요구를 갖으며, 잠재적으로 연결의 source와 혼합적인 협상을 요구한다.

방송환경에서는 그렇지 않다. broadcast network을 위한 인터페이스는 multiplex의 multiplex를 모델로 할수 있다. 이와 같은 모델은 실제 tuner(첫번째 multiplex)와 demux(두번째 multiplex)를 결합한다. 따라서, broadcast network로의 인터페이스의 제어는 튜닝(primary multiplex selection)과 stream selection(두번째 multiplex section)에 의해 구성된다(그림 6을 보시오). 전통적인 비디오 broadcast를 위해서는 결과 pipeline은 항상 같다: 두 번째 multiplex는 audio/video decoder에 연결된다. 따라서, 채널을 바꾸려할 때 오직 network interface에 대한 튜닝과 stream selection parameter과 명령만이 필요고, 새로운 pipeline 자원(tuner, demux, codec, screen)의 획득은 필요치 않는다.

JMF는 기존의 인터페이스의 수정없이 pipeline을 모델링한다. Player객체는 pipeline전체를 표현하고, 네트웍크 연결을 표현하는 DataSource를 표현한다. 위에서 묘사한 broadcast selection 메카니즘을 적응하기 위해서는 simple한 추가가 필요하다. 두 multiplex중의 하나가 스위치(각각의 튜닝요청에 대해서 새로운 player가 생성된다면 어떤 일이 일어날지) 될 때마다 pipeline의 재생성을 요구 하기 보다는, 두 demux에 작용할 수 있는 selection interface가 제공된다. 이 메카니즘은 javax.tv.media.MediaSelectControl에서 찾아 볼 수 있다. 이것은 content의 비동기적인 selection과 de-selection을 위한JMF 제어 API이다.

Broadcast data를 위한 Java TV API는 television broadcast signal에서의 전송된 데이터의 접근을 허락한다. 이들 API는 세가지 형식으로 전송된 데이터의 접근을 지원한다.

• Broadcast file systems

Java TV API는 java.io패키지에 정의된 파일 접근 메카니즘을 이용하여 broadcast file과 디렉토리 데이터 접근을 제공한다.

• IP datagrams

Java TV API는 java.net패키지의 datagram 수신 메카니즘을 이용하여 broadcast stream에 전송된 unicast/multicast IP datagram의 접근을 제공한다.

• Streaming data

JavaTV API는 JMF 패키지javax.media.protocol을 이용하여 broadcast로부터 일반적인 streaming data의 접근을 제공하다.

Java TV API는 java.io패키지에 정의된 파일 접근 메카니즘을 이용하여 broadcast file과 디렉토리 데이터 접근을 제공한다. 이런 data는 일반적으로 "carousel"안에 전송되어 지는데 그곳에 원격 파일 시스템의 content들이 주기적으로 전송되어 수신기에 재생성하기 위해서 이다. Java TV API는 broadcast carousel을 일반적인 저속 disk file system처럼 모델링 되어있다. 대부분의 특정 carousel과의 interaction protocol은 application이기 보다는 Java TV API implementation에 의해 처리된다.

Java TV API는 어떤 broadcast file system protocol을 사용할수 있게 충분히 high level이다. 그러나, 이것은 가장 유행하는 DSM-CC object carousel protocol과 DSM-CC data carousel protocol, 이 두가지 protocol과 사용된다. 이것은 아래에 자세히 묘사되어 있다.

• DSM::ServiceGateway - object의 최상위 디렉토리의 접근 제공
• DSM::Directory - 일반적인 디렉토리 구조의 표현; 파일 또는 다른 디렉토리를 참조(refer)하게된다.
• DSM::File - 일반적인 파일 데이터를 표현

java.io.File class는 이들 객체의 모든 종류을 표현한다. Java TV API class javax.tv.carousel.CarouselFile은 object carousel을 접근하고, 기능을 추가하기 위해 java.io.File을 상속받는다 :

• javax.tv.locator.Locator를 이용하여 carousel object를 참조한다.
• 개별적인 carousel object의 update를 application에게 통지한다.

1. carousel의 service domain을 제거(detach)한다.

• data carousel의 top-level "directory"로써 instantiated된 CrouselFile은 carousel을 위한 DownLoadInfoIndication message contents를 제공한다.
• CarouselFile의 instance는 개별적인 data crousel module을 참조하기 위해 생성된다. Instantiating되는 CarouselFile object는 비동기적으로 이것이 참조하고 있는 module을 로드한다.
• Carousel module을 표현하고 있는 CarouselFile을 open 한java.io.FileInputStream, java.io.FileReader, 또는 java.io.RandomAccessFile의 인스턴에서의 read operation은 대응되는 모듈이 로드될 때까지 중단된다. Read operation은 오직 module을 포함하는 DownloadDataBlock message의 blockDataByte field의 contents만을 접근할 수 있다.
• Single data carousel module과 대응되는 java.io.FileInputStream, java.io.FileRead, java.io.RandomAccessFile의 모든 인스턴스들의 close operation은 그 module을 unload시킨다.

• 어플리케이션은 읽혀질 carousel file당 하나의 새로운 Thread를 생성할 수 있고, read operation을 병렬로 묶는다. 이것은 각 파일에 대한 접근 시간을 최소화 하지만, thread에 대한 추가적인 overhead를 갖느다.
• 어플리케이션은 데이터의 사용가능 여부를 결정하기 위해 FileInpustStream.available(), FileReader.redy()와 같은 비 중단(non-blocking)메서드를 이용해서 조사 할 수 있다.
• 어플리케이션은 중단된((block) thread에 Thread.interrupt()를 호출하는 것으로 read operation에서 time out 할 수 있다.(??)
• CarouselFile에 file input class의 instance생성은 대응되는 carousel data를 로드한다. 따라서, 어플리케이션은 먼저 필요한 각 carousel file에 대한 file input class의 instance를 생성하고, 그 다음 read operation을 직렬로 묶는다. 이것은 필요한 모든 파일 접근의 총 합계 시간을 최소화 할 수 있지만, 다중 별렬로 read하는 경우보다 평균 파일 접근시간이 크다.

• 단순하고 잘 정의된 상태 머신
• application 상태의 간결한 정의
• 상태들 간의 변화를 위한 신호 API

• Application manager � Java application을 관리하는 디지털 텔레비전 수신기의 소프트웨어적인 운영환경의 한 부분. Application manager는 이것의 상태 변화 신호에 의해 Xlet의 lifecycle을 제어한다. Application manager는 수신기에서 필요하지만, 이것의 정확한 동작은 specific의 구현이다.
• Xlet � 디지털 텔레비전에서 동작되는 (일반적으로 download되는) Java Application.
• Xlet states � Xlet의 상태변화는 Xlet 자신에 의해 처리된다. Xlet은 오직 언제 상태가 성공적으로 변화되었는지를 안다. 네가지의 Xlet state는 Loaded, Active, Paused, Destryed이다. Xlet은 coallback을 통해 application manager와 통신한다. Xlet은 이와 같은 상태의 성공이나 실패를 callback의 리턴값으로 신호한다.
• Xlet context � Xlet 시스템안의 다른 facilitety를 접근하기 위해 사용하는 object. 각 Xlet은 하나의 xletContext object를 갖으며, 이것은 명시된 환경에 맞추어 질 수 있다.

• Xlet은 언제든지 destry 될 수 있다.

• Xlet의 현재 상태는 항상 보고되어야 한다.

• Application manager는 Xlet의 상태를 바꿀 수 있다.

• Application manager는 Xlet의 상태가 바뀌었다면 그것을 알아야 한다.

• 감지되는 Xlet의 startup 응답시간의 매우 짧을 것이다.
• Xlet의 임시 정지를 서비스로 제공해야 하는 것이 가능하다.
• Xlet의 destroy를 언제든 가능하게 한다.

1. Xlet Lifecycle Model

Xlet 패키지는 개발자에게 디지털 텔레비전 수신기 환경에서의 application lifecycle signaling API와 함께 제공된다. Xlet API는 Xlet과 그 환경을 나타내는 Xlet과 XletContext로 구성되어진다.(JavaDoc에서 자세한 사항을 보거나 말거나..)

Xlet API는 상태변화 신호를 위해 callback 방법을 사용한다. Xlet의 상태는 application manager가 Xlet의 한 메서드를 호출하거나 Xlet이 XletContext object를 통해 내부적인 상태 변화의 application manager에게 통지에 의해 바뀔 수 있다. 정확하게 언제 그 상태의 변화가 일어나는지의 의미는 중요하다:

• Call to Xlet

• Call to XletContext

• Xlet API는 Xlet에게 상태변화가 요구될 때 신호를 보낸다.

• Xlet이 초기화될 때 context가 제공된다.

• Xlet은 상태가 변화됐을 때 신호를 보낼 수 있다.

• Xlet은 모두 마쳤을 때 신호를 보낼수 있다.

• Public void initXlet(XletContext ctx)

• Public void startXlet()

• Puglic void pauseXlet()

• Puglic void destroyXlet()

1. Xlet and Finalization

• Xlet은 finalizer에서 무슨 일을 해야 하는가.

• 부정한 짓을 하는 Xlet의 작업의 방지

1. Xlet and Threads

1. XletContext Interface

• Public void notifyDestryed()

• Public void notifyPaused()

• Public java.lang.Object getXletProperty(java.lang.String key)

• Public void resumeRequest()

1. application manager는 xlet을 위한 code를 포함한다.
2. application manager는 XletContext object를 생성하고 새로운 Xlet을 위해 이것을 초기화 한다.
3. application manager는 initXlet() 메서드를 호출하고 Xletcontext object를 전달함으로서 Xlet을 초기화 한다.
4. Xlet은 XletContext object를 이용하여 자신을 초기화 하고 Paused 상태로 들어간다.
5. 사용자는 application manager에게 Xlet을 시작 하라는 신호가 되는 텔레비전 리모콘 버튼을 누룬다.
6. application manager는 startXlet()메서드를 Xlet에 호출한다. Application manager는 Xlet이 서비스를 실행하고 있는 것으로 간주한다.
7. 신호를 받은것으로 Xlet은 주식시세를 얻기 위해 back channel을 열는 새로운 thread를 생성한다. Xlet은 이제 Active 상태에 있다.
8. xlet은 주식시세를 보여준다.
9. Xlet의 제어가 부수적인 것이기 때문에 이것은 더 이상 갱신된 주식 시세를 얻을 수 없다.
10. Xlet은 가장 최신의 시세를 계속해서 보여주기로 결정한다. Application은 아직도 Active 상태에 있음을 주지하라.
11. 시간이 지나고, Xlet은 아직도 back channel을 열 수 없다. Xlet은 보여지고 있는 시세가 너무 오래되었고 더 이상 서비스를 실행할 수 없다고 결정한다. Xlet은 스스로 Active 상태를 벗어나야 겠다고 선택한다. Xlet은 XletContext의 notifyPaused()메서드를 호출하여 application manager에게 이 변화을 알린다.
12. 마지막으로, Xlet은 더 이상 서비스를 실행할 기회가 없는 것을 알고 종결되어야 한다고 결심한다. Xlet은 XletContext의 notifyDestryed()메서들 호출하여 마지막 clean up을 실행하고, application manager에게 Destryed 상태에 들어 왔다고 알린다.
13. application manager는 xlet이 garbage collection되기를 준비한다.