번역본 원문보기(http://www.dal.co.kr/chair/javadoc/javatvap/javatvap.html) just in case the original is missing. . . .
JavaTV API Technical Overview
한글 요약 번역
Version 1.0

원문 : Sun Microsystems. November 14, 2000
http://java.sun.com/products/javatv/jtv-1_0-spec_overview.pdf
요약번역 : 이세우 2001-12-27, rainmkr@hanmail.net

1. Introduction ¶

이 문서는 자바를 기반으로 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는 여러 구현 가능성들을 망라해서 설계되어 있고, 이 문서는 최소한의 또는 성능과 관련된 하드웨어와 소프트웨어의 요구를 묘사하지 않기 때문이다.

1.1. Television Receviers ¶

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.1.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을 수반할 수 없다.

1.1.2. Interactivie Broadcast Receivers ¶

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

1.1.3. Multi-Network Receivers ¶

Multi-Network Receiver는 broadcast network과 return channel 이상의 접근방법을 제공한다. Multi-network receiver는 Internet capable receiver와 지역 전화와 같은 기타 다른 통신 서비스를 제공하는 receiver를 포함한다. 이와 같은 receiver는 home telecommunication hub가 될 수 있으며, 인터넷 브라우져와 같은 다양한 서비스를 제공할 수 있다. Multi-network receiver는 enhanced broadcast receiver와 interactive broadcast receiver에서 찾아 볼 수 있는 수용능력을 포함한다.

1.2. Television-Specific Applications ¶

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들의 몇몇 특징들은 아래에 묘사되어져 있다.

1.2.1. Electronic Program Guides ¶

Electronic Program Guides(EPGs)는 오늘날의 텔레비전 수신기에서 찾을 수 있는 것보다 좀더 공통적인 Application이다. EPGs의 본질적인 기능은 현재 또는 곧 방영될 텔레비전 프로그램에 대한 미리보기를 시청자에게 제공하는 것이다. 일반적으로, EPG는 시청자의 선택에 맞게 채널을 바꾸어 주기도 한다. 이와 같은 종류의 application에서는 interactive performance와 빠른 start-up 시간은 사용자 경험에 중요하게 작용하게 된다.

1.2.2. Program-Specific Applications ¶

program-specific application은 특정 서비스와 함께 audio-video 프로그램밍을 개발되기위해 생성된다. 예를 들어, 시청자가 집에서 게임할 수 있는 게임쇼와 함께 개발된 application이나, 스포츠 이벤트에 대한 정보의 interaction을 제공하는 application등을 들수 있다. 이와 같은 application은 몇가지 중요한 요구사항을 갖는다. 예를 들면, 시청자가 채널을 변경한 경우 application을 중지 시킬수 있어야 한다.

1.2.3. Stand-alone Applications ¶

독립 실행형 어플리케이션은 일반적인 텔레비전 프로그램에 상관없이 동작하도록 나타나야 한다. 예를 들면, 두 번째 네트웍으로 전달된 데이터를 갖는 주식정보표시(stock ticker) 어플리케이션은 주식가격을 스크린에 표시한다. 사용자가 다른 채널로 바꾸어도 이 어플리케이션은 스크린에 남아 있어서 볼 수 있어야 한다.

1.2.4. Advertisements ¶

Advertisement 어플리케이션은 상업적인 audio/video 컨텐츠에 대한 내용을 갖는 어플리케이션이다. 이런 어플리케이션은 일반적으로 광고시간 동안에만 실행되고, 따라서 상당히 짧은 시간만 동작한다. 광고 어플리케이션의 실제 다운로딩은 광고시간이 시작되기 전에 미리 이루어져야 한다. 이 어플리케이션은 일반적으로 광고시간이 지나면, 중지되고 버려진다.

1.3. Features of the Java TV API ¶

JavaTV API는 interactive television 서비스와 디지털 방송 수신기에서 동작하는 기타 다른 종류의 소프트웨어를 개발하는 개발자들을 목표로 하는 interface이다. 다양한 종류의 어플리케이션을 위해 JavaTV API가 제공하는 주요 기능 아래에 묘사되어 있다.

Accessing Services and Service Information

자바 TV API는 전통적인 것 뿐만 아니라 대화식의 텔레비전 프로그래밍을 개별적인 한 세트의 서비스로 표현한다. Service information API는 서비스를 선택하는데 사용될 서비스 정보(SI)를 얻는 것에 대하여 지원을 제공한다.
SI 데이터 베이스는 실행시간 동안 사용 가능한 서비스가 무엇인지에 대한 정보를 어플리케이션이 접근 할 수 있도록 제공한다. SI 데이터 베이스로 접근은 SI manager를 통해서 이루어 진다. 만약 애플리케이션이 이용할 수 있는 모든 서비스에 관심이 없으면, SI 관리자는 관심있는 서비스를 발견하기 위하여 필터링 연산을 할 수 있도록 허락한다. 정의된 SI 데이터 베이스의 뷰는 탐색, EPGs, 그리고 MPEG-2 전송을 제어한다. 더많은 정보에 대하여 , 3 장을(" 서비스와 업무용 정보 ") 참고 하라.
Selecting Services
Service selection API는 표현될 서비스를 선택하는데 사용되어 진다. Selecting에 대한 메커니즘은 서비스 콤포넌트에 의해 결정되어지고, 어플리케이션이 서비스의 일부분이라면 어플리케이션의 시작도 포함한다. 더 많은 정보를 원하면 4장 “Service Selection”을 참고 하라.
Controlling the Broadcast Pipeline
JavaTV API는 수신기의 broadcast pipeline의 표현을 위해 JMF를 사용한다. JMF는 데이터 원본(Data source)과 콘텐트의 취급(handle)을 정의한다. Java TV API가 방송 파이프라인을 비슷하게 구분 짓는다. Tunner demultiplexer-conditional access(C/A) 부분시스템은 데이터 원본(source of data)로, 반면, decoder-framebuffer-audio 출력은 content handler로 말이다. 더 많은 정보를 원하면 5장 “JMF and the Broadcast Pipeline”을 참고 하라.
Accessing Broadcast Data
서비스는 아날로그와 디지털 데이터 스트림의 multiplex를 모델링 되어 있다. 이런 스트림의 대부분의 경우는 어플리케이션으로의 직접적인 연결이 불가능하다(예, audio/video stream). 그러나, multiplex는 어플리케이션에 가능한 디지털 데이터 스트림을 가질 수 있다. Broadcast data API는 broadcast file system, 스트리밍 데이터, 그리고 encapsulated IP data에 대한 접근을 지원한다. 더 많은 정보를 원하면 6장 “Braodcast Data APIs”을 참고 하라.
Managing Application Lifecycle
어플리케이션이 초기화 되고, 다양한 상태 변화를 경험하고, 결국 파괴되는 일련의 단계들은 어플리케이션 생명주기(life cycle)라는 집합으로 알려 진다. Java TV API는 디지털 방송수신기에서 동작되는 어플리케이션의 생명주기를 정의 한다.

이와 같은 어플리케이션은 Xlet 어플리케이션이라고 불리워진다. Xlet은 수신기에 계속해서 위치할 수도 있으며, 다운로드 될 수 도 있고, TV수신기의 소프트웨어 운영환경의 일부분인 어플리케이션 Manager에 의해 제어된다. 어플리케이션 manager는 Xlet 생명주기 상태변화를 관리한다. 각각의 수신기들은 Xlet이 어플리케이션 context를 통해 전달되어 초기화되는 동안에 Xlet이 환경에 접근할 수 있도록 기능을 제공하는 수신기 상주 어플리케이션 manager를 갖는다. 더 많은 정보를 원하면 7장 “Application Lifecycle"을 참고 하라.

2. Environment ¶

아래 내용들은 JavaTV 어플리케이션이 동작하는 하드웨어, 소프트웨어 환경에 의해 제공되는 상태를 모델링하여 표현하고 있다. 이 모델은 텔레비전 수신기의 모든 관점들에 포괄적 이도록 의도해지지 않는다. 하지만, Java TV API 그리고 Java 어플리케이션이 환경에 접근하기 위한 수신기의 부분을 단순하게 묘사하고 있다.

2.1. Hardware Environment ¶

이 부분은 방송 수신기를 만드는 구성 요소들을 묘사한다. 이것은 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의 환경이 있을 수 있다.)
RF 신호가 tune 된다.
tuned RF 신호가 digital signal로 demodulat되고 MPEG-2 transport stream을 운반한다.
transport stream이 demultiplexer를 통해 전달되고, multi stream으로 분리된다.(예: audio, video, data)
video, audio stream이 특권에 접근하는 것을 결정짓고 데이터를 해독하는 C/A subsystem을 통해 전달된다.
해독된 audio, video stream은 audio, video 출력장치에 적절한 신호로 전환될 decoder에 전달 된다.

