제 12 장 분산환경

12.1 클라이언트/서버모델

클라이언트/서버라는 용어는 본래 하나의 응용과 지원 기능이라는 두 프로그램 사이에서 처리되는 절차를 기술하는 소프트웨어의 구조에 적용되었다. 이때의 개념은 같은 컴퓨터에서 수행되는 호출(Calling)과 피호출(Called)프로그램과 다를 것이 없었다. 그러므로, 이때 클라이언트와 서버 개념은 보통 낟사나의 클라이 언트와 하나의 서버 사이의 상호작용에 국한되었다. 그러나, 컴퓨터 및 통신 기술이 발전함에 따라 다른 많은 프로그램을 대신하여 서비스를 제공하거나 자원을 관리할 수 있는 특정 프로그램의 개념이 널리 사용되기 시작하였다. 이 장에서는 분신환경의 발전과정에서의 클라이언트/서버 구조에 대해서 소개한다.

* 클라이언트/서버 모델은 "클라이언트(또는 요청자)는 요구사항을 서버에게 제 시하고 서버는 요구사항을 처리하여 그 결과를 클라이언트에게 되돌려 주는 분 산 협동처리(Distributed Cooperative Processing)의 특별한 형태" 이다.

* 협동처리는 실제로 분산처리의 특별한 형태이며, 여기서 자원(과 그것에 영향 을 주는 처리업무들)은 두개 이상의 분리된 컴퓨터에 분산하여 존재하며 필요 시 상호 협조하여 실행한다.

* 클라이언트와 서버 모델은 넓은 범위의 기능과 서비스, 그리고 분산환경의 여 러가 지 구성들을 포함한다.

12.1.1 발전과정

(1) 호스트 기반 처리

* 초기의 분산 시스템은 실제로 분산 응용 처리능력이 없는 호스트기반 처리 (Host-based processing)에서 발전하였다.

* 이것은 비 지능적인 더미 터미널(Dubby terminal)들이 부착된 컴퓨터 시스템 에서 수행된다.

* 즉, 응용처리 관점에서 완전히 비분산형이며, 독립형(stand-alone) 개인용 컴 퓨터 또는 단말기가 부착된 중대형 컴퓨터 시스템이 좋은 예이다[그림 12.1].

(2) 주종속 처리

* 호스트 기반처리 보다 한 단계 높은 분산 응용처리로서, 종속(Slave)컴퓨터를 주(master)컴퓨터와 연결하여 주컴퓨터가 지시효葡는 대로만 응용처리 관련 기능을 수행하는 처리 구조이다.

* 처리 분배가 주 컴퓨터로 부터 일방적으로 이루어 지지만, 그 구성 및 처리에서 어느 정도는 분산된 것이다.

* 즉, 주 컴퓨터는 응용의 전체적인 기능을 수행하며, 종속 컴퓨터는 화면상의 필드 검사. 편집, 또는 기능키 처리 등 제한된 국부의 응용처리를 수행한다는 것이다.

* [그림 12.2]는 주종속처리환경을 보인 것이다.

* 이것의 예로는 집중제어기(cluster) 또는 지능형 단말기를 장착한 중대형(호스트) 컴퓨터이다.

(3) 클라이언트/서버 처리

(가) 공유기 처리환경

* 근거리 통신망( LAN)에서 일반적으로 볼수 있는 공유기(Shared device)처리 의 고급단계로 출현한 것이다. 즉, LAN처리 환경에서 하드디스크의 화일(file) 또는 프린터( printer) 등과 같은 전형적인 자원들을 함께 사용할 수 있도록 공유기를 제공한다. 이러한 기능을 수행하는 공유기를 "서버"(화일서버 또는 프린터서버)라고 한다. [그림 12.3]

* 이러한 서버는 LAN상의 각종 장치들(PC 또는 워크스데이션 등)의 처리 요구 를 받아 이를 처리하고 해당 장치에 응답한다.

* 이 방식의 결점은 모든 응용처리가 각종장치들에서 수행되고 인쇄출력 또는 화 일 입출력 등과 같은 기능만을 공유기 서버로 분산하고 있다. 그러므로, 예를 들어 화일의 읽기(read)를 요구한 장치에게 해당 화일의 전부를 전송해야 하며, 화일 수정(Update)시 이를 공유하고 있는 다른 장치와의 화일에 대한 일관성 (consistency)문제에 대한 해결방법(예, Lock/ Unlock 메카니즘 등) 등을 제공 해야 한다.

