컴포넌트 개발을 위한 환경

컴포넌트 개발을 위한 환경

컴포넌트로부터 어플리케이션을 조립할 수 있다는 것은 컴포넌트들이 일정한 개발 환경 표준을 준수해야 한다는 것을 의미한다. 다른 산업에서 부품을 구매하는 것과 마찬가지로 컴포넌트 역시 주어진 일정한 기술 표준에 맞아야만 플러그 인이 된다. 그렇기 때문에 플러그 인을 하는 조각의 형태는 매우 중요하며 우리는 이것을 컴포넌트 표준(Component Standard)이라 부른다. 현재 시장에는 마이크로소프트사의 COM+, 썬마이크로시스템즈사의 EJB, OMG(Object Mamagement Group)와 CORBA(Common Object Request Broker Architecture)와 같은 몇몇 컴포넌트 표준 모델들을 소개하고 있으며, 이미 시장에서 상당한 사용자를 확보하고 있다. 이 절에서는 앞서 언급한 몇 가지 컴포넌트 관련 환경에 대해 간략히 소개한다.

.NET

COM이란 컴포넌트와 컴포넌트를 사용하는 클라이언트 응용 프로그램들이 대화하는 표준적인 방법을 규정한 사양이며 COM+는 이것을 확장한 기술이다. 사실 동적링크 라이브러리(Dynamic Link Library), 동적 데이터 교환(Dynamic Data Exchange), 원격 프로시져 호출(Remote Procedure Call)등 분할된 단위 응용 프로그램이 서로 통신할 수 있을 방법들이 이미 존재하였지만, 이들의 통신 매커니즘이 서로 달랐을 뿐만 아니라 컴포넌트의 버전관리도 쉽지 않았다. 더욱이 이들 단위 응용 프로그램이 서로 다른 언어를 사용하여 작성되었다면 단위 응용 프로그램 사이의 통신 조차도 쉽지 않았다. 이러한 문제점들을 해결하기 위하여 마이크로소프트사는 COM이라는 바이너리 표준을 제시하였으며 현재까지 상업적으로 성공한 컴포넌트 표준으로 평가 받고 있다.

COM컴포넌트의 가장 큰 특징은 언어 중립성을 보장하기 때문에 C와 같은 절차적 언어나 C++같은 객체지향 언어, 그리고 Visual Basic등 다양한 프로그래밍 언어를 지원한다는 점이다. 이것은 C#과 같은 CLR(Common Language Runtime)을 지원하는 언어로 계속 확장되고 있다. 또한 뛰어난 위치 투명성(Location Transparency)을 제공하여 클라이언트에게 동일한 접근 방법을 제공한다. 또한 마이크로소프트사가 제공하는 개발 도구, 성숙한 스펙 및 수많은 참조 사이트는 다른 컴포넌트 모델과 비교하였을 때 가장 많은 개발자를 확보할 수 있는 원동력이 되었다.

COM+는 윈도우 플랫폼 위에서 동작하는 대규모 분산 시스템을 위한 프레임워크의 기술적 토대를 제공하는데, 얼마 전까지 이러한 프레임워크를 우리는 DNA(Distributed internet Architecture)라고 불렀으며 현재 .NET이 이것을 대체한다. 개발자는 .NET 프레임워크가 제공하는 JIT활성(Just-In-Time Activation), 동기화, 트랜잭션, 오브젝트 풀링, 이벤트, 보안 등의 컴포넌트 서비스를 사용함으로써 대규모 분산 시스템을 보다 쉽게 개발할 수 있을 것이다.

CCM(CORBA Component Model)

네트워크에 의한 분산 컴퓨팅이 가능해짐에 따라서 정보시스템은 다양한 이기종 컴퓨터 사이의 상호 운용성, 자원 공유, 병렬성, 위치 투명성 등을 제공할 필요가 생겼으며, 이에 따라 소프트웨어 개발에서도 새로운 기술의 등장이 필요하였다. OMG는 추상화, 캡슐화, 상속성, 다형성 등을 제공하는 객체지향 기술과 분산 컴퓨팅을 통합한 CORBA라는 표준 아키텍처를 제안하여 이러한 문제를 해결하려고 시도 하였다.

