웹 애플리케이션 서버 (Web Application Server : WAS)

1) 웹 애플리케이션 서버 (Web Application Server : WAS)

- 대규모 인터넷 환경에서의 Web 서비스를 위한 일종의 '환경' 이라고 볼수있습니다.

- 例)우리가 '지식in'검색을 위해 '네이버'에 접속하고, '로그인'을 하고, '검색'하고 '답변'하고

하는 일련의 과정들은, 사용자, 즉 Client들의 이런 다양한 명령어를 받아서 처리해주는

'Naver社'의 'WAS'를 통해서(거쳐서) 이뤄집니다.( DB에로의 정보저장등..)

- 일반적으로 상용화된 제품으로는 Bea社의 '웹로직(WebLogic)'과, 우리나라에서 만든

tMax社의 '제우스(Jeus)'등이 있습니다.

- 질문하신 '톰캣'도 일종의 WAS인데요, 즉 위에서 설명드린 '서버측' 프로그램들중

'jsp(java server page)'등의 코드들을 작동시키는 능력을 가지고있지요.

일반적으로 '톰캣'등은 'JSP엔진' 이라고 통용된답니다.

2) 자바밴더 (Java Vendor)

- 'Java'라는 언어는 'Sun MicroSystems'라는 회사에서 관리를 합니다.

'관리'라 함은 'java'란 언어를 사용하여, 적용될수 있는기술들을 발표하고, 또한언어

자체를 업그레이드 시키는 작업을 말하지요.

- 例) 어느날 'Sun社'에서 이렇게 결정내립니다. '아! 자바란 언어로 Jsp라는 서버측 언어를 만들어 보자! 그런데 이 언어를 서버에서 돌리려면 이렇고,저런 기능이 필요한 프로그램들이필요할꺼야!' 라고 말이지요.

'Sun社'는 이러한 일련의 요구사항들을 '문서화' 시킵니다.

이를 'API'라고 하지요.

이 'API'를 읽어본 Bea란 회사 사장은 이런 프로그램들을 만들기로 결정합니다!

'아! 이렇고,저런 기능이 포함될 앞으로의 우리 제품을 WebLogic이라 하자!'

이때 'Bea社'는 이러한 제품을 제공한다 하여

'Vendor'라는 칭호를 받게 됩니다.

따라서 '자바밴더'란 '자바기술응용 프로그램 제작단체/기업/개인'등을 칭합니다.

WAS를 도입할려는데...
Oracle AS 어떤지 사용해 보신 분들 알려주세요...
전에 Oracle 7에서 OWS는 완전 실패작이던데...
WAS에서 9i부터 도입된 Oracle AS는 어떤지요?
현재 검토 대상은 아래와 같습니다...

1. BEA Web Logic
2. IBM Web Spere
3. Tmax Jeus
4. Oracle AS
5. Tomcat

제가 알기로는 Web Logic을 가장 많이 사용하는 것 같은데
Oracle사에서 Oracle AS가 좋다고 말을 많이해서요...

참고로 서버는 SUN으로 갈 것 같습니다...

수고하세요...
답변들
re: [WAS] Oracle AS(Application Server) 사용하신 분들 알려주세요

yhchang (2004-05-12 09:51 작성) 이의제기
흠.... 개인적인 의견을 드릴께요...
얼마전 신문에서도 나왔듯이 오라클에서는 데이터베이스와의 연동등을 이유로
자사의 OAS를 추천하고 있다고 합니다.
그러나 실제적으로 OAS는 내부의 수많은 버그들이 존재하는 것 같습니다.
WAS는 안정적인 운영과 리소스 관리가 중요한데 OAS에서는 이러한 부분에서
문제가 많이 발생하는 것 같아요... 예전에 OAS로 하다가 죽을뻔 했습니다.
아시다시피 한국 오라클의 기술지원도 힘들었구요..

BEA가 LG전자, SK주식회사의 WAS를 OAS에서 BEA WebLogic을 윈백하기도 하였구요.
그리고 TMax JEUS의 경우에서 많은 사이트에서 OAS를 윈백했다구 하네요...
전자신문에서 "WAS 윈백"로 검색해보시면 자료들이 많이 나올겁니다.

제 개인적인 생각으로는 기술지원부분에서는 국산 JEUS를 권고드리고 많이 쓰이는
WAS를 검토하실 경우에는 BEA WebLogic을 그리고 전 세계시장 분할를
보면 IBM WebSpere를 권해드립니다.
OAS는 강력하게 하시지 말라고 말씀드리고 싶습니다.
오라클사에서는 데이터베이스와의 유연한 통합을 많이 얘기하지만 믿지 마세요...

도움이 되셨기를....

[질문] 웹서버와 WAS 차이  
비공개 님이 2003-06-17 16:36 작성  채택 포인트 0   답변 1   한줄의견 0   조회 228 
웹에 관한 글을 읽다 보니 웹서버와 웹어플리케이션서버라는 게 나오는데
그 둘의 차이가 뭔지 궁금합니다.  

      

 
  
WAS 라는 것은 J2EE 쪽에서 나온 용어인데요..

사실 Windows 2000 Server 도 WAS 역할을 합니다.

WAS 가 갖추고 있어야할 기능으로 대표적인 것으로

분산 트랜잭션 기능, 보안기능, 메시징 기능들이 있는데요.
엔터프라이즈급의 대용량 트랜잭션 업무에 적용합니다..

J2EE 에서 EJB 스펙에서 맞게 컴포넌트를 만들었을 경우

이 컴포넌트들을 상호 연동해서 위의 기능들을 덧붙여주는 거죠

개발자가 위의 기능들을 각자 코딩을 한다면, 품질도 보장 안되고
생산성도 낮아지겠지요..

요즘은 WAS 에 웹 서버기능까지 포함되어있기도 하죠..

.NET 쪽에서는 COM+라는 것이 있어서 위의 기능을 하구요..
IIS 가 웹서버 역할을 합니다.

J2EE 의 WAS 는 IBM 의 WebSphere 와 BEA WebLogic
국산으로는 jeus 가 있습니다..

각 벤더마다 EJB 스펙을 기준으로 위 기능들을 처리하도록
구현해놓은 것이 WAS 지요..

음 제가 알고 있는 것은 여기까지인데요.. 말로 풀려니까 좀 힘드네요^^