(나) 클라이언트/서버 처리환경

* 공유기 처리환경을 자연스럽게 확장한 개념으로, LAN의 규모와 지원되는 장치 들(PC 또는 워크스테이션 등)이 복잡하고 커짐에 따라 공유기 서버의 형태가 화일 또는 프린터 기능 분산 뿐만 아니라 각종 응용에 대한 분산 처리를 가능 하게 하는 처리환경이다.

* 이것은 분산환경에서 구성기기(워크스테이션)의 기능 및 계산 성능이 급속도로 발전함에 따라 각종 응용처리에 대한 분산이 가능할 수 있도록하는 요구와 부 합되어 자연 스럽게 도출되어 있다.

* 이때 분산 응용서비스를 요구하는 장치를 "클라이언트(요구자)"라고 한다.

* 즉, 클라이언트/서버 모델은 특정 응용의 의미있는 기능을 LAN사용자 간에 공 유할 수 있도록 하기 위해서, 그 응용의 처리는 클라이언트에서 실행하는 관련 된 응용으로 부터 요구를 받아 이에 대한 서비스를 제공하는 서버에서 실행하 는 처리의 분산된 구조이다. [그림 12.4]

* 이 모델에서 응용처리는 (반드시 균등하게는 아니지만) 클라이언트와 서버에게 분배되는 형태이며, 처리는 클라이언트가 개시하고 부분적으로 제어하지만 주 종속처리가 아니라 클라이언트와 서버가 모두 협력하여(Cooperative)수행한다.

* 이것의 예로는, 사이베이스(Sybase) 또는 SQL서버 같은 데이타베이스 서버등 이 있다.

* 클라이언트/ 서버 구조에서 필요한 사항

♠ 클라이언트와 서버 간의 신뢰할 수 있는 통신기능

♠ 클라이언트가 개시한 클라이언트/서버의 협동적인 상호 접속기능

♠ 클라이언트와 서버 간의 응용처리의 분배기능

♠ 클라이언트가 요구할 수 있는 서비스나 데이타에 대한 서버 주도의 제어기능

♠ 상충되는 클라이언트 요청에 대한 서버의 중재기능

* 클라이언트/서버 모델의 장점

♠ 새로운 데스크탑 컴퓨터 계산 기수?을 더욱 유용하게 사용할 수 있 다.

♠ 처리할 데이터의 출처 가까이에서 처리작업이 진행될 수 있다.

♠고성능 워크스테이션에서 가능한 그래픽사용자 인터페이스(GUI: Graphical User Interface)를 용이하게 사용할 수 있다.

♠ 특정 하드웨어 또는 소프트웨어 프랫폼에 독접적(proprietary)으로 의 존하지 않고 개방형 시스템으로 용이하게 채택될 수 있다.

* 그러므로, 잘 구현된 클라이언트/서버 모델은 소프트웨어 유지 및 관리비를 절 감하고 소프트웨어 이식성을 증가시키며, 기존 네트워크의 성능을 향상시키며, 개발자의 생산성 증가 및 개발 주기를 단축함으로서 응용 잔무를 줄일 수 있을 것이다.

* 클라이언트/서버 모델의 단점

♠ 응용 논리가 상당 부분 서버로 이관되면, 주종속 구조에서 발생할 수 있는 병목현상(Bottleneck)

이 일어날 수 있다. 즉, 자원의 소비자 수 가 증가하여 서버의 한정된 자원에 대한 요구가 높아

질 수 있다.

♠ 협동처리를 위한 분산 응용이 복잡해 질수 있다. 즉, 응용의 개발, 실 행시간, 관리 들에 따른 분산 응용간의 협동체계에 대한 복잡성이 발 생할 수 있다.

(4) 동등 처리(Peer-to-peer processing)

* 클라이언트에서 요구하고 서버에서 처리하는 클라이언트/서버 모델과는 달리, 구성되는 모든 시스템이 그 기능 및 처리의 관점에서 동등하며 서로가 서로에 게 서비스를 요청하기도 또는 서비스를 제공하기도 하는 처리 구조이다.[그림 12.5]

* 이것은 응용처리 분산의 이상적이고 최종적인 형태이며, 구성되는 하나의 시스 템은 다른 서버에 대한 클라이언트로서 또한 (자신을 포함하는) 다른 클라이언 트에 대한 서버로 동작한다.

