Java Image I/O API 가이드:2 - 목표 - xrath.com 에서 번역됨

목차 | 전의 항목 | 다음의 항목 | JavaTM Image I/O API 가이드

제 2 장

# 목표

## 2.1 API 의 목표

> Image I/O API 의 설계는, 몇개의 기본적인 목표를 지원하고 싶다고 하는 소원에 영향을 받았습니다. 특정의 API 기능 세트에 대해서, 정당한 이유에 의해 각 목표가 설치되고 있습니다. 그러한 목표는, 클라이언트측 어플리케이션의 필요를 주요한 동기로 하는 것과 서버측 어플리케이션의 필요를 주요한 동기로 하는 것으로 크게 나눌 수 있습니다. 물론, 이러한 기본적인 목표는, API 의 기능의 매우 일부를 표현하고 있는에 지나지 않습니다. 여기에서는, 이 API 를 설계하기에 이른 동기에 대해 감촉을 잡아 주기 위해서(때문에), 이러한 목표를 열거해 갈 것입니다.

> 경험으로부터 하면(자), 어플리케이션의 개발자에게 있어서의 편리한 사용과 플러그 인의 개발자에게 있어서의 편리한 사용의 사이에 이율배반적인 조건이 존재하는 경우에는, 언제라도 어플리케이션의 개발자가 우선되어 왔습니다. API 를 이용해 플러그 인을 작성하는 사용자는 비교적 소수이며, 실제로 플러그 인을 작성하는 개발자조차, 곧바로 사용하는 이미지 형식을 지원하기 위해서 그저 한 줌의 플러그 인을 작성할 뿐(만큼)인 것이 통례이기 (위해)때문에, 복잡한 일을 어플리케이션은 아니고 플러그 인(분)편에 밀어넣어 버린다는 것은, 당연하게 이루어지고 있습니다.

> 플러그 인 개발의 복잡함을 개선하기 위해서, 자주(잘) 사용되는 기능을 실행하는 유틸리티 메소드나 구현 클래스가 몇개인가 제공되고 있습니다. 그러나, 모든 상황을 커버하는 구현 클래스를 제공하는 것은 불가능합니다. 게다가, 제공하는 유틸리티 클래스나 유틸리티 메소드의 수가 많아너무 많아 지면(자) , 표준 이외의 플러그 인을 사용하지 않는 API 사용자에게까지, 사이즈의 큰 API 를 사용하게 하게 되어 버립니다. 플러그 인의 개발자에게는, 기존의 플러그 인의 원시 코드나, 샘플의 원시 코드를, 우리들의 플러그 인에 짜넣도록(듯이) 기대합니다. 이와 같이 해, 따로 따로 개발된 플러그 인을 복수 사용하면(자) 얼마인가의 장황성이 생기는 일이 있습니다만, 대부분의 사용자는 아마, 어떤 경우라도 한 번에 소수의 플러그 인 밖에 사용하지 않을 것입니다. 그래서, 이론상은 공용될 가능성이 있어도 실제로는 공용되지 않는 코드를 로드하지 않으면 안 되는 코스트가, 다수의 플러그 인을 사용하는 경우에 얼마인가 장황한 코드를 로드하는 코스트보다 비싸게 든다, 라고 우리는 생각합니다.

### 2.1. 1 클라이언트측 어플리케이션의 목표

> 플러그 인 가능성

> Image I/O API 를 사용하도록(듯이) 작성된 어플리케이션은, 새로운 플러그 인이 등장했을 때에, 어플리케이션을 다시 만들거나 재컴파일 하거나 하지 않아도, 그 새로운 플러그 인을 자동적으로 이용할 수 있는 것 같아야 합니다. 그 때문에(위해)는, 이미지 형식에 의존하지 않는 일식의 인터페이스에, 가능한 한 플러그 인이 준거하고 있을 필요가 있습니다. 그러나, 모든 이미지 형식에는 각각 독자적인 프로퍼티이나 기능이 있어, 플러그 인은 그러한 프로퍼티이나 기능을 어플리케이션에 대해서 공개할 수 없으면 안됩니다. 이것은, API 내의 몇개의 인터페이스를 플러그 인을 확장할 수 있도록(듯이) 하는 것에 의해 실현됩니다. 플러그 인이 제공하는 특정의 확장 기능에 대응하고 있지 않는 어플리케이션은, 플러그 인의 일반적으로의 기능만을 계속 이용합니다만, 확장된 인터페이스에 대응하고 있는 어플리케이션은 그것을 이용할 수 있다는 것입니다.

