MIDAS에 관하여

여러분 분산 처리 기술에 대해서 이번 기회에 확실히(??) 알아보도록 하죠...

요즘 기업체 동향인 분산 시스템 환경에서는 사용자가 그 위치와 무관하게
신뢰성 있고 빠른 서비스를 받을 수 있도록 하는 방법으로 다계층(Multi-Tier)
환경 구축 방법의 하나로 MIDAS(Multi-Tier Distributed Application Service)를
사용하기도 하죠...

이 MIDAS에 대하여 함께 공부하기로 하는 것입니다.
우선, MIDAS를 구체적으로 다루기 전에 다계층 응용프로그램 구조에 대해 간단히
살펴보면....

다계층 클라이언트/서버 응용프로그램은 인터넷 또는 LAN상에서 비즈니스로직이
구현이 서버 응용프로그램과 프리젠테이션 로직이 구현된 클라이언트 프로그램이
서로 통신하면서 원하는 서비스를 구현하는 것을 말합니다.

다계층 응용 프로그램의 모델 중 가장 간단한 형태인 3-계층은 클라이언트
응용프로그램, 응용프로그램 서버, 리모트 데이터베이스 서버로 구성되어
있습니다...

이에 대한 기능과 장점을 알아보도록 하죠.  

◇ 클라이언트 응용프로그램

  사용자 시스템에 사용자 인터페이스를 제공하죠.

◇ 응용프로그램 서버(서버 프로그램)

  모든 사용자가 접근 할 수 있는 중앙 네트워크에 위치하며,

  흔히, 데이터 서비스를 제공하는 기능을 갖습니다.

◇ 리모트 데이터베이스 서버

  관계형 데이터베이스 시스템을 제공합니다.


◆ 다계층(Multi-Tier) 응용 프로그램의 장점

☞ 응용프로그램 서버에 통합적으로 비즈니스 로직을 구현함으로써

   여러개의 각 클라이언트 응용프로그램마다 중복된 비즈니스

   로직을 구현할 필요가 없으므로 유지보수 비용이 적게 든다.

☞ 가벼운 클라이언트 응용프로그램은 인스톨, 환경설정이 용이하다.

☞ 몇 개의 시스템에 응용프로그램 서버를 분산시킴으로써 Load

   Balancing 기능을 수행하며, 한 시스템이 다운되어도 여유 시스템이

   가동되므로 Fail Over기능을 구현할 수 있다.

☞ 다계층 각 계층별로 보안단계를 분류하여 서로 접근 권한을 달리

   부여함으로써 보안 기능을 강화 할 수 있다.


- MIDAS기술과 특징 #1

MIDAS는 앞의 다계층 응용 프로그램의 장점을 지니면서 클라이언트 응용프로그램과
응용프로그램 서버 사이에 데이터베이스 정보를 통신하는 메커니즘을 제공합니다.

MIDAS기술을 자세히 살펴보면 빠르고 쉽게 개발할 수 있도록 디자인되었으며,
최고의 개발 속도와 호환성을 높이기 위해 MIDAS는 서버용 데이터베이스에 접근
가능하며, 비즈니스 룰과 데이터 Constraint를 지원합니다.

클라이언트 단에 데이터 Constraint가 정의되면 자동으로 서버 단에서
클라이언트 단으로 Constraint가 전달됩니다.

이것은 네트워크의 프래픽을 줄여 효율을 증진시키게 되며, 에러 처리 부하를
감소시켜주는 효과가 있습니다. 또한 사용자의 응용프로그램 속도를 높여주는
효과도 있습니다.

MIDAS는 다계층의 특성상 비즈니스 룰이 서버에 위치함으로써 가벼운
클라이언트를 유지하고 클라이언트 단에 환경설정이 거의 필요없으므로 배포 후
유지보주 또한 쉽고 비용이 적게 듭니다.

이는 요즘 추세인 사용자의 위치 이동이 잦은 응용프로그램에 매우 적합한
기술입니다. 또한, Load Balancing 기능이 있어 높은 서버 이용률과 Fail-Over
기능으로 시스템을 안정적으로 운영할 수 있도록 하여 줍니다.

- Remote DataBroker

Remote DataBroker를 쉽게 말하면 Cliente Program과 Server Program을
상호연결해주는 기반 기술이라고 합니다.