* 이러한 형태의 처리는 데이타베이스를 망으로 구성하여 지원하고자 하는 것을 목표로 하고 있으나, 오늘날 완전한 동등처리를 지원하는 제품을 거의 없다. 이 는 동등처리의 구현을 어렵게하는 여러가지 문제들에 대한 기술적 해결이 요구 되기 때문이다.

* 그러나, 아직은 완전한 동등처리는 아니지만, 클라이언트/서버 모델이 분산시스 템을 개발하는데 합리적인 접근방법으로 이용되고 있다.

12.2 개방시스템

12.2.1 개방시스템 개요

* 모든 시스템들을 상호 접속하고 응용들을 하나의 시스템에서 다른 시스템 으로 이전할 수 있도록 하기 위해서, 기존의 독점 시스템(Proprietary system)들은 표준 인터페이스를 채택함으로서 그들의 구조를 개방(op en)할 수 있다.

* 개방시스템은 분산시스템의 프랫폼에 대한 상호운용성(interoprability)을 위해서 필요한 요구사항이다.

* "상호운용성"이란 기존의 여러 판매업체 시스템들이 서로 대화 또는 통신 할 수 있다는 것을 의미하며, "개방상호운용성"이란 시스템의 설계나 구 현을 어떤 특정 업체의 하드웨어 또는 소프트웨어 플랫폼에 의존하지 않 고 새로운 응용을 구축할 수 있도록 하는 것이다.

* 즉, 개방시스템은 특정 응용(application)이 특정 시스템에 의존하지 않고 모든 고객이 명시한 플랫폼들 간에 이식(Portavility)할 수 있도록 한다.

* 개방시스템의 상호운용성 및 이식성에 대한 요구 사항을 만족하기 위해서 는 해당 시스템에 대한 표준안에 따른 구축이 필요하게 된다.

* 이러한 표준안은 국제적 요구에 따라 산업계 또는 정부차원에서 주도적 역할을 하게 된다.

* 특정 시스템이 이러한 표준을 만족할때 만이 그 표준을 따르는 특정 업체 의 다른 구현제품과도 상호운용성 및 이식성을 보장할 수 있는 것이다.

12.2.2 개방시스템의 특징

* 프로그래밍, 통신, 네트워킹, 시스템관리, 표현, 시스템서비스, 그리고 응용 과 시스템서비스 간의 인터페이스에 대한 산업 표준안과 일치해야 한다.

* 시스템간의 응용 이 성이 있어야 한다.

* 응용의 성능과 처리율의 확장성(Scalability)이 있어야 한다.

* 시스템간의 상호운용성을 보장해야 한다.

12.2.3 개방시스템의 표준화기구들

* [그림 12.6]은 개방시스템의

표준화기구들이다.

(1)POSIX(Potable Operating

Interface for computer

Environment)

* 다른 동작환경 간의 확실한 일관성을 제공하기 위해서 IEEE TCOS가 정 의한 표준안이다.

(2) X/Open

*소프트웨어와 시스템의 비일치성(incompatbility)으로 일어나는 문 제를 해결하기 위해서 1984년에 서립된 비영리 기구로서, CAE(Common Application Environment), XPG3(X/Open Portability Guide 3판)에 포함된 명세서(Specification)를 저의하는데 중요한 역할을 한다.

(3) ISO( International Organizatio for Standard)

* 각종 표준안과 이를 구현하는 제품에 대한 촉진을 위한 국제 표준화기구 로, 개방형 시스템의 통신 참조모델(OSI Referencd Model)표준을 제안한 바 있다.]

(4) COS(Corperation for Open System)

* 이것은 OSI, ISDN(종합정보 통신망), 표준안 적합성시험(Conformance Testing) 인증시험(Certification)등의 분야에서 표준에 대한 노력을 하고 있다.

(5) OMG(Object Management Group)

* 여기서는 객체 지향(Object-orient)기술과 관련되는 시스템과 소프트웨어 개발에 대한 국제표준을 위       한 기구이다.

(6) OSF(Open Softward Foundation)/UI(UNIX Inernational)

* 이것은 개방시스템 환경을 위한 기술 공급자 역할을 하며, 핵심소프트웨 어 기술을 개발하고 이를       산업계에 공급하기 위한 특별한 표준 기구 이 다.

* OSF는 대표적인 분산시스템 구조인 분산 계산환경(DCE: Distributed Computing Environment)을, 그       리고 UI는 개방형 네트워크 계산(ONC: Open Network Computing)를 제안하였다.