2.2. Software Environment ¶

디지털 수신기의 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는 장치 드라이버의 모음을 통해 수신기를 제어 한다.

2.3. Application Environment ¶

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

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

Java.io패키지는 java.io.InputStream, java.io.OutputStream, 그리고 그 subclass들을 이용하여 data input/output 기능을 제공한다.
Networking

java.net 패키지는 java.net.URL, java.net.InetAddress, java.net.Socket 과 같은 클래스들을 이용하여 네트웍기능을 접근하도록 제공한다.
graphics toolkit

java.awt패키지는 java.awt.Canvas, java.awt.Font, java.awt.Scrollbar와 같은 클래스들을 이용하여 그래픽연출이나 윈도우 서비스를 어플리케이션에게 제공한다.
system functions

java.lnag.Thread, java.util.EventObject와 같은 클래스들은 시스템레벨의 기능을 어플리케이션에게 제공한다. 어플리케이션 환경은 또한 java.util.Hashtable, java.util.Calendar와 같은 유용한 utility 클래스들을 포함하고 있다.

2.3.1. storage and Input/Output ¶

java.io 패키지는 stream-based I/O, file-based I/O, 그리고 다양한 버퍼링 옵션을 위한 추상화를 제공한다. Flash ROM system, local hard drivers, 그리고 server-based remote storage system들은 java.io 패키지를 이용하여 접근할 수 있다. 어떤 환경에서는 수신기의 상태 정보나 사용법과 같은 서비스 운영을 위한 system error stream의 사용을 지원한다. 이와 같은 stream 또한 java.io를 사용한다.

추가적으로, broadcast data stream과 file system은 java.io의 사용을 필요로 한다. 보다 많은 정보는 broadcast data API section을 참고하라.

2.3.2. Return Channel and Non-broadcast Network Access ¶

java.net 패키지는 네트웍 소켓의 접근과 HTTP connection, 그리고 URL의 파싱을 위한 환경을 제공한다. java.io 패키지와 함께 이 패키지는 IP return channel의 접근과 관리또는 MPEC stream에 encapsulate 된 IP data에 대한 접근을 위한 기능의 요구사항을 제공한다.

2.3.3. security ¶

어플리케이션 환경은 네트웍 operation과 표준 organization이 자신만의 보안 모델과 정책을 정의 내릴 수 있도록 기반을 제공한다. java TV API 는 특정 보안 정책이나 모델을 강요하지는 않는다. 하지만, JDK1.2 보안구조를 사용하여 어플리케이션 환경에 의해 제공되는 보안정책을 표현한다.

이와 같은 접근은 네트웍 오퍼레이터나 standard organization이 미래에 변화를 필요로 하는 그들만의 보안 모델을 재 정의 하는데 자유를 주는 것이다. 이것은 또한 braodcaster가 기존의 보안 메커니즘을 플랫폼에 적용시키는 것을 가능하게 한다. 이 장에 남아있는 부분은 interactive television과 연관된 몇몇 중요한 보안 문제와 API가 각각에 대해 지원하는 것을 묘사하고 있다.
conditional Access

C/A subsystem은 downstream video 또는 datat stream의 descramble이나 해독에 사용되는 인증키 세트의 관리를 제어한다. Java TV API는 C/A key나 해독 알고리즘에 대한 획득과 관리 메커니즘을 정의 하지 않는다. 너무나 다양한 전개 시스템과, API를 포함하고, C/A architecture를 정의 하는 몇몇 표준 인터페이스가 존재한다.

