"와스"의 두 판 사이의 차이
(→개요) |
(→비교) |
||
43번째 줄: | 43번째 줄: | ||
웹 서버는 정적 데이터를 처리하고, 웹 애플리케이션 서버는 동적 데이터를 처리한다. 이 특징으로, 실무에서는 이 둘을 연동하여 사용하는데, 와스는 동적 처리에 최적화 되어 있는 서비스이기 때문에 처리 속도를 위해, 정적 처리는 웹서버에서 처리를 하고, 동적 컨텐츠는 와스에서 처리한다. 웹 서버에 웹 문서를 처리하는 기능을 분배하여 서버의 부담을 줄일 수 있고, 이로 인해 웹 애플리케이션에서 정적 데이터 처리를 위해 지연되는 시간이 줄어들어 동적 컨텐츠의 처리 속도가 빨라진다.<ref>논리적 코딩, 〈[https://logical-code.tistory.com/30 웹 서버와 웹 어플리케이션 서버의 차이]〉, 《티스토리》, 2017-12-22</ref> | 웹 서버는 정적 데이터를 처리하고, 웹 애플리케이션 서버는 동적 데이터를 처리한다. 이 특징으로, 실무에서는 이 둘을 연동하여 사용하는데, 와스는 동적 처리에 최적화 되어 있는 서비스이기 때문에 처리 속도를 위해, 정적 처리는 웹서버에서 처리를 하고, 동적 컨텐츠는 와스에서 처리한다. 웹 서버에 웹 문서를 처리하는 기능을 분배하여 서버의 부담을 줄일 수 있고, 이로 인해 웹 애플리케이션에서 정적 데이터 처리를 위해 지연되는 시간이 줄어들어 동적 컨텐츠의 처리 속도가 빨라진다.<ref>논리적 코딩, 〈[https://logical-code.tistory.com/30 웹 서버와 웹 어플리케이션 서버의 차이]〉, 《티스토리》, 2017-12-22</ref> | ||
+ | |||
+ | 위에서 설명한 각 서버에서 보듯이 기능적인 차이로 구분을 지어 사용한다. 웹 서버는 정적 데이터를 처리하는 용도로, 웹 애플리케이션 서버는 동적 데이터를 처리하는 용도로 말이다. 하지만 톰캣의 경우처럼 웹 애플리케이션 서버에 웹 서버 기능을 포함된 서버 프로그램도 존재한다. 간단히 집에서 웹서버 기능이나 웹 애플리케이션을 이용하고자 한다면 톰캣만 설치해도 된다. 반대로 웹 서버에서 내부에 애플리케이션을 동작할 수 있는 기능을 내장하기도 한다. 간단한 웹 사이트를 구축한다면 웹 서버와 웹 애플리케이션 서버를 구분 지어 사용할 필요가 없다. 톰캣 하나만 설치하면 되기 때문이다. 그럼 웹 서버와 웹 애플리케이션 서버를 어떻게 구성해 사용하는지 살펴 보도록 하겠다. | ||
+ | |||
+ | *스위치 - WAS | ||
+ | 웹 사이트의 가장 기본적인 구성 환경이다. 모든 컨텐츠를 WAS에 모아 놓고, WAS가 웹서버와 웹 애플리케이션 서버 역할을 동시에 수행한다. 트래픽이 많지 않고, 간단한 웹 사이트 서비스를 제공하거나, 개발 및 테스트 시스템 구성시 활용하기도 한다. 스위치로 로드밸런싱을 하기 때문에 쉽게 다른 WAS를 설치하여, 부하를 분산 시킬 수 있는 장점이 있는 반면에, WAS가 웹서버와 웹 애플리케이션 서버 역할을 동시에 수행하기 때문에 각각의 기능이 다른 기능 수행시 부하를 발생 시킬 수 있기 때문에 성능 저하가 나타날 수 있는 단점을 가지고 있다. | ||
+ | |||
+ | *스위치 - 웹 서버 - WAS | ||
+ | 웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태라고 한다. 정적인 데이터는 웹 서버가, 동적인 데이터는 WAS가 담당하게 함으로써 간단한 1번 구조보다 더 나은 성능을 발휘 한다. | ||
+ | |||
+ | *(스위치 - 웹 서버 - WAS) + 이미지를 위한 웹 서버 | ||
+ | 초고속 인터넷이 발달함에 따라 고화질의 이미지나 동영상을 제공하는 페이지가 증가하고 있다. 이러한 페이지는 네트워크 비중의 상당 부분을 차지한다. 그래서 고화질 이미지나 동영상 데이터 제공을 위한 웹서버를 따로 추가하여, 기존 네트워크 비중도 줄이고, 기존의 웹 서버와 WAS를 좀 더 효율적으로 사용할 수 있도록 하는 구성이다. 이러한 구조는 다양한 환경의 대한 네트워크 이슈를 좀 더 용이하게 대처할 수 있지만, 구조를 정확하게 이해하지 않았을 경우 개발 및 테스트에 많은 시간이 소요 된다. | ||
+ | |||
+ | *스위치 - 웹 서버 - WAS(프리젠테이션) - WAS(비즈니스) | ||
+ | 이 구조는 2번째 구조를 변경한 형태이다. WAS단의 프로그램들이 많은 비중을 차지할 때, Presentation Logic을 담당하는 프로그램과 Business Logic을 담당하는 프로그램을 구분하여 각각의 WAS가 처리하도록 분리하는 형태이다. 이러한 구조는 계층 구조의 부하를 적절히 분산할 수 있는 반면, 구조가 복잡해 유지보수가 어려워지는 단점을 가지고 있습니다.<ref>빌리, 〈[https://bsnippet.tistory.com/47 웹 서버와 웹 애플리케이션 서버]〉, 《티스토리》, 2013-07-02</ref> | ||
==전망== | ==전망== |
2020년 8월 24일 (월) 10:50 판
와스(WAS)란 "Web Application Server"의 약자로서, 웹 응용 프로그램이 설치되어 작동하는 웹 애플리케이션 서버를 말한다. 미들웨어의 일종이자 시스템 소프트웨어의 일종이다. 웹서버에는 HTML 문서가 저장되고, 와스에는 Java 등 응용 프로그램 파일이 저장된다. 주로 영어 약자인 WAS라고 쓴다.
개요
와스는 웹과 기타 클라이언트 인터페이스를 지원하는 다계층 아키텍쳐에서 안정적인 트랜잭션 처리를 가능하게 해주고, 분산 시스템을 개발 도와주는 역할을 하는 미들웨어의 일종으로 이해할 수 있다. 이와 같은 개념은 새로운 것이 아니며, 이미 기존의 TP 미들웨어나 RDBMS 제품 혹은 클라이언트 서버 제품에서 부분적으로 이미 제공되고 있던 것이 웹 기반을 강화하면서 와스로 새롭게 소개되고 있는 것이다. 와스는 그 기능과 발달단계에 따라 크게 네 가지로 구분이 가능하다. 웹 사이트 툴(Web Site Tool)은 서버단의 프로그램이나 컴포넌트가 HTML 스크립트를 전송하고 받을 수 있도록 하는 기능을 제공하는 것으로, 복잡한 웹 애플리케이션의 통합 기능은 제공하지 않는다. 이는 실제로는 운영 체계나 프로그램의 인터페이스인 API와 큰 차이가 없으며, 다만 기존의 애플리케이션이 인터넷 환경에서 인터페이스를 갖게 하기 방편으로 이해될 수 있다. 기본 애플리케이션 서버(Modest Application Server)는 웹 환경 아래서 애플리케이션간의 통신 등의 기본적인 애플리케이션 서버 기능을 제공하며, 기존의 트랜잭션 미들웨어 제품들이 이에 속한다. 기업용 애플리케이션 서버(Enterprise Application Server) 같은 경우는 단순히 엔드 투 엔드(End-to-End) 방식의 통신을 넘어서 애플리케이션 간에 인터랙티브한 정보교환이 이루어지게 하는 기반 구조를 가지고 있다. 이 제품들은 기본 통합 기능 이외에도 애플리케이션 간의 상호 차별적 인증과 정보교환, 보안 등의 부가기능도 제공한다는 특징이 있다. 패키지 애플리케이션 서버 수트(Packaged Application Server Suites)는 e 비즈니스를 위해 기업 내 애플리케이션 통합 뿐 아니라 기업 간 애플리케이션 통합을 전제로 설계된 애플리케이션 서버들이다. 이는 다른 기업의 애플리케이션과의 통신을 위해 되도록 적은 커스터마이징을 하도록 설계되어 있으며, B2Bi를 위한 통합 엔진으로써 사용되는 것을 목적으로 설계된 것들이 대부분이다. 또한 와스 개발 업체들은 각자 컴포넌트 모델을 구현해 제품을 출시하고 있는데, 이가 어떤 개발 프레임워크로 개발되었는가에 따라 DCOM/COM 기반 와스, CORBA 기반 와스, EJB 기반 와스 등으로 구분이 가능하다. 초기의 제품들은 CORBA(Common Object Request Broker Architecture)를 기본으로 개발된 것들이 많으며, 비지브로커, 오빅스가 대표적이다. DCOM(Distribute Component Object Model)은 마이크로소프트에서 제시한 프레임워크로 마이크로소프트 제품군이 이 방식을 따르고 있다. 그러나 J2EE 표준이 만들어지면서 최근의 대부분의 기업용 와스 제품들은 EJB(Enterprise JavaBeans) 방식으로 개발되고 있으며, 대표적인 것으로는 웹로직, 웹스피어 등이 있다. 주의할 것은 J2EE을 기반으로 한 제품들이라고 해서 모든 기업 상황에 다 적합한 것은 아니라는 점이다. 어떤 기반의 와스를 선택하는가 하는 것은 기업의 어떤 목적으로 와스를 도입하려는가에 달려있다. 기업 내의 애플리케이션 통합과 통신만이 목적인 경우는 DCOM이나 EJB 기반이 유리하며, B2B 통합과 같은 기업 간 통합을 위한 프로젝트에는 EJB 기반의 와스가 유리한 것으로 알려져 있다. 한편, 많은 양의 트래픽을 안정적으로 처리하는 시스템을 구축하고자 하는 경우에는 CORBA 기반의 제품이 추천되고 있다.[1]
역사
1990년대 초반 클라이언트/서버(C/S) 시스템에서는 클라이언트에 화면을 구성하는 각종 기능을 제공하는 Thick 클라이언트 구조가 대세였다. 하지만, RDBMS를 포함하는 서버 가격은 매우 고가이고 변경이 편리하지 않은 단점이 있었다. 따라서, 업무 프로세스를 변경할 경우 화면 프로그램을 교체하는 경우가 있었으나, 그 당시는 사용자가 주로 인트라넷이었기 때문에 큰 어려움이 없었다. 1990년대 후반 인터넷이 보급되면서 웹 브라우저를 사용한 전자상거래의 요구가 생기기 시작했다. 웹 브라우저를 주로 사용하는 시스템은 사용자가 불특정 다수이기 때문에 시스템의 변경에 따라 사용자의 화면을 수정하는 것은 거의 불가능하다. 이러한 요구와 함께 서버의 고성능화(UNIX서버 등의 저가의 고성능 서버 등장)와 초고속 네트워크 등장, 자바 등의 프로그램 언어의 처리능력 향상으로 애플리케이션의 위치가 클라이언트에서 서버로 전환되었다. 1990년대 후반에는 웹 브라우저를 화면으로 사용하면서 서버에서 애플리케이션을 수행하는 시스템이 일반화되었다.[2]
특징
와스는 플랫폼 기능, 런타임 매니지먼트 서비스, 통합 기능, 툴 개발 등의 기능을 제공한다.
- 플랫폼 기능(Platform service)
다양한 기반으로 구축된 클라이언트와의 인터페이스를 제공하는 기능을 말한다. 클라이언트가 웹 브라우저기반일 경우 대부분의 와스는 HTTP 서버에 게이트웨어 인터페이스인 CGI(Common Gateway Interface)나 마이크로 소프트의 인터넷 AIP (IAPI), 넷 스케이프의 NSAPI 등의 리퀘스터를 통해 어프리케이션과의 연결기능을 제공한다. 최근에는 리퀘스터를 통해서 뿐만 아니라 다계층 아키텍쳐로 이러한 기능을 제공하는 경우가 많다. 이러한 기능을 클라이언트 연결(Client connectivity services)이라고 한다. 원래 HTTP 문서들은 문서의 정보를 입력하고 있는 태그(tag)가 정의되어 있지 않은 것이 대부분이다. 이러한 특징은 HTTP 자체를 가볍게 하는데는 효과적이지만, 어플리케이션과의 통신에는 적합하지 않다. 스테이트 메니지먼트 서비스(Stated Management)는 HTTP 문서와의 의사소통이 가능하도록 만들어주는 역할을 하는 것으로, HTTP 클라이언트에 대한 정보를 붙여줌으로써 이들이 다른 어플리케이션과의 통신이 가능하도록 하는 역할을 한다.
- 런타임 매니지먼트 서비스(Runtime management services)
와스의 구동을 실시간으로 감시하고 리포팅하는 기능이며, 어플리케이션간의 실시간 연결, 데이터베이스 연결, 등의 여러 부가 기능들을 제공한다. 특히 트렌젝션 프로세싱 서비스(Transaction processing service)는 컴포넌트와 컴포넌트(혹은 어플리케이션과 어플리케이션)가 효과적인 통신이 가능하도록 만들어주는 역할을 한다. 많은 정보량이 한꺼번에 몰릴 수 있는 서버의 부하를 효율적으로 조절함으로써 시스템의 안정성을 높여주는 역할이 트랜젝션 프로세싱의 역할이다.
- 통합 서비스(Integration services)
기존의 시스템과 새로운 어플리케이션간의 통합기능을 제공한다. 이들은 기존의 패키지 어플리케이션, 데이터 베이스와 이들을 연결해 주었던 미들웨어들은 각각의 설치 환경에 따라 각기 구축되어 있는 경우가 많다. 통합 기능은 이러한 파편화된 어플리케이션들을 통합함으로써 서로간의 연동이 가능한 구조로 만드는 역할을 한다.
- 툴 개발(Tool development)
와스의 환경 안에서 기업에게 필요한 다른 응용프로그램을 개발할 수 있는 툴을 제공하는 것을 의미한다. 와스 업체들은 자신들이 개발한 툴을 와스의 아키텍처에 넣어놓거나, 전문 툴 개발업체에서 개발한 표준화한 툴이 연동될 수 있도록 설계하고 있다. 그 기업에 맞는 프로그램을 기업들이 스스로 개발할 수 있도록 와스를 통해 여러 정보가 통합되면 보안도 매우 중요해 진다. 와스에서 특히 중요한 것은 통합된 정보들은 정보 사용자에 따라 각기 다른 수준의 정보가 제공되어야 한다는 점이다. 이를 위해서 와스는 정보사용자 뿐만 아니라 그 디바이스에 대한 인증 기능을 갖추어야 하며 이를 통해 차별화된 정보 제공을 할 수 있게 된다. 현재 하나의 와스 솔루션이 이러한 다양한 기능을 모두 완벽하게 지원하는 것은 현실적으로 불가능하다. 따라서 와스 업체들은 기존에 자신들이 강점을 자기고 있던 분야를 중심으로 자신의 제품을 와스로 규정하고 시장에 진출하고 있다.[1]
현황
와스 시장이 급성장 하는 가장 커다란 원인은 와스가 향후 EAI와 B2Bi 프로젝트에서 핵심 엔진으로 사용될 것으로 예상되기 때문이다. 현재 많은 업체들이 와스의 성장 가능성에 주목하고 있으며, 다양한 업체들이 자신들의 제품을 와스로 마케팅하며 적극적으로 시장에 진출하고 있다. 이처럼 다양한 배경의 업체들이 와스를 개발할 수 있는 것은 어플리케이션 서버가 통신과 통합에 관련된 부분을 어디에 위치시키느냐에 따라 다양한 구현이 가능하기 때문이다. 우선 RDBMS 제품을 중심으로한 인프라스트럭쳐 업체들은 스스로를 와스로 정의하고 있지는 않으나, 기본적으로 와스에서 제공하는 대부분의 핵심 서비스를 모두 제공한다. 여기에 RDBMS 제품들 중 일부는 데이터베이스 인프라스트럭쳐를 바탕으로 어플리케이션 서버 기능에다 인터페이스를 통합 관리할 수 있는 팩키지화된 솔루션을 제공하고 있다. 특히 오라클이 최근 발표한 9iAS는 그 동안 상이한 벤더들이 제공하던 단편적인 미들웨어 제품을 통합함으로써, 경제적으로 애플리케이션을 통합할 수 있게 했다. 미들웨어 제품들은 서로 다른 기종의 어플리케이션이나 컴포넌트간의 통신을 원할 하게 한다는 점에서 와스 제품군을 보유할 수 있다. 실제로 인프라이즈(Inprise), BEA와 같은 업체들은 TP 모니터와 같은 통신기능에 어플리케이션 통합 로직을 더함으로써, 이미 와스 시장에서 중요한 업체로 자리잡고 있다. 또한 컴퓨웨어(Compuware), 포르테 소프트웨어 (Forte Software), 다이너스티(Dynasty)와 같은 클라이언트 서버 툴 개발 업체들 중 일부도 자신들의 제품을 와스로 포지셔닝하고 있다. 이들은 어플리케이션들이 다양한 클라이언트에 분산될 수 있도록 했던 자신들의 개발 툴에 미들웨어 통신기능을 강화함으로써 자신들의 제품을 어프리케이션 서버제품으로 포지셔닝 하고 있다. 이외에도 SI 업체들, 비즈니스 솔루션 업체들이 이 시장에 관심을 가지고 진출하고 있다. 국내 와스 시장은 BEA, IBM, 오라클 등의 외국 업체들이 주도하고 있다. 이는 기존의 미들웨어와 RDBMS 관련 기술이 국내에 전무하다시피 했기 때문이며, 따라서 국내의 시장 점유율 현황은 거의 해외의 그것과 유사하다. 컴퓨터 월드에 의하면 2000년 국내 와스 시장은 BEA와 IBM이 선두 업체인 것으로 파악되고 있다. 그러나 최근 적극적으로 와스 시장에 진입하고 있어서, 국내 주요 와스 시장은 이 세 기업에 의해 주도될 것으로 보인다.[1]
종류
글래스피시 |
레진 |
와일드플라이 |
웹로직 |
웹스피어 |
제우스 |
톰캣 |
비교
구분 역할 프로그램 명 웹서버 웹 클라이언트의 요청을 받아서 요청을 처리하고, 그 결과를 웹 클라이언트에게 응답한다. 주로 정적 페이지인 HTML, 이미지, CSS, 자바스크립트 파일을 웹 클라이언트에 제공할 때 웹 서버를 사용한다. 만약 동적 페이지 처리가 필요하다면 웹 애플리케이션 서버에 처리를 넘긴다. Apache httpd, Nginx, Iighttpd, IIS 등 웹 애플리케이션 서버 웹 서버로부터 동적 페이지 요청을 받아서 요청을 처리하고, 그 결과를 웹 서버로 반환한다. 주로 동적 페이지 생성을 위한 프로그램 실행과 데이터베이스 연동 기능을 처리한다. Apache Tomcat, JBoss, WebLogic, WebSphere, Jetty, Jeus 등
웹 서버는 정적 데이터를 처리하고, 웹 애플리케이션 서버는 동적 데이터를 처리한다. 이 특징으로, 실무에서는 이 둘을 연동하여 사용하는데, 와스는 동적 처리에 최적화 되어 있는 서비스이기 때문에 처리 속도를 위해, 정적 처리는 웹서버에서 처리를 하고, 동적 컨텐츠는 와스에서 처리한다. 웹 서버에 웹 문서를 처리하는 기능을 분배하여 서버의 부담을 줄일 수 있고, 이로 인해 웹 애플리케이션에서 정적 데이터 처리를 위해 지연되는 시간이 줄어들어 동적 컨텐츠의 처리 속도가 빨라진다.[4]
위에서 설명한 각 서버에서 보듯이 기능적인 차이로 구분을 지어 사용한다. 웹 서버는 정적 데이터를 처리하는 용도로, 웹 애플리케이션 서버는 동적 데이터를 처리하는 용도로 말이다. 하지만 톰캣의 경우처럼 웹 애플리케이션 서버에 웹 서버 기능을 포함된 서버 프로그램도 존재한다. 간단히 집에서 웹서버 기능이나 웹 애플리케이션을 이용하고자 한다면 톰캣만 설치해도 된다. 반대로 웹 서버에서 내부에 애플리케이션을 동작할 수 있는 기능을 내장하기도 한다. 간단한 웹 사이트를 구축한다면 웹 서버와 웹 애플리케이션 서버를 구분 지어 사용할 필요가 없다. 톰캣 하나만 설치하면 되기 때문이다. 그럼 웹 서버와 웹 애플리케이션 서버를 어떻게 구성해 사용하는지 살펴 보도록 하겠다.
- 스위치 - WAS
웹 사이트의 가장 기본적인 구성 환경이다. 모든 컨텐츠를 WAS에 모아 놓고, WAS가 웹서버와 웹 애플리케이션 서버 역할을 동시에 수행한다. 트래픽이 많지 않고, 간단한 웹 사이트 서비스를 제공하거나, 개발 및 테스트 시스템 구성시 활용하기도 한다. 스위치로 로드밸런싱을 하기 때문에 쉽게 다른 WAS를 설치하여, 부하를 분산 시킬 수 있는 장점이 있는 반면에, WAS가 웹서버와 웹 애플리케이션 서버 역할을 동시에 수행하기 때문에 각각의 기능이 다른 기능 수행시 부하를 발생 시킬 수 있기 때문에 성능 저하가 나타날 수 있는 단점을 가지고 있다.
- 스위치 - 웹 서버 - WAS
웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태라고 한다. 정적인 데이터는 웹 서버가, 동적인 데이터는 WAS가 담당하게 함으로써 간단한 1번 구조보다 더 나은 성능을 발휘 한다.
- (스위치 - 웹 서버 - WAS) + 이미지를 위한 웹 서버
초고속 인터넷이 발달함에 따라 고화질의 이미지나 동영상을 제공하는 페이지가 증가하고 있다. 이러한 페이지는 네트워크 비중의 상당 부분을 차지한다. 그래서 고화질 이미지나 동영상 데이터 제공을 위한 웹서버를 따로 추가하여, 기존 네트워크 비중도 줄이고, 기존의 웹 서버와 WAS를 좀 더 효율적으로 사용할 수 있도록 하는 구성이다. 이러한 구조는 다양한 환경의 대한 네트워크 이슈를 좀 더 용이하게 대처할 수 있지만, 구조를 정확하게 이해하지 않았을 경우 개발 및 테스트에 많은 시간이 소요 된다.
- 스위치 - 웹 서버 - WAS(프리젠테이션) - WAS(비즈니스)
이 구조는 2번째 구조를 변경한 형태이다. WAS단의 프로그램들이 많은 비중을 차지할 때, Presentation Logic을 담당하는 프로그램과 Business Logic을 담당하는 프로그램을 구분하여 각각의 WAS가 처리하도록 분리하는 형태이다. 이러한 구조는 계층 구조의 부하를 적절히 분산할 수 있는 반면, 구조가 복잡해 유지보수가 어려워지는 단점을 가지고 있습니다.[5]
전망
와스에 대한 이해를 바탕으로 기업이 와스 솔루션과 관련 통합 프로젝트를 수행할 때 무엇을 고려해야 하는가에 대하여 살펴보았을 시 와스는 하나의 제품이라기보다는 기존의 미들웨어 등의 여러 컴포넌트가 결합되어 만들어진 복잡한 기반 소프트웨어라는 점을 알 수 있다. 또한 이들은 자신들의 강점을 바탕으로 그 기능의 범위를 EAI나 B2Bi 솔루션으로까지 확장하고 있는 상황이다. 따라서, 하나의 솔루션 도입만으로 통합과 관련된 완전한 해답을 얻는 것은 불가능한 것이 현실이다. 실제로 EAI와 B2Bi를 위해 많은 미들웨어와 와스를 도입했던 해외 기업들은 ‘통합솔루션의 통합을 위한 또 다른 통합 솔루션이 필요’할 것으로 예상하고 있다. 더욱이 솔루션 업체들이 활발한 M&A를 통해 자신들의 솔루션 맵을 빠르게 확장하고 있어, 기업들은 자신의 통합 목적에 맞는 솔루션 도입이 현실적일 것으로 판단된다. 현재 대부분의 솔루션 도입은 기업내의 CIO가 제품의 기술적인 고려를 바탕으로 솔루션을 도입하는 경우가 대부분이다. 그러나 와스와 같은 통합 솔루션의 도입에는 기업의 전략적 목표가 먼저 정확히 그려지는 것이 바람직하며, 이를 위한 CEO의 적극적인 방향제시가 필요할 것으로 판단된다.[1]
각주
- ↑ 1.0 1.1 1.2 1.3 심동철, 〈[file:///C:/Users/envy/Downloads/%EC%9B%B9%20%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%EC%84%9C%EB%B2%84(Web%20Application%20Server)%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%9D%B4%ED%95%B4%EC%99%80%20%EA%B8%B0%EC%97%85%EC%9D%98%20%EC%86%94%EB%A3%A8%EC%85%98%20%EC%84%A0%ED%83%9D%20%EC%A0%84%EB%9E%B5.pdf 웹 어플리케이션 서버 (Web Application Server)에 대한 이해와 기업의 솔루션 선택 전략]〉, 《정보통신정책연구원》, 2001-09
- ↑ 웹 애플리케이션 서버 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98_%EC%84%9C%EB%B2%84
- ↑ 기억 저장소, 〈웹 어플리케이션 서버〉, 《티스토리》, 2019-09-16
- ↑ 논리적 코딩, 〈웹 서버와 웹 어플리케이션 서버의 차이〉, 《티스토리》, 2017-12-22
- ↑ 빌리, 〈웹 서버와 웹 애플리케이션 서버〉, 《티스토리》, 2013-07-02
참고자료
- 심동철, 〈[file:///C:/Users/envy/Downloads/%EC%9B%B9%20%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%EC%84%9C%EB%B2%84(Web%20Application%20Server)%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%9D%B4%ED%95%B4%EC%99%80%20%EA%B8%B0%EC%97%85%EC%9D%98%20%EC%86%94%EB%A3%A8%EC%85%98%20%EC%84%A0%ED%83%9D%20%EC%A0%84%EB%9E%B5.pdf 웹 어플리케이션 서버 (Web Application Server)에 대한 이해와 기업의 솔루션 선택 전략]〉, 《정보통신정책연구원》, 2001-09
- 웹 애플리케이션 서버 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98_%EC%84%9C%EB%B2%84
- 논리적 코딩, 〈웹 서버와 웹 어플리케이션 서버의 차이〉, 《티스토리》, 2017-12-22
- 기억 저장소, 〈웹 어플리케이션 서버〉, 《티스토리》, 2019-09-16
같이 보기