여기서 여거된 대표적인 개방시스템을 위한 표준화그룹들은 시스템을 실제로 상용화하기 위한 개발방법 및 구현에 대해서는 관심사항이 아니다. 단지 이들은 그 시대의 기술적 발전 분야에서의 업계 및 정부차원에 대한 국가 또는 국제적 시스템 요구에 따라, 이들을 구성하는 기능들에 대한 여구와 이들을 시스템으로 반영하기 위한 요구사항들을 검토하고, 이들에 대한 기능적 명세를 작성하는 것을 목적으로 하는 것이다. 그러므로, 이들이 작성하여 하?의에 이른 표준들은 업계에서 제품으로 개발하여 구현할 지에 대한 여부는 그들의 범위에서 벗어나며, 단지 특정 표준에 대한 구현을 위한 지침을 제공함으로서 구현제품들간의 상호운용 가능성을 높일 수 있도록 하는 것이다.

12.3 분산 계산 환경(DCE)

* OSF(Open Softward Foundation) 표준기구에서 개발한 분산 개방형 시스템구조이다.

* EC(유럽공동 위원회)에서도 복수개의 업체들의 분산 응용을 개발하기 위해서 채택하고 있는 구조이다.

* 이 구조는 최종사용자와 소프트웨어 개발자들에게 진정한 분산 개방시스템을 이용할 수 있도록 하며, 서도 다른 하드웨어와 소프트웨어 환경에서 분산 응용을 이용하고 개발하는데 필요한 기본적인 구조를 제공하기 위해서 공개모집(RFT:Request For Technology)에 응모한 50여개의 업체들에서 응모하여 우수한 기술들을 채택 통합한 분산환경 구조이다.

* 이 구조의 대부분의 기술들은 HP, Apollo, IBM, DEC, Mirsoft Co., Locus, Transarc등이 연합하여 제출한 DECorum제안서에서 나온 기술들이다.

12.3.1 DCE의 구조

* DCE는 다음의 요소들을 통합한 환경이다.[그림 12.7]

♠분산화일 시스템(DFS: Dstributed File System)

♠디렉토리 서비스

♠원거리 절차 처리(RPC)

♠스레드 서비스(Thread Service)

♠시간서비스

(1) 분산화일 시스템(DFS: Disributed file System)

* 네트워크에 연결된 한 시스템상의 사용자가 다른 시스템의 화일로 지정된 데 이터에 접근하고 수정할 수 있도록 하는 시스템이다.

* 원걸리의 화일에 접근하고자 사용자가 작업하고 잇는 시스템을 "클라이언트 (Client)"라고 한다.

* 또한 데이타를 저장하고 클라이너트의 접근 요구에 대해서 서비스를 제공하는 시스템을 "화일서버(File Server)"라고 한다.

* 이 시스템은 클라이언트가 데이터를 읽어 수정할 수 있도록 해당 데이터의 사 본을 가져오는데 이를 캐쉬(Cache)라 한다. 클라이언트는 캐쉬된 데이터를 수 정하여 서버에 되돌려 준다.

* 이때, 여러 클라이언트에서 동시에 같은 데이터를 수정하려고 할 때, 데이터 내 용에 대한 불일치가 발생하여일관성(Consistency)문제가 발생할 수 있다.

* 이러한 일관성 문제를 해결하기 위해서, DFS에서는 캐쉬된 정보를 추적하는 토큰(Token)개념을 사용한다.

* 토큰개념은 여러 클라이언트에서 요청된 접근유형을 근거로 데이터를 캐쉬할 때, 서버가 수정 요구된 데이터에 대해서 통제하는 수단이다. 이때, 데이터를 수정하려면 클라이언트는 서버에게 기록토큰(Write Token)을 요구한다.

* 특정 클라이언트에게 할당된 기록토큰에 대해서 서버는 다른 클라이언트들에게 알려, 기록토큰이 없는 다른 클라이언트들은 같은 데이터에 대해서 일기(Read) 이외의 행위를 할 수 없도록 한다.

(가) DCE에서 제공하는 DFS의 특징

1) 접근보안(Security)와 보호(Protection)

# 사용자 인증확인(Authentication)기법과 권한을 가진 클라이언트에게 파일 접근을 허용할 수 있도록하는 접근제어리스트(Access Control List)를 지 원하여 파일에 대한 보안체계를 실현한다.

2) 데이터의 신뢰도(Data Reliability)