> 메타데이타 (이미지 이외의 데이터)에 대한 범용의 액세스와 플러그 인 고유의 액세스를 어느쪽이나 지원하기 위해서, 복수의 형식의 메타데이타에의 액세스를 플러그 인을 제공할 수 있도록(듯이) 합니다. 메타데이타의 형식에는, 플러그 인에 고유의 형식, 플러그 인에 의존하지 않는, API 에 의해 정의된 형식, 및 업계표준의 형식이 있습니다.

> 자동 및 수동에 의한 플러그 인의 인스톨과 선택

> 사용자의 개입없이 이미지를 로드하고 싶은 단순한 어플리케이션의 경우, 파일의 내용에 근거해 read 플러그 인을 자동적으로 선택할 수 있는 것이 중요합니다. 다만, 불필요한데 복잡한 클래스를 로드해 인스턴스 생성하는 것은 피하고 싶은 것입니다. 플러그 인의 코드 전체를 로드하지 않아도, 그 플러그 인이 특정의 이미지를 처리할 수 있을지 어떨지를 판별할 수 있도록(듯이) 하지 않으면 안됩니다. 이 목표를 달성하기 위해(때문에), 플러그 인의 메인 코드를 로드하지 않아도 간단한 조회를 실행할 수 있는 서비스 프로바이더 인터페이스의 기구를 이용해, 플러그 인의 인스턴스를 생성하도록(듯이) 합니다.

> 1 개의 플러그 인에 관계하는 모든 바이트 코드 (. class) 파일을, 1 개의 JAR 파일에 정리할 수가 있습니다. 그리고, 그 JAR 파일은, Java Runtime Environment 에 영속적으로 인스톨 하는 일도, 어플리케이션의 `CLASSPATH` 기구를 사용해 동적으로 로드하는 일도 가능합니다.

> 수동에 의한 플러그 인의 선택

> 플러그 인을 자동적으로 선택하는 기능은 많은 어플리케이션에 있어 편리합니다만, 한층 더 선진적인 어플리케이션을 위해서(때문에), 플러그 인을 선택하는 프로세스를 좀 더 제어할 수 있도록(듯이) 해 둘 필요도 있습니다. 이것을 실현하려면 , 어플리케이션으로부터 조회하거나 조작하거나 할 수 있는, 플러그 인의 실행시 레지스트리를 이용합니다.

> 네트워크 경유, 디스크 베이스, 및 다이렉트인 입출력

> 어플리케이션에 있어, 디스크 베이스의 데이터와 네트워크 베이스의 데이터의 양쪽 모두를 처리할 수 있는 필요성은, 더욱 더 커져 왔습니다. 많은 경우, 디스크 베이스의 데이터조차, 다른 API 의 필요를 채우기 위해서(때문에),`InputStream` 의 형식에서 처리하지 않으면 안됩니다. Image I/O API 가 제공하는 인터페이스세트에서는,`File`,`InputStream`, 또는 그 외의 소스로부터의 데이터를 통일적인 방법으로 처리할 수가 있습니다. 게다가, 후방향과 전방향에 시크 하는 기능은 없어지고 있지 않습니다. 이 API 에는, 장래, 새로운 입출력 인터페이스를 추가하는 여지도 남아 있습니다. 예를 들어, 이미지의 capther-장치나 출력 길이치에의 다이렉트인 인터페이스를, 어플리케이션 코드를 고쳐 쓰지 않고 사용할 수 있습니다.

> 메타데이타에의 액세스

