개념: 웹 아키텍처 패턴
웹 아키텍처 패턴은 재사용할 수 있는 공통 패턴인 응용프로그램 또는 응용프로그램 인터페이스의 일부를 나타냅니다.
관계
기본 설명

소개

가장 공통적인 세 가지 패턴은 다음과 같습니다.

Thin 웹 클라이언트 - 클라이언트의 구성에 대한 제어가 거의 없는 인터넷 기반 응용프로그램에 대부분 사용됩니다. 클라이언트에는 표준 웹 브라우저(양식 사용 가능)만 필요합니다. 모든 비즈니스 로직은 서버에서 실행됩니다.

Thick 웹 클라이언트 - 비즈니스 로직의 구조적으로 중요한 부분이 클라이언트 시스템에서 실행됩니다. 일반적으로 클라이언트는 동적 HTML, Java 애플릿 또는 ActiveX 제어를 사용하여 비즈니스 로직을 실행합니다. 서버와의 통신은 계속 HTTP를 통해 수행됩니다.

웹 전달 - 클라이언트 및 서버의 통신에는 HTTP 프로토콜이 사용되고 IIOP 및 DCOM과 같은 다른 프로토콜도 사용되어 분산 오브젝트 시스템을 지원합니다. 웹 브라우저는 기본적으로 분산 오브젝트 시스템의 전달 및 컨테이너 장치로 작동합니다.

이 목록은 특히 매년 기술 혁명이 발생하는 산업에 대해서는 완벽하지 않습니다. 이 목록은 상위 레벨에서 웹 응용프로그램의 가장 공통적인 아키텍처 패턴을 나타냅니다. 임의의 패턴을 사용하여 단일 아키텍처에 여러 패턴을 적용할 수 있습니다.

Thin 웹 클라이언트

Thin 웹 클라이언트 아키텍처 패턴은 가장 작은 클라이언트 구성만 보장할 수 있는 인터넷 기반 응용프로그램에 유용합니다. 클라이언트 브라우저의 페이지 요청을 수행하는 동안 모든 비즈니스 로직은 서버에서 실행됩니다.

적용 가능성

이 패턴은 인터넷 기반 웹 응용프로그램 또는 클라이언트에 최소 계산 기능이 있거나 구성에 대한 제어가 없는 환경에 가장 적합합니다.

알려진 용도

대부분의 전자상거래 인터넷 응용프로그램은 이 패턴을 사용합니다. 고객 부문을 제거하면 클라이언트 기능이 충분하지 않기 때문에 비즈니스에 적합하지 않기 때문입니다. 일반적인 전자상거래 응용프로그램은 가능한 최대 고객 풀에 접근하려고 합니다. 어차피 Commodore Amiga 사용자도 고객이라는 면에서 Windows NT 사용자와 다름없습니다.

구조

Thin 웹 클라이언트 아키텍처 패턴의 주요 컴포넌트는 서버에 있습니다. 여러가지 면에서 이 아키텍처는 최소 웹 응용프로그램 아키텍처를 나타냅니다. 주요 컴포넌트는 다음과 같습니다.

클라이언트 브라우저 - 표준 양식을 사용할 수 있는 임의의 HTML 브라우저. 브라우저는 일반화된 사용자 인터페이스 장치로 작동합니다. Thin 웹 클라이언트 아키텍처에서 사용될 때 이 아키텍처가 제공하는 단 하나의 다른 서비스는 쿠키를 허용하고 리턴하는 기능입니다. 응용프로그램 사용자는 브라우저를 사용하여 웹 페이지(HTML 또는 서버)를 요청합니다. 리턴된 페이지에는 완전히 형식화된 사용자 인터페이스(텍스트 및 입력 제어)가 들어 있고, 이 페이지는 브라우저에 의해 클라이언트 디스플레이에 표시됩니다. 시스템과의 모든 사용자 상호작용은 브라우저를 통해 일어납니다.

웹 서버 - 모든 클라이언트 브라우저의 기본 액세스 위치. Thin 웹 클라이언트 아키텍처의 클라이언트 브라우저는 웹 페이지(정적 HTML 또는 서버 페이지)의 요청을 허용하는 웹 서버를 통해서만 시스템에 액세스합니다. 요청에 따라 웹 서버는 일부 서버측 처리를 시작할 수 있습니다. 서버에서 스크립트 페이지, CGI, ISAPI 또는 NSAPI 모듈에 대한 페이지 요청이면 웹 서버는 해당 스크립트 해석기 또는 실행 가능 모듈에 처리를 위임합니다. 어떤 경우든 결과는 HTML 브라우저에서 표시하기에 적합한 HTML 형식화된 페이지로 리턴됩니다.

