Liberty: 제로 마이그레이션 아키텍처
Liberty 제로 마이그레이션 아키텍처를 사용하여 사용자의 현재 애플리케이션과 구성에 영향을 최소화하면서 Liberty의 최신 버전으로 이동할 수 있습니다.
제로 마이그레이션은 작동에 원하지 않거나 예기치 않은 변경 없이 Liberty 런타임 환경의 업데이트된 버전과 함께 기존의 수정되지 않은 구성 및 애플리케이션 파일을 사용할 수 있음을 의미합니다. 아키텍처의 다음 두 가지 측면으로 인해 변경사항을 작성할 필요가 거의 없습니다.
- 제품 버전 간 전체 호환성
- 구성 파일을 마이그레이션하지 않고 Liberty를 업데이트할 수 있습니다.
- 플러그 가능한 기능
- 기존 API 및 작동이 새 제품 버전에서 지원되며 새 API 및 작동이 새 기능에 추가됩니다.
사용자 구성 파일
Liberty 런타임 환경은 사용자 구성 파일을 수정하지 않으며 버전 간에 완벽하게 호환됩니다. 여러 버전에 대하여 단일 버전의 구성 파일을 사용할 수 있습니다. Liberty의 이전 버전에 대해 작성된 파일을 이후 버전에서 사용할 수 있습니다. 이후 버전에 대해 작성하는 파일을 이전 버전에서 사용할 수 있습니다. 그 결과, 구성된 기능이 모두 설치되었으면 수정하지 않고도 여러 버전에서 구성 파일의 단일 세트를 사용할 수 있습니다. Liberty 런타임 환경의 특정 버전에 적용되지 않은 구성 설정은 무시됩니다.
사용자 애플리케이션
Liberty 런타임 환경에서는 플러그 가능한 기능을 사용하여 API의 여러 버전을 지원합니다. 예를 들어, Servlet 3.0 및 3.1 스펙이 모두 지원됩니다. API 작동의 변경사항은 새 기능 버전에서만 발생하므로 사용자의 애플리케이션에 적합한 기능 버전을 선택할 수 있습니다. 이러한 버전화된 기능은 Liberty 업데이트에서 계속 지원됩니다. 같은 기능 버전을 계속 사용하는 경우, 애플리케이션을 마이그레이션할 필요가 없습니다.
예를 들어, 사용자의 애플리케이션이 Servlet 3.0을 사용하면 애플리케이션을 실행하는 Liberty 서버에 servlet-3.0 기능이 있어야 합니다. 다른 서블릿 스펙 레벨이 얼마나 많이 지원되는지에 상관없이 Liberty를 업데이트하고 servlet-3.0 기능을 무기한으로 계속 사용할 수 있습니다. 그 대신 servlet-3.1 기능을 사용하려고 선택하는 경우에만 애플리케이션을 마이그레이션해야 합니다.