High-level의 C/A subsystem API를 제공하는 것보다는, Java TV API는 service selection API와 SI databases를 통한 C/A subsystem interaction을 표현 한다. 좀 더 자세한 정보를 위해서, 3장 "Service and Service Information"과 4장 "Service Selection"을 보라.
secure Commnunication

금융데이터나 전자메일과 같은 비밀정보의 보호를 위해 Secure Communication은 매우 중요하다. 안전한 bi-directional(??) TCP/IP 접속을 이루기 위해 SSL(Secure sockets layer)와 TLS(Transport Level Security)연결을 이용한다. Java Secure Socket Extention(JSSE)는 SSL과 TLS접속을 만들기 위한 자바 표준 확장이다. JSSE는 어플리케이션이 java.io와 java.net에서 제공되는 서비스를 기반으로 secure communication을 접근하게 하기 위해 javax.net과 java.net.ssl 패키지를 포함한다.
Virtual Machine

Java VM은 코드의 secure execution을 제공하도록 설계되어 있다. Bytecode 검증은 VM 실행 instruction의 유효성을 보증한다. 클래스 로딩 매카니즘은 어떻게 코드가 머신에 로드되는지를 보호하고, 코드 소스의 유효성을 보증한다. 직접적인 메모리 포인터의 관리를 자바 언어에서 제거함 으로서 데이터나 스택오버플로우를 기반으로 하는 공격과 같은 코드 masquerading에 기인하는 위험을 제거 했다.

2.3.4. Abstract Window Toolkit ¶

Java Abstract Window(AWT)는 UI 콤포넌트나 위젯의 생성을 위한 기본적인 도구의 모음을 제공한다. AWT는 또한 native widget의 커다란 모음을 제공한다. Vendor, consortia, standard는 수신기에 상주할 위젯을 정의 내릴 수 있다. 어플리케이션은 또한 특정 look and feel지원하는 특별한 목적의 위젯을 만들기위해 AWT를 사용할 수 있다.

3. Service and Service Information ¶

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과 같은 다양한 환경에서 동작하기위한 특별한 코드를 필요치 않는다.

3.1. Service and Service Information Definitions ¶

Service - content provider에 의해 정의된 대로 함께 제공되는 것을 지향하는 서비스 콤포넌트의 모음이다. 각각의 service는 service information(SI)와 연결되어 있으며, 모든 service는 반드시 그것의 SI를 수신기에게 이용할 수 있게 만들어야 한다. SI entry는 service의 정의된 속성값들 중에 하나이다.
Service information(SI) ? information은 service의 content 또는 service들을 묘사하고 있다. 이것은 등급과 같은 메타 정보 뿐만 아니라 일관된 전체 서비스 컴포넌트들을 제공하기 위한 기본적인 정보를 포함한다.
service Component ? video stream, audio stream, java application과 같은 "mono-media" 구송요소나, 다른 정보를 필요치 않고 표현될 수 있는 어떤 다른 데이터 종류. Service는 하나이상의 서비스 콤포넌트를 포함하며, service component 하나 이상의 service에 의해 공유되어 질 수 있다.
Srevice locator ? 표현되기 위해 물리적 주소로 resolove되어야 하는 것을 필요로 하는 서비스에 관한 정보
SI database ? television application에 의해 접근가능한 service information을 저장하고 있는 database.
SI manager ? SI database를 기반으로 가장 기본적인 접근 포인트. SI manager는 사용가능한 SI 구성요소와 관련된 변화를 보고하고, 서비스 locator를 서비스와 연관되어 있는 메타데이타 에 해석하는 기능이다.
SI element ? service information의 한부분을 표현하는 객체

3.2. SI Packages ¶

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

Service 패키지는 SI database에 접근하는 기본적인 포인트를 제공하고, Service, SIElement interface와 같은 다른 SI package로의 공통 클래스들을 포함한다.
Navigation package : javax.tv.service.navigation

Navigation 패키지는 기존에 존재하는 서비스들을 탐색하는데 사용되는 클래스들을 포함한다.(DVB에서의 Service, ATSC에서의 Vitual Channel이고 불리우는)
Guide package : javax.tv.service.guide

Guide 패키지는 프로그램의 스케쥴, 개별 프로그램 이벤트, 프로그램 등급 등을 포함하는 eletronic program guide(EPGs)위해 사용되는 클래스를 포함한다.
Transport package : javax.tv.service.transport

Transport 패키지는 MPEG-2 전송 매카니즘을 표현한다.

그림 4는 SI API 패키지를 묘사하고 있다. 그림에서의 화살표는 패키지 간의 의존성을 나타낸다.

대부분의 디지털 TV 수신기는 모든 SI data를 메모리에 캐쉬할 수 없다. 수신기는 가장 유용한 정보로 구성된 SI data의 일부분을 캐쉬한다. 그러나,메로리에 저장되지 않은 데이터를 수신할 필요가 있을때에는, 수신기는 transport stream을 파싱할 것이다.

왜냐하면 transport stream에 접근은 상당한 시간이 걸리기 때문에, SI API는 캐쉬되지 않은 정보에 비동기 접근을 제공한다.

SI API는 또한 추가적인 정보에 접근을 허용하는 SIElement의 확장을 통해서 미래의 API확장을 위한 유연한 메커니즘을 제공한다.

3.2.1. Service Package ¶

service 패키지는 다른 SI package에서 사용될 몇몇 특징을 제공한다.
다른 SI package에 의해 확정될 기본 클래스들
transport stream에서 SI element 변화의 탐지를 위한 이벤트 통지 메커니즘과 비동기 요청에 대한 이벤트 전달.
예외(Exception)

대부분의 SI 구성요소들은 클래스 이기 보다는 interface이기 때문에, 어플리케이션은 특정 인터페이스를 implements하는 object를 직접적으로 인스턴스화하는 방법을 갖지 못한다.