CORBA의 가장 두드러진 특징은 언어나 플랫폼, 프로토콜 등에 종속적이지 않은 완전히 개방된 산업 표준을 제공한다는 점이다. CORBA가 갖고 있는 이러한 장점에도 불구하고 개발자들은 여전히 방대한 양의 표준에 압도당하고 있다. 뿐만 아니라 전통적인 CORBA오브젝트 모델은 몇 가지 문제점을 안고 있는데, 대표적인 것이 오브젝트의 배포에 관한 표준적인 방법이 없었?때문에 개발자의 능력에 크게 의지하게 되었고 ORB간의 상호 운용성(Interoperability)을 크게 떨어뜨렸다.

1991년 CORBA 1.0이 제안된 이래, OMG는 앞서 언급한 문제와 더불어 CORBA 서브 프로그래밍을 위한 표준의 미비, 인터페이스를 통한 오브젝트 기능의 확장 제한, 오브젝트 생명주기 관리 표준 등에 대한 문제를 꾸준히 개선하고 있다. 특히 아직 개발 중이긴 하지만 곧 선보이기 될 CORBA 3.0에는 CCM(CORBA 컴포넌트 모델)을 포함 시켰으며, CCM은 CORBA오브젝트 모델을 확장하여 개발자가 컴포넌트를 구현, 관리, 구성, 배포할 수 있는 트랜잭션, 보안, 영속성, 이벤트 등의 서비스를 제공해 준다. 여기서 분산 작업의 기본 단위가 되는 컴포넌트 모델은 EJB가 CORBA의 표준 컴포넌트 모델이 될 것이다.

J2EE(Java 2 Enterprise Edition)

오늘날 자바는 가장 빠른 기간 동안에 시장에서 성공한 개발 언어로 손꼽힌다. 우리는 하나 이상의 자바 클래스들을 그룹핑하여 패키지로 만들 수 있는데, 일반적으로 자바 컴포넌트는 이러한 패키지의 한 단편이다. 1997년 썬 마이크로시스템즈사는 EJB 1.0을 발표하고 이러한 자바 컴포넌트의 개념을 분산 환경하의 컴포넌트 아키텍쳐로 확장하였다. EJB는 대규모 비즈니스 어플리케이션의 개발 및 배치를 위한 소프트웨어 컴포넌트 모델로서 서버, 컨테이너, 클라이언트 인터페이스, 그리고 백 엔드 인터페이스로 구성된다. 또한 EJB는 클라이언트, 컨테이너, 그리고 엔터프라이즈 빈즈 사이의 관계를 명확히 정의하여 각자의 역할을 분리함으로써, 분산 환경에서 정보 시스템을 개발하는 개발자로부터 트랜잭션 관리, 커넥션 풀링, 상태관리, 멀티 스레딩 등의 기술적 문제를 해방시켰다.

EJB의 가장 큰 특징은 서버측의 표준 컴포넌트 모델을 제공하였다는 점이다. 이것은 이미 언급한 COM+나 CORBA와는 다르게 플랫폼(Platform)이나 공급 업체(Vendor)로부터의 종속 문제를 해결하였다는 점에서 큰 의미를 갖는다. 또한 업계의 수많은 아이디어를 채택하는 개방형 구조를 가짐으로써 매우 유연하고 확장성 있는 모델을 제공하였고, 이것은 데이터베이스 관리 시스템이나 어플리케이션 서버를 제공하는 많은 벤더들의 참여를 이끌어낼 수 있는 원동력이 되었다.

썬의 J2EE는 자바의 영역을 기업 전반으로 확장하였다. 여기에는 클라이언트계층, 웹 계층, 어플리케이션/데이터 연동 등을 포함하고 있으며, 업무 로직을 처리하는 EJB가 J2EE의 중심에 있다.

어떤 환경을 선택할 것인가?

