주제

소개 페이지 맨 위

어플리케이션 상태의 효과적 관리는 분산 어플리케이션 설계의 중요한 측면입니다. 이 가이드라인에서는 J2EE 어플리케이션에서 상태 관리를 위한 몇 가지 일반 설계 고려사항 및 메커니즘의 개요를 제공합니다.

상태 관리와 관련된 설계 고려사항은 프로젝트의 구현 단계 중 지정되어야 합니다. 소프트웨어 아키텍트는 분석 & 설계 규칙 워크플로우 세부사항: 후보 구조 정의와 연관된 활동의 일부분으로 상태 관리에 대한 일반 접근 방식을 조사해야 합니다. 활동: 구조적 분석 중에, 소프트웨어 아키텍트는 어플리케이션의 확장성 및 성능 요구사항을 조사하여 어떤 상태 관리 기술을 사용해야 어플리케이션이 성능 목적을 충족시킬 수 있는지 결정해야 합니다. 어플리케이션의 설계가 구현 단계의 과정 중 세분화되면, 아키텍트를 정의할 필요가 있습니다. 활동: 설계 메커니즘 식별에서 어플리케이션으로 상태 정보를 관리하기 위한 J2EE 특정 설계 및 구현 메커니즘.

개념: J2EE 전개 형상에서 설명한 대로, J2EE 어플리케이션은 일대다 실제 층(시스템)에서 여러 논리적 계층으로 구성될 수 있습니다. 상태 관리의 간략한 기술적 개요 이후에, 이 가이드라인의 나머지 섹션에서는 여러 어플리케이션 층에서 사용될 수 있는 다른 상태 관리 설계 및 구현 메커니즘을 설명합니다.

소프트웨어 아키텍트는 결과물: 소프트웨어 구조 문서의 일부분으로 선택된 메커니즘을 문서화해야 하며, 프로젝트 특정 설계 가이드라인의 일부분으로 이 메커니즘을 사용하는 가이드라인을 제공해야 함을 참고하십시오.

기술적 개요 페이지 맨 위

하나의 양식 또는 다른 양식에서 인터넷과 상호 작용하는 분산 어플리케이션을 빌드하는 경향이 증가합니다. 인터넷 기반이 stateless 속성에 의해서이긴 하지만, 자주 임의의 종류의 비즈니스 어플리케이션을 빌드하기 위해 상태를 관리할 필요가 있습니다. 사용자가 페이지 a에서 페이지 b로의 링크를 누르는 인터넷 어플리케이션을 고려하십시오. 페이지 b의 요청을 처리하는 어플리케이션은 페이지 a를 처리하는 데 사용하는 정보에 더 이상 액세스할 필요가 없습니다. 이 작동은 정적 웹 페이지용으로 승인 가능할 수 있지만, 대부분의 비즈니스 어플리케이션은 이전 처리에 대한 정보를 필요로 합니다. 이것은 J2EE에서 제공하는 상태 관리 메커니즘이 제공되는 곳입니다.

임시 상태 대 지속적 상태 페이지 맨 위