HTTP 연결 -  클라이언트 브라우저 및 웹 서버 간에 가장 공통적으로 사용되는 프로토콜. 이 아키텍처 요소는 클라이언트와 서버 간의 비연결 통신 유형을 나타냅니다. 클라이언트나 서버가 서로에게 정보를 보낼 때마다 클라이언트와 서버 간에 별도의 새 연결이 설정됩니다. HTTP 연결의 변형은 SSL(Secure Sockets Layer)을 통한 보안 HTTP 연결입니다. 이 연결 유형은 공용/개인용 암호화 주요 기술을 사용하여 클라이언트와 서버 간에 전송되는 정보를 암호화합니다.

HTML 페이지 - 서버측 처리를 자세히 검토하지 않으며 사용자 인터페이스 및 컨텐츠 정보가 있는 웹 페이지. 일반적으로 이러한 페이지에는 지침이나 도움말 정보 또는 HTML 입력 양식과 같은 설명 텍스트가 들어 있습니다. 웹 서버가 HTML 페이지의 요청을 받으면 서버는 단순히 파일을 검색하여 필터링 없이 다시 요청 클라이언트로 보냅니다.

서버 페이지 - 서버측 처리의 일부 양식을 자세히 검토하는 웹 페이지. 일반적으로 이러한 페이지는 응용프로그램 서버의 필터 또는 실행 가능 모듈(ISAPI 또는 NSAPI)에서 처리되는 스크립트 페이지(Active Server Page, Java Server Page, Cold Fusion 페이지)처럼 서버에서 구현됩니다. 이러한 페이지는 비즈니스 로직, 컴포넌트, 데이터베이스, 레거시 시스템 및 가맹 계정(merchant account) 시스템을 포함하여 모든 서버측 자원에 액세스할 수 있습니다.

응용프로그램 서버 - 서버측 비즈니스 로직을 실행하는 기본 엔진. 응용프로그램 서버는 서버 페이지에서 코드를 실행하며 웹 서버와 같은 시스템에 있을 수 있고 웹 서버와 동일한 프로세스 공간에서 실행될 수도 있습니다. 응용프로그램 서버는 비즈니스 로직의 실행에만 관련되고 웹 서버와는 전혀 다른 기술을 사용할 수 있으므로 논리적으로 별도의 아키텍처 요소입니다.

아래 그림은 Thin 웹 클라이언트 아키텍처에 대한 논리 보기의 다이어그램을 표시합니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

최소 Thin 웹 클라이언트 아키텍처

최소 Thin 웹 클라이언트 아키텍처에는 일반적으로 웹 응용프로그램에 있는 공통 선택적 컴포넌트(특히 데이터베이스)가 제외되어 있습니다. 대부분의 웹 응용프로그램은 데이터베이스를 사용하여 비즈니스 데이터를 지속적으로 작성합니다. 어떤 경우에는 데이터베이스는 페이지 자체를 저장하는 데도 사용할 수 있습니다(그러나 이 데이터베이스 사용은 다른 아키텍처 패턴을 나타냄). 웹 응용프로그램은 다양한 기술을 사용하여 비즈니스 데이터를 지속적으로 만들 수 있으므로 아키텍처 컴포넌트는 보다 일반적 용어인 지속성으로 레이블됩니다. 지속성 컴포넌트에는 TPM(Transaction Processing Monitor)을 사용할 수도 있습니다.

시스템에 데이터베이스를 연결하는 가장 간단한 방법은 서버 페이지의 스크립트를 지속성 컴포넌트에 직접 액세스하도록 하는 것입니다. 이 직접 액세스에서도 RDO, ADO, ODBC, JDBC, DBLib 등의 표준 데이터 액세스 라이브러리를 사용하여 힘든 작업을 수행합니다. 이 경우 서버 페이지는 데이터베이스 스키마를 인식할 수 있습니다. 관계형 데이터베이스 시스템은 필요한 SQL 문을 구성하고 실행하여 데이터베이스의 데이터에 대한 액세스를 얻습니다. 더 작고 덜 복잡한 웹 응용프로그램에서는 이 방법으로 충분할 수 있습니다. 그러나 더 크고 보다 견고한 시스템의 경우에는 전체 비즈니스 오브젝트 계층을 사용하는 것이 좋습니다.

비즈니스 오브젝트 컴포넌트는 비즈니스 로직을 캡슐화합니다. 이 컴포넌트는 대개 응용프로그램 서버에서 컴파일되고 실행됩니다. 다른 웹 또는 클라이언트 서버 시스템이 동일한 컴포넌트를 사용하여 동일한 비즈니스 로직을 호출할 수 있다는 점은 비즈니스 오브젝트 아키텍처 컴포넌트의 이점 중 하나입니다. 예를 들어 인터넷 기반 상점 프론트는 모든 고객 활동에 서버 페이지 및 Thin 웹 클라이언트 아키텍처 패턴을 사용할 수 있지만, 청구 부서는 데이터 및 비즈니스 로직에 대한 보다 복잡한 액세스를 필요로 하며 웹 기반 시스템보다 클라이언트 서버 시스템을 사용하는 것이 좋습니다. 청구 부서의 시스템은 웹 상점과 같은 응용 프로그램 서버에서 동일한 비즈니스 컴포넌트를 사용하지만 보다 복잡한 고유의 클라이언트 소프트웨어를 사용할 수 있습니다.

