J2EE VS .NET

웹서비스 실현을 위한 맞수 .NET vs. J2EE
차세대 컴퓨팅 환경의 새로운 정의, 닷넷
지난 한 해 동안 개발자와 IT 업계에서 닷넷(.NET) 만큼 많이 입에 오르내린 단어를 찾아보기도 힘들다. 닷넷에 관한 모든 논의의 공통 분모는 닷넷이 개발자에게 기존의 도스에서 윈도우로의 변화에 맞먹을 만한 패러다임의 전환을 가져올 것이라는 것이다. 닷넷을 간단하게 정의하는 것은 어렵지만 마이크로소프트가 내놓은, 웹서비스 환경을 위한 새로운 차세대 플랫폼이라고 할 수 있을 것이다.

CLR을 통한 플랫폼 독립 선언
닷넷의 근본적인 철학은 자바와 일맥상통하는 면이 있다. 개발자의 원대한 이상 중 하나였던 WORA(Write Once, Run Anywhere)라는 플랫폼 독립성을 구현하여 플랫폼 간의 통합과 애플리케이션의 호환성을 극대화하고자 한다는 면이 바로 그것이다.
자바가 플랫폼 독립성을 위해 처음부터 끝까지 자바라는 언어를 사용해야 하므로 프로그래밍 언어에 종속적인 것에 비해 닷넷은 개발자가 원하는 언어를 마음대로 사용할 수 있다는 언어적 자유와 호환성을 보장하고 있다. 현재 닷넷을 지원하는 프로그래밍 언어는 약 20여개에 달한다. 이에따라 개발자는 취향에 맞는 언어를 선택하여 애플리케이션을 개발할 수 있으며, 다른 언어로 작성된 코드와도 자유롭게 연동이 가능하다.
닷넷은 자바 VM과 유사한 CLR(Common Language Runtime)을 통해 플랫폼 독립성을 보장한다. 닷넷으로 작성된 코드는 컴파일러에 의해 중간 단계 언어인 MSIL(Microsoft Intermediate Language)로 변환되며, 이 코드는 CLR에 의해서 실행되고 관리된다.
CLR은 기본적인 코드의 실행과 관리뿐만 아니라 가비지 컬렉션(Garbage Collection), 표준 타입 시스템(CTS, Common Type System), JIT(Just-In-Time) 컴파일, 애트리뷰트의 지원, 애플리케이션 도메인 개념, 스레드 지원, 코드 액세스 보안, 예외 처리 및 디버깅 엔진, COM 및 Win32 API와의 상호호환(Interoperability) 등과 같은 다양한 서비스를 제공한다.

단일 프로그래밍 모델 BCL 사용
닷넷에서는 애플리케이션의 배치 및 버전 관리 등의 문제를 해결하기 위해 어셈블리라는 새로운 배포 단위를 지원한다. 어셈블리는 기존 파일 단위 배포가 가지는 번거로운 패키징 작업을 단순화시키며, 애플리케이션의 유지 보수를 획기적으로 향상시키고 있다. 개발자는 어셈블리를 이용해 번거로운 패키징 작업을 더 이상 별도로 하지 않아도 되며, 컴포넌트를 레지스트리에 등록할 필요 없이 단순히 복사하는 것으로 모든 배치 작업을 쉽게 끝내고 버전 충돌 문제를 극복할 수 있다.
또한 닷넷에서는 과거 애플리케이션을 개발하기 위한 프로그래밍 모델들인 Win32 API, MFC, ATL, 비주얼 베이직의 폼 기반 개발 형태로 새롭게 디자인된 BCL(Base Class Library)을 사용하여 어떠한 프로그래밍 언어를 사용하든지 단일한 프로그래밍 모델을 사용할 수 있는 환경을 제공한다. BCL은 특정 언어에 종속되지 않는 일관성 있고 통합적인 성격을 가지고 있다. BCL에서는 모든 것이 객체이며 OOP(Object Oriented Programming) 개념을 충실하게 준수하고 있는 제대로 디자인된 라이브러리이다.
BCL은 네임스페이스라고 불리는 논리 영역에 따라 계층적으로 분화되어 있다. 예를 들어 최상위에는 System이라는 네임스페이스가 존재하며, System 하부에는 콘솔 입출력을 처리하기 위한 클래스인 System.Console이 존재한다. 실제 콘솔에 출력을 하기 위한 메소드는 System.Console.WriteLine이라는 메소드이다.
물론 BCL이 기존의 Win32 API를 완벽하게 대체하고 있는 것은 아니지만 대부분의 주요한 요소들을 포함하고 있으며, BCL은 과거보다 간결하고 보다 나은 구조의 프로그래밍 모델을 제시하고 있다. BCL의 디자인 철학은 자바와는 약간 차이를 보이고 있는데, 자바 API는 근본적으로 OS가 제공하는 기능을 대체하는 목적을 갖고 있지만 BCL은 각 OS별로 사전에 구현되어 있는 라이브러리(예를 들어 윈도우에서는 Win32 API)를 최대한 활용해 시스템에서 제공하는 기능을 재활용하고 있다.