어플리케이션은 broadcast에서 SI 구성요소가 변화될 때 통지되게 할 다양한 객체에 등록될 수 있다. SIChangeListener Object와 SIChangeEvent object는 표준 자바 이벤트 모델을 지원한다. 변화 통지를 지원하는 객체의 종류는 다음과 같다.
ServiceDetail object: 자신과 연결된 ServcieComponent object와 관련된 변화를 보고 한다.
Trainsport object : TrainsportStream, NetWork, Bouquet 객체에 의해 표현되는 테이블과 관련된 전달된 서비스와 네트웍의 정의 변화를 보고한다.(??)
ProgramSchedule object : 스케쥴에서의 어떤 하나의 PrgramEvent에 대한 탐지에 의한 변화를 보고한다.

Service패키지는 또한 동기 데이터의 전송 메커니즘도 제공한다. 이 기능은 SIRequestor, SiRequest interface에 의해 제공된다. 동기 메서드의 호출자는 한번 요청한 데이터가 사용가능하다는 최근에 수신한 callback을 수신하기 위해 SIRequestor를 등록한다.(??)

SIRequestor boject는 요청된 데이터 또는 실패 표시를 수신한다. SIRequest 객체는 호출자에게 더 이상 필요가 없는 경우 동기 요청의 취소를 하기 위해 제공된다.

3.2.2. navigation Package ¶

navigation 패키지는 두 종류의 기능을 제공한다 :
Service와 service components에 대한 보다 자세한 정보 요청을 위한 메커니즘
service 객체를 다양한 분류 기준에 기반을 둔 모음들 안으로 group시키는 매커니즘

주요 탐색기능은 몇몇 객체에 의해 표현된다. SI manager는 SI database에 기본적인 접근 포인트가 된다. 이것은 serviceFilter 객체에 의해 표현되는 선택기준에 기반을 둔 ServiceList라고 불리우는 Service 객체의 모음을 생성해 낸다. Collection은 채널넘버, 채널이름에 의해 정렬을 할수 있고, Service object를 통해 탐색한다. 기본 클래스인 ServiceFilter는 수신기에 install된 모든 service를 표현하는 기본 collection을 생성해 낼 수 있다.

Service object 그 자신은 탐색에 필요한 오직 최소한의 정보(locator, 채널이름과 번호와 같은)만을 가지고 있다. 서비스와 관련된 추가적인 정보는 ServiceDetail 객체에 포함되어 있다. ServiceDetail 객체는 접근조건(C/A), 서비스의 전달 메커니즘,서비스가 마지막으로 갱신된 시간 등과 관련된 정보를 제공한다.

Channel component 세트는 Service 객체와 연관되어있다. 이것은 또한 특정 정보가 사용가능 하다면 특정 ProgramEvent와도 연관될수 있다. 현재의 ProgramEvent 객체는 현재의 프로그램을 수송하는 Service object와 같은 component를 제공한다.

3.2.3. Guid Package ¶

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

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

3.2.4. Transport Package ¶

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

4. Service Selection ¶

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

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

4.1. sercive Selection Definitions ¶

service context ? 서비스가 존재하는 환경. 수신기는 하나이상의 service context를 지원한다. Service context내에서, 한번에 보여질 하나의 서비스가 선택될 수 있다.
Service content handler ? 수신기안에서 어떤 서비스 일부분의 표현을 위한 책임 엔티티. Single service content handler는 같은 time clock간에 공유되는 몇몇 서비스 콤포넌트를 표현한다. Service content handler의 생명주기는 service의 표현 생명주기에 의해 bound된다. 개별적인 service content handler는 또한 service 생명주기 내에서 자신의 생명주기를 갖을 수 있다. 예를 들어, service내에 있는 어플리케이션은 같은 서비스 안에 있는 다른 어플리케이션과 자신을 교체 할 수 있다.

4.2. Service Selection API Overview ¶

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

ServiceContext object가 서비스를 표현할 때, getServiceContentHandler()메서드는 다양한 서비스 콤포넌트를 표현하고 있는 “엔진”이나 “players”의 reference를 리턴한다. 오디오, 비디오, 동일한 clock을 공유하는 subtitle 콤포넌트와 같은 실시간 미디어 때문에 single JMF player가 리턴된다.

4.3. Service Context State Model ¶

ServiceContext는 네가지 상태중에 하나에 존재 할 수 있다 ? Presenting, NotPresenting, Presentation Pending, Destryed. 초기상태는 Presenting이 아니다. 어느 상태에서도(Destryed 상태를 제외하고) select()메소드는 호출될 수 있다. 어떤 Exception도 발생하지 않았다는 가정하에 ServiceContext는 Presentation Pending상태로 들어간다. 이 상태 trainsaction상에서는 어떤 이벤트도 생성되지 않는다.

만약 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
상태 이름
설 명

Not Presengting
ServiceContext의 초기화 상태. 이 상태에서 어떤 서비스도 뷰어에 표현되지 않는다. ServiceContext는 또한 stop메서드가 호출되거나 만약 이전에 표현되던 서비스가 더 이상 표현되지 않는다면 이 상태로 들어 온다.

Presentation Pending

ServiceContext는 select메서드가 호출된 이후에 아무런 Exception이 발생하지 않으면 이 상태로 들어온다. 만약 서비스가 이전 상태에서 표현되고 있었다면, 서비스는 이 상태에서 계속해서 표현된다. 만약 selection operation이 성공적으로 마쳐지지 않으면, ServiceContext는 이 상태를 떠나서 이전 상태로 돌아 가려고 시도한다.

Presenting
만약, service selection이 성공적으로 이루어 진다면, ServiceContext는 이 상태로 들어온다. 이 상태에서는 normal content 또는 alternative content가 뷰어에 표현된다.

Destryed
Destroy메서드가 호출된 때, ServiceContext는 이 상태로 들어온다. 이 상태에서는 어떤 서비스도 뷰어에 표현되지 않는다. 일단 이상태에 들어 오면, ServiceContext는 더 이상 사용될 수 없다.

5. JMF and the Braodcast Pipeline ¶

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을 보라.

5.1. JMF Controls ¶

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들을 포함한다.
Interface
Function

Javax.tv.media.MediaSelectControl
Media 선택