이제까지 컴포넌트를 실현시킬 개발 환경에 대해서 살펴보았다. 공통적인 점은 저수준의 기술적 문제와 핵심 업무 흐름을 분리하여 개발자가 더 이상 트랜잭션, 데이터베이스, 메시지, 보안 등의 문제에 신경 쓰지않고 순수 비즈니스 로직의 개발과 운영에 집중할 수 있다는 점이다. 이것은 비즈니스 요구사항을 보다 빠르고 정확하게 반영하게 할 수 있다는 점에서 앞서 언급한 e비즈니스의 요구사항과 상통한다.

COM+, EJB, CORBA등의 컴포넌트 표준에 맞추어 개발된 비즈니스 컴포넌트는 일반적으로 다계층-분산 시스템의 중간 계층(Middel-tier)에 위치하게 된다. 중간 계층의 컴포넌트는 순수 비즈니스 로직만을 표현하고 있으며 프리젠테이션 로직이나 데이터베이스와는 분리되는데, 이런 구조가 갖는 장점은 다음과 같다.

유연성 : 비즈니스 로직이 중간 계층의 서버에 위치한다는 것은 다양한 클라이언트가 동일한 비즈니스 서비스에 접근할 수 있다는 것을 의미하여 이것은 서버 서비스의 업그레이드나 교체를 유연하게 만든다.

확장성: 어플리케이션은 데이터베이스 컨넥션과 같은 한정된 자원을 사용해야 하는데, 이러한 자원을 중간 계층에 둠으로써 클라이언트들이 한정된 자원을 최대한 공유하여 사용할 수 있다.

강건성 : 비즈니스 서비스를 제공하는 서버가 작동하지 않더라도 클라이언트는 동일한 서비스를 제공하는 다른 서버에게서 서비스를 제공받으면 된다.

지금까지 살펴본 컴포넌트 개발환경 중에서 하나의 솔루션을 선택하기란 매우 어렵다. 따라서 우리는 각각이 갖는 장점과 단점을 비교하여 프로젝트에 맞는 환경을 선택해야 할 것이다.<표2>는 컴포넌트 개발 환경들을 비교한 평가표이다.

<표2. COM+, EJB, CCM의 평가표>

대표기술 적용분야	SUN의 JAVA	MS의 COM	OMG의 CORBA	기   타
클라이언트	JaVaBean	ActiveX		XML
서   버	EJB	.NET	CCM
	JSP	COM+/DCOM
	Servlet	ASP.NET

COM+는 컨테이너 관리 퍼시스턴스(Persistence)를 제공하지 않기 때문에 '상태관리'항목에서 상대적으로 낮은 평가를 받았다.

EJB는 현재 '배치'항목에서 낮은 평가를 받았다. 하지만 EJB2.0을 대상으로 한다면 이것은 어느 정도 상향 조정될 것이다. EJB는 스펙에서 명시적으로 '강건성'에 대하여 다루고 있지 않으므로, 이 항목에서 낮은 평가를 받았다. 하지만 몇몇 EJB제품은 강건성에 있어서 COM+보다 나을 수도 있다, '구현'항목의 경우 다양한 EJB 공급업체가 존재하기 때문에 일관성 있는 평가를 내리기 힘들다.

현재 CCM의 경우 개발 중이기 때문에 '플랫폼 지원'과 '구현'의 일관성에 대해 평가할 수 없다.

<참고문헌>
[01]	Paul Allen, "Realizing e-Business with Components", Addison-Wesley, 2000
[02]	Alan W. Brown, "Latge-Scale Component Based Development", Prentice Hall, 2000
[03]	George T.Heineman & William T. Council, "Component-Based Software Engineering-", Addison-Wesley, 2001
[04]	Peter Herzum & Oliver Sims, "Business Component Factory: A Comprehensive Overview of Component-based Development for the Entetprise", John Willey & Sons, Inc, 1999
[05]	John Cheesman & John Daniels, "UML Components: A simple process for specifying component-based software", Addison-Wesley, 2000