도움이 되셨으면 좋겠습니다.

  [답변] 차이에 대하여   
cyjpat 님이 2003-06-17 16:45 작성  
웹에서 볼 수 있는 내용은 여러가지가 있죠.
그 가장 초기적 형태는 html파일이었습니다. 이것은 대부분 정적인
즉 그냥 문서자체가 달랑 올라가 있는 거고, 그것을 웹서버가
HTTP프로토콜을 태워서 우리에게 보내주는 구조였죠. 그러다가,
점차 웹 기술이 발전하여가고, MS에서는 ASP를 내놓지만, 자바 진영(Java를 주기술로 채택한 일련의 IT회사들)
에서는 자바의 스펙을 무척 많이 지정하며, J2EE를 발표합니다.
자바는 플랫폼 독립성, 재사용성등의 잇점으로, 엄청난 수요를 몰고온 기술이죠.
그 자바의 스펙을 사용하여 서버중심에서 무언가 비즈니스의 로직을 돌려서 동적인
일을 하여 웹서버로 보내자는 생각을 하게 됩니다.
그러나, 앞서 말한 여러 자바 스펙은, 웹 서버가 핸들하기가 불가능합니다.
JSP, Servlet, EJB, JMS등...그런 스팩으로 만든 프로그램들은 적절한 콘테이너라는
공간안에서 움직여야 합니다. 이 콘테이너를 제공하도록 하는 것이 바로 WAS입니다.
즉, 자바로 만든 E business enterprise application들이 돌아갈수 있는 큰 OS같은 거죠.
넓게 말하면, ASP, dot NET도 웹 어플리케이션 서버라 할수 있으나, 보통 WAS라 하면
J2EE를 돌릴수 있는 서버와 그 서버환경을 제공할수 있는 상용 시중 소프트웨어르 지칭합니다. 
 
   좋은 답변에 칭찬의견을 달아주세요!     

  의견 :   webSever VS WAS (kdskor 님이 2003-06-17 17:21 작성) 
webServer은 단순히 홈페이지를 운영하기 위한 것입니다. 이것에는 iis, apache, iPlanet가 유명합니다.

여기에 WAS는 단순히 홈페이지를 운영하는 것이 아니라 데이터베이스 연결,
여러개의 분산 웹서버 운영, 분산 프로그래밍(EJB) 등등의 기업형 서버를 운영하기
위하여 사용되면, WebLogic, WebSphere, 9iAS, .NET 등등이 있습니다.

웹서버 환경에서 프로그래밍을 한다면 단순히 웹프로그래밍을 하면 되지만 WAS환경에서
프로그래밍을 한다면 분산객체와 같은 지식이 필요합니다. 

웹 애플리케이션 서버

  

웹을 이용한 비즈니스가 본격화되면서 오늘날 기업들은 과부하와 트랜잭션 의
안정성과 신뢰성 확보라는 커다란 도전에 직면해 있다. 웹 애플리케이션 서버의
등장은 과거 3계층 아키텍처가 컴퓨팅 환경에 혁명을 몰고 온 것에 비견될 만큼 극적이다.

오늘날 사업의 성패는 필요한 정보와 서비스를 얼마나 빠르고 효과적으로 제공하느냐에
달려있다. 즉 기업 내 인트라넷, 기업간 엑스트라넷 그리고 인터넷을 얼마나
잘 활용하느냐에 따라 승패가 갈린다.

고객에게 빠르고 정확한 정보와 서비스를 제공하고 기업 환경의 변화에
유연하게 대응하려면 적용하는 솔루션도 유연성과 지속성을 가져야 한다.
기술이나 업무의 변화에도 쉽게 적응할 수 있어야 함은 물론이다.

인터넷을 이용하면 새로운 시장을 창출하고 고객 지원의 질을 높일 수 있을
뿐 아니라 공급자들과 종업원, 기타 자원들을 보다 잘 관리할 수 있다. 또한
거래처리(트랜잭션) 비용을 줄이고 업무 프로세스를 합리화하여 ROI 기간을
단축시킬 수 있다. 하지만 인터넷에서 사업을 시작하면 수많은 문제에 직면하게 된다.
자주 변화되고 통제하기 힘든 기존의 OS나 데이터베이스, 네트워크에 의존적이지 않으면서
전체적인 모양을 갖춘 애플리케이션을 어떻게 전개할 것인가? 기존의 정보시스템들을 구매고객이나 직원, 비즈니스 파트너들과 연결시킬 수 있을까? 풍부한 유저 인터페이스와 클라이언트 서버 환경에서 누려 온 빠른 애플리케이션 개발속도를 씬 클라이언트의 관리 편의성이나 메인프레임의 안정성과 결합할 순 없을까? 장애가 발생하면 자동으로 복구하고 인터넷의 작업부하에도 사용자들에게 빠르고 강력한 서비스를 제공할 방법은? 이러한 수많은 의문점들에 대한 명확한 해답이 필요한 시점이다.

인터넷 비즈니스의 뉴 패러다임  웹  애플리케이션  서버

웹을 이용한 비즈니스가 본격화되면서 기업들은 사용자들의 접속에 따른 과부하와 트랜잭션의 안정성과 신뢰성 확보라는 큰 도전에 직면해 있다. 이제 기업의 컴퓨팅 환경은 변화를 요구받고 있고 웹 애플리케이션 서버는 이를 수용할 핵심 인프라로 자리잡고 있다.

웹 애플리케이션 서버의 등장은 과거 3계층 아키텍처가 컴퓨팅 환경에 혁명을 몰고 온 것에 비견될만큼 극적이다.

웹 애플리케이션 서버란 대체 무엇이며 왜 중요한가? 지금부터 이에 대한 해답을 알아보자.

글/조계원 기자 chowon@pserang.co.kr

CGI 환경의 문제점

웹 사용자가 기하급수적으로 늘어남에 따라 웹 서버에 대한 접속도 엄청나게 늘어났다. 인트라넷 개념이 날로 확산되면서 기존의 웹 기술은 인트라넷으로 사용되기에는 결정적인 문제점을 안고 있다.