# 부적절하게 설계된 분산시스템에서는 한 클라이언트가 필요한 많은 자원에 의존하게 하여 그 중 하나만 잃어도 처리를 계속할 수 없도록 할 수 있다. 이러한 문제를 해결하기 위해서, DCE DFS에서는 서버 중 하나를 이용할 수 없게 되면, 자동적으로 중복된 다른 서버로 전환할 수 있도록 하는 네트 워크 서비스의 중복성(Replication)을 지원하여, 데이터처리의 신뢰성을 보장 한다.

3) 데이터의 가용성(Data Availability)

# 시스템관리자가 네트워크 또는 서버를 정지하지 않고도 네트워크 자원에 대 한 일상적인 유지보수 작업(예, 데이터 백업, 파일전송 등)을 수행할 수 있 다.

4) 성능(Performance)

# 효율적이고 확장가능한 시스템을 제공하기 위해서 파일의 상태정보와 데이 터를 클라이언트에게 캐쉬함으로서 서버 또는 네트워크의 작업 부담을 줄이 도록 하여 성능을 향상시킨다.

5) 효율적 관리(Manageability)

# 분산데이터 베이스를 이용하여 파일 위치, 인증, 및 클라이언트와 서버가 사 용하는 접근제어 리스트를 기억하여 클라이언트에 대한 관리 부분(Domain) 을 분할함 으로서, 효율적인 관리가 가능하도록 한다.

6) 표준적합성(Standard Conformance)

# IEEE POSIX 1003.1의 파일 시스템 표준안에 대한 적합성을 가지고 있다.

7) 망화일 시스템(NFS: Network File System)와의 상호 운용성

# 현재 SUN사의 표준인 NFS를 이용하는 클라이언트와 상호 운용될 수 있는 게이트웨이(Gateway)를제공하여 DCE DFS 서버와 경로를 열어 줄 수 있다.

(2) 디렉토리 서비스(Directory Service)

* 디렉토리 서비스는 특정인들의 정보 또는 네트워크 상에서 제공하는 서비스와 정보 등을 취합하여 제공하는 서비스이다. 일반적으로 이것은 이름(name) 또는 주소 등의 키(key) 정보를 중심으로 이와 고나련된 세부 정보들을 구축하고 있 다.

* 디렉토리 서비스의 예로 각 국가의 디렉토리를 포함할 수 있는 전화번호부 서 비스를 제공하는 시스템이라고 할 수 있다.

* DCE에서는 우편배달 응용이 사용자의 이르모가 주소(위치)를 조사하기 위해서 디렉토리 또는 다른 서비스를 제공하는 응용과 접촉한다. 여기서(네트워크 서 비스, 전자우편함, 또는 컴퓨터 등과 같이)개별적으로 이름을 부여할 수 있는 것을 "객체(Ovject)"라고 한다. 또한 각 객체는 디렉토리 서비스내에 상응하는 "항목(Entry)"을 가지며, 이들 각 항목은 해당 객체를 기술하는 "속성 (Attribute)"를 포함한다.

* 이때 이름 항목들을 모은 목록을 "디렉토리(Directory)"라고 한다.

* DCE에서 하나의 디렉토리는 다른 디렉토리를 포함할 수 있는 계층 구조로 구 성될 수 있다.

* 이러한 디렉토리서비스는 응용과 서비스로 하여금 적절한 디렉토리항목을 접근 하고, 각 속성들을 검색하도록 하여 접근할 수 있도록 하므로 어떤 객체가 특 정한 지정된 위치에 없어도 되는 객체의 위치독립성(Location independance)을 보장할 수 있다는 특성을 가진다.

* DCE 디렉토리서비스는 다른 구성요소들과 통합되며, CCITT와 ISO의 OSI X.500디렉토리 서비스 권고안을 따른다.

* 또한 OSF DCE는 서비스에 독립적인 응용 프로그래밍 인터페이스(API: Application Programming Interface)를 이용하며, 이 API는 X/Open 디렉토리 서비스(XDS) API 규격을 따르고 있다.

(3) 원거리 절차호출(RPC : Remote Procedure Call)

* 일반 고급언어의 서브루틴(Subroutine) 호출에 대한 확장 서비스로서, 호출된 절차의 실행코드는 응용에게 투명한 방식으로 원거리 처리기(Remote processor)에 상주하여 수행한다. 또한 이것은 DCE의 모든 구성요소를 상호연 결하여 함께 묶는 역할을 수행한다.

* 이것은 사용하기 쉬우며, 여러 네트워크 구조에게 투명하고, (다음에 설명할)스 레드(Thread)를 지원할 수 있도록 설계된다.