Javax.tv.media.AWTVideoSizeControl
Video size and position

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에 나열되어있다.

DAVIC Control
Function

Org.davic.media.MediaTimeEventContrl
Time based events

Org.davic.media.LanguageControl
Base class for language selection

Org.davic.media.SubtitingLanguageControl
Subtitle language selection

Org.davic.media.MediaTimePositionControl
Position

Org.davic.media.FreezeControl
Freeze frame

Org.davic.AudioLanguageControl
Audio language selection

5.2. JMF Synchronization ¶

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에게 전달된다.

5.3. Player Architecture and the Broadcast Pipeline ¶

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이다.

6. Broadcast Data APIs ¶

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의 접근을 제공하다.

6.1. Broadcast Data API Definitions ¶

DSM-CC - MPEG-2 Digital Storage Media Command and Control, ISO/IEC13818-6에 정의되어 있다.
object carousel - data carousel 위의 DSM-CC User-to-User(U-U) Object의 주기적인 전송을 위한 메카니즘. Object carousel은 DSM-CC U-U 파일/디렉토리 객체를 이용하여 계층적인 파일 구조를 운반한다.
data carousel - DSM-CC User-to-Netwo가 Download protocol에 정의에 의해 data module의 주기적인 전송을 위한 메카니즘
asynchronous data - timing 요구가 없는 data. MPEG-2 transport stream안에 qlehdrl 데이터는 program clock reference(PCR)이나 presentation time stamp(PTS)값을 포함하지 않는다.

6.2. Braodcast File Systems ¶

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과 사용된다. 이것은 아래에 자세히 묘사되어 있다.

6.2.1. DSM-CC Object Carousels ¶

DSM-CC object carousel protocol은 일반적으로 broadcast file system의 형식이다. 이것은 carousel data를 조직하는데 세가지 종류의 object를 한정한다.
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에게 통지한다.

application은 CarouselFile object로부터 읽기 위해 java.io패키지(예, FileInputStream, FileReader, RandomAccesFile)의 클래스를 일반적인 파일의 입력으로 사용한다.

6.2.1.1. Object Carousel Example Usage ¶

1.최상의 수준의 CarouselFile을 생성한다.

CarouselFile serviceGateway = new CarouselFile(locator);

최상의 수준의 object를 나열한다.

String files[] = serviceGateway.list();

파일 object 생성

CarouselFile myfile = new CarouselFile(serviceGatewqy, files0);

file input object 생성

FileInputStream fis = new FileInputStream(myFile);

파일로부터 읽기

byte data = fis.read();

파일 닫기

fis.close();

ServiceGateway의 CarouselFile이 instantiated 됐을 때, local file system의 계층의 subtree로서 carousel namespace를 붙임으로서 수신기는 local file system에 연결된 carousel을 "mounts"한다. local file system에서 mount point 위치는 동적으로 결정되거나 텔레비전 표준 몸체에 의해 정해진다. carousel이 mount된 이후에는 어플리케이션은 CarouselFile.getCanonicalPath() 메서드를 사용해서 local file system 계층구조에서 carousel의 위치를 물어볼 수 있다.

carousel이 local file system에 mount된 이후에는, 어플리케이션은 CarouselFile object 나 java.io.File object를 이용해서 DSM::Directory와 DSM::File type의 object를 접근할 수 있다. CarouselFile클래스는 java.io.File에서 찾아 볼 수 없는 특별한 비동기 로딩특징을 갖는다.

FileInpustStream, FileReader, RandomAccessFile과 같은 file input 클래스들은 요청된 data를 carousel로부터 load할 수 없으면, IOException의 instance를 throw한다. 만약 carousel이 더 이상 접근할 수 없다면, 수신기는 어플리케이션이 계속해서 이전에 로드된 데이터로부터 읽게 할 것이다.

6.2.1.2. Object Carousel Management ¶

어플리케이션이 object carousel을 다른 file system과 같이 취급한다고는 해도, 수신기는 반드시 carousel과 명시적으로 상호작용해야 한다. 이 interaction은 한 수신기의 구현으로부터 다른 수신기에게로 일관된 동작을 어플리케이션에게 제공하도록 일관성있어야 한다. 다음 동작들은 Java TV API의 DSM-CC Object carousel 접근의 구현시 권장되는 사항들이다.

CarouselFile의 DSM::ServiceGateway object instantiation에서 수신기는 :

참조되는 carousel의 service domain을 첨부한다.
local file system에 carousel file hierarchy를 mount하고,
비동기적으로 DSM::ServiceGateway 객체의 contents를 로드한다.

DSM::Directory object의 CarouselFile을 instaintiat하는데있어서, 수신기는 비동기적으로 DSM::Directory object의 contents를 로드한다. CarouselFile.instDirectoryCotents() 디렉토리 메서드의 호출은 CarouselFile에 의해 참조되는 DSM::ServiceGateway 또는 DSM::Directory의 contents가 로드될 때 까지 중단된다.

게다가, DSM::File object를 참조하고 있는 CarouselFile의 instantiating은 비동기적으로 DSM::File object의 contents를 로드한다. DSM::File object를 표현하고 있는 CarouselFile object를 오픈한 java.io.FileInpustStream, java.io.FileReader, 또는 java.io.RandomAccessFile object에서 read operation은 DSM::File object와 일치되는 contents가 로드될 때 까지 중단된다.

single DSM::File object와 일치되는 java.io.FileInputStream, java.io.FileReader 그리고 java.io.RandomAccessFile의 모든 instance에서의 close operation은 DSM::File object의 contents를 unload한다.

마지막으로 single DSM::Directory object를 참조하는 CarouselFile의 모든 인스턴스들은 DSM::Directory object의 contents를 unload 한다. carousel에 있는 객체를 참조하고 있는 모든 CarouselFile의 인스턴스가 finalize되고 carousel에 있는 DSM::File object를 참조하고 있는 모든 java.io.FileInpustStream, java.io.FileReader, 그리고 java.io.RandmAccessFile이 close되고 나면, 수신기는 :