웹 환경은 기존의 클라이언트/서버 환경과는 분명히 다르다. 웹은 결과 화면을 보여주는 웹 클라이언트, 결과를 보내주는 웹 서버, 그리고 요청을 처리하는 처리 프로그램 층으로 구성되어 있다. 구조상으로 보면 3계층 구조이지만, 이는 진정한 3계층 구조는 아니다. 웹 서버는 애플리케이션 관리 기능을 포함하고 있지만 중계 역할만 담당한다. 웹 서버와 CGI 프로그램은 운영체계내에 두 개의 서로 다른 프로세스로 데이터를 주고받을 수 있는 통로를 갖고 있을 뿐이다. CGI 프로그램은 사용자의 요청이 있을 때마다 별도로 생성되는 프로세스로 인해 부하 분산이나 서버의 자원 절약을 지원하지 못한다. HTTP의 경우를 보자. 클라이언트와 서버 사이에 데이터를 주고받을 필요가 있을때마다 연결하고 전송이 끝나면 바로 연결을 끊는다. 프로그램이 복잡해지는 것은 당연한 일이다.

이러한 CGI 방식이 문제가 되는 것은 바로 성능이다. 서버와 네트워크에 많은 부하를 주고 새로운 CGI 프로세스를 생성하는 작업은 당연히 시스템 성능 저하를 초래한다. 또한 HTTP 기반의 통신 규약은 매번 접속이 새로 이루어져 세션 정보나 트랜잭션 정보를 관리할 수 없게 되어 궁극적으로 애플리케이션에 많은 제약을 주게 된다. 당연히 웹 환경의 문제점을 보완해 주면서 데이터 처리를 위한 프로그램층과 웹 서버층을 통합 관리할 수 있는 해결책이 필요하였다. 바로 이러한 문제점에 대한 해결책으로 웹 애플리케이션 서버가 등장하게 된 것이다.

웹 애플리케이션 서버의 등장

역사적으로 보면 애플리케이션 서버라는 용어는 클라이언트/서버가 컴퓨팅 환경으로 채택되면서 시작되었다. 3계층 구조에서는 사용자 프로그램에 대한 관리 기능을 제공하는 중간 계층인 미들웨어 내에 주된 업무 로직이 이루어지고, 클라이언트는 결과를 보여준다. 애플리케이션 서버는 사용자 애플리케이션에 대한 관리 기능을 제공하는 미들웨어층이다.

과거에 네트워크 애플리케이션을 구성하기란 쉽지 않았다. 미들웨어를 선택하고, 미들웨어의 프로그래밍 모델을 배워야했고 다시 미들웨어를 툴이나 디버거와 결합시켜야 했다. 그 결과물로 만들어지는 애플리케이션은 이식도 어렵고 호환성도 떨어지며 유지보수도 복잡한 미들웨어 호출(call) 투성이었다.

웹 애플리케이션 서버는 이종의 데이터 소스(store), 기존 시스템, 업무 프로세스 그리고 인적자원들의 통합이 필요한 엔터프라이즈 규모의 인터넷 애플리케이션들을 빠르고 유연하게 구현하고 운영할 수 있도록 해 준다. 애플리케이션 객체들간의 트랜잭션 무결성, 보안성, 확장성을 제공하며, 나아가 데이터베이스 드라이버를 데스크탑마다 설치할 필요없이 서버에 한 번만 설치하면 되므로 소프트웨어 비용과 유지관리에 드는 노력을 크게 줄여준다.

웹 애플리케이션 서버의 핵심 구성 요소

이러한 웹 애플리케이션 서버를 구성하는 요소와 핵심 기술은 무엇일까? 대부분의 웹 애플리케이션 서버가 지향하는 궁극적인 기술들은 자바를 중심으로 한 객체지향 컴포넌트와 트랜잭션 지원의 두 가지로 요약할 수 있다.

자바 중심의 객체 컴포넌트 기술

컴포넌트는 객체와 완전히 다른 성격을 갖고 있다. 객체는 코드 레벨의 재사용인데 반해, 컴포넌트는 아키텍처 레벨의 구성요소 재사용이다. 또한 컴포넌트는 레고와 같이 조립과 분해가 가능하다. 이는 여러 개의 컴포넌트를 모아 더욱 큰 컴포넌트를 만들 수 있을 뿐 아니라, 기존의 컴포넌트를 구성하고 있는 작은 컴포넌트를 떼어내 최적화할 수 있음을 의미한다. 이러한 컴포넌트 아키텍처를 제공하는 양대 산맥은 자바와 마이크로소프트 진영이다. 크게 보면 마이크로소프트의 컴포넌트 아키텍처는 COM이고, 자바의 컴포넌트는 EJB이다. 현재 많은 웹 애플리케이션 서버 업체들이 EJB 지원을 약속하고 있다. 그러나 코바 진영에서는 컴포넌트에 대한 규정이 없어 코바 객체를 컴포넌트라고 보지 않는다. 최근 OMG의 코바가 객체 컴포넌트 모델로 자바 진영의 EJB를 채택하고 있다는 사실은 눈여겨 볼만하다. 

트랜잭션 지원

이제 기업들은 인터넷을 이용해 애플리케이션 제작에서 미션 크리티컬한 업무까지 처리하길 원하고 있다. 따라서 과거 TP 모니터처럼 트랜잭션을 처리하고 관리하는 트랜잭션 매니저의 필요성이 대두되고 있다. 이를 위해 자바 진영에서는 JTA와 JTS를 만들었고, 코바 진영에서는 OTS, 마이크로소프트는 MTS를 각각 만들었다. 자바, 코바 진영과 마이크로소프트 진영의 가장 큰 차이점은 스펙과 구현이다. 자바, 코바 진영은 스펙이며 스펙을 만족하는 제품을 누구나 만들 수 있다. 그러나 마이크로소프트는 구현이기 때문에 제3자가 끼어 들 여지가 없다.

웹 애플리케이션 서버 도입의 이점

?웹 애플리케이션 서버?는 웹 환경에 기업 컴퓨팅 환경에서 필요로 하는 인트라넷 기반을 제공한다. 또한 클라이언트/서버 환경에서의 미들웨어 역할을 담당하여 웹 애플리케이션에 많은 유연성을 준다. 이러한 애플리케이션 서버의 도입으로 3계층 프로그램은 2계층의 약점들을 대폭 개선할 수 있었다. 대표적인 몇 가지를 살펴보다.

확장성과 유연성 개선