이것을 이용하게 되면 클라이언트 프로그램의 덩치나 작업량이 가볍게 줄일 수
있습니다. 즉, 클라이언트 시스템에서 프로그램의 크기가 작아진다는 의미입니다.

Remote DataBroker를 사용할 때는 140kbyte짜리인 하나의 DLL만 사용하고 배포
방법으로 델파이의 웹을 이용한다면 수동으로 설치하거나 환경설정을 할 필요성이
없어져 배포가 매우 용이해집니다.

클라이언트 프로그램은 단순히 인터페이스만을 구현하고 비즈니스 로직을 가지고
있지 않아 프로그램의 소스 대부분이 GUI(Graphic User Interface)에 해당됩니다.

클라이언트 프로그램이 작아지는 이유는 2-계층 프로그램처럼 비즈니스 로직을
따로 구현하지 않고 사용자 인터페이스 부분만을 구현하는 것 외에도 다른 것이
있습니다.

이는 3-계층 프로그램을 구축할 때에는 클라이언트 시스템에 프로그램 이외에
데이터베이스 연결을 위한 미들웨어 (델파이 SQL Link 또는 각종 벤더사들이
제공하는 ODBC 드라이버)와 각 데이터베이스 벤더에서 제공하는 클라이언트
모듈(인포믹스의 I-NET, 오라클의 SQL*NET)이 따로 필요하지 않다는 것입니다.

결국 가볍고 사용자 인터페이스 위주의 클라이언트 응용프로그램을 사용하게
되어 클라이언트측으로의 설치, 설정, 유지 보수 작업이 거의 없어지게 되는
장점을 지니고 있습니다.


- ConstraintBroker

데이터베이스와 관련된 응용프로그램에서 가장 중요한 것은 사용하고 있는
데이터가 정말 유효한 데이터인가 하는 것입니다. 만약 데이터베이스
응용프로그램에서 사용자가 잘못된 데이터를 가지고 수정하려고 할 때 어떤
순서로 어떤 작업을 하는 것일까요. 다음과 같은 순서로 작업을 처리할 것입니다.

1. 클라이언트 응용프로그램이 서버에 데이터를 전송한다.
2. 트랜잭션을 시작한다.
3. 데이터 수정을 시도한다.
4. 잘못된 데이터이므로 수정이 불가능하다.
5. 트랜잭션을 취소한다.
6. 데이터베이스 서버는 클라이언트 응용프로그램으로 에러 메시지를 전송한다.
7. 사용자는 정확한 데이터를 재전송한다.

이 과정을 살펴보게 되면, 데이터 무결성을 위해서 항상 유효한 데이터만이
데이터베이스 서버에서 적용된다는 것을 알 수 있습니다.

그러나, 이 메커니즘은 유효하지 않은 데이터는 처리되지 않으므로 비효율적으로
네트워크에 의하여 전송만 되고 처리되지 않습니다.

결국, 네트워크의 트래픽만을 증가시키게 되고, 사용자는 기다린 보람이 없이
그냥 시간이 흐른 뒤 에러 메시지만을 보게 될 것입니다.

이러한 단점을 보완하기 위한 일반적인 방법은 개발자가 데이터 무결성에 관련된
룰을 클라이언트 응용프로그램에서 구현하는 것입니다.

이렇게 하게 되면, 유효한 데이터만이 네트워크를 통해서 데이터베이스 서버에
전송되고 될 것입니다. 따라서 최종 사용자는 잘못된 자료에 대한 반응 시간이
빨라져서 작업의 효율이 높아지게 될 것입니다.

그러나, 무결성에 관련된 룰을 클라이언트에서 재 구현하는 것은 개발자의
노력이 필요하게 되고 데이터베이스가 변경될 때마다 룰을 가진 클라이언트측의
모든 응용프로그램이 수정되고 재배포되어야 하는 불편함을 가지게 됩니다.

이에 비해서 ConstraintBroker 기술은 개발자가 데이터 무결성 룰을 하나의
위치에서 관리할 수 있도록 해주면서 네트워크 트래픽은 최소화시키는 효율성
높은 응용프로그램을 생성할 수 있도록 해주는 뛰어난 솔루션입니다.

ConstraintBroker는 Remote DataBroker와 함께 운영되는데, 그 방법을 살펴보게
되면 Remote DataBroker는 클라이언트 요청을 받아서 데이터베이스로 자료를
질의하고, 다시 클라이언트로 되돌려 주게 됩니다.

