개념: 웹 구조적 패턴
주제
다음은 가장 일반적인 3가지 패턴입니다.
씬 웹 클라이언트 - 클라이언트의 형상을 거의 제어하지 않는 인터넷 기반 어플리케이션에 주로 사용됩니다.
클라이언트에는 표준 웹 브라우저(양식 수용 가능)만이 필요합니다.
모든 비즈니스 논리는 서버에서 실행됩니다.
Thick 웹 클라이언트 - 구조적으로 중요한 상당한 양의 비즈니스 논리가 클라이언트 시스템에서 실행됩니다.
일반적으로 클라이언트는 동적 HTML, Java Applet 또는 ActiveX 제어를 구현하여
비즈니스 논리를 실행합니다. 서버와의 통신은 여전히 HTTP를 통해 수행됩니다.
웹 전달 - 클라이언트와 서버의 통신에 HTTP 프로토콜을 사용하는 것 이외에
lIOP 및 DCOM과 같은 다른 프로토콜이 분산 객체 시스템을 지원하기 위해
사용될 수 있습니다. 웹 브라우저는 주로 분산 객체 시스템에 대한
전달 및 컨테이너 장치 역할을 합니다.
이 목록은 특히 기술적인 변화가 매년 발생하는 산업에서
완전한 것으로 간주될 수 없습니다.
이 목록은 상위 레벨에서 가장 일반적인 웹 어플리케이션의 구조적 패턴을 표시합니다.
어느 패턴과 함께든지 단일 구조에 여러 패턴을 적용하는 것을 고려해 볼 수 있습니다.
씬 웹 클라이언트 구조적 패턴은 인터넷 기반 어플리케이션에 유용하며
가장 최소 클라이언트 구성이 보장될 수 있는 경우에만 유용합니다.
모든 비즈니스 논리는 서버에서 클라이언트 브라우저의 페이지 요청 이행 중에 실행됩니다.
이 패턴은 인터넷 기반 웹 어플리케이션 또는
클라이언트에 최소 컴퓨팅 파워가 있거나 형상에 대한 제어가 없는 환경에 가장 적합합니다.
충분한 클라이언트 성능을 가지고 있지 않다는 이유만으로
고객의 섹터를 제거하는 것이 비즈니스 양식에 맞지 않으므로
대부분의 e-commerce 인터넷 어플리케이션이 이 패턴을 사용합니다.
일반적인 e-commerce 어플리케이션은 가능한 가장 큰 고객 풀을 달성하려고 합니다.
결국, Commodore Amiga 사용자의 돈은 Windows NT 사용자의 돈과 다름이 없습니다.
씬 웹 클라이언트 구조적 패턴의 주요 컴포넌트는 서버에 존재합니다.
이 구조는 다양한 방법으로 최소 웹 어플리케이션 구조를 표시합니다.
주요 컴포넌트는 다음과 같습니다.
클라이언트 브라우저 - 표준 양식 수용 가능 HTML 브라우저.
브라우저는 일반화된 사용자 인터페이스 장치 역할을 합니다.
씬 웹 클라이언트 구조에서 사용될 때
클라이언트 브라우저가 제공하는 기타 서비스만이 쿠키를 승인하고 리턴할 수 있습니다.
어플리케이션 사용자는 HTML 또는 서버 웹 페이지를
요청하기 위해 브라우저를 사용합니다.
리턴된 페이지에는 클라이언트 표시장치의
브라우저로 렌더링된 완전히 형식화된 사용자 인터페이스(텍스트 및 입력 제어)가 포함됩니다.
시스템과의 사용자 상호 작용 모두는
브라우저를 통해 이루어집니다.
웹 서버 - 모든 클라이언트 브라우저에 대한
주된 액세스 위치. 씬 웹 클라이언트 구조의 클라이언트 브라우저는
웹 페이지(정적 HTML 또는 서버 페이지)에 대한
요청을 승인하는 웹 서버를 통해서만 시스템에 액세스합니다.
요청에 따라 웹 서버는 일부 서버측 처리를 초기화할 수 있습니다.
페이지 요청이 서버 스크립트 페이지, CGI, ISAPI 또는 NSAPI 모듈에 대한 것이면
웹 서버는 적절한 스크립트 해석기 또는 실행 가능 모듈로
처리를 위임합니다.
어쨌든, 결과는 HTML 브라우저에 의한 렌더링에 적합한 HTML로 포맷된 페이지입니다.
HTTP 연결 - 클라이언트 브라우저 및 웹 서버 간에 사용 중인
가장 일반적인 프로토콜.
이 구조적 요소는 클라이언트 및 서버 간 통신의 비연결 유형을 나타냅니다.
클라이언트 또는 서버가 정보를 서로에게 전송할 때마다
새로운 개별 연결이 둘 사이에 수립됩니다.
HTTP 연결의 변형이 SSL(Secure Sockets Layer)을 통한
안전 HTTP 연결입니다. 이 유형의 연결은 공용/개인용 암호화 중요한 기술을 사용하여
클라이언트 및 서버 간에 전송되고 있는 정보를 암호화합니다.
HTML 페이지 - 서버측 처리를 받지 않는
사용자 인터페이스 및 컨텐츠 정보를 가진 웹 페이지.
일반적으로 이런 페이지에는 지시문, 도움말 정보 또는
HTML 입력 양식과 같은 설명 텍스트가 포함됩니다.
웹 서버가 HTML 페이지 요청을 수신하면
서버는 단순히 파일을 검색하여
필터링하지 않고 요청한 클라이언트에게
전송합니다. 서버 페이지 - 일부 서버측 처리 양식을
거치는 웹 페이지. 일반적으로 이런 페이지는 어플리케이션 서버의 필터 또는
실행 가능 모듈(ISAPI 또는 NSAPI)에 의해 처리된
스크립트 페이지(ASP(Active Server Page),
JSP(Java Server Page), Cold Fusion 페이지)로 서버에서 구현됩니다.
이런 페이지는 잠재적으로 비즈니스 논리 컴포넌트, 데이터베이스,
레거시 시스템 및 매매 계정 시스템을 포함한
모든 서버측 자원에 대한 액세스를 가집니다.
어플리케이션 서버 - 서버측 비즈니스 논리를 실행하기 위한
기본 엔진.
어플리케이션 서버는 서버 페이지의 코드 실행을 담당하며
웹 서버와 동일한 시스템에 위치할 수 있습니다.
또한 웹 서버와 동일한 프로세스 영역에서 실행될 수도 있습니다.
어플리케이션 서버는 비즈니스 논리 실행과만 관련되고
웹 서버와 완전히 다른 기술을 사용할 수 있으므로
논리적으로 독립된 구조적 요소입니다.
아래 그림은 씬 웹 클라이언트 구조에 대한 논리적 보기의 다이어그램을 표시합니다.