DSM::ServiceGateway object를 Unload하고
local file system으로부터 carousel을 unmount하고 carousel의 service domain을 제거(detach)한다.

6.2.2. DSM-CC Data Carousels ¶

DSM-CC data carousel protocol은 single-directory file system의 전송을 수신기에 지원한다. data carousel protocl은 특정 carousel에 있는 data module, 그리고 각 carousel module의 contents의 전송을 위한 메시지를 알리는 DownLoadInfoIndication message를 포함한다. 만약 텔레비전 수신기가 carousel module의 string-base naming을 허락하는 broadcast 표준을 따른다면 CarouselFile의 instance는 object carousel에서 와 같이 DSM::File object와 비슷한 형식으로 data carousel module을 접근하고 읽는데 사용될 수 있다. 특히,
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시킨다.

6.2.3. Reducing the Effects of Carousel Latency ¶

DSM-CC object carousel 또는 data carousel의 접근은 전통적인 disk-based file system에서 처럼 아주 높은 고차원의 지연시간에 대한 문제가 될 수 있다. 이런 지연시간에 대한 예방책이 없는한, multiple carousel-based file을 접근하는 application은 모든 필요한 데이터의 로드에 있어서 상당한 delay를 경험하게 될것이다. 이런 지연을 방지하기 위해서, Java TV API를 기반으로 하는 어플리케이션은 다음과 같은 응답시간 관리 테크닉을 사용할 수 있다.
어플리케이션은 읽혀질 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하는 경우보다 평균 파일 접근시간이 크다.

6.3. IP Datagrams ¶

Java TV API는 java.net 패키지의 일반적인 datagram 수신 메커니즘을 이용하여 bradcast stream으로 전달되는 IP datagrams의 접근을 제공한다. 어플리케이션은 java.net.DatagramSocket클래스를 이용하여 unicast IP datagram을 수신한다. Application은 java.net.MulticastSocket클래스를 이용하여 multicast IP datagram을 수신한다.

Multicast IP datagram을 수신하게 하기 위해서는 Java Tv API는 encapsuate된 IP datagrames을 전달하는 service component에게 local unique IP 주소를 할당해야 한다. 이와 같은 address는 사설 네트웍에서 사용되기 위해 예약된 IP주소(자세한 정보는 RFC 1918을 보라)의 세트로부터 동적으로 생성된다. 텔레비전 어플리케이션은 주어진 service component에 할당한 local IP address를 javax.tv.net.InterfaceMap을 이용하여 결정한다. 어플리케이션은 이 IP address를 java.net.MulticastSocket이나 java.net.DatagreamSocket의 인스턴스가 수신한 multicast datagram의로부터의 network interface를 지칭하는데 사용한다.

6.4. Streaming Data ¶

Java TV API는 JMF패키지의javax.media.protocol을 이용하여 television broadcast에서의 일반적인 streaming data의 접근의 제공한다. 비동기적인 streaming data는 javax.tv.media.protocol.PushSourceStream2인터페이스를 이용하여 포함될 수 있다.

Java Tv API 어플리케이션은 일반적으로 javax.tv.locator.Locator Object를 사용하여 개별적인 data service component를 참조한다. Locator.toExternalForm()메서드를 사용해서, 어플리케이션은 Locator object를 javax.media.MediaLocator object가 생성되어 지는 string으로 전환시킨다. MediaLocator object는 결과적으로 javax.media.Manager로부터 javax.media.DataSource object를 포함하는데 사용된다. 그리고 나서, DataSource object는 하나 이상의 PushSourceStream2 object를 포함하는데 사용된다.

PushSourceStream2 는 JMF version1.0의 javax.media.protocol.PushSourceStream을 새로운 read 메커니즘과 함께 확장시킨 interface이다. PushSourceStream2.readStream()메서드는 data의 payload의 접근과 데이터 손실을 알리는 exception을 throws를 제공한다. Java TV API는 PushSourceSteam2를 통해서 포함된 데이터의 버퍼링이나, 사용가능성을 보증하지 않는다.

7. Application Lifecycle ¶

Java TV API는 Xlet application lifecycle이라 불리우는 application model을 정의한다. 이와 같은 lifecycle model을 사용하는 Java application은 Xlet이라 불리워 진다. Xlet application lifecycle은 기존의 application환경과 가상머신기술에 호환된다.

Xlet application lifecycle model은 Xlet과 이것의 환경과의 대화(protocol)을 다음과 같이 정의한다:
단순하고 잘 정의된 상태 머신
application 상태의 간결한 정의
상태들 간의 변화를 위한 신호 API
Xlet Application Lifecycle Definitions

다음에 정의된것들은 Xlet application lifecycle model에 사용되어진다:
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를 갖으며, 이것은 명시된 환경에 맞추어 질 수 있다.
Application Manager Requriements

Xlet application lifecycle은 application manager가 Xlet을 통틀어 행사할 수 있는 모든 제어를 address한다. Xlet위에 있는 Applicatin manager의 제어는 Xlet이 수신기에 있는 그래픽이나 공유자원과 같은 다른 자원의 접근을 허용하지는 않는다. Application manager는 순수하게 Java언어로 쓰여질 수 도, 아닐 수 도 있다.

Application manager 의 자세한 사항이 Java TV API의 영역을 벗어 난다 할지라도, Xlet application lifecycle model은 다음과 같은 원칙을 준수하는 application manager가 상주할 것을 요구한다:
Xlet은 언제든지 destry 될 수 있다.

Application manager는 Xlet위에서 결정적인 제어권을 갖는 디지털 텔레비전 수신기의 한 entity이다. 따라서, application manager는 Xlet을 언제든지 destroy할 수 있어야 한다.
Xlet의 현재 상태는 항상 보고되어야 한다.

Application manager는 Xlet에 관한 그들의 현재 상태를 신호해야할 책임이 있다. 하지만, Xlet은 자신의 상태를 또한 바꿀 수 있어서, 그들은 반드시 이와 같은 변화를 application manager에서 신호해야 한다.
Application manager는 Xlet의 상태를 바꿀 수 있다.

Application manager의 궁극적인 목적은 Xlet의 상태 변화를 명령하기 위해서 이다.
Application manager는 Xlet의 상태가 바뀌었다면 그것을 알아야 한다.