프론트엔드부터 백엔드까지 닷넷 하나로…
엔터프라이즈 환경에서 보면 닷넷은 분산 환경의 각 계층에 대응되는 다양한 구성 요소들을 제공하고 있다. 먼저 프론트엔드 기술로 ASP.NET과 윈폼(WinForm)이라는 두 가지 형태가 제공된다. ASP.NET은 웹 환경의 프론트엔드이며, 윈폼은 스탠드얼론이나 클라이언트/서버 환경을 위한 윈도우 애플리케이션 개발 환경이다.
ASP.NET은 컴파일을 통한 강력하고 빠른 웹 애플리케이션을 작성할 수 있게 해준다. 예를 들자면 코드 비하인드 개념을 통한 개발과 유지보수의 향상, 서버 컨트롤 지원, 상태 관리(State Management), 뛰어난 성능의 캐쉬 등의 다양하고도 막강한 기능을 제공하며, 무엇보다 웹 서비스를 쉽고 빠르게 구현할 수 있다.
윈폼은 간결하고 강력한 프로그래밍 모델을 통해 윈도우 애플리케이션을 개발할 수 있게 해주는 프레임워크로 ‘다운로드와 실행(Download & Run)’이라는 새로운 개념을 지원해 기존 윈도우 애플리케이션의 가장 큰 어려움 중 하나인 설치와 배포 문제를 해결한다.
미들엔드에서는 윈도우 2000에서 소개된 COM+를 활용하는 닷넷 엔터프라이즈 서비스를 통해 미들웨어가 수행해야 될 각종 서비스인 트랜잭션, 보안, 동기화, 스케일 아웃, 상호운용성 등을 지원하며, XML을 통한 완벽한 분산 환경인 웹서비스 구현도 지원한다. XML 웹서비스는 닷넷의 가장 핵심적인 요소 중 하나로 SOAP과 XML을 통해 이기종 플랫폼 상의 애플리케이션들이 통합 및 연동될 수 있는 표준 기반을 제공한다.
마지막으로 백엔드에서는 데이터베이스에 접근하기 위한 새로운 기술인 ADO.NET이 제공된다. ADO.NET은 분산 환경에 최적화된 기술로 비연결(Disconnected) 환경 및 XML을 지원한다. ADO.NET의 구성 요소들은 데이터를 객체적인 시각에서 다룰 수 있도록 잘 정립된 모델을 제시하고 기존의 데이터베이스 연결 기술에 비해 향상된 속도를 제공한다.
마이크로소프트는 UDDI, XML, SOAP 같은 표준 기술을 받아들여 융화시키고 있으며 얼마 전에는 C#과 CLI가 ECMA 표준으로 승인을 받는 등 닷넷의 표준화 작업에도 많은 노력을 기울이고 있다. 닷넷 정식 버전이 나오는 올 해에는 닷넷과 J2EE가 실제 필드에서 치열한 경합을 벌이게 될 것이다. 이제 IT 세계에서 웹서비스는 대세이며 거역할 수 없는 흐름이다.