관계형 데이터베이스는 정통 비즈니스에서 가장 공통적인 데이터베이스 유형이므로 추가 아키텍처 컴포넌트는 대개 응용프로그램 서버와 데이터베이스 사이에 있습니다. 이 아키텍처 컴포넌트는 오브젝트와 관계형 데이터베이스 간에 맵핑 서비스를 제공합니다. 이 맵핑 계층 자체는 다양한 방법으로 구현할 수 있습니다. 이 컴포넌트에 대한 자세한 설명은 이 페이지의 범위가 아닙니다.

이 아키텍처 패턴에 일반적으로 추가되는 기타 옵션은 레거시 시스템 및 전자상거래 응용프로그램의 가맹 계정 시스템의 통합입니다. 두 시스템 모두 비즈니스 오브젝트를 통해 또는 정규 비즈니스 오브젝트 컴포넌트 없이 해당 시스템의 응용프로그램 서버를 통해 액세스합니다. 레거시 시스템은 회계 시스템 또는 제조 스케줄링 시스템을 나타낼 수 있습니다. 가맹 계정 시스템을 사용하여 인터넷 웹 응용프로그램에서 신용카드 지불을 허용하고 처리할 수 있습니다. 온라인 시장에 진출하려고 하는 소규모 비즈니스에 사용할 수 있는 다양한 가맹 계정 시스템이 있습니다. 대규모 비즈니스의 경우 이 컴포넌트는 신용카드 요청을 처리할 수 있는 기존 시스템의 인터페이스일 수 있습니다.

이러한 선택적 컴포넌트가 배치되면 Thin 웹 클라이언트 아키텍처 패턴의 논리 보기는 더욱 완전해집니다. 논리 보기가 아래 그림에 표시됩니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

Thin 웹 클라이언트 논리 보기