(4) 스레드(Thread)서비스

* 전형적인 DCE는 참여하는 프로세서들을 모두 연결하여 소정의 목적을 달성한 다. 그러므로, 각각의 프로세서들을 동시에 서로 다른 일을 수행할 수 있도록 하는 병렬처리(Parellel Processing)를 구현할 수 있다. 이때 DCE에서 사용되는 병렬처리 전략은 스레드(Thread) 전략이다.

* 스레드(Thread)전략은 수행 중인 프로그램의 하나의 인스턴스(Instance)와 그 주소 공간 내에 존재하고 동작하는 부프로세스(Subprocess, 또는 스레드)를 이 용한다.

* 각 스레드 간의 동기화 방식은 일반적인 세마포어(Semaphore)를 이용한다.

* DCE의 스레드(Thread)전략은 DEC사의 CMA(Concert Multithread Architecture)를 기본으로 하고 있다. 이는 이식성을 제공하며, POSIX 1003 응 용과 시스템 서비스 인터페이스 규격을 사용한다.

(5) 시간 서비스

* 모든 네트워크 노드의 클럭(Clock)과 네트워크 전체를 통제하는 클럭을 동기화 하는 기능을 가진 서비스이다.

* 이 서비스는 되도록 이면 완전 하고 단순하도록 하기 위해서 DEC사의 분산시 간동기화(Distributed Time Synchronization)서비스를 이용한다.

12.3.2 DCE 클라이언트/서버 모델의 구성

* DCE는 클라이언트/서버 개념에 적합하도록 설계된 것이다. 그러므로, DCE의 구성은 서비스를 요청하는 DEC클라이언트와 이에 대한 서비스를 제공하는 DCE서버로 구성된다.[그림 12.8]

* DCE의 구성요소들은 단순히 서버에 설치되는 소프트웨어 패키기가 아니라, 클 라이언트와 서버의 응용과 네트워킹 서비스 사이에 위치하여 실행된다.

* 또한 DCE는 많은 기본적인 서비스를 포함하고 있는 다중 구조 이지만, 최종의 사용자에게는 숨겨진 기능으호 제공된다.

* 분산시스템에 대한 표준의 연구에서 DCE구조는 필수적인 기능들을 제공하며 많은 공헌을 하고 있는 구조이다.

12.4 X윈도우 시스템

* 클라이언트/서버 모델을 구현하고 있는 최근의 상용자 입장에서 사용할 수 있는 그래픽 사용자 인터페이스는 다양하고 여러 가지 특징을 가질 수 있다.

* 이때, 클라이언트 입장에서 집단의 응용처리를 수행하는 네트워크 노드들에 서 돌아가는 응요들에 접근하여 표현하기 위한 서비스(표현서비스)를 수행할 필요가 있다.

* 그러므로, 클라이언트/서버 분산환경에서 표현관리를 위해 필요한 다음과 같 은 중요한 문제를 해결하기 위한 기술이 필요할 것이다.

# 서버에서 실행되는 응용을 클라이언트 시스템에 있는 표현논리로 투명하 게 접근할 수 있어야 한다.

# 클라이언트 시스템의 표현논리는 서버에서 실행되는 응용이 요청하는 표 현서비스를 실행한다. 그러므로, 실제로 표현논리 관점에서는 클라이언트 가 표현서비스의 서버 역할을 하며, 응용의 서버는 그 표현 논리서비스를 요청하는 클라이언트 역할이 된다.[그림 12.9]

* 이렇게 응용이 네트워크를 구성하는 워크스테이션 상에서 출력 표시를 투명 하게 할 수 있도록 접근하는 가장 잘 알려진 기술을 "X"또는 "X 윈도우 시스템"이라고 한다.

12.4.1 X윈도우 시스템 개요

* X는 MIT, IBM, 및 DEC 등에서 수행한 아테네(Athene) 프로젝트로 공동 개발 되었으며, 클라이언트/서버모델을 기본으로 한 것이다.

* X의 기능

# 원격 출력표시 워크스테이션에 존재할 수 있는 네트워크에 투명한 응용과 그 표현논리간의 통신 프로토콜 기능

# 장치와 독립적인 고성능 그래픽 제공기능

# 자유로운 윈도우 크기조정과 중첩 가능한 윈도우 계층배열 기능

* X는 복수개의 응용들을 한 개 이상의 윈도우를 이용하여 동시에 출력 표시할 수 있으며, 개발자들이 네트워크의 한 노드에서 실행하고 있는 동안 다른 노드 에서는 정보를 출력하고 입력을 받아 들일 수 있는 프로그램도 작성할 수 있는 등 동시 환경을 제공한다.

