문서요약 - 미들웨어는 어디에 by Vinoski

제목: 미들웨어는 어디에(Where is Middleware?)

저자: Steve Vinoski, 아일랜드

문서유형: 저널 서문(총 3 페이지), 2002년

 

미들웨어 기술 동향에 대해 간단히 소개한 저널 컬럼

---

미들웨어(Middleware)

• 이질적인 컴퓨팅 시스템 통합을 위한 미들웨어는 여러 해 동안 다양한 형태로 존재해 옴. 대표적인 예로 IBM의 CICS(Customer Information Control System), IBM의 MQ 시리즈, Corba(Common Object Request Broker Architecture), Microsoft의 COM(Component Object Model), J2EE(Java 2 Enterprise Edition), Web services 등이 있음
• 거의 모든 유형의 애플리케이션, 프로그래밍 언어, 운영 체제, 하드웨어가 이런 미들웨어 시스템을 이용한 통합 노력의 목표가 되어왔으므로 미들웨어는 어디서든 찾아볼 수 있다.
• 시스템에 인위적인 동질성(artificial homogeneity)을 도입하는 미들웨어가 다양성(diversity)과 이질성(heterogeneity) 문제를 완화하기는 하지만 완전히 해결하지는 못함. 더구나 미들웨어 시스템들도 결국은 서로가 다르며 시스템 관리자는 다른 미들웨어를 사용하는 두 개 또는 그 이상의 시스템들을 통합할 필요가 생길 수 있다.

미들웨어 분류(Middleware Classification)

원격 프로시져 호출(Remote Procedure Call) vs. 비동기식 메시징(Asynchronous Messaging)

• 원격 프로시셔 호출(RPC)은 원격의 서비스를 마치 애플리케이션 내부의 프로시져 호출(procedure calls)인 것처럼 다룰 수 있게 한다. RPC는 호출된 서비스가 호출자의 리퀘스트를 수행하는 동안 호출자의 실행을 막는다(block). 즉 호출한 쓰레드(calling thread)가 그 실행을 멈추고 리퀘스트의 정상 반환이나 또는 타임아웃 같은 에러 상황이 발생할 때까지 기다림
• 대기열 추상화(queuing abstraction)에 기반하는 메시징 시스템에서는 소비자가(consumers) 조회하고 액션을 취할 수 있는 데이터를 생산자가(producers)가 큐에 게시한다(post).
• RPC 시스템은 프로시져 지향 또는 객체 지향인 반면 메시징 시스템은 데이터 지향 또는 문서 지향(document-oriented)이다. 즉, RPC 기반의 애플리케이션이 시스템 서비스를 제공하는 객체와 기능(functions)을 중심으로 하는 반면 메시징에 기반한 미들웨어 애플리케이션은 정보(information)를 중심으로 한다.
• 근래에 등장한 Web services는 대부분의 미들웨어와 달리 RPC 위주의 시스템과 메시지 위주의 시스템 양쪽 모두를 잘 지원하는 유연성을 가짐

언어 종속적(Language-Specific) vs. 언어 독립적(Language-Independent)

• 복잡한 컴퓨팅 시스템은 하나의 언어로만 작성된 경우가 드물기 때문에 많은 미들웨어 시스템이 여러 다른 프로그래밍 언어로 작성된 애플리케이션의 통합을 지원한다. 예를 들어, Corba는 여러 언어를 Corba 오브젝트의 contracts을 정의하는 IDL(Interface Definition Language)로 매핑하는 것을 지원함
• 반면에 단일 프로그래밍 언어 사용이라는 단순화된 가정에 기반하는 미들웨어 시스템도 다수 존재한다. 예) J2EE

소유주 독점의(Proprietary) vs. 표준 기반의(Standards-Based)

• 미들웨어 표준은 제품간의 상호운용성(interoperability)과 이식성(portability)을 가능하게 하여 고객이 특정 제품에 얽매이는 것을 막고 사용자가 품질에 기반하여 미들웨어를 선택할 수 있게 한다.
• 하지만 실 세계에서는 이런 이상적인 목표가 완전하게 달성되지는 못함. 선전과는 달리 표준에 충실하지 않은 미들웨어 벤더도 있을 수 있고, 표준에 충실하다 해도 표준이 다루지 않는 부분을 커버하기 위해 벤더의 고유 기능(proprietary features)을 도입해야만 하는 경우도 있으며, 더욱이 모든 가능한 문제를 커버할 수 있는 표준은 없기 때문이다.
• 표준화 노력은 오랜 시간과 많은 비용이 소요되거나 관료적이고 정치적인 문제가 될 수도 있다. 따라서 많은 업체들이 경쟁 업체로부터 비밀을 보호할 수 있는 자사 고유의 제품을 개발하고 이를 시장의 사실상 표준으로 만들려는 노력을 기울임(예, Microsoft)

임베디드(Embedded) vs. 엔터프라이즈(Enterprise)

• 미들웨어는 전통적으로 엔터프라이즈 시스템(여러 조직 부서와 많은 이종의 컴퓨팅 시스템이 포함되며 대개 비즈니스 프로세스 자동화를 향상하고자 함)을 겨냥함
• 특수한 하드웨어 환경과 한정된 자원의 소프트웨어 요구사항을 가진 임베디드 시스템은 최근까지는 미들웨어의 출입 금지 구역이었지만 하드웨어와 소프트웨어의 발전으로 임베디드 미들웨어가 점차 실현 가능해짐(하지만 여전히 실시간 데드라인 및 예측성 제약 등이 임베디드 미들웨어의 크기와 가능한 기능에 제한을 가함)
• 엔터프라이즈 미들웨어는 동적으로 구성가능하며(configurable) 시스템 오퍼레이터가 오퍼레이션이 적절한지 모니터 할 수 있는 런타임 관리 기능(runtime management capabilities)을 필요로 한다. 임베디드 미들웨어와 마찬가지로 엔터프라이즈 미들웨어도 런타임 오버헤드를 다루는 경향이 있지만 memory footprint 같은 이슈들은 대개 무시한다.
• 엔터프라이즈 미들웨어는 다수의 이종 시스템들을 통합해야 하므로 사용자는 신규 시스템을 통합하는 것이 얼마나 용이한지로 엔터프라이즈 미들웨어를 평가한다. 반면 실시간/임베디드 미들웨어 평가에는 memory footprint, 성능, 예측성(predictability) 등을 고려한다.