써드파티 API를 사용하는 경우, Liberty를 업데이트할 때 해당 API가 변경되거나 제거될 수 있음을 유의하십시오. 써드파티 API는 Liberty 기능을 통해 애플리케이션에 노출됩니다. 해당 API의 이전 버전과의 호환성은 Liberty에서 제어되지 않으며 보장되지 않습니다. 애플리케이션에 사용 가능한 일부 API는 Liberty 기능에서 제공되지 않고 이 디자인으로 인한 이득이 없어서 사용자의 애플리케이션 코드를 수정할 필요가 없을 수 있습니다. 예를 들면, 기본 Java™ SDK에서 제공되는 Java API는 업데이트해야 할 수 있습니다. 때때로 Java SDK의 버전을 업데이트해야 합니다. 수동으로 정보를 수집하고 애플리케이션을 마이그레이션하기 보다는 애플리케이션 2진용 마이그레이션 툴킷 및 WebSphere Application Server 마이그레이션 툴킷을 사용하여 애플리케이션에 필요한 변경사항이 있는지 스캔하십시오. 툴킷을 다운로드하고 자세한 정보를 보려면 WASdev의 마이그레이션 기사를 참조하십시오.
새 기능 사용
새 기능을 사용하려는 경우 다음과 같은 질문사항을 고려하십시오.
- 새 기능이 기존 애플리케이션에 어떻게 영향을 미칩니까?
- 이미 사용 중인 기능의 새 버전이 기존 애플리케이션에 영향을 미칠 수 있습니다. 예를 들어, 현재 Servlet 3.0을 사용하고 있으며 Servlet 3.1을 사용하고자 하는 경우, 기존 서블릿 애플리케이션을 변경해야 Servlet 3.1과 함께 올바르게 작업할 수 있습니다. 새 기능 버전과 함께 작업할 수 있도록 사용자의 애플리케이션을 수정하거나 원래 기능 버전(예: Servlet 3.0)으로 구성된 서버에 애플리케이션을 유지하고 새 애플리케이션에 대한 새 버전으로 서버 구성을 작성하십시오.
- 새 기능이 기존 기능과 호환 가능합니까?
- 제품은 다른 버전의 Java EE에서 일부 기능의 혼합을 지원하지만, 가능하면 Java EE 스펙의 한 가지 버전 내에 있는 것이 더 단순합니다. 일부 기능은 동일한 서버로 구성되었을 때 다른 기능과 밀접하게 상호작용하며 해당 버전에 민감합니다. 예를 들면, 다수의 Java EE 기능이 CDI(Contexts and Dependency Injection)에 대한 기능과 밀접하게 연관되어 있으며 그 기능의 특정 버전으로만 작업합니다. 사용자의 구성으로 기능을 추가하는 경우, 이미 사용 중인 다른 기능의 버전을 변경해야 할 수 있습니다. 자세한 정보는 지원되는 Java EE 6 및 7 기능 조합을 참조하십시오.
- 새 기능에 다른 구성 변경이 필요합니까?
- 일부 기능에는 특정 버전의 전제조건 소프트웨어(가장 일반적으로 Java SDK)가 필요합니다. Java EE 7 기능에는 예를 들면 최소한 Java 버전 7이 필요합니다. 따라서, Java EE 7 기능을 사용자의 서버 구성에 추가하려면 Java SDK 7 이상으로 이동해야 할 수 있습니다.
제로 마이그레이션에 대한 예외
- 보안 수정사항
- 보안 관련 수정사항이 필요하지만 기존 작동을 유지하면서 안전하게 완료할 수 없는 경우에는 사용자의 애플리케이션 또는 구성을 수정해야 할 수 있습니다.
- 써드파티 API 요구사항
- 제품은 써드파티 클래스 로더 구성에서 API를 제어하지 않습니다. 그 결과, 써드파티 컴포넌트에 대한 업데이트는 이전 버전과의 호환성을 보장하지 않습니다.
- 지원 제거
- Liberty는 사용자 데이터에 영향을 미치는 제품의 파트에 대한 지원을 계속하지만, 때때로 기능 또는 지원되는 소프트웨어 제품을 철회할 필요가 있습니다. 일반적으로 사용자는 최소 2년 전에 제거 알림을 받습니다. 그러나 다른 소프트웨어 공급자가 Liberty보다 더 이전에 해당 제품에 대한 지원을 제거할 때는 알림이 그렇게 유용하지 않습니다. Liberty 설치와 함께 사용하고 있는 써드파티 제품 및 해당 라이프사이클 날짜에 대해 알아두십시오. 향후 제거 가능성이 있는 항목에 대한 정보는 제거 알림을 참조하십시오.
- 문서화되지 않은 구성 특성
- Liberty 코드 베이스는 WebSphere® Application Server Traditional 코드 베이스와 동일합니다. 따라서 Liberty 코드 베이스의 일부 구성 특성이 문서화되지 않을 수 있지만 지정되는 경우에는 Liberty의 동작에 영향을 미칠 수도 있습니다. 이러한 구성 특성은 Liberty에 적용되지 않기 때문에 Liberty에서는 지원되지 않습니다. 이러한 구성 특성은 Liberty에서 테스트되지 않았으며, 현재 또는 미래에 Liberty에서 올바르게 작동하지 않을 수도 있습니다. 이러한 특성은 제품 외부로 문서화되지 않으며 언제든지 제거될 수 있습니다.