업무 로직이 중간 계층인 애플리케이션 서버에 존재하므로 변경이 있더라도 클라이언트 프로그램에는 영향을 주지 않는다. 또한 서버 머신의 추가 등 환경이 변하더라도 대부분 애플리케이션 서버에서 처리되므로 프로그램의 변경을 최소화할 수 있다.

가용성 증대

애플리케이션 서버의 미들웨어 층에서 장애시 처리를 위한 백업 머신을 지정, 업무의 중단을 최소화하여 시스템의 가용성을 향상시킬 수 있다.

성능 향상

CGI 방식의 경우 사용자 요청이 발생할 때마다 새로운 프로세스로 생성되므로 서버에 많은 부하를 준다. 웹 애플리케이션 서버는 애플리케이션 서버 플랫폼 내에서 쓰레드(Thread)를 생성해 처리하여 불필요한 부하를 줄인다. 또한 세션 관리 기능을 추가해 웹 환경의 애플리케이션은 보다 다양한 형식이 가능하다. 그리고 클라이언트 프로그램에 대한 버전 관리 등 관리 기능을 얻을 수 있다. 기존의 애플릿 방식의 경우 매번 접속 때마다 새롭게 다운로드가 되어야 했으나 웹 애플리케이션 서버의 클라이언트 관리 기능은 필요한 애플릿을 필요한 경우에만 다운로드하여 네트워크의 부하를 줄이고 초기 접속 속도를 개선하였다. 이외에도 현재 애플리케이션의 동작 상태, 혹은 접속한 클라이언트 등에 대한 모니터링 기능이 있어 장애에 대한 감지 및 복구를 보다 빠르게 도와준다.

웹 애플리케이션 서버의 주요 기능

웹 애플리케이션 서버는 다양한 기능을 갖추고 있다.

세션 관리 기능

CGI 프로그램은 웹 환경에서 세션을 관리할 수 없다. 사용자 요청을 할 때마다 해당 정보가 있는 서버로 접속하고 데이터를 가져오고 접속을 끊는 작업을 하게 되는데 각각의 요청에는 일반적으로 특정 클라이언트를 구분 짓는 내용이 없다. 따라서 서버 내에서 세션 정보를 저장하고 있을 수 없다.

또한 웹 브라우저는 이전 작업에 대한 내용을 저장할 수 없다. 그러나 웹 애플리케이션 서버는 서버 프로그램에 대한 플랫폼을 제공한다. 제품에 따라 저장 방법에는 차이가 있지만 일반적으로 서버 플랫폼에 세션 정보를 유지하기도 하고 애플릿을 이용하여 클라이언트에 저장하기도 한다.

상태 관리 기능

사이버 쇼핑몰에서 사용자가 물건을 주문하기 위해 입력을 마치고 전송 버튼을 누른 순간 웹 브라우저 혹은 사용자의 컴퓨터가 갑자기 에러가 발생해 비정상적으로 종료되었다고 가정하자.

이 경우 사용자의 주문은 어떻게 처리될까? 정상적으로 처리가 되어 물건이 발송될 수도 있지만 물건이 주문되지 않았을 경우도 있다. 또, 각각의 경우 사용자는 비정상 처리로 생각해 새로운 물건 주문을 보낼 수도 있고, 정상적으로 주문이 되었다고 생각해 물건을 기다릴 수도 있다. 이 경우 고객이나 회사는 혼란과 금전적인 손해가 발생할 가능성이 있다. 웹 애플리케이션 서버는 이러한 트랜잭션의 상태 정보를 관리할 수 있는 기능을 제공한다.

서블릿 지원

서블릿은 서버에서 동작하는 애플릿(Applet)이다. 애플릿은 자바를 지원하는 웹 브라우저 상에서 동작한다. 웹 브라우저가 애플릿을 위한 플랫폼을 제공하듯 웹 애플리케이션 서버는 서블릿이 동작할 수 있는 플랫폼을 제공한다. 이러한 서블릿 방식은 애플릿 방식의 프로그램을 보완하기 위해 추가된 기능이다.

애플릿 방식의 가장 큰 단점은 초기에 다운로드를 위해 많은 시간이 필요하고 단순한 조회의 이용이 많을 경우 서버에 부하가 크게 걸린다는 점이다. 서블릿은 애플릿의 코드를 서버에서 동작시키고 결과를 HTML 형식으로 보낸다. 이와 같이 서블릿은 CGI 형식의 장점에 애플릿의 장점을 더한 것이다.

멀티 쓰레드 기능

이전의 CGI 환경에서는 프로세스의 생성과 소멸이 잦아 시스템에 많은 부하를 준다. 이로 인한 성능 저하는 물론 시스템을 마비시킬 수도 있다. 웹 애플리케이션 서버는 이런 부하를 최소화하기 위해서 멀티쓰레드 기능을 제공한다. 웹 애플리케이션 서버는 사용자 요청을 처리하기 위해 프로세스를 생성하는 것이 아니라 쓰레드로 처리해 서버에 주는 영향을 줄였다. 결과적으로 웹 서버로 들어오는 많은 사용자의 요청을 보다 빠르게 처리할 수 있다.

코바 지원

소프트웨어의 미래는 객체 기술에서 찾을 수 있다. 모든 웹 애플리케이션 서버들은 코바 기술에 대한 지원을 약속하고 있다. 이러한 코바 기술과 웹의 접목은 두 가지 이점이 있다. 우선 코바는 서버와 서버 간 연결의 기반 구조를 제공하며 클라이언트에서 들어오는 요청에 의해 발생하는 부하를 여러 서버로 분산시키는 부하 분산 기능 등을 포함한다. 이에 반해 CGI 환경에서는 프로세스간 혹은 머신간의 부하를 분산시킬 수 있는 방법이 없다. 이 약점을 보완할 수 있는 기술을 코바에서 찾을 수 있다. 또한 코바는 분산 객체 기반을 제공한다. IIOP를 기반으로 하는 코바 기술은 분산 객체 기술들 간의 결합성을 높이고 웹 애플리케이션 서버에 코바의 분산 객체 기술을 바로 적용시킬 수 있다. 이런 이유로 코바와 웹 애플리케이션 서버의 결합을 웹의 미래로 예측하는 사람들도 많다.

가트너 그룹의 웹 애플리케이션 서버 시장 전망

