미들웨어란 무엇인가?
기본적으로 미들웨어는 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해 주는 소프트웨어다. 미들웨어는 애플리케이션들을 직접 연결하는 방식에 비해 몇 가지 중요한 이점이 있다. 애플리케이션들을 직접 연결할 경우, 일반적으로 관련된 애플리케이션 모두에 코드를 추가해 각 애플리케이션이 서로 대화하도록 지시해야만 한다. 반면 미들웨어는 이 대화 과정에서 번역기라는 독립적인 제3자의 역할을 함으로써 애플리케이션 모두에 코드를 추가하는 엄청난 작업을 할 필요가 없다.
미들웨어의 종류
기업들이 통합과 관련된 여러 업무를 더 잘 처리하기 위해 여러 종류의 미들웨어를 도입하는 일은 이례적인 일이 아니다. 일반적으로 더 복잡한 통합 작업이 요구되는 더 큰 기업들은 EAI(Enterprise Application Integration)와 같은 더 정교한 미들웨어 제품을 선호하기 마련이다.
RPC와 데이터베이스 게이트웨이
설명
아마도 이것들은 진짜 미들웨어가 아닐 수 있지만, 문맥상으로 볼 때 전혀 관련이 없다고도 말할 수 없다. 양쪽 모두 애플리케이션 연결 기능을 다루는 더 오래된 방법들로, 특히 분산 환경에서 그렇다.RPC는 원격절차호출(Remote Procedure Call)의 약어로, 서버 애플리케이션에 있는 어떤 절차를 촉발하는 클라이언트 애플리케이션의 코드중 한 조각을 말한다. 오늘날의 정의에 따르면 RPC는 미들웨어가 아니다. 비록 지금도 사용되고는 있지만, RPC는 여러 개의 애플리케이션을 서로 묶으려 할 때 프로그래머들이 반복해서 코딩 작업을 해야만 하는 방식이기 때문이다. 따라서 애플리케이션의 수가 늘어나면 RPC 외의 다른 미들웨어 방식이 더 효과적이다. 현재 RPC는 미들웨어들에 의해 대체되고 있다. 반면 데이터베이스 게이트웨이는 데이터 접근을 용이하게 할 수 있는 제3의 역할을 하기 때문에 RPC보다 미들웨어의 정의에 더 들어맞는다. 데이터베이스 게이트웨이는 애플리케이션들을 특정 종류의 데이터베이스 플랫폼에 연결해 준다. 일례로 HP 3000 서버에 있는 중대형 애플리케이션 및 데이터를 가진 기업을 생각해 보자. 많은 새로운 상용 애플리케이션들이 오라클이나 사이베이스 같은 유명 데이터베이스에 접근할 수 있도록 고안되었지만, 이 애플리케이션들이 더 오래된 HP 3000용 ‘터보이미지(TurboImage)’ DBMS를 이용하려면 약간의 도움이 더 필요한데, 이때 데이터베이스 게이트웨이가 그런 도움을 주다. 이런 것이 데이터베이스 게이트웨이의 전형적인 활용 사례다.
메시지-지향 미들웨어(MOM)
제품
MQ시리즈(MQSeries) - 아이비엠MSMQ - 마이크로소프트스마트소켓츠(SmartSockets) - 탈라리안(Talarian)
설명
MOM은 오래된 미들웨어 기술이다. 메시지-지향 미들웨어는 이메일과 비슷한 방식으로 데이터를 메시지 형태로 만들어 하나의 애플리케이션에서 다른 애플리케이션으로 전달한다. 사실 상용 MOM 제품이 보급되기 전, 세계 최대의 곡물회사인 카길 같은 대기업은 데이터 전송을 위해 휴렛팩커드의 오픈메일(OpenMail) 이메일 엔진을 토대로 MOM 통합 도구들을 자체 개발했었다.이메일의 원리를 이해하고 있다면, MOM의 원리도 알 수 있을 것이다. 그리고 이메일의 경우처럼, MOM의 장점은 애플리케이션 A의 데이터가 대기열에 가서 기다릴 수 있기 때문에 애플리케이션 B는 나중에 필요한 시점에서 그 데이터를 불러올 수 있다는 것이다. 이로 인해 일례로 애플리케이션 A가 정보를 전달하려는 순간 애플리케이션 B가 우연히 다운돼 재부팅을 해야만 하는 등의 상황에서도 데이터의 무결성이 보호될 수 있다. 이런 비동기적 접근법을 사용해, 미들웨어 서버는 애플리케이션 B가 다시 작동을 시작할 때까지 기다린 후 대기열의 데이터를 올바른 순서에 따라 던져준다.(이 같은 데이터 메시지의 전송 유보는 앞에서 말한 지속성의 한 예다.)
전형적인 사용처
MOM은 대개 데이터에 대해 수행되어야 하는 운영이 비교적 많지 않고 데이터 교환 시간이 그리 중요하지 않은 단순한 일방향의 교환을 위해 사용된다. 일례로 서로 다른 데이터베이스에 저장되어 있는 저축성 예금과 수표 계좌의 연결을 들 수 있다. 고객이 수표 계좌에 대한 자신의 주소를 갱신하면, 이에 따라 총괄 시스템은 이 고객의 다른 계좌의 주소들도 갱신하게 되지만, 이 갱신 작업에 3초나 10분이 걸린다고 해서 그것이 그리 큰 문제는 되지 않을 것이다.
거래처리(TP) 모니터
제품
CICS, 오픈CICS(OepnCICS) - 아이비엠BEA 턱시도(Tuxedo) - BEA 시스템즈
설명
거래처리(TP) 모니터는 본래 메인프레임 환경을 위해 개발된 유래가 오래된 기술이다.(MOM보다 오래됐다.) TP 모니터는 거래 데이터의 작성과 읽기를 관리하기 위해 전위처리 애플리케이션들과 후방지원 데이터베이스 사이에 위치한다.TP 모니터는 메시지-지향 미들웨어보다 더 애플리케이션들에 간여한다. 이것은 TP 모니터가 제공하는 고유의 서비스 이점을 활용하기 위해서 TP 모니터들이 애플리케이션들에 대해 더 많은 수정 작업을 요구한다는 의미다. TP 모니터는 또한 특수 보안 기능과 데이터 무결성 기능을 제공한다.
전형적인 사용처
TP 모니터는 대규모의 거래가 처리되는 환경에 맞는다. 다시 은행 업무의 예를 들면, 현금자동입출금기(ATM)에서 기록되는 모든 거래는 해당 금융기관이 고객의 계좌 잔고를 정확하게 추적할 수 있도록 세심하게 다뤄져야만 한다. 이 일을 TP가 담당한다. 특히 TP 모니터는 복수의 애플리케이션들이 보안이나 디렉토리 서비스 같은 동일한 기본 기능 몇 가지를 동시에 필요로 할 때 유용하다.“TP 모니터의 이점은 새로운 애플리케이션들을 작성할 때 이 애플리케이션들에 맞춰 이런 서비스들을 다시 개발할 필요가 없다는 것이다.”라고 부쉐는 말한다. “애플리케이션들은 다른 종류의 미들웨어를 통해 서로 의사소통할 수 있지만, TP 모니터는 그 이상의 기능을 제공한다.” 따라서 TP 모니터를 단순한 일대일 애플리케이션 연결성을 위해 사용할 경우, 그것은 “성능 과잉”이 될 것이라고 그녀는 덧붙인다.
객체 모니터(Object Monitors)
제품
아이비엠 컴포넌트 브로커(Component Broker)비지브로커 ITS(VisiBroker Integrated Transaction Server) - 인프라이즈(Inprise)마이크로소프트 트랜잭션 서버(Transaction Server)
설명
객체 모니터(Object Monitors, 객체 TP 모니터라고도 불린다.)는 앞에서 설명한 TP 모니터의 발전된 버전이다. 새롭게 태동중인 제품군인 객체 모니터는 TP 모니터의 기능을 그대로 제공하지만, 바로 아래에서 설명될 객체요구브로커(ORB) 모델들과 같은 객체-지향 표준에 따라 작성된다는 점이 다르다. ORB 모델을 사용하기 때문에, 기업은 애플리케이션에 손을 대지 않고도 TP 모니터에 의해 제공되는 서비스들을 수정할 수 있다.
전형적인 사용처
온라인 쇼핑 장바구니 및 관련 주문처리 애플리케이션들 같은 전자상거래 애플리케이션이 객체 모니터를 사용하는 경향이 있다. 이것은 전자상거래 애플리케이션들이 서로 다른 많은 원천들로부터 데이터를 끌어올 필요가 있고, 갈수록 늘어나는 기능성에 맞춰 자주 수정될 필요가 있기 때문이다. 이에 필요한 유연성으로 인해 컴포넌트
기반의 아키텍처가 인기를 끌고 있는데, 이 아키텍처는 시스템의 다른 부분에 영향을 주지 않으면서도 시스템의 한 부분을 바꿀 수 있는 능력을 제공하기 때문이다. 또 객체 모니터는 웹 상거래시 필요한 고도의 데이터 무결성과 초대규모의 거래 용량 처리 능력을 제공한다.
객체요구브로커(ORBs)와 아키텍처
아키텍처 표준들
코바(Corba, Common Object Request Broker Architecture) - OMG(Object Management Group)엔터프라이즈 자바빈즈(EJB, Enterprise JavaBeans) - 썬 마이크로 시스템즈COM+(Component Object Model) - 마이크로소프트
설명
ORB는 애플리케이션과 네트웍 서비스(보안, 성능 모니터링, 프린트 등) 사이에서 정보를 전달한다. ORB는 서비스들과 상호운영 애플리케이션들을 위한 더 넓은 아키텍처 표준들의 핵심 부분이다. 위에 나열한 세 가지는 이런 표준 가운데 가장 유명한 주자들이다. 이 표준 가운데 하나를 구현한 실제 미들웨어 제품의 한 예가 최신 코바 표준 3.0에 기초하고 있는 아이오나(Iona) 테크놀러지로스社의 ‘오빅스 2000(Orbix 2000)’이다.ORB의 기본 전제는 애플리케이션들이 다른 애플리케이션들뿐 아니라 동일한 서비스들에도 접근할 필요가 있다는 것이다. 오늘날의 컴퓨팅 현실은 이기종 컴퓨팅 하드웨어와 운영체제 플랫폼 및 다양한 개발 도구들과 언어들로 구축된 애플리케이션들이 혼재돼 있다. 이 모든 컴포넌트(구성요소)가 서로 통신할 수 있도록 하기 위해서, 기업은 일관된 객체-지향 아키텍처가 필요한 것이다.그리고 비즈니스 파트너나 공급자들과 데이터 공유를 해야 하는 기업의 애플리케이션들이 늘어나면서, 이런 종류의 표준화된 접근법은 통합 작업을 크게 단순화시켜 줄 수 있다.코바는 역사적으로 유닉스 환경에 초점을 맞추고 있으며, 반면 엔터프라이즈 자바빈즈는 자바 언어로 개발하고 있는 기업에 가장 잘 맞는 아키텍처다. 좋은 소식은 이 두 표준이 서로 협력하고 있으며, 조화를 이루고 있다는 것이다. 코바 지지자들은 최소한의 작업으로 자바 개발 프로젝트를 통합할 수 있게 될 것이다.
그러나 부쉐는 현시점에서 코바 모델로 개발된 서버 객체들이 COM+ 모델로 개발된 서버 객체들과 잘 통신되지 않는다는 점을 지적한다.(반대도 마찬가지) 이것은 기업들이 이 2개 ORB 아키텍처 가운데 어느 한쪽을 선택해 사용해야지, 혼합 사용해서는 안된다는 것을 의미한다. 윈도우 NT/2000 서버 사용자들은 COM+에 의해 최적의 서비스를 받을 수 있다. 반면 유닉스 서버 사용자들(마이크로소프트의 윈도우를 탑재한 데스크탑 컴퓨터에 의해 접근되는 경우에도)은 코바가 최고의 선택일 것이다.
특별히 주목할 사항
마이크로소프트의 미들웨어 구조와 제품 계획들은 계속 진화되고 있으며, 그에 따라 관련 용어도 바뀌고 있다. 따라서 이 회사의 계획을 세심하게 따라가지 않는 사람들에겐 이것이 혼란의 한 원인이 될 수 있다. COM+의 원래 명칭은 단순히 COM이었다. 그러다 DCOM(Distributed Common Object Model)이 되었다. 부쉐에 따르면, 마이크로소프트는 현재 DCOM에서 벗어나 현재의 이름인 COM+으로 옮겼다고 한다. 그러나 COM+도 미들웨어 범주를 넘은 제품과 서비스를 포함하고 있는 DNA(Distributed Network Architecture)란 더 커다란 마이크로소프트 아키텍처 계획의 일부일 뿐이다.
기업 애플리케이션 통합(EAI)
제품
액티브엔터프라이즈(ActiveEnterprise) - 팁코 소프트웨어(Tibco Software)네온 임팩트(NEON Impact) - 뉴 에라 오브 네트웍스(New Era of Networks)이-게이트(e-Gate) - STC(Software Technologies Corp.)비즈니스웨어(BusinessWare) - 비트리아 테크놀러지(Vitria Technology)제네바 엔터프라이즈 인티그레이터(Geneva Enterprise Integrator) - 레벨 8 시스템즈(Level 8 Systems)(그 외 다수)
설명
EAI 업체들은 EAI 제품을 미들웨어라고 부르는데 커다란 거부감을 느끼고 있다. 기업(enterprise)이란 매력적인 단어를 포함하고 있는 EAI에 미들웨어란 명칭은 어울리지 않는다는 것이다. 그러나 EAI의 근본 개념은 통합이다. 불행하게도 EAI란 단어는 마케팅 목적에 아주 유용하기 때문에, 많은 업체가 각자의 제품이 제공하는 기능성들이 그처럼 폭이 넓음에도 불구하고 이 용어를 굳이 사용하고 있는 것이다. EAI는 미들웨어 이상이다. ORB와 같이 EAI 도구들은 일반적으로 데이터 전송을 위한 기저 메커니즘으로 메시지 브로커(broker)를 사용한다. 여기에 EAI 도구들은 데이터를 받으려는 각각의 특정한 애플리케이션의 입맛에 맞춘 형태로 데이터를 분석, 복제, 변환할 수 있다. 대기업의 경우, MOM과 EAI를 모두 사용할 수는 있지만, 아주 탄탄한 EAI 제품을 사용하고 있다면, MOM 같은 더 낮은 수준의 통합 도구를 사용하지 않아도 된다.EAI 도구들이 제공하게 될 차세대 기능성(이 기능성으로 인해 EAI와 다른 종류의 미들웨어는 한층 명확히 구분이 될 것이다.)은 비즈니스 프로세스 규칙들(rules)의 지원이다. EAI는 사용자가 적절한 비즈니스 프로세스를 정의하고 이런 규칙에 따라 데이터를 통합할 수 있게 해 준다. 일례로 적절한 권한자에 의해 승인을 받기만 하면, 구매 애플리케이션에서 수취 계정 애플리케이션으로 데이터를 자동으로 이동시키도록 규칙을 정할 수 있다.허위츠 그룹에 따르면, 비트리아社의 제품이 이런 종류의 비즈니스 프로세스 규칙을 지원한 최초의 제품이라 한다. 현재 다른 경쟁사들도 기업의 내부 및 공급망 전체에 이 기능을 추가할 수 있도록 각사 제품에 대해 작업하고 있다.XML(eXtensible Markup Language) 지원은 EAI 제품의 최대 장점중 하나다. 또한 EAI 제품은 비쯔톡(BizTalk, 마이크로소프트가 후원하는 B2B 통신 프로토콜)과 로제타넷(RosettaNet, 전자 업계 통신 프로토콜을 만들기 위한 이 업계 컨소시엄) 등 표준도 지원한다.
대부분의 EAI 제품의 경우, 사용자는 중앙 모듈을 구매한 후 각자가 필요로 하는 특정 인터페이스만을 선택적으로 구매할 수 있다. 일례로 STC의 이-웨이(e-Way) 제품군은 SAP, 시벨, 로터스 노츠, 다양한 후방지원 데이터베이스들을 위한 개별적인 ‘어댑터들(adapters)’을 포함하고 있다. 또한 대부분의 EAI 업체는 고객이 자체적으로 개발한 애플리케이션들을 연결할 필요가 있을 때, 고객의 프로그래밍 작업을 지원하는 서비스 부서를 갖고 있다. “그들은 80-20 법칙을 따르는 것처럼 보인다. 다시 말해 인터페이스의 80%는 미리 구축된 것을 사용하도록 하고, 나머지 20%는 고객이 작업을 하도록 하는 것이다.”라고 컨설팅 업체인 ARC의 부사장 존 캠패네일은 말한다.
전형적인 사용처
EAI는 많은 애플리케이션들을 통합해야 하는 대기업에 적합하다. 일례로 카길은 ERP, 유지보수 관리, 재고, 비용 회계 시스템 등 다양한 애플리케이션들을 연결하기 위해 BEA 시스템즈社의 이링크(eLink) EAI 제품을 사용하고 있다.
결론
당신의 회사에 적합한 미들웨어는 어떤 것인가? 유일한 대답은 없다. 서로 다른 애플리케이션과 통합 요구에 맞춰 각기 다른 미들웨어를 사용해야 한다. 반면 단일화된 접근법은 규모의 경제성을 제공하고 개발에 따른 수고를 덜어줄 것이다. 어느 경우든 각 용어가 무엇을 의미하는지 알고 있을 때, 선택의 고민은 훨씬 가벼워질 것이다.
출처 :
기본적으로 미들웨어는 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해 주는 소프트웨어다. 미들웨어는 애플리케이션들을 직접 연결하는 방식에 비해 몇 가지 중요한 이점이 있다. 애플리케이션들을 직접 연결할 경우, 일반적으로 관련된 애플리케이션 모두에 코드를 추가해 각 애플리케이션이 서로 대화하도록 지시해야만 한다. 반면 미들웨어는 이 대화 과정에서 번역기라는 독립적인 제3자의 역할을 함으로써 애플리케이션 모두에 코드를 추가하는 엄청난 작업을 할 필요가 없다.
미들웨어의 종류
기업들이 통합과 관련된 여러 업무를 더 잘 처리하기 위해 여러 종류의 미들웨어를 도입하는 일은 이례적인 일이 아니다. 일반적으로 더 복잡한 통합 작업이 요구되는 더 큰 기업들은 EAI(Enterprise Application Integration)와 같은 더 정교한 미들웨어 제품을 선호하기 마련이다.
RPC와 데이터베이스 게이트웨이
설명
아마도 이것들은 진짜 미들웨어가 아닐 수 있지만, 문맥상으로 볼 때 전혀 관련이 없다고도 말할 수 없다. 양쪽 모두 애플리케이션 연결 기능을 다루는 더 오래된 방법들로, 특히 분산 환경에서 그렇다.RPC는 원격절차호출(Remote Procedure Call)의 약어로, 서버 애플리케이션에 있는 어떤 절차를 촉발하는 클라이언트 애플리케이션의 코드중 한 조각을 말한다. 오늘날의 정의에 따르면 RPC는 미들웨어가 아니다. 비록 지금도 사용되고는 있지만, RPC는 여러 개의 애플리케이션을 서로 묶으려 할 때 프로그래머들이 반복해서 코딩 작업을 해야만 하는 방식이기 때문이다. 따라서 애플리케이션의 수가 늘어나면 RPC 외의 다른 미들웨어 방식이 더 효과적이다. 현재 RPC는 미들웨어들에 의해 대체되고 있다. 반면 데이터베이스 게이트웨이는 데이터 접근을 용이하게 할 수 있는 제3의 역할을 하기 때문에 RPC보다 미들웨어의 정의에 더 들어맞는다. 데이터베이스 게이트웨이는 애플리케이션들을 특정 종류의 데이터베이스 플랫폼에 연결해 준다. 일례로 HP 3000 서버에 있는 중대형 애플리케이션 및 데이터를 가진 기업을 생각해 보자. 많은 새로운 상용 애플리케이션들이 오라클이나 사이베이스 같은 유명 데이터베이스에 접근할 수 있도록 고안되었지만, 이 애플리케이션들이 더 오래된 HP 3000용 ‘터보이미지(TurboImage)’ DBMS를 이용하려면 약간의 도움이 더 필요한데, 이때 데이터베이스 게이트웨이가 그런 도움을 주다. 이런 것이 데이터베이스 게이트웨이의 전형적인 활용 사례다.
메시지-지향 미들웨어(MOM)
제품
MQ시리즈(MQSeries) - 아이비엠MSMQ - 마이크로소프트스마트소켓츠(SmartSockets) - 탈라리안(Talarian)
설명
MOM은 오래된 미들웨어 기술이다. 메시지-지향 미들웨어는 이메일과 비슷한 방식으로 데이터를 메시지 형태로 만들어 하나의 애플리케이션에서 다른 애플리케이션으로 전달한다. 사실 상용 MOM 제품이 보급되기 전, 세계 최대의 곡물회사인 카길 같은 대기업은 데이터 전송을 위해 휴렛팩커드의 오픈메일(OpenMail) 이메일 엔진을 토대로 MOM 통합 도구들을 자체 개발했었다.이메일의 원리를 이해하고 있다면, MOM의 원리도 알 수 있을 것이다. 그리고 이메일의 경우처럼, MOM의 장점은 애플리케이션 A의 데이터가 대기열에 가서 기다릴 수 있기 때문에 애플리케이션 B는 나중에 필요한 시점에서 그 데이터를 불러올 수 있다는 것이다. 이로 인해 일례로 애플리케이션 A가 정보를 전달하려는 순간 애플리케이션 B가 우연히 다운돼 재부팅을 해야만 하는 등의 상황에서도 데이터의 무결성이 보호될 수 있다. 이런 비동기적 접근법을 사용해, 미들웨어 서버는 애플리케이션 B가 다시 작동을 시작할 때까지 기다린 후 대기열의 데이터를 올바른 순서에 따라 던져준다.(이 같은 데이터 메시지의 전송 유보는 앞에서 말한 지속성의 한 예다.)
전형적인 사용처
MOM은 대개 데이터에 대해 수행되어야 하는 운영이 비교적 많지 않고 데이터 교환 시간이 그리 중요하지 않은 단순한 일방향의 교환을 위해 사용된다. 일례로 서로 다른 데이터베이스에 저장되어 있는 저축성 예금과 수표 계좌의 연결을 들 수 있다. 고객이 수표 계좌에 대한 자신의 주소를 갱신하면, 이에 따라 총괄 시스템은 이 고객의 다른 계좌의 주소들도 갱신하게 되지만, 이 갱신 작업에 3초나 10분이 걸린다고 해서 그것이 그리 큰 문제는 되지 않을 것이다.
거래처리(TP) 모니터
제품
CICS, 오픈CICS(OepnCICS) - 아이비엠BEA 턱시도(Tuxedo) - BEA 시스템즈
설명
거래처리(TP) 모니터는 본래 메인프레임 환경을 위해 개발된 유래가 오래된 기술이다.(MOM보다 오래됐다.) TP 모니터는 거래 데이터의 작성과 읽기를 관리하기 위해 전위처리 애플리케이션들과 후방지원 데이터베이스 사이에 위치한다.TP 모니터는 메시지-지향 미들웨어보다 더 애플리케이션들에 간여한다. 이것은 TP 모니터가 제공하는 고유의 서비스 이점을 활용하기 위해서 TP 모니터들이 애플리케이션들에 대해 더 많은 수정 작업을 요구한다는 의미다. TP 모니터는 또한 특수 보안 기능과 데이터 무결성 기능을 제공한다.
전형적인 사용처
TP 모니터는 대규모의 거래가 처리되는 환경에 맞는다. 다시 은행 업무의 예를 들면, 현금자동입출금기(ATM)에서 기록되는 모든 거래는 해당 금융기관이 고객의 계좌 잔고를 정확하게 추적할 수 있도록 세심하게 다뤄져야만 한다. 이 일을 TP가 담당한다. 특히 TP 모니터는 복수의 애플리케이션들이 보안이나 디렉토리 서비스 같은 동일한 기본 기능 몇 가지를 동시에 필요로 할 때 유용하다.“TP 모니터의 이점은 새로운 애플리케이션들을 작성할 때 이 애플리케이션들에 맞춰 이런 서비스들을 다시 개발할 필요가 없다는 것이다.”라고 부쉐는 말한다. “애플리케이션들은 다른 종류의 미들웨어를 통해 서로 의사소통할 수 있지만, TP 모니터는 그 이상의 기능을 제공한다.” 따라서 TP 모니터를 단순한 일대일 애플리케이션 연결성을 위해 사용할 경우, 그것은 “성능 과잉”이 될 것이라고 그녀는 덧붙인다.
객체 모니터(Object Monitors)
제품
아이비엠 컴포넌트 브로커(Component Broker)비지브로커 ITS(VisiBroker Integrated Transaction Server) - 인프라이즈(Inprise)마이크로소프트 트랜잭션 서버(Transaction Server)
설명
객체 모니터(Object Monitors, 객체 TP 모니터라고도 불린다.)는 앞에서 설명한 TP 모니터의 발전된 버전이다. 새롭게 태동중인 제품군인 객체 모니터는 TP 모니터의 기능을 그대로 제공하지만, 바로 아래에서 설명될 객체요구브로커(ORB) 모델들과 같은 객체-지향 표준에 따라 작성된다는 점이 다르다. ORB 모델을 사용하기 때문에, 기업은 애플리케이션에 손을 대지 않고도 TP 모니터에 의해 제공되는 서비스들을 수정할 수 있다.
전형적인 사용처
온라인 쇼핑 장바구니 및 관련 주문처리 애플리케이션들 같은 전자상거래 애플리케이션이 객체 모니터를 사용하는 경향이 있다. 이것은 전자상거래 애플리케이션들이 서로 다른 많은 원천들로부터 데이터를 끌어올 필요가 있고, 갈수록 늘어나는 기능성에 맞춰 자주 수정될 필요가 있기 때문이다. 이에 필요한 유연성으로 인해 컴포넌트
기반의 아키텍처가 인기를 끌고 있는데, 이 아키텍처는 시스템의 다른 부분에 영향을 주지 않으면서도 시스템의 한 부분을 바꿀 수 있는 능력을 제공하기 때문이다. 또 객체 모니터는 웹 상거래시 필요한 고도의 데이터 무결성과 초대규모의 거래 용량 처리 능력을 제공한다.
객체요구브로커(ORBs)와 아키텍처
아키텍처 표준들
코바(Corba, Common Object Request Broker Architecture) - OMG(Object Management Group)엔터프라이즈 자바빈즈(EJB, Enterprise JavaBeans) - 썬 마이크로 시스템즈COM+(Component Object Model) - 마이크로소프트
설명
ORB는 애플리케이션과 네트웍 서비스(보안, 성능 모니터링, 프린트 등) 사이에서 정보를 전달한다. ORB는 서비스들과 상호운영 애플리케이션들을 위한 더 넓은 아키텍처 표준들의 핵심 부분이다. 위에 나열한 세 가지는 이런 표준 가운데 가장 유명한 주자들이다. 이 표준 가운데 하나를 구현한 실제 미들웨어 제품의 한 예가 최신 코바 표준 3.0에 기초하고 있는 아이오나(Iona) 테크놀러지로스社의 ‘오빅스 2000(Orbix 2000)’이다.ORB의 기본 전제는 애플리케이션들이 다른 애플리케이션들뿐 아니라 동일한 서비스들에도 접근할 필요가 있다는 것이다. 오늘날의 컴퓨팅 현실은 이기종 컴퓨팅 하드웨어와 운영체제 플랫폼 및 다양한 개발 도구들과 언어들로 구축된 애플리케이션들이 혼재돼 있다. 이 모든 컴포넌트(구성요소)가 서로 통신할 수 있도록 하기 위해서, 기업은 일관된 객체-지향 아키텍처가 필요한 것이다.그리고 비즈니스 파트너나 공급자들과 데이터 공유를 해야 하는 기업의 애플리케이션들이 늘어나면서, 이런 종류의 표준화된 접근법은 통합 작업을 크게 단순화시켜 줄 수 있다.코바는 역사적으로 유닉스 환경에 초점을 맞추고 있으며, 반면 엔터프라이즈 자바빈즈는 자바 언어로 개발하고 있는 기업에 가장 잘 맞는 아키텍처다. 좋은 소식은 이 두 표준이 서로 협력하고 있으며, 조화를 이루고 있다는 것이다. 코바 지지자들은 최소한의 작업으로 자바 개발 프로젝트를 통합할 수 있게 될 것이다.
그러나 부쉐는 현시점에서 코바 모델로 개발된 서버 객체들이 COM+ 모델로 개발된 서버 객체들과 잘 통신되지 않는다는 점을 지적한다.(반대도 마찬가지) 이것은 기업들이 이 2개 ORB 아키텍처 가운데 어느 한쪽을 선택해 사용해야지, 혼합 사용해서는 안된다는 것을 의미한다. 윈도우 NT/2000 서버 사용자들은 COM+에 의해 최적의 서비스를 받을 수 있다. 반면 유닉스 서버 사용자들(마이크로소프트의 윈도우를 탑재한 데스크탑 컴퓨터에 의해 접근되는 경우에도)은 코바가 최고의 선택일 것이다.
특별히 주목할 사항
마이크로소프트의 미들웨어 구조와 제품 계획들은 계속 진화되고 있으며, 그에 따라 관련 용어도 바뀌고 있다. 따라서 이 회사의 계획을 세심하게 따라가지 않는 사람들에겐 이것이 혼란의 한 원인이 될 수 있다. COM+의 원래 명칭은 단순히 COM이었다. 그러다 DCOM(Distributed Common Object Model)이 되었다. 부쉐에 따르면, 마이크로소프트는 현재 DCOM에서 벗어나 현재의 이름인 COM+으로 옮겼다고 한다. 그러나 COM+도 미들웨어 범주를 넘은 제품과 서비스를 포함하고 있는 DNA(Distributed Network Architecture)란 더 커다란 마이크로소프트 아키텍처 계획의 일부일 뿐이다.
기업 애플리케이션 통합(EAI)
제품
액티브엔터프라이즈(ActiveEnterprise) - 팁코 소프트웨어(Tibco Software)네온 임팩트(NEON Impact) - 뉴 에라 오브 네트웍스(New Era of Networks)이-게이트(e-Gate) - STC(Software Technologies Corp.)비즈니스웨어(BusinessWare) - 비트리아 테크놀러지(Vitria Technology)제네바 엔터프라이즈 인티그레이터(Geneva Enterprise Integrator) - 레벨 8 시스템즈(Level 8 Systems)(그 외 다수)
설명
EAI 업체들은 EAI 제품을 미들웨어라고 부르는데 커다란 거부감을 느끼고 있다. 기업(enterprise)이란 매력적인 단어를 포함하고 있는 EAI에 미들웨어란 명칭은 어울리지 않는다는 것이다. 그러나 EAI의 근본 개념은 통합이다. 불행하게도 EAI란 단어는 마케팅 목적에 아주 유용하기 때문에, 많은 업체가 각자의 제품이 제공하는 기능성들이 그처럼 폭이 넓음에도 불구하고 이 용어를 굳이 사용하고 있는 것이다. EAI는 미들웨어 이상이다. ORB와 같이 EAI 도구들은 일반적으로 데이터 전송을 위한 기저 메커니즘으로 메시지 브로커(broker)를 사용한다. 여기에 EAI 도구들은 데이터를 받으려는 각각의 특정한 애플리케이션의 입맛에 맞춘 형태로 데이터를 분석, 복제, 변환할 수 있다. 대기업의 경우, MOM과 EAI를 모두 사용할 수는 있지만, 아주 탄탄한 EAI 제품을 사용하고 있다면, MOM 같은 더 낮은 수준의 통합 도구를 사용하지 않아도 된다.EAI 도구들이 제공하게 될 차세대 기능성(이 기능성으로 인해 EAI와 다른 종류의 미들웨어는 한층 명확히 구분이 될 것이다.)은 비즈니스 프로세스 규칙들(rules)의 지원이다. EAI는 사용자가 적절한 비즈니스 프로세스를 정의하고 이런 규칙에 따라 데이터를 통합할 수 있게 해 준다. 일례로 적절한 권한자에 의해 승인을 받기만 하면, 구매 애플리케이션에서 수취 계정 애플리케이션으로 데이터를 자동으로 이동시키도록 규칙을 정할 수 있다.허위츠 그룹에 따르면, 비트리아社의 제품이 이런 종류의 비즈니스 프로세스 규칙을 지원한 최초의 제품이라 한다. 현재 다른 경쟁사들도 기업의 내부 및 공급망 전체에 이 기능을 추가할 수 있도록 각사 제품에 대해 작업하고 있다.XML(eXtensible Markup Language) 지원은 EAI 제품의 최대 장점중 하나다. 또한 EAI 제품은 비쯔톡(BizTalk, 마이크로소프트가 후원하는 B2B 통신 프로토콜)과 로제타넷(RosettaNet, 전자 업계 통신 프로토콜을 만들기 위한 이 업계 컨소시엄) 등 표준도 지원한다.
대부분의 EAI 제품의 경우, 사용자는 중앙 모듈을 구매한 후 각자가 필요로 하는 특정 인터페이스만을 선택적으로 구매할 수 있다. 일례로 STC의 이-웨이(e-Way) 제품군은 SAP, 시벨, 로터스 노츠, 다양한 후방지원 데이터베이스들을 위한 개별적인 ‘어댑터들(adapters)’을 포함하고 있다. 또한 대부분의 EAI 업체는 고객이 자체적으로 개발한 애플리케이션들을 연결할 필요가 있을 때, 고객의 프로그래밍 작업을 지원하는 서비스 부서를 갖고 있다. “그들은 80-20 법칙을 따르는 것처럼 보인다. 다시 말해 인터페이스의 80%는 미리 구축된 것을 사용하도록 하고, 나머지 20%는 고객이 작업을 하도록 하는 것이다.”라고 컨설팅 업체인 ARC의 부사장 존 캠패네일은 말한다.
전형적인 사용처
EAI는 많은 애플리케이션들을 통합해야 하는 대기업에 적합하다. 일례로 카길은 ERP, 유지보수 관리, 재고, 비용 회계 시스템 등 다양한 애플리케이션들을 연결하기 위해 BEA 시스템즈社의 이링크(eLink) EAI 제품을 사용하고 있다.
결론
당신의 회사에 적합한 미들웨어는 어떤 것인가? 유일한 대답은 없다. 서로 다른 애플리케이션과 통합 요구에 맞춰 각기 다른 미들웨어를 사용해야 한다. 반면 단일화된 접근법은 규모의 경제성을 제공하고 개발에 따른 수고를 덜어줄 것이다. 어느 경우든 각 용어가 무엇을 의미하는지 알고 있을 때, 선택의 고민은 훨씬 가벼워질 것이다.
출처 :