> 이미지와 함께 포함되는 메타데이타는, 이미지 그 자체의 데이터와 같은 중요성을 가지는 일이 있습니다. Java Image I/O API 에서는, 완전하고 유연하게 메타데이타에 액세스 할 수 있습니다. 메타데이타의 형식은 다방면에 걸쳐, 이미지 형식에 특화한 정보가 포함되어 있기 (위해)때문에, 그러한 메타데이타에 직접 액세스 하는 기능을 범용의 API 에 집어 넣는 것은 곤란합니다. 거기서, API 에는, 메타데이타를 XML 문서의 구조에 캐스트하기 위한 플러그 인이 필요합니다. 그리고, 텍스트 데이터 뿐만이 아니라,`Object` 에 의한 참조도 가능한 것 같게 확장할 수가 있습니다. 여기까지 변환해 버리면, 그 메타데이타는, 표준의 XML DOM (Document Object Model) 인터페이스를 사용해 액세스 하거나 편집하거나 할 수 있습니다. `Document` 의 구문이 플러그 인 마다 다르다고 해도, 그 객체의 데이터를 처리 (횡단(traverse))해, 표시해, 편집하는데, 사용하고 있는 플러그 인에 특유의 지식은 불필요합니다.

> 고도의 어플리케이션의 지원

> 고도의 어플리케이션을 지원하기 위해서는, API 는, 「썸네일」이미지, 1 개의 파일에 포함된 복수의 이미지, 멀티 해상도의 이미지, 타일링 된 이미지 등에 액세스 하는 기능을 제공하지 않으면 안됩니다. 또, 큰 이미지를 부분적으로 복호화 하는 기능이나, 매우 큰 이미지를 바라볼 수가 있도록(듯이) 하기 위한(해), 복호화중에 서브 샘플링을 실행하는 기능도 필요합니다. 게다가 이미지를 기입할 때는, 이미지 전체를 한 번에 메모리내에 포함하지 않아도, 단편 마다 이미지 데이터를 기입할 수 없으면 안됩니다.

### 2.1. 2 서버에서의 사용 사례

> 이미지의 동적인 생성

> 최근의 Web 서버에서는, 컨텐츠의 대부분을 동적으로 생성하는 것이 통례가 되어 있습니다. Java Servlet 및 Java Server Pages (JSP)의 각 API 에 의해, Web 브라우저로부터의 요구에 응답해 HTML 페이지를 생성하기 위한 , 이식 가능한 수단이 제공됩니다. 사용자 마다 독자적으로 커스터마이즈 된 HTML 를 생성할 수 있는 것과 완전히 똑같이, 이미지의 내용을 커스터마이즈 할 수도 있습니다.

> 많은 경우, 이미지의 내용은 동적으로 생성하지 않으면 안됩니다. 예를 들어, 주가 차트를 제공하는 경우를 생각해 봅시다. 표시되는 주식 마다, 한정된 수의 차트를 미리 생성해 포함해 두는 일도 가능할지도 모릅니다. 그러나, 사용자가 차트를 커스터마이즈 할 수 있도록(듯이) 한다고 하면(자), 어떻게 될까요. 예를 들어, 주가를 표시하는 시간 간격을 설정하거나 주가의 비교 대상으로 하는 지표나 다른 주식을 선택할 수 있도록(듯이) 하거나 하면(자), 미리 생성해야 하는 이미지의 수는 지수함수적으로 증가합니다. 그러한 커스터마이즈를 가능하게 하려면 , 동적인 생성이라고 하는 어프로치 밖에 없습니다.

> 이미지의 커스터마이즈

> Web 의 이미지는 1 개의 사이즈로 모두 도움이 되게 해 버리는 것이 보통으로, 수신측의 표시 능력을 고려에 넣는 일 없이, 언제나 같은 이미지 데이터를 전달하고 있습니다. 무선 단말이나 휴대단말이 증가하는 것에 따라, 그러한 단말이 한정된 대역폭이나 표시 능력에 맞추어 이미지를 커스터마이즈 할 필요가 생겨 옵니다. 반대로, 데스크탑 컴퓨터의 표시 해상도는 커지는 경향에 있기 (위해)때문에, Web 의 이미지의 상당수는 보이는 방법이 너무 작다고 하는 상황도 일어나고 있습니다. 이미지를 확대/축소할 수 없는 것은, 시력 장해를 가지는 사용자에 있어서도 문제가 됩니다. 서버측에서의 이미지의 커스터마이즈 처리를 이용하면, 모든 사용자에게 최적인 이미지를 제공할 수 있습니다. 사용자의 취향에 맞추어, 이미지의 해상도나 칼라 특성을 선택할 수 있는 것입니다.

목차 | 전의 항목 | 다음의 항목

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.