향후 웹 애플리케이션 서버 시장은 어떻게 전개될 것인가? 가트너 그룹이 내놓은 2003년까지의 웹 애플리케이션 서버 시장에 대한 향후 전망을 요약해 소개한다.

●절대 강자가 없고 하나의 솔루션이 모든 것을 만족시킬 수 없다.

●서버측 컴포넌트 모델을 계속 사용하지만 미성숙 단계에 있으며 웹 솔루션과 EAI 솔루션의 제품 통합이 전개된다.

●향후 5년 내에 애플리케이션 서버의 제품 수는 크게 증가하면서도 한편으론 감소한다

●2000년까지 COM/MTS 혹은 COM+는 Systematic 엔터프라이즈 애플리케이션으로는 생존할 수 없고 주로 Opportunistic 애플리케이션에 사용된다.

●2002년까지 3~4개의 제품만이 시장을 지배할 것이다.

●2002년까지 Opportunistic 애플리케이션의 성공을 배경으로 COM+가 Systematic 엔터프라이즈 애플리케이션에도 사용되기 시작할 것이다.

●2002년까지 Microsoft의 COM+와 EJB+CORBA의 2개의 컴포넌트 모델이 엔터프라이즈 애플리케이션 시장을 지배한다.

●2003년에는 애플리케이션 개발시, Pre-Component Programming Model, COM/MTS/COM+, Java/CORBA 등이 각각 1/3씩 차지한다.

●CORBA는 점차 Java(EJB)에 통합된다.

●2003년까지 Systematic과 Opportunistic 애플리케이션 시장을 모두를 겨냥하는 벤더는 어떤 시장에서도 선두를 차지하지 못할 것이다.

●2003년까지 대규모 엔터프라이즈 시장의 90%는 서로 다른 애플리케이션에 서로 다른 서버를 사용할 것이다.

●결론적으로 어떤 제품이라도 Systematic, Opportunistic 애플리케이션 모두를 만족시킬 수 없다.

웹 애플리케이션 서버의 미래

현재 기존 클라이언트 서버 기반의 정보시스템을 웹으로 전환하는 움직임이 늘어나면서 웹 애플리케이션 서버의 도입이 크게 증가하고 있다. 지난 97년 국내에 소개된 이후 전 산업에 걸쳐 웹 기반 정보시스템 구축의 핵심 도구 역할을 하고 있다. 이에 따라 인터넷 뱅킹, 사이버 증권, 쇼핑몰 등에 활발히 도입되고 있으며 이러한 웹 애플리케이션 서버를 이용해 시스템을 구축한 업체는 현재 100여 개에 이른다.

이에 따라 새로운 천년을 앞두고 차세대 제품들이 속속 등장하고 있다. 이미 출시되었거나 출시를 앞둔 신제품들은 대부분 EJB와 J2EE 스펙을 채택하고 트랜잭션 처리, 개발 편의성, 기존 시스템과 통합성이 향상되어 전사적인 웹 프로젝트가 가능하다는 공통점을 갖고 있다.

시장조사기관인 포레스트 리서치는 2002년이 되면 전세계 웹 애플리케이션 서버 시장 규모가 20억 달러에 이를 것으로 예상한다. 국내의 경우 금융권과 통신 서비스업체들을 비롯한 정부기관이나 대형 유통업체들이 웹 기반의 정보시스템 구축에 나서면서 시장 규모가 200억 원에 이를 전망이다.

결론적으로 웹 애플리케이션 서버의 미래는 밝다. 대부분의 업체들이 향후 2～3년 이내에 웹 애플리케이션 서버를 이용해 업무를 웹 기반으로 가져갈 것으로 예측되기 때문이다.

얼마 전까지만 해도 서버측의 플랫폼 중립성이 중요하지 않기 때문에 자바가 클라이언트에 국한된 것이라는 전문가들의 견해가 있었다. 그러나 이러한 예측은 빗나가고 있다. Zona Research의 조사에 의하면 275개의 중대형 IT 조직들 중 97%가 앞으로 2년 이내에 서버측에 자바를 사용할 계획을 가지고 있다.

웹 애플리케이션 서버의 핵심언어, 자바

Java는 인터넷을 위한 이상적인 프로그래밍 언어이다. Java는 비주얼 베이직의 사용편의성과 C++의 강력한 힘과 풍부함을 결합하고 있다. Java는 네트워크 애플리케이션을 위하여 설계되었으며 Java만 있으면 프로그래머들은 두 배의 생산성을 올릴 수 있고 애플리케이션은 더욱 이식성 높고, 강력하며 안전해 질 수 있다. 그리고 Java는 시스템 통합의 해결책이 되었다. IBM, Oracle, Novell, SAP 같은 대형 소프트웨어 업체들이 제품에 표준 자바 결합성(binding)을 부여하고 있다. 하지만 Java는 네트워크 애플리케이션을 모으고 통합하고, 배치하거나 관리하는데 필요한 토대는 제공하지 못한다. 이런 점에서 웹 애플리케이션 서버의 역할과 중요성이 대두된다.

웹 애플리케이션 서버는 대규모 네트워크 애플리케이션의 개발과 통합, 구현 그리고 관리에 자바의 강력한 힘과 자바 엔터프라이즈 표준의 안정성을 부여하였다. 아울러 인터넷을 통한 비즈니스를 수행하는 데 필요한 다양한 서비스로 자바의 강력함을 확장하였다.

개발자들은 이제 웹 애플리케이션 서버가 있으면 비즈니스 로직에만 신경을 쓰면 된다. 어떻게 이종의 데이터 소스를 통합할 것인가 혹은 고객들의 실시간 요구를 감당해 내는 강력한 성능을 낼까 라는 골치 아픈 문제는 웹 애플리케이션 서버가 해결해 준다. 웹 애플리케이션 서버는 비즈니스상의 기회나 변화에 빠르게 대응할 수 있도록 애플리케이션을 수시로 재구성하고 업그레이드할 수 있도록 해 준다.

웹 애플리케이션 서버의 출발 기반

웹 상에서 발생할 수 있는 문제를 해결하기 위해 등장했지만 방식은 서로 달랐다. 예를 들면 기존의 미들웨어 업체들은 웹 상에서 비즈니스 업무에 대한 고객들의 요구에 직면하자 DCOM 서버와 통신하기 위해 액티브 X 컴포넌트를 제공하거나 또는 자바와 연동될 수 있는 자바 클래스를 제