최소 씬 웹 클라이언트 구조
최소 씬 웹 클라이언트 구조에는 보통 웹 어플리케이션에서 발견되는
일부 선택적인 공통 컴포넌트(특히, 데이터베이스)가 빠져 있습니다.
대부분의 웹 어플리케이션은 비즈니스 데이터를 지속되게
하기 위해 데이터베이스를 사용합니다.
일부 경우에는 데이터베이스가 페이지 자체를 저장하는 데 사용될 수도 있습니다(그러나
이러한 용도로 데이터베이스를 사용하는 것은 다른 구조적 패턴을 나타냄).
웹 어플리케이션이 비즈니스 데이터를 지속되게 하기 위해
여러 가지 기술을 사용할 수 있으므로
구조적 컴포넌트는 일반적인 용어인 지속성으로
레이블이 지정됩니다.
지속성 컴포넌트는 적절한 TPM(Transaction Processing Monitor) 사용도 포함합니다.
시스템에 데이터베이스를 연결하는 가장 단순한 방법은
서버 페이지의 스크립트에서 지속성 컴포넌트에 직접 액세스할 수 있도록 하는 것입니다.
이러한 직접 액세스는 번거로운 작업을 수행하기 위해
RDO, ADO, ODBC, JDBC, DBLib와 같은 표준 데이터 액세스 라이브러리를 구현합니다.
이 상황에서 서버 페이지는 데이터베이스 스키마에 대해 알고 있습니다.
관계형 데이터베이스의 경우 서버 페이지는 데이터베이스에서 데이터에 대한 액세스를 얻기 위해
필요한 SQL 문서를 구축하고 실행합니다.
작고 덜 복잡한 웹 어플리케이션에서는
이것으로 충분할 수 있습니다. 그러나 보다 크고 견고한 시스템에서는
완전한 비즈니스 객체 계층의 사용이 선호됩니다.
비즈니스 객체 컴포넌트는 비즈니스 논리를 캡슐화합니다.
이 컴포넌트는 보통 어플리케이션 서버에서 컴파일되고 실행됩니다.
비즈니스 객체 구조적 컴포넌트를 가지는 장점 중 하나는
다른 웹 또는 클라이언트 서버 시스템이 동일한 컴포넌트를 사용하여
동일한 비즈니스 논리를 호출할 수 있다는 것입니다.
예를 들어, 인터넷 기반 상점은 모든 고객 활동에 대해 서버 페이지 및
씬 웹 클라이언트 구조적 패턴을 사용할 수 있습니다.
그러나 청구 부서에는 데이터 및 비즈니스 논리에 대한 보다 복잡한 액세스가 필요할 수 있으며
웹 기반 시스템보다 클라이언트 서버 시스템을 사용하는 것을 선호할 수 있습니다.
청구 부서의 시스템은 웹 프런트와 동일한 어플리케이션 서버에 동일한 비즈니스 컴포넌트를 구현할 수 있으며
아직은 보다 복잡한 자체 클라이언트 소프트웨어를 사용합니다.
관계형 데이터베이스가 주류 비즈니스에서 가장 일반적인 데이터베이스 유형이므로,
일반적으로 추가적인 구조적 컴포넌트가 어플리케이션 서버 및 데이터베이스 사이에 존재합니다.
이러한 컴포넌트는 객체 및 관계형 데이터베이스 사이의 맵핑 서비스를 제공합니다.
이 맵핑 계층 자체는 여러 가지 방법으로 구현될 수 있습니다.
이 컴포넌트에 대한 세부사항은 이 페이지의 범위를 벗어나는 것입니다.
일반적으로 이 구조적 패턴에 추가되는 기타 옵션은
레거시 시스템과 통합 및 e-commerce 어플리케이션(상인 계정 시스템)에 대한 것입니다.
두 가지 모두가 비즈니스 객체(또는 정규 비즈니스 객체 컴포넌트가 없는
시스템의 어플리케이션 서버)를 통해 액세스됩니다.
레거시 시스템은 회계 시스템 또는 제조 스케줄링 시스템을 나타낼 수 있습니다.
상인 계정 시스템은 인터넷 웹 어플리케이션이
신용 카드 지불을 승인하고 처리할 수 있게 합니다.
온라인 시장에 참여하기 원하는 소형 비즈니스에서
사용할 수 있는 많은 상인 계정 시스템이 있습니다.
대형 비즈니스에서는 이 컴포넌트가 신용 카드 요청을 처리할 수 있는 기존 시스템에 대한
인터페이스일 수 있습니다.
적소에 있는 선택적 컴포넌트를 통해 씬 웹 클라이언트 구조적 패턴의 논리적 보기가
점차 완성되어갑니다.
논리적 보기는 아래 그림에 표시됩니다.

