확장 기능 기구 - xrath.com 에서 번역됨

# 확장 기능 기구의 아키텍쳐(architecture)

## 목차

- 처음에
- 확장 기능 기구

- 아키텍쳐(architecture)
- 옵션 패키지의 배치
- 번들형 옵션 패키지
- 인스톨형 옵션 패키지

- 옵션 패키지의 실링
- 옵션 패키지의 시큐리티
- 관련 API

## 처음에

> 주: 옵션 패키지는, 지금까지 「표준 확장 기능」으로서 알려져 왔지만 새로운 명칭입니다. 확장 기능 기구는, 옵션 패키지의 사용을 지원하는, JDK™ 및 JRE™ 의 기능입니다.

> 이 문서에서는,옵션 패키지 를 처리하기 위한 Java™ 플랫폼이 제공하는 기구에 대해 설명합니다. 옵션 패키지는, 1 개(살) 또는 복수의 JAR 파일에 정리된 패키지의 모임에서, Java 플랫폼을 확장하는 API 를 구현합니다. 옵션 패키지는 플랫폼을 확장해, 가상 머신이, 클래스 패스에 존재하지 않는 클래스를 플랫폼의 코어 API 의 클래스로서 검색해, 로드할 수 있도록(듯이) 합니다.

> 옵션 패키지는, 플랫폼의 코어 API 를 확장하기 위해(때문에), 적절히 적용할 필요가 있습니다. 일반적으로은 Java Community ProcessSM 로 정의된 인터페이스 등, 적절히 표준화 된 인터페이스를 위해서(때문에) 사용됩니다만, 사이트 전체의 인터페이스에 적용되는 일도 있습니다. 옵션 패키지가 단일 또는 소수의 어플리케이션으로 사용되는 인터페이스에 적용되는 것은 거의 없습니다.

> 또,인스톨형 옵션 패키지로 정의되는 기호는 어느 JAVA 프로세스에서도 시인할 수 있기 (위해)때문에, 반드시 모든 참조 가능한 기호가 주어진(given) 「역순서 도메인명」 및 「클래스 계층」의 규약을 지키고 있을까 조심해 보도록(듯이) 합니다 (com.mycompany.MyClass 등).

> 옵션 패키지의 구현은, Java 프로그램 언어로 기술된 코드입니다만, 보기 드물게, 플랫폼 고유의 native code가 포함되는 경우도 있습니다. 게다가 프로퍼티, 로컬라이제이션의 카탈로그, 이미지, 직렬화 된 데이터, 및 그 외의 자원 등, 그 옵션 패키지에 고유의 각종 자원이 포함되는 일도 있습니다.

> Internet Explorer 나 Netscape Navigator 등의 브라우저에서는, 옵션 패키지는 Java Plug-in 에 의해 지원되고 있습니다.

> 옵션 패키지는, 오픈으로 표준적인 API 를 구현한 것입니다 (Sun 가 제공하는 옵션 패키지는,JavaServlet ,Java3D ,JavaManagement 등). 예외도 있습니다만, 옵션 패키지의 상당수는 `javax. *` 의 이름 공간에 할당할 수 있습니다.

## 확장 기능 기구

> ### 아키텍쳐(architecture)

> 확장 기능 기구는, 다음의 요소를 포함하도록(듯이) 설계되고 있습니다.
> - JAR 파일에 정리한 옵션 패키지 또는 어플리케이션은, 다른 JAR 파일과의 의존관계(dependencies)를 선언할 수 있게 되어 있습니다. 이 때문에, 어플리케이션을 복수의 모듈로 구성할 수 있습니다.
> - 클래스 로딩 기구를 확장해, 인스톨형 옵션 패키지 ( 및 다른 라이브러리)로부터 클래스를 검색할 수 있게 되어 있습니다. 검색에 실패하면(자), 어플리케이션으로 지정한 패스로부터 클래스를 검색합니다.
> 따라서 일반적으로, 어플리케이션에서는, 필요한 옵션 패키지 (보다 일반적인 말투를 하면, 라이브러리)를 지정해, 한층 더 제공할 필요가 있습니다. 시스템은, 인스톨 되고 있는 옵션 패키지 ( 및 라이브러리)가 있는 경우는, 그것을 선택해, 없는 경우는, 참조되고 있는 옵션 패키지 ( 및 라이브러리) 클래스의 검색과 로드를 어플리케이션의 클래스 로더에 위양 합니다.