공했다. 물론 이러한 방식들은 웹 서버 기능은 없으나 웹과의 인터페이스를 제공하고 애플리케이션 서버 역할이 가능했다. 하지만 웹 서버와 미들웨어가 분리되어 각각의 독립적인 프로세스로 존재하기 때문에 웹 서버가 안고 있는 문제점은 그대로 갖고 있었다.

웹 서버 기능을 보완한 CGI 서버 업체들 역시 자체 아키텍처에 불만을 가지고 있었다. CGI 프로그램이 DB와 연동되거나 메인프레임에 접근할 때 데이터베이스 미들웨어를 사용하거나 3티어를 지원하는 미들웨어를 사용해야 했기 때문이다.

이러한 문제점을 보완하기 위해 CGI 서버 업체들은 웹 서버 기능에 미들웨어 기능을 추가했다. 또한 자바가 웹 애플리케이션의 표준 언어로 등장하면서 기존의 CGI 뿐만 아니라 자바 객체도 수행할 수 있는 구조를 만들었다. 이로써 웹 서버와 다른 시스템 사이를 3계층 구조로 만들어 웹 서버에 대한 애플리케이션 서버 역할까지 가능하도록 설계했다.

1997년 썬이 엔터프라이즈 자바빈을 발표한 이후 몇몇 업체들은 다양한 구현 방식을 수용할 수 있을 만큼 유연하고 미션 크리티컬한 개발을 지원하는 견고한 모델에 합의하였다. 이러한 합의 결과 만들어진 것이 엔터프라이즈 자바 API 스펙이며 이를 근간으로 비즈니스 업무를 처리하기 위한 하부구조를 마련해 주는 업체들이 서서히 등장하기 시작했다.

자바 엔터프라이즈 API의 등장

자바 엔터프라이즈 API(Java Enterprise APIs)는   ?80년대에 SQL이 관계형 데이터베이스 시장을 재 규정한 것과 같이 애플리케이션 서버 시장을 재 규정하고 있다.

엔터프라이즈 자바는 서버측 자바에 기초를 두고, 웹 환경에서 자바가 수행될 수 있는 환경과 자바 객체들간의 분산 컴퓨팅에 대한 프로토콜 스펙, 그들간의 트랜잭션 규약 및 서버측 자바의 트랜잭션 컴포넌트 만들기 위한 스펙, 자바로 미션 크리티컬한 업무를 웹과 클라이언트/서버 시스템을 복합 운영할 수 있는 스펙들이 있다.

엔터프라이즈 자바 API는 기업의 미션 크리티컬한 업무를 웹이나 클라이언트/서버 시스템으로 구축하기 위한 각종 스펙과 향후 웹 애플리케이션 서버 및 자바 중심의 클라이언트/서버 시장을 주도해 나갈 하부 구조를 제공한다. 이러한 자바 엔터프라이즈 API는 EJB, RMI, JDBC, JNDI, JTS, JMS, HTTP Servlets, SSL, HTTPS 등 다양한 스펙으로 구성되어 있다.

엔터프라이즈 자바빈(EJB)

EJB는 엔터프라이즈 자바 API중 가장 핵심적인 부분이다. 마이크로소프트의 MTS에 대응되는 자바 측의 기술로 서버 측의 트랜잭션에 관련되는 비즈니스 로직이나 데이터베이스 로직을 컴포넌트화 시키는 모델을 제공하고 있다.

자바는 현존하는 객체 기술 중에서 가장 현실적이고 보편화된 방안이다. 자바 기술의 본산인 썬에서는 기업 환경에서 자바를 사용하여 보다 편리하게 프로그램을 작성할 수 있도록 JPE(Java Platform for Enterprise) 표준을 발표하였다. 그 일부분인 EJB 기술은 트랜잭션 관리나 보안, 데이터베이스 커넥션 그리고 쓰레딩 등의 다양한 문제로부터 개발자를 분리시켜 준다.

EJB는 세션 빈과 엔터티 빈으로 구성되며, 엔터티 빈은 데이터 레코드에 연관되고 세션빈은 클라이언트의 세션을 관리하는 역할을 한다. 제품에 따라 클라이언트 코드에 대한 배포 기능, 장애시 가용성을 높여주는 HA 기능, 기존 시스템에 대한 손쉬운 접근 그리고 애플리케이션 상호 간의 연동 등 많은 편리한 기능들을 제공한다.

JDBC(Java DataBase Connectivity)

1997년, 썬은 엔터프라이즈 자바빈이라는 자바 구현을 위한 개방형 서버측 컴포넌트 표준을 개발했다. 이는 가장 좋은 솔루션을 내놓기 위해 여러 업체들과 긴밀하게 협력한 결과였다. 자바 데이터베이스 연결 API인 JDBC는 이러한 성공적인 결과물의 하나였다. JDBC는 마이크로소프트사의 ODBC에 기반하면서도 데이터베이스 업체들이 자사의 데이터베이스 접속 드라이버를 플러그인 할 수 있는 유연한 모델을 제공할 뿐 아니라 개발자들에게도 훨씬 쉽고 편리한 환경을 제공했기 때문이다.

JDBC API 스펙은 크게 데이터베이스 커넥션, 데이터베이스 메타 데이터에 관한 사항, 정적 SQL 질의어 및 동적 SQL을 수행하기 위한 사항, 질의 결과를 처리하기 사항, 데이터베이스 스토어드 프로시저에 관련된 사항으로 구성되어 있다.

자바 사용자는 이러한 JDBC API를 사용하여 로컬 및 리모트 데이터베이스에 접근할 수 있고 ODBC 드라이버와 마찬가지로 JDBC 드라이브 업체들은 위의 사항을 구현한 JDBC 드라이버를 제공하고 있다. 이 JDBC 드라이버는 100% 순수 자바로 만들 수 있으며, 기존의 데이터베이스 업체에서 제공하는 클라이언트 데이터베이스 미들웨어에 대한 인터페이스를 제공할 수도 있다.

자바 트랜잭션 서비스(JTS)