Xlet applicatio lifecycle API의 한 특징은 Xlet은 자신의 상태를 바꿀 수 있다는 것이다. 따라서, application manager는 반드시 이 상태 변화를 통지 받아서 Xlet의 상태를 추적 할 수 있어야 한다.
Xlet States

Xlet에 관한 lifecycle은 다음과 같다.

Table 4 Xlet States
상태 이름
설 명

Loaded
Xlet이 로드되고 아직 초기화 되지 않은 상태. 이 상태는 new를 이용해서 생성된 다음 들어 가게 된다. Xlet의 아규먼트없는 constructor을 호출하고 Exception없이 리턴된 경우. Xlet은 일반적으로 이 단계에서 거의 또는 전혀 초기화를 하지 않는다. 만약 Exception이 발생하면, Xlet은 즉시 Destroyed상태로 들어가며, 버려진다.

Note; 이 상태는 Xlet instance당 단 한번만 만날 수 있다.

Paused
Xlet이 초기화되고 정지된 상태. 이 상태는 어떤 공유 자원을 선점하거나 사용할 수 없다.

이 상태는 다음과 같은 상화에서 만나게 된다:

Loaded상태로부터 Xlet.init()메서드가 성공적으로 리턴한 다음 또는

Active 상태로부터 Xlet.pauseXlet() 메서드가 성공적으로 리턴한 다음 또는

Active 상태로부터 XletContext.notifyPaused()메서드가 성공적으로 리턴하기 전

Active
Xlet이 일반적인 기능을 하고 있으며, 서비스를 제공하는 상태. 이 상태는 Paused 상태에서 Xlet.startXlet()메서드가 정상적으로 리턴된후 들어 오게 된다.

Destryed
Xlet은 모든 자원을 반납하고 종결된다. 이 상태는 다음 상황에서 들어온다 :

DestroyXlet() 메서드가 성공적으로 리턴했을 때. DestroyXlet()메서드는 모든 홀드하고 있는 자원을 반납하고 필요한 clean up을 실행하고 garbage collect당 할것이다. 또는,

XletContext.notifyDestroyed()메서드가 성공적으로 리턴되었을 때.

Xlet은 XletContext.notifyDestoryed의 호출전에 반드시 Xlet.destryXlet()메서드와 동일한 수행을 해야 한다.

Note: 이 상태는 Xlet의 instance당 오직 단 한번만 만날 수 있다

Xlet state Machine

Xlet 상태 머신은 Xlet의 동작을 텔레비전 시청자가 기대하는 동작에 가능한 가깝게 설계되었다. 특히:
감지되는 Xlet의 startup 응답시간의 매우 짧을 것이다.
Xlet의 임시 정지를 서비스로 제공해야 하는 것이 가능하다.
Xlet의 destroy를 언제든 가능하게 한다.

그림 7은 Xlet에 대한 application 상태 머신을 그림으로 보여주고 있다.

Xlet Lifecycle Model

오직 Xlet 만이 설계된 서비스를 제공할 수 있는지를 결정할 수 있다. 따라서, application manager는 Xlet에게 서비스를 제공하라고 강요할 수 없다. 이것은 오직 Xlet이 그렇게 하라고 허락된 것을 가르킬 수 있다. 일반적인 Xlet 실행 순서는 다음과 같다:

Table5 Xlet Excution

Application Manager
Xlet

Application manager는 Xlet의 새로운 instance를 생성한다.
Xlet의 default constuctor(아규먼트 없는)가 호출되고 Loaded 상태에 있다.

Application manager는 Xlet을 실행시키기 위해 필요한 context object를 생성하고 Xlet을 초기화 시킨다.
Xlet은 context object를 이용하여 자신을 초기화 한다. Paused상태에 있다.

Application manager는 이 서비스를 실행하기 적절한 시간을 결정하고, Active 상태로 들어갈 것을 신호한다.
Xlet은 서비스를 실행하는데 필요한 모든 자원을 획득한다.

Application Manager은 더 이상 Xlet이 서비스를 실행하는 것을 필요치 않는다. 따라서 Xlet에게 서비스를 멈추라는 신호를 보낸다.
Xlet은 서비스 실행을 멈추고 현재 선점하고 있는 자원을 반납하는 선택을 하게 될것이다.

Application manager는 Xlet이 더 이상 필요치 않다고 결정하거나 보다 높은 우선순위를 위한 방을 만든다. 따라서 이것은 Xlet에게 destroy되는 신호가 된다.
만약 그렇게 하도록 설계되었다면 Xlet은 상태나 사용자 선호를 저장하거나 clean up을 실행한다.

Xlet Package

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

이 interface에 호출은 호출의 성공적인 리턴이 이루어 졌을때만 성공적인 상태변화를 가르킨다.
Call to XletContext

이 interface에 호출은 상태변화가 입구에 있음을 나타낸다.

Xlet API는 다음의 원칙을 따른다:
Xlet API는 Xlet에게 상태변화가 요구될 때 신호를 보낸다.

궁극적인 Xlet API의 목적은 Xlet의 상태변화를 명령하는데 있다.
Xlet이 초기화될 때 context가 제공된다.

XletContext는 Xlet을 표현하는데 사용될 object이다. XletContext는 환경에 기반해서 환경설정을 허락하기위해 XletContext가 전달된다.
Xlet은 상태가 변화됐을 때 신호를 보낼 수 있다.

개별적인 Xlet은 적절한 실행을 할 수 있게 또는 없게 정의 할 수 있는 오직 개체(entity)일뿐이다. 따라서, Xlet은 원하는 실행을 더 이상 할수 없음을 발견하고 상태 변화를 선택 하게 될것이다.
Xlet은 모두 마쳤을 때 신호를 보낼수 있다.

Xlet은 자신의 작업을 모두 마쳤을 때, application manager에게 신호를 보낸다.

8. 4.1Xlet interface ¶

Xlet interface는 application manager에게 application lifecycle 상태변화를 Xlet에게 신호보낼 수 있는 네개의 메서드를 제공한다:
#!java Public void initXlet(XletContext ctx)