J2EE(Java 2 Platform, Enterprise Edition)는 웹 기반의 엔터프라이즈 애플리케이션을 구축하기 위한 썬마이크로시스템즈의 플랫폼으로 표준이자 규약이다. J2EE의 핵심 요소는 JSP, 서블릿, EJB(Enterprise Java Beans) 등이 있으며 J2EE 인터페이스로는 데이터베이스를 위한 JDBC, 디렉토리를 위한 JNDI(Java Naming and Directory Interface), 트랜잭션을 위해서는 JTA(Java Transaction API)를, 메시징을 위해서는 JMS(Java Message Service)를, 이메일 시스템을 위해서는 JavaMail을, 그리고 CORBA와의 접속을 위해서는 Java IDL(Interface Definition Language)을 포함한다. J2EE는 기본적으로 썬마이크로시스템즈의 자바를 이용해 기업용 애플리케이션을 개발할 수 있게 해주는 표준을 제공한다.
닷넷은 마이크로소프트라는 거대 기업 하나가 지원하고 있는 반면 J2EE는 썬마이크로시스템즈, IBM, 오라클 등 여러 회사들이 공동으로 지원하고 있어 사실상 어느 한 기업이 단독으로 개발한 제품이라고 말할 수 없다. J2EE는 많은 개발자들이 자유롭게 이용할 수 있는 개발 표준의 집합체인 것이다.
OS에 자유로운 이식성
필자는 J2EE와 닷넷 두 가지 중에 어느 한쪽을 옹호하는 진영에 속하는 사람은 아니다. 마이크로소프트와 자바 진영의 싸움을 지켜보면서 과연 어느 기술이 살아남을 것인 가에 대해 이야기하지만 이면을 자세히 들여다보면 단순한 기술 경쟁이 아니라 표준과 기술의 경쟁임을 알 수 있다. J2EE는 앞서 말한 것처럼 표준 규약이고 닷넷은 마이크로소프트의 독자 기술이기 때문에 객관적으로 비교하기는 어려운 대상이지만 <표 1>에 두 기술의 차이에 관해 간략하게 정리해 보았다.
J2EE와 닷넷의 가장 큰 차이점은 사용하는 프로그래밍 언어이다. 닷넷을 구성하는 소프트웨어는 닷넷 버전의 비주얼베이직, C, C# 같은 여러 언어를 이용해 제작할 수 있다. 프로그래밍 언어로 작성된 소스 코드는 MSIL로 컴파일되며, CLR로 재컴파일되거나 각 플랫폼에 맞는 네이티브 코드로 컴파일된다.
반면 J2EE가 이용하는 프로그래밍 언어는 오직 자바이다. 프로그래머가 작성한 자바 소스 코드는 바이트 코드라고 알려진 객체 코드로 컴파일된다. 자바 버추얼 머신이 설치된 플랫폼은 모두 이 바이트 코드를 받아들일 수 있다. 따라서 자바 이외의 다양한 프로그래밍 언어를 이용해야 하는 개발자라면 닷넷 플랫폼을 택할 것이고, 윈도우 시스템 외에 다양한 플랫폼을 지원해야 하는 개발자라면 당연히 J2EE를 선택할 것이다.
J2EE의 가장 큰 장점은 이식성이다. 이식성이라는 것은 소스 코드를 수정하지 않고도 OS에서 다른 OS로 이동시킬 수 있는 능력을 말한다. J2EE에서 OS의 이식이 가능한 것은 J2EE 자체가 갖는 본질적인 이식성이라기보다 대부분의 J2EE 벤더들이 다양한 OS를 지원하기 때문이다. 이식성보다 확장성을 원한다면 닷넷을 사용해야 할 것이다.

J2EE의 다섯 가지 핵심 아키텍처
J2EE 아키텍처는 자바 랭귀지 시스템, 클라이언트 프로그래밍 모델, 미들티어 인프라스트럭처, 프로그래머 엔터프라이즈 API, 논 프로그래머 비저블 API의 다섯 부분으로 크게 나눌 수 있다. 각 구조에 대해 자세히 살펴보자.

■자바 랭귀지 시스템(Java Language System)
자바와 닷넷은 소스 코드가 저차원 언어로 번역된다. 닷넷 플랫폼에서는 저차원 언어가 MSIL인 반면에 자바에서는 자바 바이트 코드이다. 닷넷에서 이 환경은 앞서 설명한 CLR이고 자바에서는 자바 가상 머신이 된다.

■클라이언트 프로그래밍 모델(Client Programming Model)
J2EE 클라이언트 프로그래밍 모델은 브라우저와 상호 작용하는 것으로 자바 애플릿, 자바 서블릿과 자바 서버 페이지로 구성되어 있다. 자바 애플릿은 브라우저 내에서 실행되는 자바 코드를 패키지하는 데 사용된다. HTTP 요청과 HTML 응답을 처리하는 기술은 자바 서블릿과 자바 서버 페이지이다. 이 두 기술은 기능 면에서 닷넷의 프리젠테이션 계층 모델인 ASP.NET과 같은 역할을 한다. 닷넷의 프리젠테이션 계층과 자바 프리젠테이션 계층 간의 차이점이라면 서로 다른 클라이언트 기능을 처리하는 방법이라는 점이다.

■미들티어 인프라스트럭처(Middle tier infrastructure)
J2EE에서는 EJB가 중간 계층의 하부 구조가 된다. EJB는 닷넷 프레임워크의 COM+와 대응되는 기술이다.