자바 트랜잭션 API는 트랜잭션 매니저(TM)와 애플리케이션(TP)과 애플리케이션 서버, 리소스 매니저(DBMS, Messaging System) 사이의 인터페이스를 규정한 것이다. JTA는 트랜잭션 매니저에게 자바 분산 환경에서 유저의 트랜잭션을 조정하게 할 수 있도록 하는 것이다. 전체적인 연관 관계는 그림과 같다. 애플리케이션은 애플리케이션 서버와 EJB 스펙에 의한 경계로 되어 있다. 애플리케이션에서 트랜잭션을 시작할 수 있으며, EJB 서버인 애플리케이션 서버가 담당할 수도 있다. 애플리케이션 서버는 리소스 매니저와 JDBC 혹은 JMS에 의하여 서로 인터페이스하고, 트랜잭션 매니저와 애플리케이션과의 관계는 JTA Use transaction에 의한 인터페이스로 되어 있다.

트랜잭션 매니저와 애플리케이션 서버와는 JTA Transaction Manager에 대한 인터페이스를 통해 트랜잭션을 관리한다. 트랜잭션 서버와 리소스 매니저와의 관계는 JTA Resource에 의해 인터페이스한다. 만약 애플리케이션 서버 내에 JTA 스펙을 구현한 경우는 애플리케이션 서버가 트랜잭션 매니저 역할을 하게 된다.

자바 네이밍 디렉토리 서비스(JNDI)

JNDI(Java Naming Directory Service)는 썬소프트와 노벨 등이 자바 프로그래머에게 네이밍과 디렉토리 서비스를 제공하고자 만든 스펙이다. 네이밍은 네트워크 상의 어떤 특정 노드를 지칭하는 IP 어드레스에 사용자나 객체 ID에 대한 이름을 붙일 때 사용하며, 디렉토리 서비스는 객체의 속성을 조작하는 서비스이다.

JNDI는 JNDI SPI와 API의 두 가지로 나뉜다. JNDI SPI는 네이밍 및 디렉토리 서버를 가지고 있는 업체들이 JNDI API를 사용하는 프로그램에게 해당 디렉토리 서비스에 접근할 수 있게 하는 것이다. 이는 DBMS 업자들이 자기 데이터베이스에 접근할 수 있도록 ODBC 드라이브를 제공하는 것과 비슷한 방식이다.

보통 LDAP, DNS, NIS, NDS, ODS, RMI 레지스트리 등에 대한 JNDI SPI가 구현되어 있고, JNDI API를 구현한 소프트웨어를 가지고 있으며 네이밍과 디렉토리 서버에 접근이 가능하다. 혹은 제3의 네이밍과 디렉토리 서버에 대해 JNDI SPI를 구현했으며 JNDI API를 통해 접근이 가능하다.

분산 객체를 위한 프로토콜 RMI

RMI(Remote Method Interface)는 자바에서 분산 객체를 위해 만들어진 프로토콜로 분산 환경에서 자바 to 자바 프로그래밍을 지원한다. RPC 미들웨어와 비슷하게 IDL 컴파일러를 갖고 있으며, 클라이언트가 리모트의 객체 메소드를 호출할 때 그 파라미터 인자로 객체를 사용할 수 있다. 이는 코바나 DCOM이 지원하지 못하는 Object BY Value를 제공해 가능한 것이다. 마이크로소프트 DCOM의 MIDL 컴파일러의 경우, IDL 파일을 만들고 여기에 리모트 객체의 메소드들과 데이터를 주고받을 변수의 포맷 및 IN, OUT 속성을 정의해 컴파일러를 수행하면 클라이언트와 서버 측에 각각 스텁이 만들어진다.

자바의 RMI는 개발 방식이 조금 차이가 난다. 클라이언트 프로그램이 리모트의 서버 객체의 메소드를 호출하기 위해서 그 메소드에 대한 인터페이스를 만든다. 이는 IDL 디스그립션 파일과 같다. 이 인터페이스를 상속받아 구현하는 객체를 만들고 컴파일한 다음 이 컴파일된 구현 객체를 가지고 RMIC이란 IDL 컴파일러를 수행하면 클라이언트와 서버 스텁이 생기게 된다.

이러한 RMI를 사용하여 서버 프로그램을 작성하는 경우, 보통 JNDI API를 사용하여 그 객체의 유저에게 친숙한 이름으로 JNDI에 등록한다. 클라이언트에서 해당 서버 객체를 찾고자 하는 경우 JNDI API를 사용하여 위의 이름을 사용하여 객체를 찾아 그 속의 메소드를 호출하면 된다.

웹 애플리케이션 서버의 선두주자 -  BEA 웹로직 애플리케이션 서버

자바는 지금까지 주로 스탠드 얼론 애플릿이나 서블릿에 사용되어 왔지만 앞으로는 분산 컴포넌트 아키텍처에 사용될 것이다. 이제 남은 것은 업체들이 엔터프라이즈 자바 API를 최대한 활용한 제품을 만들어내는 것이다. 웹로직 애플리케이션 서버는 이 요구에 가장 충실한 제품이다.

자바가 가능성을 열고, 웹로직이 실현

웹로직은 자바가 OS냐, 플랫폼이냐, API 셋이냐 아니면 하나의 언어에 불과하느냐는 논란을 일축시켰다. 개발자들은 시장을 이끌고 있는 몇몇 플랫폼 군에서 돌아가는 3계층 애플리케이션들을 빠르고 신뢰성 있게 모을 수 있는 클래스 셋을 얻게 되었다. 웹로직의 두드러진 특징은 순수 자바이며 기업 규모의 애플리케이션 서버가 수행해야 하는 모든 일들을 실질적으로 수행한다는 점이다. 다시 말해 웹로직은 기능을 풍부하게 제공할 뿐만 아니라 강력하며 수행력도 우수하다. 웹로직은 썬의 자바 엔터프라이즈 API를 강력하고 유연하게 지원하는 첫 번째 제품이다.

주요 기능

웹로직 애플리케이션 서버는 대규모 네트워크 애플리케이션의 개발과 통합 및 구현 그리고 관리에 자바의 강력한 힘과 자바 엔터프라이즈 표준의 안정성을 부여하였다. 따라서 개발자들은 이제 비즈니스 로직에만 신경을 쓰면 된다. 이종의 데이터 소스 통합이나 성능에 대한 고민을 할 필요가 없다.

빠르고 쉬운 인터넷 애플리케이션 구축