* [그림 12.9]는 X윈도우 시스템의 개념을 보인 것이다.

* X의 특징

# X윈도우 시스템의 구조모델인 X모델을 제공한다. 이것은 크게 출력표시 장 치, 서버 및 클라이언트 프로그램으로 구성되며, X서버 프로그램은 출력 표 시장치를 제어하고, 자신의 응용 프로그램과 X클라이언트들 사이의 인터페 이스를 제공한다. 이때 X클라이언트와 서버간의 표현논리를 위한 메시지 교 환을 X프로토콜이라고 한다.[그림 12.10]

# 윈도우 배열을 위한 트리형태의 계층 구조를 가진다. 윈도우들의 배열은 하 위의 종속된 자신의 윈도우들을 가지는 첫 번째 루트 윈도우로 구성된다.

# X는 사건 구동시스템(Event-driven System)이다. 즉, X 클라이언트와 서버 간의 구동은 X클라이언트가 X서버에서 하나의 사건(Event)(예, 윈도우 크 기 조정, 또는 키 입력 등의 사건)이 일어날 때 일시 정지하고, X서버의 프 로토콜을 보낼 때 수행을 재개한다.

# X 클라이언트/서버간의 통신을 위해서 사용되는 X프로토콜을 위해서 C 라 이브러리인 "Xlib"를 제공한다. 이것은 X윈도우 시스템과 함께 사용되는 유 용한 최저급의 인터페이스이다.

# Xlib의 제한사항을 완화하기 위해서 Xlib위에 다른 프로그램 계층 즉, 툴킷 (Toolkit)을 이용하여 X윈도우 응용들을 작성한다. 이것은 메뉴와 위젯 (Widgets)이라는 특별한 윈도우 객체를 포함하는 고급의 그래픽 기능을 제공한다.

# 위젯라이브러리는 버털, 스크롤바 등과 같은 추상 데이터 객체들인 위젯들 로 구성된다.

# 고유라이브러리는 위젯 라이브러리가 의존하는 객체지향 골격을 제공한다. 이것은 사건 메시지를 취할 뿐만 아니라 위젯의 생성, 삭제 및 관리를 하는 기능도 제공한다.

* 여기서, 클라이언트/서버 구조의 용어와 X모델의 용어에 다소 혼동될 수 있다. 클라이언트/서버에서는 정보를 출력하고 사용자와 상호 작용하는 노드를 "클라 이언트"노드라고 한다. 그러나, X모델에서는 이러한 클라이언트에 있는 표현논 리를 "X서버"라고 한다. 이때, 표현 논리를 요구하는 모드를 "X클라이언트"라 고 하며, 여기서 사용되는 X프로토콜을 "X11 프로토콜"이라고 한다.

12.4.2 X터미널

* 이것은 X서버기능을 수행하는 소프트웨어만을 가진 기계이다. 일반적으로, X윈 도우 시스템에서 X클라이언트들은 UNIX 호스트 또는 비 UNIX호스트에서도 실행할 수 있다.

* X터미널의 사용은 중앙집중 관리와 보안을 단순화하며, 유지관리와 설치르 ? 용이하게 하고 전기가 덜 든다는 장점이 있다.

12.4.3 MOTIF

* X윈도우 시스템은 완전한 그래픽사용자 인터페이스(GUI)가 아니다. 이것은 윈 도우 관리, 그래픽스들을 위한 GUI를 제공하기 위해서 기본적으로 제공되는 사건 취급 루티의 패키지(Package)이다.

* 그러므로, 완전한 GUI를 제공하기 위해서 일반적으로 윈도우관리기(Window Manager)를 제공해야 한다. 이것의 대표적인 GUI로는 OSF의 MOTIF와 SUN 사의 Open Look이 있다.

* 이것은 X윈도우 시스템을 기초로 한 것으로, DECwindows, HP사의 툴킷과 윈 도우 관리기, 그리고 마이크로 소프트사의 표현관리기들의 좋은 특징들을 통합 한 것이다.

* MOTIF의 특징은 다음과 같다.

(1) 이식성

# 모든 지원되는 플랫폼에 대해서 하나의 API를 사용하여 구현된다.

(2) 표준 적합성(Standard Conformance)

# 업계 표준인 X윈도우시스템을 기초로 하며 이를 따르는 표준과의 적합성을 가진다.