이 때, ConstraintBroker가 작동되면 Remote DataBroker는 제약사항을 검색하기
위해 데이터 딕셔너리(Data Dictionary)로 추가 질의를 보내게 됩니다.
데이터 딕셔너리는 자료의 무결성에 대한 정보를 포함하는 테이블입니다.
이 테이블은 BDE(Borland Database Engine:ODBC보다 빠르다고 평가되어
있습니다)가 지원하는 어떤 종류의 데이터베이스에도 저장될 수 있습니다.

ConstraintBroker는 개발가에게 무결성 룰의 배포를 간단하고 자동화된 방법으로
제공합니다. 룰의 배포를 동적으로 할 수 있게 되면 개발자들이 많은
애플리케이션을 보다 쉽게 관리하여 유지할 수 있게 됩니다.

예를 들어, 데이터베이스에서 룰이 수정되면 개발자는 데이터 딕셔너리를
수정해야 할 필요가 발생합니다. 데이터 딕셔너리가 수정된 후에 Remote
DataBroker는 내부적으로 수정을 위해 하나의 함수를 호출할 수 있게 되는데
클라이언트가 그 데이터를 요청하게 되면, 재프로그래밍, 재컴파일, 재배포,
재설정 등의 과정이 필요없이 새로운 룰이 클라이언트로 전달됩니다.
예를 들어, ConstraintBroker가 구현되어 있는 곳에서 잘못된 데이터를 가지고
수정하려고 한다면 이제는 다음과 같은 순서로 작업이 처리됩니다.

1. 클라이언트 응용프로그램이 데이터베이스 서버로 자료를 전송합니다.
2. 클라이언트 단계에서 즉시 에러가 발생되어 유효하지 않은 데이터임
  을 사용자에게 알려줍니다.
3. 사용자는 정확한 데이터 재전송을 합니다.

여기에서 사용자는 잘못된 데이터 입력에 대해 빠르게 반응을 하여 대처할 수
있게 됩니다. 이것은 네트워크나 데이터베이스 서버가 데이터의 검증을 위해
전혀 관여하지 않기 때문입니다.

정확한 데이터 입력으로 Constraint가 통과되면 데이터베이스 서버로 레코드가
전송될 것입니다.

데이터 딕셔너리는 사용자 Constraint와 사용자 정의 에러 메시지를 추가하는
기능을 포함하고 있습니다. 이것은 응용 프로그램에 트정 룰을 추가하는 기능을
의미합니다. 예를 들어, 데이터 무결성 룰은 값이 0보다 큰 경우에만 입력되도록
하기 위한 것인 경우입니다.

인프라이즈에서 제공하는 툴에서 데이터 딕셔너리의 수정, 관리를 위해 사용하는
뛰어난 툴로 SQL 익스플로러가 있습니다. SQL 익스플로러를 이용하여 테이블,
앨리어스, 스토어드 프로시져, 트리거, 무결성 룰의 생성과 수정을 관리할 수
있으며, 또한 손쉽게 각 데이터베이스를 관리할 수 있게 합니다.

오라클, 인터베이스, 사이베이스, 인포믹스, DB2, MS SQL 서버 등의 스키마
정보를 나타내 주며, SQL 익스플로러에서 개발자는 SQL문을 사용하여 자료를
보거나 편집할 수 있습니다.


- Business ObjectBroker

Business ObjectBroker 기능을 이용하기 위해서는 델파이에서 제공하는 툴인
OLEnterprise를 인스톨하여 사용해야 하는데, OLEenterprise은 클라이언트와
서버 시스템 사이에 Remote Procedure Calls(RPCs) 프로토콜을 이용하여
오토메이션 마샬링을 호출하거나, 상호통신을 하는데 관여한다. Business
ObjectBroker기능과 서비스하던 서버가 갑자기 다운되었을 때 다른 정상
서버로 서비스를 받도록 하는 Fail-Over기능을 제공한다. 앞에서 설명한
Remote DataBroker는 DCOM(Distributed Common Object Model)을 기반으로 하여
설계되었으며, 이러한 DCOM은 위와 같은 기능을 제공하기 어렵다.

Business ObjectBroker와 OLEnterprise는 OLE 자동화 서버(OLE Automation
Server, COM 서버)나 DCE/RPC 서버가 Load Balancing과 Fail-Over 기능을 가질
수 있도록 해준다. 다시 말해 이러한 기능을 제공하기 위한 조건은
응용프로그램이 OLE자동화 서버나 DCE/RPC서버 기능이 있어야 한다는 말이다.