웹로직 애플리케이션 서버를 이용하면 원하는 자바 개발 툴이나 웹 퍼블리싱 툴로 네트워크 애플리케이션을 빠르게 개발할 수 있다. 시만텍의 비주얼 까페, 인프라이즈의 J빌더, 사이베이스의 파워제이, IBM의 비쥬얼에이지 for 자바, 슈퍼시드, 마이크로소프트의 Visual J++ 등 어떤 툴과도 결합할 수 있는 구조를 갖고 있다. 개발자들은 단지 자바빈즈를 드래그 앤 드롭하여 애플리케이션을 만들 수 있다.

또한 기존의 자바 애플리케이션 컴포넌트나 마이크로소프트의 애플리케이션 컴포넌트들을 수정없이 웹로직 애플리케이션 서버에 결합시킬 수 있다. 웹로직 COM은 마이크로소프트의 컴포넌트를 웹로직 프레임워크에 플러그인, 자바 클래스로 자동 웨퍼하여 네트워크 상에서 투명하게 공유할 수 있게 한다. 이는 솔라리스 사용자가 자신의 워크스테이션에서 엑셀과 같은 윈도우 애플리케이션을 실행시킬 수 있음을 의미한다.

기존 시스템과 인터넷의 유연한 통합

웹로직 애플리케이션 서버는 네트워크의 어디에서나 조직 내 데이터베이스에 접근하여 트랜잭션을 완벽하고 안전하게 처리할 수 있다. 또한 기존 시스템에 접근하는 다양한 통로를 제공해 실시간 자바 바인딩에서 애플리케이션간 메시징 또는 CORBA로의 접근이 가능하다.

웹로직은 JNDI를 통하여 노벨의 NDS, 썬의 NIS+, 마이크로소프트의 액티브 디렉토리 그리고 기타 LDAP을 지원하는 디렉토리 서비스에 접속할 수 있고 자바의 통제하에 작동되는 멀티 티어로 구현되어 기존의 네이밍 서비스에 저장된 정보에 접근하고 이를 갱신할 수도 있다.

대규모의 강력한 인터넷 배치

웹로직 클러스터는 서버로의 디스패칭을 위한 프락싱 기능과 서버간의 리퀘스트 포워딩 기능을 제공하여 리퀘스트 레벨에서 로드 밸런싱이 가능하다. 세션 관리와 상태 정보가 각 서버간에 복제되므로 하나의 서버가 정지하더라도 정상적인 서비스를 제공받을 수 있으며, 각 클러스터간 보안과 시스템 관리도 통일적으로 이루어진다.

또한 RSA 기반 보안 제품 및 방화벽 제품들과 통합 기능을 제공하고 각 데이터베이스에 접속 풀을 제공하여 클라이언트가 사용자와 패스워드 정보에 직접 접속하는 것을 막아준다. 특히 웹로직이 제공하는 동적 애플리케이션 분할 기능은 업무나 네트워크의 변화에 실시간으로 대응할 수 있도록 애플리케이션을 이동 또는 재배치할 수 있도록 해준다.

저비용의 유연한 관리

웹로직은 중앙집중식으로 모니터링하고 시스템을 업데이트할 수 있는 GUI 방식의 관리 클라이언트를 제공한다. 콘솔을 통해 클래스 패스와 자바 힙 사용상태 같은 세부적인 것들부터 JDBC 드라이버 정보, 서블릿, 쓰레드, 유저, 소프트웨어 버전, 라이센스 등 웹로직 애플리케이션 서버에 관한 각종 정보들을 텍스트나 그래픽 형태로 제공받을 수 있다.

특히 인터넷상의 데스크탑과 서버에 소프트웨어를 자동으로 분배하기 때문에 관리자들은 소프트웨어 설치와 업그레이드를 중앙집중식으로 관리할 수 있다. 중앙에서 프로그램 라이브러리들을 설치할 수 있으며, 갱신된 컴포넌트들이 모두 정확한 위치에 제대로 설치되었는지 확인할 수 있다. 이밖에 이용 통계, Audit 트레일(감사 기록) 그리고 애플리케이션의 예외상황 같은 시스템 진단 정보를 제공하기 때문에 문제 발생시 쉽게 상황을 파악하고 해결할 수 있다

현재 나와있는 BEA WebLogic Enterprise 4.0은 C++ 및 자바를 사용하는 CORBA를 지원하여 BEA Tuxedo API를 지원한다. 특히 올말에 발표될 BEA WebLogic Enterprise 5.0은 자바 언어, 자바 엔터프라이즈 API(EJB 포함), C++와 자바를 지원하는 CORBA 및 기존 BEA Tuxedo API를 모든 지원하는 통합 제품이 될 것이다.

미래의 개발 환경 

웹 애플리케이션을 개발하기 위한 방법들은 무수히 많다. 기존 응용프로그램 및 시스템 하부구조를 그대로 활용하면서 웹과 인터페이스를 모색하는 것이 기존 자원의 효과적인 활용 측면에서 분명한 이점이 된다. 앞으로 웹 서버가 가지고 있는 문제점을 극복하는데 있어, 확장성이 우수한 웹 미들웨어의 도입을 검토하는 것도 한가지 방법이 될 수 있다. 이를 이용해 구축한 시스템은 뛰어난 유연성과 경쟁력을 확보할 수 있기 때문이다.

엔터프라이즈 자바 API의 등장은 자바가 GUI 중심의 클라이언트보다는 서버 측 자바 기술에 초점을 맞추고 있음을 의미한다. 따라서 클라이언트 프리젠테이션 로직은 WIN32 중심의 C++에서 자바 AWT 혹은 스윙으로, 서버 로직은 C에서 자바로 전환을 시도하는 것도 좋은 방법이 될 것이다. 이것은 GUI 뿐만이 아니라 서버 측의 자바를 클라이언트에서 개발하여 컴파일한 후 서버로 배치가 가능하다는 장점이 있다.

우리는 기술의 홍수 속에 살고 있다. 웹 애플리케이션 서버의 기술의 흐름을 예측하기란 쉽지 않지만 분산 객체와 분산 시스템하의 트랜잭션 처리 등이 하나의 신기술로 접목되는 형태가 될 것은 분명하다. 이의 근간이 되는 기술은 엔터프라이즈 자바 API, 코바 OTM, MTS/DCOM 위에서 존재할 것이다.