(3) 개발도구

# OSF/MOTIF는 X11 intrinsics위의 그래픽객체로 사용자 인터페이스 툴킷, 사용자 인터페이스 언어   (UIL), 윈도우 관리기(MWM)등 다양한 개발도구를 제공할 수 있다.

(4) 융 성(Flexibility)

# 새로운 유형의 입출력장치에 대한 융통성 및 확장성이 높다.

(5) 국제화

# X/Open의 NLS를 위한 XPG3(Portability Guide Issue 3) 표준안을 따른다.

(6) 플랫폼의 독립성

# X표준안에 완전히 부합되므로 극소수의 운영체제와 네트워크 프로트콜에 종 속성을 가진다. 이   를 지원하는 운영체제로는 IBM의 UNIX운영체제인 AIX, UNIX BSD 4.3, Data General UX, Dell     Unix system, MS-DOS2.0 이후 버 전, HP-UX 버전 6.5/7.0, Macintosh, MIPS RISC/OS, SCO       UNIX, OS/2, Sun OS 3.5/4.0, Ultrix, UNIX System V 3.2/4.0, 그리고 VMS 등이다.

12.4.4 Open Look

* Sun Microsystem사와 AT&T사에서 개발한 그래픽사용자 인터페이스(GUI: Graphic User Interface)이다.

* 이것도 OSF/MOTIF와 마찬가지로 특정한 구현에 의존하지 않는다.

12.4.5 기타 GUI들

* OSF/MOTIF와 Open Look이외에도 많은 GUI들이 구현되어 있다. 이중에서 도 잘알려 진 것들은 다음과 같다.

* 멕킨토시(Macintosh)는 일반적인 GUI들 중 가장 오래되고 가장 발달된 것이 다. 멕킨토시 GUI는 가격이 비싼 반면, 그래픽과 출판응용 분야에 많이 사용되 었다.

* 마이크로소프트 윈도우즈(MS Windows)는 포괄적이고 잘 다듬어진 GUI로, 기 존의 개인용컴퓨터의 MS-DOS의 지원을 받아 수행되지만, 대부분의 MS-DOS 의 당점을 보완하고 있다. 1995년에 과거의 MS윈도우 3.0을 보완하여 좀더 새 로운 형태의 윈도우 95가 출시되었으며, 1997년에는 좀더 향상된 개념의 윈도 우 97버전이 사용될 전망이다.

* OS/2의 표현관리기는 마이크로소프트사와 IBM사가 공동으로 개발한 것이며, MS 윈도우에 근거를 두고 있다. 기존의 MS-DOS의 제한사항을 무력화하는 포괄적이고 강력한 GUI를 제공한다.

* DECwindows는 DEC사의 UNIX시스템(Ultrix)과 VMS시스템을 위한 GUI이다. 이것은 X 윈도우 시스템에 구축된 OSF/MOTIF의 기본이다. DECwindows는 텍스트필드, 버튼, 그크롤링 및 표준대화상자 같은 유용한 GUI기능들을 포함하 고 있다.

* NeXT GUI는 인상적인 회색점의 출력표시를 제공하며, 광디스크를 사용함으로 서 GUI기능의 새로운 차원을 소개한 것이다. NeXT는 다소 가격이 높다는 단 점 때문에 널리 보급되지는 못했다.

12.4.5 호환성 도구들

* 호환성도구는 앞의 GUI들을 모두 포함하는 공통적인 특성을 주어, 응용 개발 자들이 서로 다른 여러개의 GUI를 배우기 보다는 주어진 플랫폼에서 원하는 GUI를 생성하는 하나의 도구에 익숙하도록 하여 사용할 수 있도록 하는 것이 다.

* 그러므로, 이것은 하나의 응용에서 사용하는 GUI에 따라, 응용코드는 GUI의 API(Application Program Interface)고유기능들을 수행해야 한다. 그러나 모든 GUI를 포함할 수 있는 API도구를 사용하면, 응용개발자 입장에서는 어떤 특정 프랫폼에 의존하지 않을 수 있다는 큰 장점을 가질 수 있다.

* [그림 12.11]은 여러 GUI에 의존하는 API를 사용할 경우이다.

* [그림 12.12]는 호환성 도구의 API를 사용할 경우의 구조를 보인 것이다.

* 호환성도구의 대표적인 Oracle사에서 개발한 Oracle 툴킷과 XVT사의 XVT(eXtensibal Virtual

Toolkit)등이 있다.