■프로그래머 엔터프라이즈 API(Programmer Enterprise API)
자바 엔터프라이즈 API라고 부르는 것 중에서 가장 중요한 부분은 JDBC, JNDI, JMS이다. JDBC는 자바에서 관계형 데이터베이스에 접속하기 위한 API이고, 이것은 닷넷의 ADO.NET에 해당된다. JNDI는 엔터프라이즈 이름 정보와 자바의 디렉토리 서비스에 접속하기 위한 API로 닷넷의 ADSI(Active Directory Services Interface)와 비슷하다고 보면 된다. JMS는 비동기식 워크플로우를 위한 자바 API로 메세지 큐 API(Message Queue API)와 같은 기능을 한다.

■ 논 프로그래머 비저블 API(Non Programmer Visible API)
이 API에는 다른 제품들이 어떻게 J2EE에 끼워질 수 있는 지를 정의하는 API(Connector API 등)와 J2EE 모델에서 이후에 개선되어 효과적으로 대체된 API(JTA-Java Transaction API)가 포함되어 있다.

J2EE냐 닷넷이냐 그것이 문제로다
J2EE는 많은 기업이 지원하고 있어 벌써 시장이 형성되어 있다는 장점이 있다. 많은 개발자들이 자바를 사용하고 있으며 현재도 자바 개발자 인력이 다수 양성되고 있다. J2EE는 고급 프로그래밍 모델로 객체 모델을 개발하는 개발자에게 편리한 기능들을 많이 제공한다. 이를 사용하기 위해서는 객체지향 개념에 대한 완벽한 이해와 설계가 있어야 할 것이다. 어떠한 OS에서도 사용할 수 있다는 점도 J2EE의 큰 매력이다. 즉, 고객의 플랫폼을 알 수 없는 상황에서는 J2EE를 선택할 수밖에 없다.
J2EE 기반의 응용 프로그램 개발을 더욱 가속화하기 위해 썬마이크로시스템즈의 자바 센터 설계자는 J2EE 플랫폼 기반 솔루션 구축의 복잡성을 단순화하는 여러가지 J2EE 기반 패턴을 개발했다. 이런 설계 패턴은 객체지향 시스템에 대해 충분히 증명된 재사용이 가능한 설계 솔루션이며 특정 시스템 유형이나 프로그래밍 언어 또는 응용 프로그램 영역에 한정되지 않는다.
J2EE 기반 패턴을 사용하면 J2EE 기반 솔루션을 개발할 수 있다. 이러한 패턴은 J2EE 기반의 응용 프로그램을 빠르게 개발할 수 있어 제품의 시장 출하 시간을 단축시키고 개발 비용을 줄이며 플랫폼의 신뢰성을 증가시켜 준다. 이런 패턴은 JSP, 서블릿, EJB, JMS 등을 포함한 J2EE 설계의 모든 계층에 걸쳐 적용할 수 있다.
J2EE 또는 닷넷 어느 것을 선택하느냐 보다 개발 대상에 따라 어떻게 개발을 해나가는가 하는 점이 중요하다. 자바 사용자들은 기술 요소로 우선 자바를 정해놓고 그것만 사용하려는 경향이 있는데 시스템이 요구하는 특성에 따라 그 환경에 맞는 기술을 선택하는 것이 올바를 것이다. 그리고 자바로 개발하면 당연히 객체지향 프로그램이 개발된다고 생각하지만 객체지향 프로그램이 나오기 위해서는 반드시 설계가 뒷받침 되어야 한다.
플랫폼을 선택할 때 차후의 전망보다는 당장의 현실적인 요인에 의해 결정을 내리는 경우가 많다. 하지만 워낙 빠른 속도로 바뀌고 있는 IT 환경에서 한 가지만은 명심해야 할 것이다. 개발 환경이나 개발 언어보다 중요한 것은 바로 개발된 제품의 완성도라는 것을 꼭 점검해 봐야 한다는 것이다.
J2EE와 닷넷의 표준과 기술 싸움은 어느 한쪽의 패배나 승리로 끝나지 않을 것이다. 시스템 간의 호환성 문제는 XML이 자리를 잡으면서 시스템이 무엇으로 구현되어 있건 간에 XML을 이용해 시스템에 독립적으로 존재할 수 있게 되었다. 닷넷과 J2EE라는 다른 이름으로 경쟁하고 있지만 웹서비스의 구현이라는 하나의 목적지를 향해 가고 있고, 이 둘은 공존하는 형태가 될 것으로 보인다.

[출처] J2EE VS .NET|작성자 미래