Business ObjectBroker는 비즈니스 오브젝트브로커(Business ObjectBroker),
오브젝트 팩토리(Object Factory), 오브젝트 에이전트(Object Agent),
오브젝트 익스플로러(Object Explorer)등 다시 4가지 요소로 구성된다.


~ 비지니스 오브젝트브로커

비즈니스 오브젝트브로커는 클라이언트에서 요청한 서버 응용프로그램이
설치되고 등록된 서버 시스템 중에서 하나를 클라이언트에 연결시켜 주는
역할을 한다. 이를 위해 서버 응용프로그램은 그것의 레지스트리 항목을
만들고자 하는 곳에서 글로벌 레지스트리를 제공한다. 이것은 클라이언트
응용프로그램이 네트워크상의 응용프로그램 서버 중의 하나로 연결할 때
참조할 수 있는 유일한 정보이다.


~ 오브젝트 팩토리

서버에 의해 사용되는 오브젝트 팩토리는 RPC 서버이면서 OLE 자동화
클라이언트이다. OLE 자동화 클라이언트로 행동할 때에는 원거리 OLE
요청(Remote OLE Request)이 발생할 때 클라이언트 시스템상의 오브젝트
에이전트에 의해 RPC(Remote Procedure Call)통신으로 오브젝트 팩토리에
전달된다. 그러면 오브젝트 팩토리는 원격 클라이언트 응용프로그램을 대신하여
OLE 요청을 다시 발생시킨다. 또한, RPC 서버로의 원격지 요청은 오브젝트
팩토리를 통하지 않고 오브젝트 에이전트가 RPC 오브젝트와 직접 통신한다.


~ 오브젝트 에이전트

클라이언트에서 사용되는 것으로 OLE 자동화 서버이면서 RPC 클라이언트이다.
이것은 원격지 서버를 대신하여 OLE 자동화 서버처럼 작동한다. 원격 요청은
오브젝트 에이전트를 통해 전달된다. 원격 OLE 오브젝트를 위한 요청은
오브젝트 에이전트가 그 요청을 서버 시스템의 오브젝트 팩토리로 RPC를
사용하여 전달하고, 원격 RPC 오브젝트를 위한 요청은 오브젝트 에이전트가
레지스트리로부터 인터페이스 정의를 읽어 동적으로 RPC 요청을 만들고 그것을
서버로 보낸다.


~ 오브젝트 익스플로러

사용자가 기업 내 환경을 탐색할 수 있도록 오브젝트들과 각종 서비스 내용을
동적으로 볼 수 있는 유틸리티이다. 오브젝트 익스프로러는 클라이언트에서
오브젝트를 공유하고 재사용할 수 있도록 불러오기(Import)/내보내기(Export)
기능을 제공한다. 오브젝트를 개발하는 개발자는 오브젝트를 사용할 수 있도록
하기 위해 오브젝트 익스프로러를 사용한다. 익스플로러는 기업내의 각종
오브젝트에 대한 로컬, 원격, 글로벌 레지스트리를 검색할 수 있다. 하나의
오브젝트가 선택되면 익스플로러는 자동적으로 오브젝트에 대한 접근을
가능하게 하기 위해 요구되는 모든 정보를 가져와서 사용자 로컬 레지스트리에
등록시킨다.


지금까지는 클라이언트가 연결할 서버를 결정하는 방법은 무작위 선택(Random)
알고리즘에 따르고 있다. 그러나 인프라이즈(Inprise)사는 앞으로 이것을
서버의 CPU 사용도, I/O등과 물리적인 거리를 고려하여 좀더 논리적으로
구성하기 위한 기술을 개발하고 있다고 한다.

지금까지 개략적으로 MIDAS의 기반 기술인 Remote DataBroker, ConstraintBroker,
Business ObjectBroker에 대해서 살펴보았다.

개념적으로 살펴본 것이기 때문에 바로 직접 시험해 보기에는 다소 설명의
부족이 보이는 것 같아 안타까운 생각이 든다. 다음에 기회가 된다면 더욱
상세히 설명을 할 것을 약속하면서 이만 MIDAS에 대한 개략적인 내용은
줄일까 한다.

2009년 글