씬 웹 클라이언트 논리적 보기
대부분의 웹 어플리케이션 서버 컴포넌트는
웹 기반이 아닌 어플리케이션에서도 발견될 수 있습니다.
웹 어플리케이션 백엔드의 설계 및 구조는
메인프레임 또는 클라이언트/서버 시스템의 설계와 다르지 않습니다.
웹 어플리케이션은 동일한 이유로 다른 시스템에서 수행되는
데이터베이스 및 TPM(Transaction Processing Monitor)을 사용합니다.
EJB(Enterprise Java Bean) 및 MTS(Microsoft Transaction Server)는
웹 어플리케이션을 염두에 두고 도입되었지만
동시에 다른 어플리케이션 구조에도 적합한 새 툴 및 기술입니다.
웹 어플리케이션 서버측 컴포넌트의 구조 및 설계는
클라이언트 서버 시스템의 구조 및 설계와 정확하게 동일하게
취급됩니다.
이 구조적 패턴은 웹 어플리케이션에 특정한 웹 및 컴포넌트에 중점을 두고
가능한 백엔드 서버 구조에 대한 세부사항 검토는
이 패턴의 범위를 벗어나는 것입니다.
이 구조적 패턴의 원동력에 대한 기본 원칙은
비즈니스 논리가 클라이언트의 웹 페이지 요청에 대한 응답으로만 실행된다는 것입니다.
클라이언트는 HTTP 프로토콜을 통해 웹 서버에서 웹 페이지를 요청하여
시스템을 사용합니다.
요청된 페이지가 웹 서버의 파일 시스템에 있는 HTML 파일인 경우
단순히 요청된 파일을 가져와 요청한 클라이언트에게 다시 전송합니다.
페이지가 스크립트된 페이지인 경우
그 페이지는 클라이언트에 리턴될 수 있기 전에
처리되어야 하는 해석 가능한 코드가 포함된 페이지이며
웹 서버는 이 조치를 어플리케이션 서버에 위임합니다.
어플리케이션 서버는 페이지의 스크립트를 해석하고
지시된 경우 데이터베이스, 전자 우편 서비스, 레거시 시스템 등과 같은
서버측 자원과 상호 작용합니다.
스크립트된 코드는 어플리케이션 및 웹 서버를 통해
페이지 요청을 수반하는 특수 정보에 액세스합니다.
이 정보에는 사용자가 입력한 양식 필드 값과 페이지 요청에 추가된 매개변수가 포함됩니다.
최종 결과는 클라이언트에게 다시 전송하는 데 적합하도록 올바르게 포맷된 HTML 페이지입니다.
이 페이지는 SAPI 또는 NSAPI DLL과 같은 실행 가능 모듈일 수 있습니다.
DLL 또는 동적 링크 라이브러리는 런타임에 어플리케이션 서버에서
로드되고 실행될 수 있는 컴파일된 라이브러리입니다.
모듈은 스크립트된 페이지에 있는 동일한 페이지 요청(양식 필드 값 및 매개변수)
세부사항에 대한 액세스를 가집니다.
이 패턴의 동적 작동에 대한 주안점은 비즈니스 논리가
페이지 요청 처리 중에만 호출된다는 것입니다.
페이지 요청이 이행되면 그 결과과 요청한 클라이언트에게 전송되며
클라이언트와 서버 간의 연결이 종료됩니다.
요청이 이행된 후에 비즈니스 프로세스가 남아 있을 수 있지만
일반적인 것은 아닙니다.
이 유형의 구조는 서버 응답이 사용자가 기대하는 승인 가능한 응답 시간 이내에(그리고 클라이언트
브라우저에서 허용되는 시간 종료 값 이내에)
완료될 수 있는 어플리케이션에 가장 적합합니다.
이것은 보통 몇 초를 넘지 않습니다.
어플리케이션에서 사용자가 긴 시간 지속되는
비즈니스 프로세스를 시작하고 모니터할 수 있도록 해야 하는 경우
이것이 가장 적합한 구조적 패턴이 아닐 수 있습니다.
그러나 클라이언트가 긴 시간 실행 중인 프로세스를 모니터할 수 있도록
푸시(Push) 기술이 사용될 수 있습니다.
대부분의 경우 푸시(Push) 기술은 단지 서버의 주기적인 폴링을 사용합니다.
이 구조적 패턴의 또다른 주요 결과는 정교한 사용자 인터페이스에 대한
제한된 능력입니다.
브라우저가 전체 사용자 인터페이스 전달 메커니즘 역할을 하기 때문에
모든 사용자 인터페이스 위지트(widget) 및 제어가 브라우저를 통해 사용 가능해야 합니다.
가장 일반적인 브라우저 및 HTML 스펙에서
이것은 몇 개의 텍스트 항목 필드 및 단추로 제한됩니다.
다른 한편, 이렇게 엄격하게 제한된 사용자 인터페이스가
올바른 것이라고 주장될 수 있습니다.
부족한 사용자 인터페이스 제공은 보다 단순한 인터페이스로 충분한 경우에
개발 팀이 "멋있고" "근사한" 인터페이스를 개발하기 위한
노력에 시간을 소비하지 않도록 합니다.
Thick 웹 클라이언트 구조적 패턴은 클라이언트측 스크립트 및
ActiveX 제어 및 Java Applet과 같은 사용자 정의 객체 사용을 통해
씬 웹 클라이언트를 확장한 것입니다.
Thick 웹 클라이언트는
클라이언트가 실제로 시스템의 일부 비즈니스 논리를 실행할 수 있다는 사실에서
이러한 이름을 얻게 되었으며
따라서 단지 일반화된 사용자 인터페이스 컨테이너 이상의 것이 되었습니다.
Thick 웹 클라이언트 구조적 패턴은 일정한 클라이언트 형상 및 브라우저 버전이
가정될 수 있고 정교한 사용자 인터페이스가 요구되며
일정한 양의 비즈니스 논리가 클라이언트에서 실행될 수 있는
웹 어플리케이션에 가장 적합합니다.
씬 웹 클라이언트 및 Thick 웹 클라이언트 패턴 사이의 차이점 대부분은
시스템의 비즈니스 논리 실행에서 브라우저가 수행하는 역할에서 나옵니다.
Thick 웹 클라이언트를 사용하는 강력한 두 가지 동기는
개선된 사용자 인터페이스 성능 및 비즈니스 논리의 클라이언트 실행입니다.
정교한 사용자 인터페이스는 3차원 모델을 보고 수정하거나
재정 그래프를 만드는 데 사용될 수 있습니다.
일부 인스턴스에서 ActiveX 제어는 클라이언트측 모니터링 장비와
통신하는 데 사용될 수 있습니다.
예를 들어, 혈압, 혈당 및 기타 바이탈 사인을 측정할 수 있는
의료 장비는 지역적으로 떨어져 있는 환자를 매일 모니터해야 하는 에이전시에서 사용될 수 있고
직접적인 방문을 일주일에 두 번으로 줄일 수 있습니다.
어떤 상황에서는 비즈니스 논리가 클라이언트에서만 실행될 수 있습니다.
이러한 상황에서는 프로세스를 수행하는 데 필요한 모든 데이터가
클라이언트에서 사용 가능해야 합니다.
논리는 입력된 데이터를 검증하는 것과 같이 단순할 수 있습니다.
정확도를 위해 날짜가 확인되거나 다른 날짜와 비교될 수 있습니다(예를
들어, 생일은 병원에 처음 수용된 날짜 이전이어야 함).
시스템의 비즈니스 규칙에 따라 일부 필드는
현재 입력된 값을 기준으로 사용 가능하게 될 수도 있고 그렇지 않을 수도 있습니다.
가장 명백한 클라이언트측 스크립트, Applet, 제어 및 플러그인 사용은
개선된 사용자 인터페이스 양식의 인터넷에 있습니다.
Java 스크립트는 대개 HTML 페이지에서 단추나 메뉴 항목의
색깔 또는 이미지를 변경하는 데 사용됩니다.
Java Applet 및 ActiveX 제어는 대개 매우 복잡한
계층적 트리 보기 제어를 작성하는 데 사용됩니다.
Shockwave ActiveX 제어 및 플러그인은 현재 인터넷에서 사용되는
가장 일반적인 사용자 인터페이스 컴포넌트 중 하나입니다.
이것은 대화식 애니메이션을 사용 가능하게 하며
주로 눈에 뜨이는 그래픽으로 인터넷 사이트에 흥미를 더하는 데 사용되지만
시뮬레이션을 표시하고 스포츠 이벤트를 모니터하는 데도 사용되고 있습니다.
Microsoft의 에이전트 제어는 몇몇 인터넷 사이트에서
사용자의 웹 사이트 탐색에 도움을 주는
브라우저의 음성 명령을 승인하고 조치를 실행하는 데 사용됩니다.
인터넷 밖에서 의료 소프트웨어 회사는 웹 기반 인트라넷 어플리케이션을 개발하여
환자 레코드 및 청구를 관리합니다.
웹 기반 사용자 인터페이스는 데이터 검증을 수행하고 사용자가 사이트를 탐색하는 데 도움을 주기 위해
클라이언트측 스크립트를 자주 사용합니다.
스크립트 이외에, 이러한 어플리케이션은 정보에 대한 기본 인코딩 스키마로
사용되는 XML 컨텐츠를 관리하는 데 여러 ActiveX 제어를 사용합니다.
씬 웹 클라이언트 패턴에서와 같이 클라이언트 및 서버 간의 모든 통신은
HTTP를 통해 수행됩니다.
HTTP가 "비연결" 유형의 프로토콜이므로
대부분 클라이언트와 서버 사이에 연결이 열려 있지 않습니다.
클라이언트는 페이지 요청 중에만 정보를 전송합니다.
이것은 클라이언트측 스크립트, ActiveX 제어 및 Java Applet이
클라이언트에 있는 객체와만 상호 작용하는 것으로 제한됨을 의미합니다.
Thick 웹 클라이언트 패턴은 클라이언트에서 비즈니스 논리를 실행하기 위해
ActiveX 제어 또는 Java Applet과 같은 임의의 브라우저 성능을 구현합니다.
ActiveX 제어는 HTTP를 통해 클라이언트에 다운로드될 수 있는 2진 실행 파일로 컴파일되고
브라우저에서 호출됩니다.
본래 COM 객체인 ActiveX 제어이므로
클라이언트측 자원에 대한 완전한 제어 권한을 가집니다.
ActiveX 제어는 클라이언트 시스템 자체 및
브라우저 모두와 상호 작용합니다.
이러한 이유로 ActiveX 제어는, 특히 인터넷의 ActiveX 제어는
일반적으로 제3 신뢰 기관에서 "인증을 받습니다".
일반 HTML 브라우저의 가장 최신 버전은 클라이언트측 스크립트 작성도 허용합니다.
HTML 페이지는 Java 스크립트 또는 VB 스크립트로 작성된 스크립트를 통해 임베드될 수 있습니다.
이 스크립트 성능은 브라우저 자체에서
시스템 비즈니스 논리의 파트일 수 있는 코드를 실행(더 정확히 말하자면 해석)할 수 있도록 합니다.
클라이언트 스크립트가 실제로 비즈니스 논리의 파트가 아닌 사용자 인터페이스의
이질적인 측면에만 기여하는 것이 매우 일반적이기 때문에
"아마도"라는 용어가 사용됩니다.
다른 경우에, 이와 같이 표현될 필요가 있는 HTML 페이지 내부에 임베드되는
잠재적으로 구조적으로 중요한 요소가 있습니다.
Thick 웹 클라이언트 패턴이 실제로 씬 웹 클라이언트 패턴의 확장이므로
구조적으로 중요한 요소 대부분은 서로 동일합니다.
Thick 웹 클라이언트 패턴에 도입된 추가 요소는 다음과 같습니다.
클라이언트 스크립트 - HTML로 포맷된 페이지에 임베드되는 JavaScript 또는 Microsoft® VirtualBasic®스크립트.
브라우저가 스크립트를 해석합니다. W3C(인터넷 표준 본문)는
브라우저가 클라이언트 스크립트에 제공하는 HTML 및 문서 객체 모델 인터페이스를 정의했습니다.
XML 문서 - XML(eXtensible Markup Language)로 포맷된 문서.
XML 문서는 사용자 인터페이스 포맷 없이 컨텐츠(데이터)를 표시합니다.
ActiveX 제어 - 클라이언트 스크립트에서 참조될 수 있고
필요한 경우 클라이언트에 "다운로드"될 수 있는 COM 객체.
모든 COM 객체와 같이 이것도 클라이언트 자원에 완전하게 액세스할 수 있습니다.
클라이언트 시스템을 보호하기 위한 보안 원리는
인증 및 서명을 통해 이루어집니다.
인터넷 브라우저는 ActiveX 제어가 클라이언트에 다운로드될 때
승인하지 않거나 사용자에게 경고하도록 구성될 수 있습니다.
인증 및 서명 메커니즘은 단지 제3 신뢰 기관을 통해 제어 작성자의 ID를 확인합니다.
Java Applet - 브라우저의 컨텍스트에서 실행되는 자체 포함되고
컴파일되는 컴파일. 보안상의 이유로 이것은 클라이언트측 자원에 대해 제한된 액세스를 가집니다.
Java Applet은 정교한 사용자 인터페이스 요소로서
XML 문서 구문 분석과 같은 비 사용자 인터페이스 목적으로 또는
복잡한 비즈니스 논리를 캡슐화하기 위해 사용됩니다.
Java Bean - 보다 크고 복잡한 시스템으로 쉽게 통합될 수 있게 하는
일정한 인터페이스 세트를 구현하는 Java 컴포넌트.
Bean이라는 용어는 컴포넌트가 가져야 하는 작은 특징과 단일 목적을 나타냅니다.
커피 한 잔에는 보통 여러 개의 커피 열매(Bean)가 사용됩니다.
ActiveX가 Microsoft 중심 구조에서 Java Bean과 비슷하게 사용됩니다.
아래 그림은 Thick 웹 클라이언트 구조에 대한 논리적 보기의 다이어그램을 표시합니다.