Xlet을 초기화한다. 이 메서드는 Xlet에게 자신을 초기화하라는 신호를 보낸다, 그래서 이것은 서비스를 빠르게 제공할 수 있게 준비하게 한다. XletContext object는 이 메소드 안으로 전달된다. 이 object는 상태가 바뀔 때 application manager에게 신호를 보내는 것 뿐만 아니라 , 이것 환경과 연관된 propertie를 Xlet이 접근하게 하는데 사용된다. 만약 Xlet이 성공적으로 초기화를 하지 못하는 무슨 원인이 있다면, XletStateChangeException의 발생으로 application manager에게 신호를 보낸다. 그 밖에 Xlet은 Paused 상태로 돌아온다.
Public void startXlet()

Xlet은 이 메소드가 완결되면 Active상태로 옮겨 간다. Xlet은 이 상태에서 서비스를 제공하게 된다. Xlet 일반적으로 이 시점에서 자원을 획득한다. 만약 Xlet이 Active 상태로 들어가지 못하면, application manager에게 상태변화 실패를 통지하는 XletStateChangeException을 발생시킬 수 있다.
Puglic void pauseXlet()

PauseXlet은 제공하는 서비스를 중단하라는 신호를 Xlet에게 통지한다. Callback이 리턴될 때, xlet은 Pause 상태에 있게 된다. Xlet은 이 시점에서 자원들을 반납하는 선택을 하게 될것이다. 만약 Xlet이 Paused 상태로 들어가지 못하면, application manager에게 상태변화 실패를 통지하는 XletStateChangeException을 발생 할 수 있다.
Puglic void destroyXlet()

이 메서드는 Xlet이 더 이상 필요없고 곧 시스템에서 제거 될것이라는 신호를 보낸다. Xlet은 종결되기전에 자원의 반납, preference 저장, 상태저장 등과 같은 모든 필요한 처리를 실행한다.
Xlet and Finalization

Java언어는 object가 gabarge collection 되기 전에 어떤 clean up처리를 할 수 있도록하는 finaization 호출 메커니즘을 제공하고 있다. Object의 finalizer는 모든 object를 참조들이 버려지거나, object가 garbage collect될 준비가 되기전 까지는 호출되지 않는다. Java language specification은 programmer는 절대 finalize 호출에 의존하지 말아햐 한다고 한다. Xlet interface에서 Xlet destroyXlet() 메소드 호출은 destroy되기 바로 직전에 호출는것에 주의하라. 두 메서드의 의도가 비슷하기는 하지만, 프로그래머는 destryXlet() 메서드가 호출될 것 이라고 간주 할 수 있다.
Xlet은 finalizer에서 무슨 일을 해야 하는가.

위에서 언급했듯이, object는 그들의 finalizer가 호출되는 것에 의존해서든 안된다. 만약 Xlet이 일반적인 실행의 끝에서 반드시 clean up해야할 것이 있다면, Xlet은 destoryXlet()메서드를 대신에 이용해야 한다. 대부분의 경우 finalizer는 텅 비어야 한다.
부정한 짓을 하는 Xlet의 작업의 방지

일반적으로 Java application 환경은 Xlet의 finalizer에서 부정한 짓을 하는 Xlet의 작업을 방지하게 설계되어 있다. 이것을 가능하게 하는 하나의 방법은 finalizer thread group의 최고우선 순위를 가장 낮게 setting되어 있다는 것이다. Object의 Constructor를 통한 잠재적인 작업은 또한 security exception을 발생시킬 수 있다. Application 환경을 구현하는 사람은 반드시 이 정책을 구현하는 SecurityManager를 제공해야 한다. 어플리케이션 환경은 적어도 두개의 SercurityManager object를 제공해야 한다. 하나는 Xlet의 일반적인 수행을 위한 것이고, 하나는 finalizer thread를 실행하는 ThreadGroup의 보안정책을 구현하는 것이다.
Xlet and Threads

Xlet은 그들의 lifecycle 메서들(Xlet interface를 구현하는 메서드)를 sychronized로 선언하고 있다. 이것은 Xlet interface 메서드 에는 행해 지지 않는데, 그 이유는 Java language에서 interface 메서드는 synchronized 로 선언될 수 없기 때문이다. 이런 메서드들을 syschronized로 선언함 으로서, Xlet object interface에서 하나의 lifecycle method의 호출은 lock을 획들하게 된다. 이것은 하나가 다른 하나의 메서드의 lifecycle 메서들의 호출을 중단하는 결과를 갖는다. Xlet은 XletContext에서 lifecycle 메서드의 호출전에 그들 자신이 lock의 획득하는 장점을 또한 갖을 수 있다. 좋은 설계를 한 application manager는 Xlet의 lifecycle 메서들의 호출에 각각의 개별적인 thread를 생성하게 될것이다.
XletContext Interface

XletContext는 Xlet이 초기화 될 때 전달되는 object이다. XletContext는 Xlet에게 properties를 포함하는 메커니즘과 함께, application manager에게 내부적인 상태변화의 신호를 보내는 방법을 제공한다.
XletContext와 Xlet간에는 일대일 대응이 된다. XletContext interface는 다음과 같은 메서드를 정의하고 있다:
Public void notifyDestryed()

이 메서드는 Xlet이 Destryed상태에 들어 왔다는 것을 application manager에게 알린다. 이 메서드는 Xlet의 실행이 완결되었고 destrye될 준비가 되었다는 것을 application manager에게 알리는 것을 허락한다.
Public void notifyPaused()

이 메서드는 Xlet이 Paused 상태에 들어왔다는 것을 application manager에게 알린다. 이 상태는 Xlet이 더 이상 서비스를 제공하지 못할 때 들어오게 된다.
Public java.lang.Object getXletProperty(java.lang.String key)

이 메서드는 Xlet이 XletContext로부터 주어진 이름의 property를 가져 올 수 있게 허락한다.
Public void resumeRequest()

이 메서드는 Xlet이 application manager에게 Active 상태로 들어가려 한다는 것을 알린다.
Xlet Lifecycle Example

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

Contents