상태 관리 가이드라인으로 인도되기 전에 상태 정보 유형 사이를 차별화하는 것이 중요합니다. 상태 정보는 두 개의 카테고리로 나뉠 수 있습니다(임시(어플리케이션이 활성 상태인 경우에만 존재) 및 지속적(어플리케이션이 종료된 후에 존재). 

임시 상태 정보는 이 정보를 보유하는 엔터티가 활성 상태인 동안 존재합니다. 예를 들어, 상태 정보가 보통의 Java 클래스에 있는 필드로 저장되었습니다. 어떤 이유로 이 클래스를 호스트하는 컨테이너가 종료된 경우, 백업 서버에서와 같이 다른 어딘가에서 데이터가 복제되는 경우를 제외하고는 상태 정보가 유실됩니다.

상태 정보를 유지보수하기 위해 사용되는 데이터 저장소가 존재하는 한 지속적 상태가 존재합니다. 지속적 상태 정보는 보통 파일이나 데이터베이스에 저장되며 어플리케이션에서 필요할 때 로드됩니다. 지속적 상태 정보에 대한 변경사항은 다시 데이터베이스에 쓰여져야 합니다. 지속적 데이터 저장소의 무결성 및 복구성 측면이 어플리케이션에서 액세스 중인 데이터와 일치해야 합니다. 지속적 상태의 예는 관계형 데이터베이스와 같은 데이터 저장소에 저장된 정보입니다.

세션 상태 페이지 맨 위

웹 클라이언트는 장바구니의 항목과 같이 클라이언트 특정 정보를 보유하면서 페이지 간을 탐색하며 다중 브라우저 요청을 작성하는 기능을 자주 요구합니다. 웹 어플리케이션은 세션 ID를 작성하고 상태 데이터를 이 세션 ID와 연관시켜 이를 처리합니다. 세션 ID 및 연관된 상태는 세션 상태로 나타냅니다.

세션 상태는 짧은 기간 동안(일보다는 분 또는 시간) 웹 어플리케이션과 특정 클라이언트의 상호 작용에 연관되는 데이터입니다. 그러므로 세션 상태는 자원 소비를 피하기 위해 일반적으로 약간의 시간 종료 기간 이후에 삭제되는 짧은 수명의 데이터입니다.

나중 섹션에서 설명한 대로 세션 상태는 클라이언트나 서버에서 저장될 수 있습니다. J2EE 플랫폼은 웹 기반 어플리케이션의 중요성으로 인해 세션 상태 관리로 특별히 조정된 메커니즘을 제공합니다.

기본 지속성 메커니즘 페이지 맨 위

다음은 상태를 저장하기 위해 웹 어플리케이션에서 사용하는 일반적인 메커니즘입니다.

쿠키페이지 맨 위

쿠키는 웹 기반 클라이언트에 저장되는 작은 텍스트 파일입니다. 서버는 클라이언트에 쿠키를 저장할 수 있습니다. 차후 클라이언트 요청은 쿠키를 서버로 전송하며, 쿠키에 저장된 상태 데이터에 대한 서버 액세스를 제공합니다.

쿠키에 대한 몇 가지 문제가 있습니다.

  • 많은 사용자는 쿠키가 보안 및/또는 기밀성을 손상시킨다고 믿으므로 쿠기를 사용 불가능하게 합니다.
  • 쿠키 머리글 크기에는 제한이 있고 이것은 데이터가 저장되는 양을 제한합니다.
  • WAP(Wireless Access Protocol)과 같은 일부 프로토콜은 쿠키를 지원하지 않습니다.
  • 클라이언트가 다른 위치(예: 다른 시스템)에서 로그인하는 경우 다른 위치에 저장된 쿠키는 사용할 수 없습니다.
  • 상태 데이터는 문자열 값으로 표시할 수 있어야 합니다.

URL 다시 쓰기 페이지 맨 위

URL 다시 쓰기는 각 페이지에서 참조되는 URL로 세션 상태를 임베드하는 메커니즘입니다. 웹 서버가 클라이언트로 전달되는 페이지를 생성할 때, 세션 상태를 페이지의 URL로 인코드합니다. 그런 다음, 사용자가 URL을 누르면 URL에 저장된 상태 데이터가 다시 서버로 전송되며, 세션 컨텍스트를 다시 수립하게 합니다. 유사한 메커니즘이 숨겨진 HTML 필드를 사용합니다. 이러한 메커니즘에는 다음과 같은 문제가 있습니다.

  • 제공된 세션의 모든 페이지는 서버에서 처리되어야 하며, 그렇지 않은 경우 서버는 세션의 트랙을 유실할 수 있습니다.
  • 클라이언트가 브라우저를 종료하거나 또는 책갈피를 사용하거나 입력하여 특정 URL에 링크하면 상태가 유지되지 않습니다.
  • 쿠키에서와 같이, 클라이언트가 다른 위치에서 로그인하면 상태 데이터를 사용할 수 없습니다.
  • 쿠키에서와 같이, 상태 데이터를 문자열 값으로 표시할 수 있어야 합니다.

텍스트 파일페이지 맨 위

텍스트 파일은 지속적 상태 정보를 유지보수하는 가장 간단한 메소드 중 하나입니다. 초기화시, 초기 상태 값을 설정하기 위해 텍스트 파일을 읽습니다. 상태가 변경될 때마다, 상태를 저장하려면 파일을 다시 써야 합니다. 텍스트 파일에 어플리케이션 상태를 유지보수하는 것의 단점은 다음과 같습니다.

  • 어플리케이션 상태 변수가 갱신되고 텍스트 파일에 다시 쓰여지는 동안 글로벌 데이터에 대한 액세스를 방지하기 위해 어플리케이션이 어플리케이션 객체를 잠궈야 하므로 어플리케이션의 확장성은 불리하게 영향을 미칩니다.
  • 대부분의 경우, 데이터 갱신은 전체 파일을 다시 쓰도록 요구합니다.
  • 텍스트 파일이 오류 발생시 항상 복구성을 제공하는 것은 아닙니다.

XML 페이지 맨 위

XML 파일에서 지속적 상태 정보를 유지보수하는 것은 텍스트 파일에서의 단계입니다. 텍스트 파일과 반대로 XML 파일에서 어플리케이션 상태를 유지보수하는 이점은 다음과 같습니다.

  • XML 파일은 텍스트 파일에 없는 구조를 제공합니다.
  • XML 파일은 표준 API를 사용하여 구문 분석될 수 있습니다.
  • 일반적으로 XML 파일이 더 이식성이 뛰어납니다.

데이터베이스 페이지 맨 위

데이터베이스에서 지속적 상태 정보를 유지보수하는 것은 최대 복구성을 제공합니다. 데이터베이스에서 어플리케이션 상태를 유지보수하는 이점은 다음과 같습니다.

  • 테이블의 설계는 구조를 제공합니다.
  • 어플리케이션 변수 갱신시 전체 어플리케이션 상태를 다시 작성할 필요는 없습니다. 갱신된 정보만 다시 작성하면 됩니다.
  • 프로덕션 데이터베이스의 복구로 어플리케이션 상태 복구를 조정하여 일관성을 유지보수할 수 있습니다.
  • 신뢰성을 높이기 위해 데이터베이스 서버를 클러스터링할 수 있습니다.

데이터베이스는 JDBC(Java Database Connectivity) API를 사용하여 액세스될 있습니다. 또한 JDBC는 스프레드시트 및 텍스트 파일을 포함하여 테이블로 된 기타 데이터 소스에 액세스하는 데 사용될 수 있습니다.

J2EE 특정 메커니즘 페이지 맨 위

J2EE 플랫폼은 상태 관리를 위한 특정 메커니즘을 제공합니다. 이것은 지금까지 설명한 하나 이상의 기본 메커니즘을 사용하도록 구성될 수 있는 상위 레벨 메커니즘입니다.

Servlet 컨텍스트 페이지 맨 위

Servlet은 다중 클라이언트 및 클라이언트 세션에 적용할 수 있는 데이터를 저장하기 위해 servlet 컨텍스트를 사용할 수 있습니다.

servlet 컨텍스트에 저장된 데이터는 본질적으로 J2EE 어플리케이션의 글로벌 변수입니다. 결과적으로, 어플리케이션 상태의 사용은 어플리케이션 설계에 중요한 영향을 미칠 수 있습니다. 소프트웨어 아키텍트는 servlet 컨텍스트가 적절한지 여부를 결정할 때 활동: 설계 메커니즘 식별을 수행하는 동안 다음 항목을 고려해야 합니다.

  • Servlet 컨텍스트는 단일 프로세스에서 유지보수될 수 있으므로, 다중 서버(클러스터)에서 공유될 수 없습니다. 이것이 어플리케이션의 확장 필요성과 일치하지 않는 경우, 아키텍트는 상태를 세션 상태로 저장하는 것을 고려해야 합니다.   
  • Servlet 컨텍스트는 프로세스 메모리의 일부이므로, 프로세스 종료시 보통 유지보수되지 않습니다.
  • 다중 스레드는 글로벌 데이터에 액세스할 수 있습니다. 글로벌 데이터의 잠금 및 동기화는 어플리케이션의 확장성에 영향을 미칠 수 있습니다.

HTTP 세션 객체 페이지 맨 위

Servlet 및 JSP는 HTTP 세션 객체에서 특정 클라이언트 세션과 연관된 데이터를 저장할 수 있습니다. 세션 객체에 데이터를 저장하는 경우, 세션 데이터가 여러 서버에서 사용 가능하게 되는 방식에 사안이 있을 수 있습니다. 일부 벤더는 실제로 "서버 유사 관계"로 알려진 것과 같은 서버에 클라이언트의 요청을 라우팅하는 기능을 제공합니다.

HTTP 세션 객체는 클라이언트 요청 처리 중 서버에서 사용 가능하지만, 요청 사이에 서버에서 저장되거나 저장되지 않을 수 있습니다. 클라이언트의 쿠키, 파일 또는 서버의 데이터베이스에 세션 상태를 저장하는 것을 포함하여 이전에 설명한 기본 지속성 메커니즘을 사용하도록 서버를 구성할 수 있습니다. 또한 서버에 걸쳐 메모리에 세션 데이터를 복제하는 기능을 제공할 수도 있습니다.

메커니즘은 서버를 구성하여 선택되며 JSP 및 Servlet은 Servlet 스펙에서 지정된 API를 사용하여 세션 객체에 액세스하여 선택된 메커니즘과 별개로 코딩됩니다.

엔터프라이즈 JavaBean 페이지 맨 위

엔터프라이즈 JavaBean은 데이터베이스 및 파일과 같이 이전에 설명한 하위 레벨 메커니즘에 근거하여 상태를 저장하는 상위 레벨 메커니즘을 포함합니다. Stateful 세션 Bean은 특정 클라이언트 세션과 연관된 데이터를 저장하기 위해 사용되지만, 엔티티 Bean은 장기간 데이터를 저장하기 위해 사용됩니다. EJB에 의해 저장되는 상태의 설명은 가이드라인: EJB를 참조하십시오.

세션 상태 설계페이지 맨 위

웹 클라이언트는 장바구니의 항목과 같이 클라이언트 특정 정보를 보유하면서 페이지 간을 탐색하며 다중 브라우저 요청을 작성하는 기능을 자주 요구합니다. 웹 어플리케이션은 세션 ID를 작성하고 상태 데이터를 이 세션 ID와 연관시켜 이를 처리합니다.

세션 ID 자체는 하나 또는 두 개의 메커니즘에 의해 클라이언트에 저장됩니다.

  • 쿠키 - 클라이언트 브라우저는 서버가 세션 상태를 다시 설정하도록 각 요청시 이 쿠키를 서버로 전송합니다.
  • URL 다시 쓰기 - 서버에서 클라이언트로 전달되는 페이지의 URL은 세션 ID를 인코드합니다. 사용자가 이러한 URL을 누르면, 세션 ID는 서버로 전송되며, 서버가 세션 상태를 다시 설정할 수 있습니다.

선택된 접근 방식을 사용하도록 서버를 구성합니다. Servlet 및 JSP는 구성된 메소드와 무관하게 작업하도록 코딩되어야 합니다. 특히 HttpServletResponse.encodeURL() 메소드를 사용하여 모든 URL을 인코드하십시오. 이 메소드는 URL 다시 쓰기가 사용 가능한지 검사하며, 그런 경우 인코딩을 수행합니다.

세션 ID와 연관된 데이터는 HTTP 세션 객체에 저장될 수 있으며, 여기서 JSP 및 servlet에 의해 액세스되거나 세션 Bean에서 액세스될 수 있습니다.

세션 ID 및 연관된 데이터가 시간 종료로 설정되어야 장시간 사용되지 않은 세션 데이터가 무한히 자원을 소비하지 않습니다. 아키텍트는 적절한 시간 종료 기간을 선택해야 합니다.

올바른 메커니즘 선택페이지 맨 위

아키텍트는 단순성 및 성능의 이유로 클라이언트에서 세션 상태를 저장하는 것을 고려해야 합니다. 상태가 클라이언트에서 관리되고 저장될 때, 서버는 상태 정보를 저장하기 위해 자원을 소비하거나 일관성을 확인할 필요가 없습니다. 클라이언트에 상태 정보를 저장할 때의 불리한 점은 필요할 때마다 정보가 서버에 전송되어야 하므로 네트워크 지연 관련 문제가 발생할 수 있다는 것입니다. 또한 클라이언트에게 노출하지 않으려는 세션 상태 데이터가 있는 경우 보안 고려사항이 있을 수 있습니다. 이 경우, 암호화가 선택사항일 수 있습니다.

어플리케이션이 많은 양의 세션 상태를 가지고 있는 경우, 보통 크기가 작고 입력 제한사항이 있는 서버에 이 상태를 저장하도록 선호합니다.

보통 프리젠테이션 사안과 관련된 세션 상태는 HTTP 세션 객체에 저장되어야 하지만, stateful 세션 Bean은 비즈니스 논리를 제대로 구현하는 데 필요한 상태를 포함해야 합니다. 상태 데이터의 중복은 피해야 합니다. 대신 중복된 상태 데이터를 HTTP 세션으로 이동시키고, 필요할 때 세션 Bean 메소드 호출시 이 데이터를 매개변수로 세션 Bean으로 전달하십시오.

서버에 저장된 세션 데이터가 서버 노드의 장애에 견딜 수 있어야 하는 경우 세션 데이터 지속하거나 복제하기 위해 메커니즘을 사용하는 것을 고려하십시오.

장시간 활동 상태 설계페이지 맨 위

세션 데이터는 시간 종료되는 수명이 짧은 클라이언트 데이터용입니다. 또한 훨씬 오랜 기간 동안 존재하는 데이터가 필요할 수 있습니다.

이러한 데이터의 올바른 메커니즘은 저장 중인 데이터의 특성에 의해 좌우됩니다. 쿠키, 텍스트 파일, XML 파일 및 데이터베이스는 모두 선택사항입니다. 데이터베이스 액세스의 경우, 엔티티 Bean은 보통 최적의 선택입니다. 세부사항은 가이드라인: 엔티티 Bean을 참조하십시오.



Rational Unified Process   2003.06.15