Thick 웹 클라이언트 구조적 패턴의 논리적 보기
Thick 웹 클라이언트 패턴의 주요 원동력에는 씬 웹 클라이언트 패턴의
능력에 덧붙여 클라이언트에서 비즈니스 논리를 실행하기 위한 능력이 포함됩니다.
씬 웹 클라이언트 패턴과 같이, 클라이언트와 서버 사이의
모든 통신은 페이지 요청 중에 수행됩니다.
그러나 비즈니스 논리는 부분적으로 클라이언트에서 스크립트, 제어 또는 Applet을 통해 실행될 수 있습니다.
페이지가 클라이언트 브라우저에 전송될 때
페이지에는 스크립트, 제어 및 Applet이 포함될 수 있습니다.
이것들은 단순히 사용자 인터페이스를 개선하거나
비즈니스 논리에 도움을 주기 위해 사용될 수 있습니다.
가장 단순한 비즈니스 논리 사용은 필드 검증입니다.
클라이언트 스크립트는 단일 필드에서 뿐 아니라
해당 웹 페이지의 모든 필드에서 입력이 올바른지 확인하는 데 사용될 수 있습니다.
예를 들어, 사용자가 자체 컴퓨터 시스템을 구성할 수 있게 하는 e-commerce 어플리케이션에서는
호환되지 않은 옵션이 지정되지 않도록 하기 위해 스크립트를 사용할 수 있습니다.
Java Applet 및 ActiveX 제어를 사용하려면
HTML 페이지의 컨텐츠에 지정해야 합니다. 이러한 제어 및 Applet은 페이지의
스크립트와 독립적으로 작동되거나 페이지의 스크립트에 의해 조종될 수 있습니다.
HTML 페이지의 스크립트는 브라우저에서 전송된 특수 이벤트에 응답할 수 있습니다.
이러한 이벤트는 브라우저가 웹 페이지 로드를 완료했다거나
사용자의 마우스가 페이지의 특정 영역으로 이동했다는 것을 표시할 수 있습니다.
이것은 브라우저의 DOM(Document Object Model) 인터페이스에 액세스할 수 있습니다.
이 인터페이스는 브라우저 및 페이지의 HTML 컨턴츠에 대한
제어, Applet 액세스를 제공하기 위한 W3C 표준입니다.
Microsoft 및 Netscape에서 이 모델은 동적 HTML(DHTML)로 구현됩니다.
DHTML은 DOM 인터페이스의 구현 이상의 것이며
특별한 DHTML은 작성 시점에서 DOM 레벨 1 스펙의 파트가 아닌 이벤트를 포함합니다.
DOM(Document Object Model)의 중심에는 특히 XML 문서를 처리하는
인터페이스 세트가 있습니다.
XML은 설계자가 자체 특수 목적 태그를 작성할 수 있도록 하는
유연한 언어입니다. DOM 인터페이스는
클라이언트 스크립트에서 XML 문서에 액세스할 수 있도록 합니다.
XML을 클라이언트와 서버 간에 정보를 교환하는 표준 메커니즘으로
사용하려면 클라이언트에서 특수 컴포넌트를 사용해야 합니다.
ActiveX 제어 또는 Java Applet은 독립적으로 XML 문서를 요청하고 전송하도록
클라이언트에 위치할 수 있습니다.
예를 들어, HTML 페이지에 임베드된 Java Applet은
웹 서버로부터 XML 문서에 대한 HTTP를 요청할 수 있습니다.
웹 서버는 요청된 정보를 찾아 처리하고
HTML 문서를 다시 전송하지만 XML로 포맷된 문서는 전송하지 않습니다.
여전히 클라이언트의 HTML 페이지에서 실행 중인 Applet은
XML 문서를 승인하고 구문 분석하며
사용자에게 컨텐츠를 표시하기 위해 브라우저에 있는 현재 HTML 문서와 상호 작용합니다.
전체 순서는 클라이언트 브라우저에 있는 단일 HTML 페이지의 컨텍스트에서 발생합니다.
이 패턴의 가장 중요한 결과는 단연 브라우저 구현에 걸친 이식성입니다.
모든 HTML 브라우저가 Java 스크립트 또는 VirtualBasic 스크립트를 지원하는 것은 아닙니다.
추가적으로 Microsoft Windows 기반 클라이언트만이 ActiveX 제어를 사용할 수 있습니다.
특정 브랜드의 클라이언트 브라우저가 독점적으로 사용될 때에도
DOM(Document Object Model) 구현에 있어 미묘한 차이가 있습니다.
클라이언트 스크립트, 제어 또는 Applet이 사용될 때
테스트 팀은 지원될 각 클라이언트 형상에 대해 전체 테스트 시나리오 세트를 수행해야 합니다.
중요한 비즈니스 논리가 클라이언트에서 수행되므로
관련된 브라우저 모두에 대해 일관되고 정확하게 작동하는 것이 중요합니다.
모든 브라우저가 동일하게 작동한다고 가정하지 마십시오.
다른 브라우저가 동일한 소스 코드를 가지고 다르게 작동하는 것이 가능할 뿐 아니라
다른 운영 체제에서 실행되는 동일한 브라우저가
예외적인 작동을 표시할 수도 있습니다.
웹이 주로 다른 전통적 분산 객체 클라이언트/서버 시스템에 대한
전달 메커니즘으로 사용되므로 웹 전달 구조적 패턴에 이름이 지정됩니다.
어떤 관점에서 보면 이 유형은 어플리케이션은 실제로
웹 서버 및 클라이언트 브라우저를 중요한 구조적 요소로서 포함하게 되는
분산 객체 클라이언트/서버 어플리케이션입니다.
이러한 시스템이 분산 객체를 포함한 웹 어플리케이션이든지 웹 요소를 포함한 분산 객체 시스템이든지
긍극적인 시스템은 동일합니다.
이러한 두 개의 관점이 동일한 시스템에 속하고 분산 객체 시스템이 항상 신중한 모델링을 필요로 하는
시스템으로 간주되었고, 이것이 이 페이지의 주제를 한층 더 강조한다는 사실에서
웹 어플리케이션은 다른 소프트웨어 시스템과 같이 모델링되고 설계되어야 합니다.
웹 전달 구조적 패턴은 클라이언트 및 네트워크 형상에 대해
상당한 양의 제어가 있는 경우 가장 적합합니다.
이 패턴은 특히 인터넷 기반 어플리케이션,
클라이언트 형상에 대한 제어가 적거나 거의 없는 곳이나
네트워크 통신을 신뢰할 수 없을 때 적합하지 않습니다.
이 구조의 가장 큰 장점은 웹 어플리케이션의 컨텍스트에서
기존 비즈니스 객체를 활용할 수 있는 능력입니다.
클라이언트와 서버 간에 가능한 직접 및 지속적 통신을 통해
이전 두 가지 웹 어플리케이션 패턴의 한계가 극복될 수 있습니다.
중요한 비즈니스 논리를 고도로 수행하기 위해
클라이언트가 활용될 수 있습니다.
이 구조적 패턴은 따로 분리되어 사용될 가능성이 없습니다.
현실적으로 이 패턴은 이전 패턴 중 하나 또는 모두와 결합됩니다.
일반적인 시스템은 정교한 사용자 인터페이스를 필요로 하지 않는
시스템의 파트에 대해서나 클라이언트 형상이 대형 클라이언트 어플리케이션을 지원하기에 충분히
강력하지 않은 곳에서 첫 번째 구조적 패턴 중 하나 또는 모두를 구현합니다.
CNN 양방향 웹 사이트는 네트워크에서 가장 분주한 새 사이트 중 하나입니다.
대부분의 시청자 제작 프로그램(public access)은
전통적인 브라우저와 직접적인 HTML을 통해서 수행됩니다.
그러나 웹 사이트 배후에는 정교한 CORBA 기반의 브라우저, 서버 및 분산 객체 네트워크가 있습니다.
이 시스템의 케이스 연구는 발표된 분산 컴퓨팅입니다.
의료 소프트웨어 회사는 환자, 건강 레코드 및 청구를 관리하기 위해
웹 어플리케이션을 작성했습니다.
시스템의 청구 측면은 전체 사용자 커뮤니티의 상당히 작은
영역에서만 사용됩니다.
대부분의 레거시 청구 시스템은 FoxPro에서 작성되었습니다.
새 웹 기반 시스템은 이전 FoxPro 레거시 코드를 활용했고
일부 변환 유틸리티를 통해 사용자 인터페이스 및 비즈니스 논리용
ActiveX 문서를 빌드했습니다.
결과 시스템은 청구 조작용 웹 전달 기반 웹 어플리케이션과 통합된
환자 및 건강 레코드용 Thick 웹 클라이언트 기반 웹 어플리케이션입니다.
웹 전달과 기타 웹 어플리케이션 구조적 패턴 간의 가장 중요한 차이는
클라이언트 및 서버 간 통신 메소드입니다.
다른 패턴에서는 기본 메커니즘이 사용자와 서버 간에 양방향 활동이 시작될 때
설계자를 엄격히 제한하는 HTTP, 비연결 프로토콜이었습니다.
웹 전달 패턴에서
구조적으로 중요한 요소에는 씬 웹 클라이언트 패턴에서 지정된 모든 요소와
추가로 다음이 포함됩니다.
DCOM - Distributed COM은 Microsoft의 분산 객체 프로토콜입니다.
하나의 시스템에 있는 객체가 다른 시스템에 있는 객체에 대한 메소드와 상호 작용하고 호출할 수 있게 합니다.
IIOP - Internet Inter-Orb Protocol은 인터넷(또는 모든
TCP/IP 기반 네트워크)을 통해 분산 객체와 상호 작용하기 위한
OMG의 CORBA 프로토콜입니다.
RMI(JRMP) - Remote Method Invocation은
다른 시스템에 있는 객체와 상호 작용하는 Java 방법입니다.
JRMP(Java Remote Method
Protocol)는 RMI의 원시 프로토콜이지만
사용될 수 있는 유일한 프로토콜은 아닙니다.
RMI는 CORBA의 IIOP와 함께 구현될 수 있습니다.
아래 그림은 웹 전달 구조적 패턴에 대한 논리적 보기의 다이어그램을 표시합니다.