웹 응용프로그램의 많은 서버 컴포넌트가 웹 기반이 아닌 응용프로그램에서도 있을 수 있습니다. 웹 응용프로그램 백엔드의 디자인 및 아키텍처는 메인프레임 또는 클라이언트/서버 시스템의 디자인과 같습니다. 웹 응용프로그램은 다른 시스템과 동일한 이유로 데이터베이스 및 TPM(Transaction Processing Monitor)을 사용합니다. EJB(Enterprise Java Bean) 및 MTS(Microsoft's Transaction Server)는 웹 응용프로그램을 위해 도입된 새 도구 및 기술이지만 다른 응용프로그램 아키텍처에서도 마찬가지로 사용할 수 있습니다.

웹 응용프로그램 서버측 컴포넌트의 아키텍처 및 디자인은 클라이언트 서버 시스템의 아키텍처 및 디자인과 동일하게 처리됩니다. 이 아키텍처 패턴은 웹 응용프로그램에 특정한 웹 및 컴포넌트에 초점을 맞추므로 가능한 백엔드 서버 아키텍처에 대한 자세한 검토는 이 패턴의 범위를 벗어납니다.

역학

이 아키텍처 패턴의 기본 역학은 클라이언트에 의한 웹 페이지 요청에 대한 응답으로 비즈니스 로직만 실행되는 것입니다. 클라이언트는 HTTP 프로토콜을 사용하여 웹 서버에서 웹 페이지를 요청하여 시스템을 사용합니다. 요청된 페이지가 웹 서버 파일 시스템의 HTML 파일이면 웹 서버는 단순히 파일을 페치하여 다시 요청 클라이언트로 보냅니다.

스크립트 페이지(클라이언트로 리턴되려면 먼저 처리해야 하는 해석 가능 코드가 있는 페이지)이면 웹 서버는 응용프로그램 서버에 이 조치를 위임합니다. 응용프로그램 서버는 페이지의 스크립트를 해석하고 데이터베이스, 전자 우편 서비스, 레거시 시스템 등의 서버측 자원과 상호작용합니다(지시된 경우). 스크립트 코드는 응용프로그램 및 웹 서버를 통해 페이지 요청을 포함하는 특수 정보에 액세스할 수 있습니다. 이 정보에는 사용자가 입력한 양식 필드 값 및 페이지 요청에 추가된 매개변수가 포함됩니다. 최종 결과는 다시 클라이언트로 보낼 수 있는 제대로 형식화된 HTML 페이지입니다.

페이지는 ISAPI 또는 NSAPI DLL과 같은 실행 가능 모듈이 될 수도 있습니다. DLL 또는 동적 링크 라이브러리는 런타임 시 응용프로그램 서버에 의해 로드되고 실행될 수 있는 컴파일된 라이브러리입니다. 모듈은 스크립트 페이지에 있는 것과 동일한 페이지 요청(양식 필드 값 및 매개변수)에 대한 세부사항에 액세스할 수 있습니다.

이 패턴 동적 동작의 요점은 비즈니스 로직이 페이지 요청을 처리하는 동안에만 호출된다는 것입니다. 페이지 요청이 충족되면 결과는 다시 요청 클라이언트로 전송되고 클라이언트 및 서버 간의 연결이 종료됩니다. 요청이 충족된 후에도 비즈니스 프로세스가 지속될 수 있지만 이는 일반적 경우가 아닙니다.

결과

이 아키텍처 유형은 사용자가 기대하는 허용 가능 응답 시간 내(및 클라이언트 브라우저가 허용하는 제한시간 값 내)에 완료할 수 있는 서버 응답을 가지는 응용프로그램에 가장 적합합니다. 이는 대개 몇 초 이내입니다. 응용프로그램에서 사용자가 장기간 지속되는 비즈니스 프로세스를 시작하고 모니터할 수 있어야 하는 경우 이 유형은 가장 적절한 아키텍처 패턴이 아닐 수 있습니다. 그러나 클라이언트가 장기 실행 프로세스를 모니터할 수 있도록 푸시(push) 기술을 사용할 수 있습니다. 대부분의 경우 푸시(push) 기술은 서버의 정기적 폴링만 사용합니다.

이 아키텍처 패턴의 다른 주요 결과는 복잡한 사용자 인터페이스의 제한된 기능입니다. 브라우저는 전체 사용자 인터페이스 전달 메커니즘으로 작동하므로 모든 사용자 인터페이스 위지트(widget) 및 제어는 브라우저를 통해 사용 가능해야 합니다. 가장 공통적인 브라우저 및 HTML 스펙에서 이들은 일부 텍스트 입력 필드 및 단추로 제한됩니다. 그러나 지나친 사용자 인터페이스 제한이 도움이 되는지에 대해서는 논란의 여지가 있습니다. 단순한 사용자 인터페이스 오퍼링은 개발 팀이 보다 단순한 사용자 인터페이스로 충분한데도 "멋지고 근사한" 인터페이스를 개발하는 데 노력을 사용하지 못하게 합니다.

Thick 웹 클라이언트

Thick 웹 클라이언트 아키텍처 패턴은 ActiveX 제어 및 Java 애플릿과 같은 클라이언트측 스크립트 및 사용자 정의 오브젝트를 사용하여 Thin 웹 클라이언트 패턴을 확장합니다. Thick 웹 클라이언트 패턴은 이름에서 알 수 있듯이 클라이언트가 시스템의 일부 비즈니스 로직을 실제로 실행할 수 있으며 단순한 일반 사용자 인터페이스 컨테이너 이상의 기능을 수행합니다.

적용 가능성

Thick 웹 클라이언트 아키텍처 패턴은 특정 클라이언트 구성 및 브라우저 버전이 가정되고 복잡한 사용자 인터페이스가 권장되며 클라이언트에서 일정 양의 비즈니스 로직을 실행할 수도 있는 웹 응용프로그램에 가장 적합합니다. Thin 웹 클라이언트와 Thick 웹 클라이언트 패턴 간 차이의 대부분은 시스템 비즈니스 로직 실행 시 브라우저가 수행하는 역할에 있습니다.

Thick 웹 클라이언트를 사용하는 가장 큰 동기 두 가지는 확장된 사용자 인터페이스 기능 및 비즈니스 로직의 클라이언트 실행입니다. 복잡한 사용자 인터페이스를 사용하여 3차원 모델을 표시하고 수정하거나 재무 그래프에 애니메이션 효과를 줄 수 있습니다. 일부 인스턴스에서는 ActiveX 제어를 사용하여 클라이언트측 모니터링 장비와 통신할 수 있습니다. 예를 들어 혈압, 혈당 및 기타 활력 징후를 측정할 수 있는 의료 장비는 멀리 있는 환자를 매일 모니터하고 일주일에 두 번 왕진하여 비용을 절감할 수 있어야 하는 기관에서 사용할 수 있습니다.

어떤 경우에는 비즈니스 로직을 클라이언트에서만 실행할 수 있습니다. 이 경우 프로세스 처리에 필요한 모든 데이터가 클라이언트에서 사용 가능해야 합니다. 로직은 입력된 데이터의 유효성 검증과 같이 단순할 수 있습니다. 날짜의 정확도를 확인하거나 다른 날짜와 비교할 수 있습니다(예: 생년월일은 병원에 처음 입원한 날짜보다 이전이어야 함). 시스템의 비즈니스 규칙에 따라 일부 필드는 현재 입력된 값을 기준으로 사용하거나 사용하지 않을 수 있습니다.

알려진 용도

클라이언트측 스크립트, 애플릿, 제어 및 플러그인은 인터넷에서 확장된 사용자 인터페이스 형식으로 가장 흔히 사용됩니다. Java 스크립트는 HTML 페이지에서 단추 또는 메뉴 항목의 색상 또는 이미지를 변경하는 데 사용되기도 합니다. Java 애플릿 및 ActiveX 제어는 복잡한 계층 구조 트리 보기 제어를 작성하는 데 사용되기도 합니다.

Shockwave ActiveX 제어 및 플러그인은 오늘날 인터넷에서 사용되는 가장 공통적인 사용자 인터페이스 컴포넌트 중 하나입니다. 이 컴포넌트는 대화식 애니메이션을 사용 가능하게 하고 멋진 그래픽으로 인터넷 사이트를 꾸미는 데 사용되지만 시뮬레이션을 표시하고 스포츠 행사를 모니터하는 데도 사용되고 있습니다.

Microsoft의 에이전트 제어는 여러 인터넷 사이트에서 음성 명령을 허용하고 사용자의 웹 사이트 탐색을 지원하는 브라우저에서 조치를 실행하는 데 사용됩니다.

의료 소프트웨어 회사가 환자 기록 및 청구를 관리하는 웹 기반 인트라넷 응용프로그램을 개발했습니다. 웹 기반 사용자 인터페이스는 클라이언트측 스크립트를 많이 사용하여 데이터 유효성 검증을 수행하고 사용자의 사이트 탐색을 지원합니다. 스크립트와 함께 응용프로그램은 여러 ActiveX 제어를 사용하여 정보의 기본 인코딩 기법으로 사용되는 XML 컨텐츠를 관리합니다.

구조

Thin 웹 클라이언트 패턴에서와 같이 클라이언트 및 서버 간 모든 통신은 HTTP로 수행됩니다. HTTP는 "비연결" 유형 프로토콜이므로 클라이언트와 서버 간에는 대부분 열린 연결이 없습니다. 페이지 요청 중에만 클라이언트가 정보를 보냅니다. 즉 클라이언트측 스크립트, ActiveX 제어 및 Java 애플릿은 클라이언트의 오브젝트에 대해서만 상호작용하도록 제한됩니다.

Thick 웹 클라이언트 패턴은 ActiveX 제어 또는 Java 애플릿과 같은 특정 브라우저 기능을 사용하여 클라이언트에서 비즈니스 로직을 실행합니다. ActiveX 제어는 HTTP를 통해 클라이언트에 다운로드되고 브라우저에서 호출될 수 있는 컴파일된 2진 실행 가능 프로그램입니다. ActiveX 제어는 기본적으로 COM 오브젝트이므로 클라이언트측 자원에 대한 전체 권한이 있습니다. 이 컴포넌트는 브라우저 및 클라이언트 시스템 자체와 모두 상호작용할 수 있습니다. 이런 이유로 ActiveX 제어, 특히 인터넷의 제어는 일반적으로 신뢰할 수 있는 써드 파티에 의해 "인증"됩니다.

가장 최신 버전의 일반 HTML 브라우저도 클라이언트측 스크립트를 허용합니다. HTML 페이지는 Java Script 또는 VB Script로 작성된 스크립트와 함께 임베드될 수 있습니다. 이 스크립트 기능으로 브라우저 자체에서 시스템의 비즈니스 로직 파트가 될 수 있는 코드를 실행(또는 해석)할 수 있습니다. 클라이언트 스크립트가 보통 사용자 인터페이스의 외관과 관련되며 실제 비즈니스 로직의 파트는 아니기 때문에 "할 수 있다"는 용어가 사용됩니다. 각각의 경우에 HTML 페이지 내부에 임베드되며 그대로 표현되어야 하는 구조적으로 중요한 아키텍처 요소(예: 스크립트)가 될 수 있습니다.

Thick 웹 클라이언트 패턴은 사실 Thin 웹 클라이언트 패턴의 확장이므로 중요 아키텍처 요소의 대부분이 동일합니다. Thick 웹 클라이언트 패턴에 추가로 도입된 요소는 다음과 같습니다.

클라이언트 스크립트 - HTML 형식화된 페이지에 임베드된 JavaScript 또는 Microsoft® VisualBasic® 스크립트. 브라우저는 스크립트를 해석합니다. W3C(인터넷 표준 기구)에서 브라우저가 클라이언트 스크립트에 제공하는 HTML 및 DOM(Document Object Model) 인터페이스를 정의했습니다.

XML 문서 - XML(eXtensible Markup Language)로 형식화된 문서. XML 문서는 사용자 인터페이스 형식화가 없는 컨텐츠(데이터)를 나타냅니다.

ActiveX 제어 - 클라이언트 스크립트에서 참조되고 필요한 경우 클라이언트로 "다운로드"될 수 있는 COM 오브젝트. 다른 COM 오브젝트와 같이 이 오브젝트에는 클라이언트 자원에 대한 전체 액세스가 있습니다. 클라이언트 시스템을 보호하는 핵심 보안 메커니즘은 인증 및 서명을 통해 이루어집니다. ActiveX 제어가 클라이언트에 다운로드될 때 허용하지 않거나 사용자에게 경고하지 않도록 인터넷 브라우저를 구성할 수 있습니다. 인증 및 서명 메커니즘은 단지 신뢰할 수 있는 써드파티를 통해 제어의 작성자 ID를 설정합니다.

Java 애플릿 - 브라우저 컨텍스트에서 실행되는 자체 포함 및 컴파일된 컴포넌트. 보안 상의 이유로 이 컴포넌트는 클라이언트측 자원에 대한 액세스가 제한됩니다. Java 애플릿은 복잡한 사용자 인터페이스 요소로 사용될 뿐만 아니라 XML 문서의 구문 분석이나 복잡한 비즈니스 로직의 캡슐화와 같은 비사용자 인터페이스 목적으로 사용됩니다.

Java Bean - 보다 복잡하고 규모가 큰 시스템으로 쉽게 통합될 수 있는 특정 인터페이스 세트를 구현하는 Java 컴포넌트. Bean이라는 용어는 컴포넌트가 가지는 소형 특성 및 단일 목적을 의미합니다. 커피 한 잔에는 보통 하나 이상의 Bean이 필요합니다. ActiveX는 Microsoft 중심 아키텍처의 Java Bean과 동류입니다.

아래 그림은 Thick 웹 클라이언트 아키텍처에 대한 논리 보기의 다이어그램을 표시합니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

Thick 웹 클라이언트 아키텍처 패턴의 논리 보기

역학

Thick 웹 클라이언트 패턴의 핵심 역학에는 Thin 웹 클라이언트 패턴의 핵심 역학 및 클라이언트에서 비즈니스 로직을 실행하는 기능이 포함됩니다. Thin 웹 클라이언트 패턴에서처럼 클라이언트와 서버 간의 모든 통신은 페이지 요청 동안 수행됩니다. 그러나 스크립트, 제어 또는 애플릿을 사용하여 클라이언트에서 부분적으로 비즈니스 로직을 실행할 수 있습니다.

페이지가 클라이언트 브라우저로 전송되면 페이지에는 스크립트, 제어 및 애플릿을 포함할 수 있습니다. 이러한 요소는 단순히 사용자 인터페이스를 개선하는 데 사용되거나 비즈니스 로직에 적용될 수 있습니다. 가장 단순한 비즈니스 로직 사용은 필드 유효성 검증입니다. 클라이언트 스크립트를 사용하여 단일 필드 및 지정된 웹 페이지의 모든 필드에서 올바른 입력을 확인할 수 있습니다. 예를 들어 사용자가 컴퓨터 시스템을 구성하는 데 사용하는 전자상거래 응용프로그램은 스크립트를 사용하여 호환되지 않는 옵션이 지정되지 않도록 할 수 있습니다.

Java 애플릿 및 ActiveX 제어를 사용하려면 HTML 페이지의 컨텐츠에 이를 지정해야 합니다. 이러한 제어 및 애플릿은 페이지의 모든 스크립트와 별도로 작동하거나 페이지의 스크립트에 의해 구동될 수 있습니다. HTML 페이지의 스크립트는 브라우저에서 보낸 특수 이벤트에 응답할 수 있습니다. 이러한 이벤트는 브라우저가 방금 웹 페이지 로드를 완료했거나 사용자 마우스가 방금 특정 페이지 영역 위로 이동했음을 나타낼 수 있습니다.

해당 컴포넌트는 브라우저의 DOM(Document Object Model) 인터페이스에 대한 액세스가 있습니다. 이 인터페이스는 스크립트, 제어 및 애플릿에 브라우저 및 페이지의 HTML 컨텐츠에 대한 액세스를 제공하는 W3C 표준입니다. Microsoft 및 Netscape의 이 모델 구현은 동적 HTML(DHTML)입니다. DHTML은 단순한 DOM 인터페이스 구현 이상이며, DHTML에는 이 구현을 작성할 때 DOM 레벨 1 스펙의 파트가 아닌 이벤트가 포함됩니다.

DOM(Document Object Model)의 핵심은 특히 XML 문서를 처리하는 인터페이스 세트입니다. XML은 디자이너가 자체 특수 목적 태그를 작성할 수 있는 유연한 언어입니다. DOM 인터페이스를 사용하면 클라이언트 스크립트가 XML 문서에 액세스할 수 있습니다.

XML을 클라이언트와 서버 간 정보 교환의 표준 메커니즘으로 사용하려면 클라이언트에서 특수 컴포넌트를 사용해야 합니다. ActiveX 제어 또는 Java 애플릿을 클라이언트에 배치하여 XML 문서를 개별적으로 요청하고 보낼 수 있습니다. 예를 들어 HTML 페이지에 임베드된 Java 애플릿은 웹 서버에서 XML 문서에 대한 HTTP 요청을 작성할 수 있습니다. 웹 서버는 요청된 정보를 찾아서 처리하고 HTML 문서가 아니라 XML 형식의 문서를 다시 보냅니다. 클라이언트의 HTML 페이지에서 계속 실행되는 애플릿은 XML 문서를 허용하고 구문 분석하며 브라우저의 현재 HTML 문서와 상호작용하여 사용자에게 해당 컨텐츠를 표시합니다. 전체 시퀀스는 클라이언트 브라우저의 단일 HTML 페이지 컨텍스트에서 발생합니다.

결과

이 패턴의 가장 큰 결과는 브라우저 구현을 통한 이식성입니다. 일부 HTML 브라우저는 Java Script 또는 VisualBasic Script를 지원하지 않습니다. 또한 Microsoft Windows 기반 클라이언트에서만 ActiveX 제어를 사용할 수 있습니다. 특정 클라이언트 브라우저 상표가 독점 사용되는 경우에도 DOM(Document Object Model) 구현에는 약간 차이가 있습니다.

클라이언트 스크립트, 제어 또는 애플릿이 사용될 때 테스트 팀은 지원되는 각 클라이언트 구성에 대해 전체 테스트 시나리오 세트를 수행해야 합니다. 주요 비즈니스 로직은 클라이언트에서 수행되고 있기 때문에 이 로직이 모든 관련 브라우저에 대해 일관성 있고 올바르게 동작해야 합니다. 모든 브라우저가 동일하게 동작한다고 가정하지 마십시오. 서로 다른 브라우저가 동일한 소스 코드를 사용하여 다르게 동작할 수 있을 뿐 아니라 동일한 브라우저도 서로 다른 운영 체제에서 실행되면 이상 동작을 보일 수 있습니다.

웹 전달

웹은 기본적으로 다른 경우에는 전통적인 분산 오브젝트 클라이언트/서버 시스템이 되는 시스템이 전달 메커니즘으로 사용되기 때문에 웹 전달 아키텍처 패턴으로 이름 지정되었습니다. 어떤 점에서 보면 이 응용프로그램 유형은 사실 웹 서버 및 클라이언트 브라우저를 구조적으로 중요한 요소로 우연히 포함한 분산 오브젝트 클라이언트/서버 응용프로그램입니다. 해당 시스템이 분산 오브젝트가 있는 웹 응용프로그램이거나 웹 요소가 있는 분산 오브젝트 시스템인지 여부에 관계없이 최종 시스템은 동일합니다. 두 경우 모두 동일한 시스템이고 분산 오브젝트 시스템에는 항상 주의 깊은 모델링이 필요하다는 점에서 웹 응용프로그램을 기타 모든 소프트웨어 시스템처럼 모델링하고 디자인해야 한다는 이 페이지의 주제가 더욱 강조됩니다.

적용 가능성

웹 전달 아키텍처 패턴은 클라이언트 및 네트워크 구성에 대한 상당한 제어가 있는 경우 가장 적합합니다. 이 패턴은 특히 클라이언트 구성에 대한 제어가 없거나 거의 없는 인터넷 기반 응용프로그램의 경우 또는 네트워크 통신을 신뢰할 수 없는 경우에는 적합하지 않습니다.

이 아키텍처의 최대 장점은 웹 응용프로그램 컨텍스트에서 기존 비즈니스 오브젝트를 사용하는 기능입니다. 클라이언트와 서버 간의 직접적이고 지속적인 통신이 가능하여 이전 두 웹 응용프로그램 패턴의 제한사항을 극복할 수 있습니다. 클라이언트를 사용하여 보다 많은 중요 비즈니스 로직을 수행할 수 있습니다.

이 아키텍처 패턴은 단독으로 사용되지 않습니다. 실제로 이 패턴은 하나 또는 둘 모두의 이전 패턴과 결합됩니다. 일반 시스템은 복잡한 사용자 인터페이스를 필요로 하지 않거나 클라이언트 구성이 대규모 클라이언트 응용프로그램을 지원할 수 있을 정도로 강력하지 않은 시스템의 해당 파트에 대해 첫 번째 아키텍처 패턴의 하나 또는 둘 다를 사용합니다.

알려진 용도

CNN 대화식 웹 사이트는 네트워크에서 사용 빈도가 가장 많은 뉴스 사이트 중 하나입니다. 대부분의 공용 액세스는 기존 브라우저 및 직접 HTML 3.2로 수행되며 브라우저, 서버 및 분산 오브젝트의 복잡한 CORBA 기반 네트워크가 웹 사이트를 지원합니다. 이 시스템의 사례 연구가 "Distributed Computing"이라는 제목으로 출판되었습니다.

의료 소프트웨어 회사는 환자, 건강 기록 및 청구를 관리하는 웹 응용프로그램을 작성했습니다. 시스템의 청구 측면은 전체 사용자 커뮤니티의 상당히 작은 부분에서만 사용됩니다. 많은 레거시 청구 시스템은 FoxPro로 작성되었습니다. 새 웹 기반 시스템은 이전 FoxPro 레거시 코드를 사용하고, 일부 변환 유틸리티를 사용하여 사용자 인터페이스 및 비즈니스 로직을 위한 ActiveX 문서를 빌드했습니다. 결과 시스템은 청구 조작용 웹 전달 기반 웹 응용프로그램과 통합된 환자 및 건강 레코드용 Thick 웹 클라이언트 기반 웹 응용프로그램입니다.

구조

웹 전달과 기타 웹 응용프로그램 아키텍처 패턴 간의 가장 큰 차이는 클라이언트와 서버 간의 통신 방법입니다. 다른 패턴에서 기본 메커니즘은 HTTP이며, 이는 사용자와 서버 간의 대화식 활동에 사용되면 디자이너를 크게 제한하는 비연결 프로토콜입니다. 웹 전달 패턴의 구조적으로 중요한 요소에는 Thin 웹 클라이언트 패턴에 지정된 모든 요소 및 다음과 같은 추가 요소가 포함됩니다.

DCOM - DCOM(Distributed COM)은 Microsoft의 분산 오브젝트 프로토콜입니다. 이 프로토콜을 통해 한 시스템의 오브젝트가 다른 시스템의 오브젝트와 상호작용하고 해당 오브젝트에 대한 메소드를 호출할 수 있습니다.

IIOP - IIOP(Internet Inter-Orb Protocol)는 인터넷(또는 TCP/IP 기반 네트워크)을 통해 분산 오브젝트와 상호작용 할 수 있는 OMG의 CORBA 프로토콜입니다.

RMI(JRMP) - RMI(Remote Method Invocation)는 다른 시스템의 오브젝트와 상호작용하는 Java 방식입니다. JRMP(Java Remote Method Protocol)가 RMI의 원시 프로토콜이지만 사용할 수 있는 유일한 프로토콜은 아닙니다. RMI는 CORBA의 IIOP로 구현할 수 있습니다.

아래 그림은 웹 전달 아키텍처 패턴에 대한 논리 보기의 다이어그램을 표시합니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

웹 전달 아키텍처 패턴의 논리 보기

역학

웹 전달 아키텍처 패턴의 핵심 역학은 브라우저를 사용하여 분산 오브젝트 시스템을 전달하는 것입니다. 브라우저와 독립적으로 서버 층의 오브젝트와 통신하는 일부 비즈니스 오브젝트 및 사용자 인터페이스를 포함하는 데 브라우저를 사용합니다. 클라이언트와 서버 오브젝트 간 통신은 IIOP, RMI 및 DCOM 프로토콜로 수행됩니다.

이 분산 오브젝트 클라이언트 서버 시스템에서 웹 브라우저를 사용하는 기본 이점은 서버에서 필요한 컴포넌트를 자동으로 다운로드하는 기능이 브라우저에 기본 제공된다는 점입니다. 네트워크에 새로 연결된 컴퓨터에서 응용프로그램 사용을 시작하려면 호환 가능한 웹 브라우저만 있으면 됩니다. 브라우저가 사용자 대신 설치를 관리하므로 클라이언트에 특수 소프트웨어를 수동으로 설치할 필요는 없습니다. 필요에 따라 클라이언트에 컴포넌트가 전달되고 설치됩니다. Java 애플릿 및 ActiveX 제어는 자동으로 클라이언트에 전송되고 캐시될 수 있습니다. 이러한 컴포넌트가 활성화되면(해당 웹 페이지를 로드한 결과로) 컴포넌트는 비동기 통신으로 서버 오브젝트와 작업을 수행합니다.

결과

이 패턴의 가장 큰 결과는 브라우저 구현을 통한 이식성입니다. 이 패턴을 사용하려면 고정 네트워크가 필요합니다. 클라이언트와 서버 오브젝트 간 연결은 HTTP 연결보다 훨씬 오랫동안 지속되므로, 다른 두 아키텍처에서는 문제가 되지 않는 우발적인 서버 손실이 이 패턴에서는 처리할 심각한 문제가 됩니다.