> 이 아키텍쳐(architecture)에서는, 어플리케이션, 애플릿, 및 서브 렛이 그것들 자체의 클래스 패스를 확장할 수 있으므로, 그것들을 복수의 JAR 파일로 해 정리해 배치하는 일도 가능하게 됩니다.

> 각각의 옵션 패키지 또는 어플리케이션은, 적어도 1 개의 JAR 파일로 구성됩니다. JAR 파일에는 Manifest, 코드, 각종 자원이 포함되는 일도 있습니다. 후술 하도록(듯이), 이 주 JAR 파일에는, 다른 JAR 파일과의 의존관계(dependencies)를 기술하기 위해(때문에), 그 Manifest에 부가 정보를 포함할 수도 있습니다. JDK에 수록되고 있는 `jar` 커멘드행 툴에는, 옵션 패키지를 한덩어리로 하는 편리한 기능이 있습니다. (`jar` 툴의 참조 페이지:[Microsoft Windows 」 「Solaris™ Operating System (Solaris OS), Linux 」)

> 옵션 패키지 또는 어플리케이션은, 주 JAR 파일로부터 참조되는 다른 JAR 파일을 참조하는 일도 있습니다. 이러한 JAR 파일에는, JAR 파일 마다 독자적인 의존관계(dependencies) 정보를 포함할 수도 있습니다.

> 옵션 패키지를 구성하는 패키지는, 옵션 패키지의 구현시에는, 표준적인 패키지 명명 규약에 따라 명명할 필요가 있습니다. 이 명명 규약은 Java 언어 스펙으로 대략이 나타나고 있습니다만, 도메인의 접두사는 모두 대문자로 지정한다고 하는 규칙은 없어졌습니다. 예를 들어,`COM.sun.server` 라고 하는 패키지명은 `com.sun.server` 와도 지정할 수 있습니다. 어플리케이션과 옵션 패키지는 같은 클래스 로더를 공유하는 경우가 있으므로, 이름의 충돌을 피하기 (위해)때문에, 패키지에는 일의의 이름을 붙이는 것을 추천합니다.

> ### 옵션 패키지의 배치

> 옵션 패키지는, 어플리케이션에 번들 하는 (번들형) 방법과 모든 어플리케이션으로 사용할 수 있도록(듯이) JRE 에 인스톨 하는 (인스톨형) 방법이 있습니다. 번들형 옵션 패키지는 어플리케이션과 같은 코드 베이스에 놓여져 네트워크 어플리케이션 (애플릿)의 경우는 자동적으로 다운로드됩니다. 따라서, 번들형 옵션 패키지는, 「다운로드형」옵션 패키지로 불리는 경우가 있습니다. 번들형 옵션 패키지의 JAR 파일의 Manifest에 버젼 정보가 포함되어 그 JAR 파일에 서명이 행하여지고 있는 경우, 다운로드처의 JRE 의 확장 기능 디렉토리에 인스톨 할 수가 있습니다 ( 「Java 확장 기능의 배치 」를 참조). 인스톨형 옵션 패키지는, 최초로 사용될 때 로드 되어 같은 JRE 를 사용하는 모든 어플리케이션에 의해 공유됩니다.

> 옵션 패키지를 정리하는 경우에는, JAR 파일의 Manifest는 벤더 및 버젼 정보를 식별하기 위해서 사용됩니다 ( 「패키지의 버젼 ID 」를 참조).

> 인스톨형 옵션 패키지의 클래스는, 같은 가상 머신상의 모든 코드에 의해 「공유」됩니다. 따라서, 인스톨형 옵션 패키지는 그 플랫폼의 (`rt.jar` 의) 코어 클래스를 닮아 있습니다만, 인스톨형 옵션 패키지는, 후술 하도록(듯이), 전용의 클래스 로더와 사전에 구성된 시큐리티 정책를 가집니다.

> 번들형 옵션 패키지의 클래스는, 해당 어플리케이션, 애플릿, 또는 서브 렛의 클래스 로더만이 사용합니다. 애플릿등의 네트워크 어플리케이션의 경우, 번들형 옵션 패키지는 필요에 따라서 자동적으로 다운로드됩니다. 현시점에서는, 클래스 로더는 특정의 코드 베이스에 관련지을 수 있고 있으므로, 같은 코드 베이스에 놓여진 애플릿이면 구현 (JAR)을 공유할 수 있습니다. 다만, 전술과 같이 버젼 정보를 가져 서명된 번들형 옵션 패키지가 JRE 에 인스톨 되고 있는 경우, 그러한 내용은, 같은 JRE 에 의해 동작하는 모든 어플리케이션으로 사용 가능하고, 전유되는 것에서는 「없습니다」.

> ### 번들형 옵션 패키지

> 어플리케이션 또는 옵션 패키지의 Manifest에서는, 필요한 옵션 패키지 ( 및 그 외의 라이브러리)가 포함되는 JAR 파일과 디렉토리를 참조하는 상대 URL 를 1 개 이상 지정할 수 있습니다. 이러한 상대 URL 는, 어플리케이션 또는 옵션 패키지가 포함되어 있는 JAR 파일의 로드원인 코드 베이스와 상대적인 위치 관계에 있는 것으로서 다루어집니다.

> 어플리케이션 (보다 일반적으로는, JAR 파일)은, 필요한 옵션 패키지 ( 및 라이브러리)의 URL 를, Manifest 속성 `Class-Path` 로 지정합니다. 이 속성에서는, 호스트의 Java 가상 머신* 에 인스톨 된 옵션 패키지중에서 목적의 옵션 패키지 (또는 그 외의 라이브러리)의 구현이 발견되지 않았던 경우에 검색하는 URL 를 열거합니다. 이 상대 URL 에는, 어플리케이션 또는 옵션 패키지가 필요로 하는 라이브러리 또는 자원이 포함되는 JAR 파일과 디렉토리를 포함할 수가 있습니다. 「/」으로 끝나지 않는 URL 는, JAR 파일을 참조하고 있는 것으로 간주해집니다. 다음에 예를 나타냅니다.

> >     Class-Path: servlet.jar infobus.jar acme/beans.jar images/

> JAR 파일의 Manifest로 지정할 수 있는 `Class-Path` 헤더는 1 개 뿐입니다.

> 현시점에서는, 시큐리티상의 이유에 의해, URL 는 JAR 파일의 코드 베이스로부터 「상대적」으로 지정할 필요가 있습니다. 따라서, 원격 옵션 패키지는, 어플리케이션과 같은 코드 베이스를 바탕으로 해 지정합니다.

> 각각의 상대 URL 는, 어플리케이션 또는 옵션 패키지가 포함되어 있는 JAR 파일의 로드원인 코드 베이스와 맞대는 형태로 해결됩니다. 해결된 URL 가 무효인지, 참조하는 자원이 발견되지 않는 경우, 그 URL 는 무시됩니다.

> 해결된 URL 는, 어플리케이션, 애플릿, 또는 서브 렛의 클래스 패스의 확장에 사용되어 클래스 패스의, 그 어플리케이션, 애플릿, 또는 서브 렛이 포함되는 JAR 파일의 URL 의 직후에 삽입됩니다. 중복 하는 URL 는 제거됩니다. 예를 들어, 다음과 같은 클래스 패스가 지정되고 있다고 합니다.

>             a.jar b.jar

> 옵션 패키지 `b.jar` 에, 다음과 같은 Manifest 속성 `Class-Path` 가 포함되어 있는 경우

>             Class-Path: x.jar a.jar

> 최종적인 어플리케이션 클래스 패스는 다음과 같이 됩니다.

>             a.jar b.jar x.jar

> 물론,`x.jar` 에 의존 정보가 포함되는 경우는, 의존 파일은 이것과 같은 규칙에 따라 추가됩니다. 나중에 계속되는 URL 에 대해서도 같습니다. 실제의 구현에서는, JAR 파일의 의존관계(dependencies)는 먼저 처리되는 것이 아니라, JAR 파일이 실제로 필요하게 되었을 때까지 열리지 않습니다.

> ### 인스톨형 옵션 패키지

> Sun 에 의한 Java 2 플랫폼의 구현 이후, 인스톨형 옵션 패키지의 JAR 파일은, 다음의 표준의 로컬 코드 소스에 놓여집니다.

> >     <java-home>\lib\ext                     [Microsoft Windows]
> >     <java-home>/lib/ext                     [Solaris OS, Linux]

> 여기서 `<java-home>` 는, 런타임 소프트웨어의 인스톨처 디렉토리 (JRE 의 톱 레벨 디렉토리 또는 JDK 의 `jre` 디렉토리)를 가리킵니다.

> 시스템 프로퍼티 `java.ext.dirs` 를 사용하면(자), 인스톨형 옵션 패키지를 두는 장소를 지정할 수 있습니다. 이 프로퍼티에는, 인스톨형 확장 기능을 검색하는 디렉토리를 지정할 수 있습니다. 복수의 디렉토리를 지정하는 경우는,`File.pathSeparatorChar` 로 단락짓습니다. `java.ext.dirs` 의 디폴트의 설정치는, 위에 나타낸 인스톨형 확장 기능의 표준의 디렉토리가 되어 있습니다. Java 6 이후로 개량된 디폴트 설정에서는, 같은 시스템에 인스톨 된 모든 JRE (Java 6 이후)에 의해 공유되는 플랫폼 고유의 디렉토리에의 패스를 붙일 수 있습니다.

> >     %SystemRoot%\Sun\Java\lib\ext           [Microsoft Windows]
> >     /usr/java/packages/lib/ext              [Linux]
> >     /usr/jdk/packages/lib/ext               [Solaris OS]

> 게다가 인스톨형 옵션 패키지는, 1 개(살) 이상의 공유 라이브러리 (. dll 파일등)과 실행 가능 파일을 포함하고 있습니다. 그 후, <arch> 가 표시됩니다만, 실제로는 명령 세트 아키텍쳐(architecture)의 이름, 예를 들어 `sparc`, `sparcv9`,`i386`,`amd64` 등이 계속됩니다. 이것들은 2 개의 장소의 어느 쪽인가에 인스톨 됩니다. 최초로 검색되는 것은 다음의 디렉토리입니다.

> >     <java-home>\bin                         [Microsoft Windows]
> >     <java-home>/lib/<arch>                  [Solaris OS, Linux]

> 다음에 검색되는 확장 기능 디렉토리는, Java 6 이후에게만 적용됩니다. Java 패키지와 같이, 네이티브 라이브러리는 모든 Java 6 으로 그 이후의 JRE 에 의해 공유되는 디렉토리에 인스톨 할 수 있습니다.

> >     %SystemRoot%\Sun\Java\bin               [Microsoft Windows]
> >     /usr/java/packages/lib/<arch>           [Linux]
> >     /usr/jdk/packages/lib/<arch>            [Solaris OS]

> native code가 포함되는 옵션 패키지는, 신뢰할 수 있는 코드나 신뢰할 수 없는 코드인가에 관계없이, 실행시에 네트워크 코드에 의해 가상 머신에 다운로드할 수 없습니다. native code가 포함되어 네트워크 어플리케이션과 함께 번들 되고 있는 옵션 패키지는, JDK 또는 JRE 에 인스톨 할 필요가 있습니다.

> 디폴트에서는, 이 표준의 디렉토리에 놓여진 인스톨형 옵션 패키지는 신뢰할 수 있습니다. 즉, 이 디렉토리에 놓여진 인스톨형 확장 기능에는, 코어 플랫폼 클래스 (`rt.jar` 내의 클래스)의 경우와 같은 특권이 주어집니다. 이 디폴트의 특권은, 시스템 정책 파일 (`<java-home>/jre/lib/security/java.policy`)로 지정되고 있습니다만, 적절한 정책 파일의 엔트리 ( 「JDK에서의 액세스권 」을 참조)를 추가하면, 특정의 옵션 패키지에 오버라이드(override) 할 수 있습니다.

> 덧붙여 신뢰할 수 있는 엔티티에 의해 인스톨형 옵션 패키지의 JAR 파일에 서명을 붙일 수 있고 있는 경우, 그 옵션 패키지에는, 서명을 붙인 엔티티에 관련지을 수 있고 있는 특권이 주어집니다.

## 옵션 패키지의 실링

> JAR 파일과 패키지는, 동일 버젼내에서 무결성이 유지되도록(듯이) 「씰」할 수가 있습니다.

> JAR 파일내의 패키지를 씰 했을 경우, 그 패키지내에서 정의 떠날 수 있어 모든 클래스는, 동일한 JAR 파일이 바탕으로 되지 않으면 안됩니다. 그렇지 않은 경우는,`SecurityException` 가 throw 됩니다.

> JAR 파일을 씰 했을 경우, 그 JAR 파일로 정의 떠날 수 있어 모든 패키지는, 특별히 설정을 오버라이드(override) 하지 않는 한, 씰 됩니다.

> 패키지를 씰 할지 어떨지는, Manifest 속성 `Sealed` 로 지정합니다. 이 Manifest 속성은,`true` 나 `false` 의 값을 받습니다. 대문자 소문자는 구별되지 않습니다. 다음에 예를 나타냅니다.

> >     Name: javax/servlet/internal/
> >     Sealed: true

> 이와 같이 지정하면(자),`javax.servlet.internal` 가 씰 되어 이 패키지에 포함되는 모든 클래스는 동일한 JAR 파일로부터 로드 되지 않으면 안됩니다.

> 이 속성이 지정되어 있지 않은 경우는, 패키지의 씰 속성은, 그 패키지가 포함되는 JAR 파일의 씰 속성과 같게 됩니다.

> JAR 파일을 씰 할지 어떨지는, 위와 같은 Manifest 헤더 `Sealed` 로 지정합니다. 이 Manifest 헤더도, 같은 `true` 나 `false` 의 값을 받습니다. 다음에 예를 나타냅니다.

> >     Sealed: true

> 이와 같이 지정하면(자), 이 어카이브(archive)에 포함되는 모든 패키지는, Manifest 엔트리 중(안)에서 `Sealed` 속성에 의해 명시적으로 설정을 오버라이드(override) 하지 않는 한, 씰 됩니다.

> 이 속성이 지정되어 있지 않은 경우는, 하위 호환성을 유지하기 (위해)때문에, 그 JAR 파일은 씰되어 있지 않은 것으로 간주해집니다. 이후에, 시스템은 씰 정보를 보기 (위해)때문에, 패키지의 헤더의 체크를 계속합니다.

> 패키지를 씰 하면(자), 패키지 보호된 멤버에게로의 액세스는, 동일한 JAR 파일이 바탕으로 되는 패키지로 정의되고 있는 클래스에 제한되기 (위해)때문에, 패키지의 씰은 시큐리티 위에서도 중요합니다.

> 패키지 실링의 체크는, 다운로드형 옵션 패키지 뿐만이 아니라 인스톨형 옵션 패키지에 대해서도 행해져 위반이 있었을 경우는 `SecurityException` 가 throw 됩니다. 또, null 패키지는 씰 할 수 없기 때문에, 씰 해야 할 클래스는 그 독자적인 패키지내에 둘 필요가 있습니다.

## 옵션 패키지의 시큐리티

> 인스톨형 옵션 패키지의 코드 소스 (`<java-home>/lib/ext`)에는, 사전에 구성된 시큐리티 정책를 할당할 수 있고 있습니다. Sun 의 구현에서는, 이 디렉토리에 놓여진 JAR 파일에게 줄 수 있는 정확한 신뢰도 레벨은, 다음의 표준의 시큐리티 정책 구성 파일에 의해 지정됩니다.

> >     <java-home>/lib/security/java.policy

> 디폴트의 정책는, 인스톨형 옵션 패키지가, 코어 플랫폼의 일부인 경우와 같이 동작할 수 있도록(듯이)하기 위한의 것입니다. 이것은, 인스톨형 옵션 패키지가 native code를 로드한다고 하는 일반적인 필요성에 근거하고 있습니다.

> Java Security Model 는, 인스톨형 옵션 패키지의 코드를 신뢰할 수 없는 코드로부터 불려 갔을 경우를 위해서(때문에), 어떤 종류의 안전책을 제공하고 있습니다. 그러나, 옵션 패키지의 코드가 특권 블록을 사용하는 경우는 반드시, 시큐리티상의 위험성이 있는지 없는지 코드를 충분히 확인할 필요가 있습니다.

> 원격로부터 로드 되는 옵션 패키지로, 정상적인 동작을 위해, 액세스 체크를 하는 시스템 서비스 (파일 입출력등)를 사용할 필요가 있는 것에 대해서는, 신뢰할 수 있는 엔티티에 의한 서명을 붙일 수 있던 것인지, 신뢰할 수 있는 장소에서 로드 된 것이 아니면 안됩니다.

> Java 플랫폼의 시큐리티 기능을 이용하기 위한 옵션 패키지나 어플리케이션의 코드를 기술하는 방법의 상세한 것에 대하여는, Java「시큐리티」를 참조해 주세요.

## 관련 API

> Java 플랫폼의 몇개의 클래스는, 다음과 같은 확장 기능 기구를 지원합니다.
> - `public class java.lang.ClassLoader`
> - `public class java.lang.Package`
> - `public class java.net.URLClassLoader`

* 이 Web 사이트에서 사용되고 있는 용어 「Java 가상 머신」또는 「JVM」는, Java 플랫폼용의 가상 머신을 나타냅니다.

Copyright © 1997-2006 Sun Microsystems, Inc. All Rights Reserved. |