웹 전달 구조적 패턴의 논리적 보기
웹 전달 구조적 패턴의 기본 원동력은
분산 객체 시스템을 전달하기 위해 브라우저를 사용하는 것입니다.
브라우저는 사용자 인터페이스 및
브라우저에서 서버 단의 객체와 독립적으로 통신하는
일부 비즈니스 계층을 포함하기 위해 사용됩니다.
클라이언트 및 서버 객체 사이의 통신은
IIOP, RMI 및 DCOM 프로토콜을 통해 발생합니다.
이렇게 다른 분산 객체 클라이언트 서버 시스템에서
웹 브라우저를 사용하는 주요 장점은
브라우저가 필요한 컴포넌트를 서버에서 자동으로 다운로드할 수 있는
일부 빌드된 성능을 가진다는 것입니다.
네트워크에 아주 새로운 컴퓨터는 어플리케이션 사용을 시작하는 데
호환 가능한 웹 브라우저만이 필요합니다. 특수 소프트웨어는 브라우저가 사용자를 대신하여 이를 관리하므로
클라이언트에 수동으로 설치될 필요가 없습니다. 컴포넌트는 필요할 때마다
클라이언트에 전달되고 설치됩니다.
Java Applet 및 ActiveX 제어 모두는 자동으로 클라이언트에 전송되고
캐시될 수 있습니다.
이러한 컴포넌트는 활성화될 때(적절한 웹 페이지를 로드한 결과로)
서버 객체와의 비동기 통신에 참여할 수 있습니다.
이 패턴의 가장 중요한 결과는 단연 브라우저 구현에 걸친 이식성입니다.
이 패턴을 사용하려면 견고한 네트워크가 필요합니다.
클라이언트 및 서버 객체 사이의 연결은 HTTP 연결보다 더 오래 지속됩니다.
따라서 다른 두 가지 구조에는 없는 문제점인 산발적인 서버의 손실은
이 패턴에서 처리될 심각한 문제점을 일으킵니다.
|