오픈비 : 삽질은없다

● HP
- HP는 독점 및 오픈 소스 방식이 혼합된 사전 검증 솔루션 스택으로 구성된 오픈 소스 미들웨어 스택(OSMS)을 사용. OSMS에는 BEA 및 Oracle®의 상용 소프트웨어와 함께 JBoss, MySQL, The Apache Software Foundation, OpenLDAP Foundation, Jabber 등의 오픈 소스 소프트웨어가 포함.

● ReaHat
- Red Hat Application Stack 은 완벽하게 통합된 오픈소스 스택으로 , Red Hat Enterprise Linux, Tomcat 을 포함한 JBoss Application Server, JBoss Hibernate 및, MySQL 이나 PostgreSQL등의 오픈소스 데이터 베이스, Apache Web Server 등으로 구성.
서버당 연간 서브스크립션으로 판매되며, Red Hat Network를 통해 온라인으로 제공. Basic Edition 지원레벨부터 24시간 연중무휴의 Premium Edition 지원레벨까지 고객의 필요에 따라 선택가능

● UniSys
- Unisys Open and Secure Integrated Solutions (OASIS) 프레임워크는 JBoss 애플리케이션 서버, Tomcat 웹 서버, 그리고 MySQL이나 PostgreSQL 데이터베이스 등의 구성 요소들이 엔터프라이즈 Linux에 맞게 튜닝되어 제공

● Openlogic (http://www.openlogic.com/index.php)
- 미리 테스트된 공개SW 솔루션들(검증하지 않은 SW는 지원하지 않음)로 구성된 스택을 제공하는 OpenLogic Enterprise 제품과 엔터프라이즈 오픈소스 배포에 관련된 각종 서비스로 구성된 OpenLogic Services 를 제공

● Optaros (http://www.optaros.com/en)
다양한 공개SW 솔루션에 대한 신뢰성을 미리 여러 가지 관점에서 분석하여, 그 중 고객의 요구사항에 적합한 공개SW로 구성된 인프라를 제공하는 Optaros' Services 를 제공 한다.

● SpikeSources
http://www.spikesource.com/technology/spikeignite/spikestacks.html
다양한 테스트를 거친 15개이상의 오픈소스 컴퍼넌트와 6개의 개발언어 지원 라이브러리 및 웹서버 와 프로그램들로 구성된 Spike Stacks 을 제공한다.

기타)
● Covalent(http://covalent.com/)
Apache 재단의 HTTP, Tomcat, Geronimo, Roller Blog Server 등에 대한 기술지원기업

● DevZuz
http://www.devzuz.com/web/guest/services
DevZuz Maestro 라는 오픈소스 인프라구축을 도와주는 소프트웨어와 DevZuz Repository 라는 검색을 위한 오픈소스 라이브러리를 판매하면서, 컨설팅, 교육, 기술지원 및 서비스 사용권 판매등 을 제공

ARPANET 에 기반한 미 국방성의 인터넷 참조모델에 기반하여 만들어진 계층형 모델이다. OSI모델, DoD모델과는 약간의 차이점이 있으나 현재 사실상의 표준이다. 이상적인 모델인 OSI Layer처럼 세분화되지는 않았으나, 그러한 이유로 인해 현실세계를 가장 잘 반영하고 있는 모델이다.

  TCP/IP 모델은 언급하는 곳마다 약간의 차이가 있어서 5개 또는 4개 계층으로 구분된다. 대개 4계층 모델을 기반으로 설명하고 있으나, 경우에 따라서는 Layer 1(Network Access Layer)을 Physical Layer와 Network Access Layer로 구별하여 5계층으로 보기도 한다.
   이 모델의 기본적인 개념들은 TCP/IP의 주요 기능을 제안한 Vinton Gray Cerf(1943), TCP프로토콜 창안자인 Robert E. Kahn(1938) 두 사람의 공로에 힘입은 바가 크다.  
 

언제 어디서나 자유롭고 안전한 인터넷 사용 ‘OK’ 유지보수 비용 절감·안전한 유비쿼터스 액세스 구현 … 시장 확대 중 황인각 주니퍼코리아 기술팀 차장 최근 사내간, 사내-사외간 통신에 사용되는 네트워크가 점차 인터넷 기반으로 변모함에 따라 인터넷을 이용하면서도 종단 간에 안전한 통신이 가능하도록 하는 VPN 기술이 많이 도입됐다. 이러한 VPN 기술이 개인이나 기업의 사용 용도에 맞도록 공중망을 사설망처럼 이용할 수 있게 하는 IPSec VPN 기술이다. <편집자> VPN 기술은 한 조직의 내부 사용자 간의 혹은, 외부 사용자와의 통신에서 암호화 기술과 터널링 기술을 이용한 안전한 통신 채널을 제공하는 기술로서 비즈니스 측면의 사용자뿐만 아니라, ISP 사업자, 그리고 전자상거래 사업자까지 다양하게 사용될 수 있는 차세대 네트워킹을 위한 핵심기술로 기대되고 있다. SSL VPN의 등장, ‘클라이언트리스 VPN’ IPSec VPN을 이용한 구축은 사이트 투 사이트(Site-to-Site), 사이트 투 클라이언트(Site-to Client)의 두 가지 방식으로 이뤄지고 있으며, 사이트 투 사이트 경우는 매우 안정적인 보안 서비스를 제공한다. 반면 사이트 투 클라이언트는 원거리상의 모든 컴퓨터상에 VPN 클라이언트 소프트웨어를 설치, 관리 및 유지보수를 해야하는 어려움으로 도입에 많은 걸림돌이 되고 있다. 즉, 클라이언트 VPN은 사용자 액세스를 위해 데스크톱이나 노트북에 반드시 클라이언트 소프트웨어가 설치돼야 VPN 접속이 가능하다는 점이 활성화의 장애가 되고 있다. 그래서 새로운 개념의 액세스 솔루션에 대한 요구가 대두하게 됐고 특히 무거운 클라이언트 VPN을 대체하고자 하는 새로운 SSL-VPN 기술이 개발됐다. IPSec 기반의 클라이언트 VPN망을 운영하는 기업(관리자)은 다음과 같은 문제를 항상 가지고 있으며, SSL-VPN 솔루션은 이러한 문제를 적은 비용으로 효과적으로 해결해 줄 수 있다. · 클라이언트 소프트웨어의 버전 및 패치 관리의 어려움 · 사용자의 다양한 하드웨어, 운영체제 버전 및 패치 상태에 따른 설치의 어려움 · 장애시 정확한 해결책 제시의 어려움 SSL-VPN은 기본 웹 브라우저만 있으면 어디서든 간편하게 VPN을 접속할 수 있다는 점에서 사용자들은 별도의 장비나 클라이언트 소프트웨어 없이 브라우저를 통해 접속하면 되기 때문에 IPSec VPN에 비해 사용 및 관리가 편리하고 비용 절감도 가능하다. 센터에 설치된 SSL-VPN 장비와 연동해 클라이언트가 없는 클라이언트리스(Clientless) VPN 구축이 가능하다는 점에서 일반 사용자, 특히 협력사, 이동 사용자 및 재택 근무자들을 위한 최적의 솔루션으로 평가 받고 있다. SSL VPN이란 SSL(Secure Sockets layer)은 웹 서버와 웹 브라우저간의 안전한 통신을 위해 넷스케이프에서 제창한 프로토콜로 인터넷 익스플로러, 넷스케이프 네비게이터와 같은 웹 브라우저에 기본적으로 탑재돼 있는 보안 표준 프로토콜이다. SSL은 오늘날 온라인 상거래, 웹서비스, 그리고 안전한 애플리케이션 계층 액세스를 포함하는 많은 다른 네트워크 기능을 위해 보안을 제공하는 인터넷 보안 프로토콜의 선두주자다. 현재 SSL의 2.0, 3.0, 3.1(TLS 1.0)이 사용되고 있으며, 아래와 같은 중요한 보안 기능들을 사용해 인터넷 등 공개된 네트워크상에서 민감한 데이터의 전송을 가능하게 한다. ·상호인증 : 클라이어트와 서버간의 상호 인증(RSA, DSS, X.509 ) ·기밀성 : 대칭키 암호화 알고리즘을 통한 데이터의 암호화(DES, 3DES, RC4등) ·데이터 무결성 : MAC기법을 이용해 데이터 변조 여부 확인(md5,SHA-1) SSL VPN의 기술적 특징 지난 몇 년 동안의 기술적인 동향은 안전한 네트워크 액세스를 위해서 저가의 광대역 서비스를 통한 인터넷과 암호화 기술을 사용하는 것이었다. 특히 기업 및 기관들이 업무적인 생산성을 개선하고 비용 절감 차원에서 전용선과 모뎀 설비를 광대역으로 대체하기 시작했다. 인터넷 연결성의 편리성으로 인해 언제 어디서든 네트워크 접속이 용이해지면서 통신의 비밀을 보장하기 위해 암호화를 사용하는 동안, 기업은 재택 근무자, 원격 근무자 또는 이동 근무자들을 위해 내부 컴퓨팅 자원을 효율적으로 액세스하게 해줘 전반적인 네트워크 및 컴퓨팅 환경에 대한 비용의 절감을 실현할 수 있었다. 안전한 네트워크(리모트) 액세스를 요구하는 대표적인 유형을 든다면, 첫째로, 인트라넷 액세스(재택 근무, 출장, 호텔 혹은 고객 사이트에 있는 이동 직원) 둘째로, 엑스트라넷 액세스(고객 ,협력사, 계약직 및 임시직원과 같은 외부인 또는 비직원)을 들 수 있다. 아래의 몇 가지의 기술들은 인터넷을 통해 리모트 액세스를 안전하게 해주는 보편화된 기술 중 가장 광범위하게 적용되는 기술이다. · 네트워크 레이어 기술 : 일반적인 IPSec VPN에서 채택한 기술IPSec/IKE(Internet Key Exchange) 사용 · 트랜스포트 레이어 기술 : SSL VPN에서 채택한 기술, SSL을 사용하는 SOCKS · 애플리케이션 레이어 기술 : SSL VPN에서 채택한 기술, SSL상에서 작동되는 HTTP(대부분의 웹 브라우저에 포함된 기술) SSL VPN은 사용자와 SSL VPN 장비 사이의 안전한 데이터의 교환을 위해 애플리케이션 계층에서 SSL을 이용한 암호화 서비스를 제공함으로써 기존 VPN의 문제점인 네트워크와 방화벽을 통과할 경우 발생하는 포트 블럭(Port Block)과 같은 문제점을 해결한다. 또한 SSL VPN은 클라이언트리스 VPN이라고 부르기도 하는데 그 이유는 오늘날 대부분의 표준화된 웹 브라우저는 HTTP와 HTTPS(SSL)를 기본적으로 모두 지원하므로 IPSec 리모트 VPN과는 대조적으로 사용자 측면에 VPN 클라이언트의 설치, 구현, 그리고 지원과 함께 결부된 모든 문제들을 해결할 수 있다. SSL은 웹 브라우저와 웹 서버간의 안전한 통신을 위해 넷스케이프에서 개발됐고, 애플리케이션에서 암호화가 이뤄지기 때문에 하위 레이어의 다양한 프로토콜 및 응용 프로그램의 지원에 제한을 받게 된다. 그래서 SSL VPN업체들은 초창기 웹 및 웹 기반의 애플리케이션만을 지원했으며, 고객 및 시장의 확장성을 위해 대부분의 SSL VPN 업체들은 기업의 다양한 애플리케이션을 지원하기 위한 기술 투자에 많은 시간을 투자해야 했다. SSL VPN을 이용한 서비스의 지원 발전 단계는 다음과 같이 3단계로 발전해왔다. 1) 초기 단계 : 웹, 웹 기반의 애플리케이션, 파일 공유 지원 2) 확장 단계 : 클라이언트/ 서버 애플리케이션 지원 3) 성숙 단계 : UDP 트래픽, 네트워크 레이어 트래픽 지원 현재 SSL VPN은 웹, 웹 애플리케이션, 메세징 클라이언트, 이메일, 파일 공유, 클라이언트/서버 애플리케이션 등 기업의 핵심적인 모든 업무 형태를 모두 지원함으로 업무 적용의 한계가 완전히 극복된 상태며, 자체적으로 DMZ 서비스를 지원해 인트라넷의 사설 IP 네트워크 구성 시에도 정상적인 서비스 구현이 가능하다. 또한, 다양한 암호화 기법(DES, 3DES, RC4)과 데이터 무결성 기법(MD5, SHA-1)을 모두 지원한다. IPSec과 SSL VPN의 비교 기본적으로 IPSec과 SSL VPN은 기업의 중요한 데이터를 보호하는 기능, 즉 데이터의 기밀성 및 무결성 등의 기능은 동일하며, 단지 데이터의 암호화를 구현하는 방식의 차이가 있을 뿐이다. IPSec VPN과 SSL VPN은 서비스 측면에서 상호 보안 관계이며, 서비스의 형태는 다음과 같이 분리해 볼 수 있다, 1) 고정성 인터넷 사이트 투 사이트(Intranet Site-to-Site) VPN 2) 이동성 인터넷 사이트 투 클라이언트(Intranet Site-to-Client: 리모트 클라이언트 VPN) 3) 이동성 엑스트라넷 사이트 투 클라이언트(Extranet Site-to-Client: 리모트 클라이언트 VPN) 고정성 VPN은 본사와 지사간에 특정 장소에서 VPN을 구현하며, 이동성 VPN은 센터(본사)의 고정된 장소와 사용자의 위치가 계속 바뀌는 경우에 구현하는 VPN이다. IPSec VPN은 반드시 리모트에 하드웨어나 소프트웨어가 필요하므로 신뢰할 수 있는 네트워크(본사-지사) 간의 고정성 사이트 투 사이트 형태에 적합하며, 신뢰할 수 없는 네트워크와 신뢰할 수 있는 네트워크(본사)와의 VPN 구현에는 적합하지 못하다. 또한, 리모트 컴퓨터상에 VPN 클라이언트 소프트웨어를 반드시 설치해야 하므로 설치, 관리 및 유지보수 등의 문제점을 가지고 있다. SSL VPN은 이동성 사용자에게 아주 적합한 암호화된 리모트 액세스 방법을 제공한다. 정리하면, SSL VPN의 장점은 다음과 같다. ·기업 자원을 액세스하는데 사용되는 장비로 다운로드할 필요가 없다. ·엔드 유저가 설정 작업을 수행할 필요가 없다. ·표준 웹 브라우저가 있는 곳이라면 어디서든 사용할 수 있기 때문에 사용자가 업무용 랩톱을 보유하지 않아도 된다. ·OS 독립적이다. ·액세스를 세부적으로 제어할 수 있기 때문에 사용자들은 권한이 있는 자원과 애플리케이션만을 볼 수 있다. SSL VPN은 이와 같이 웹 브라우저에서 이용 가능한 SSL을 활용해 저가의 광대역 서비스를 통해 언제, 어디서나 손쉽게 인터넷을 통한 VPN을 구성하는 액세스 기술이며, 시장 조사 기관인 메타그룹이 발표한 자료에 의하면 향후 3년 안에 SSL VPN이 리모트 클라이언트 VPN 서비스의 80% 이상을 차지할 것으로 전망하고 있다.

공개SW의 신뢰성 확보를 위해서 해야할 일
-소프트웨어의 안전성 확보


인기 많은 오픈소스 SW에는 버그가 적다?(2006.03. zdnet)

오픈소스 소프트웨어 중에서 가장 인기가 가장 높은 것이 버그의 수도 가장 적은 것으로 드러났다. 이는 소프트웨어의 안전을 확보하기 위해 미국 정부가 후원한 대책의 첫 번째 결과물에 의해서 밝혀졌다.
　
코드 분석 툴 업체인 커버리티(Coverity)의 최근 발표에 따르면 ‘LAMP’이라는 오픈 소스 스택을 조사한 결과 다른 32개 오픈소스 프로젝트의 기준에 비해 버그 밀도가 적은 것으로 나타났다. 버그 밀도란 일정한 행수의 프로그램 코드에 포함되는 버그의 수를 나타내는 것.

미국의 국토안전보장국은 지난 1월에 스탠포드 대학, 커버리티, 시만텍 등 3곳에 124만 달러의 자금 지원을 발표했다. 이들 3곳은 이 자금을 사용해 오픈소스 소프트웨어에 있는 보안 버그 탐색이나 커버리티에서 개발한 상용 소소 코드 분석 툴의 강화를 진행하고 있다. 이 자금 지원은 ‘오픈소스 강화 프로젝트(Open Source Hardening Project)’라는 3개년 계획의 일부이다.

LAMP란 리눅스 OS, 웹 서버의 아파치, 데이터베이스의 MySQL, PHP, 펄Perl, 파이톤 등의 스크립팅 언어를 가리킨다. LAMP은 주류의 기업 컴퓨팅 분야에 진출하고 있어 자바나 MS닷넷과 경쟁하는 존재가 되고 있다.

이번 분석에서는 32개의 오픈소스 프로젝트에서 1750만행 이상의 코드를 선택해 자세하게 확인했다. 그 결과, 평균 코드 1000행에서 0.434건의 버그가 발견되었다고 커버리티는 밝혔다. 이에 비해 LAMP 스택은 코드 1000행당 버그수가 평균 0.29건이다.

단 주의해야 점이 한가지 있다. LAMP 스택의 컴포넌트 중에서도 인기가 높은 프로그램 언어인 PHP만은 버그 밀도가 기준보다 높았다고 커버리티측은 전했다.

커버리티의 조사 결과에 따르면 이번에 조사한 다른 오픈소스 프로젝트 중에서는 아만다(Amanda)의 백업 툴이 코드 1000행당 버그수가 가장 많아, 버그 밀도는 1.237이었다. 가장 적은 것은 XMMS 오디오 플레이어로 코드 1000행당 버그수는 0.051건이었다.
　
발견된 버그수 면에서는 리눅스/유닉스용 그래픽 인터페이스 소프트웨어인 ‘X’에서 1681건의 버그가, ‘XMMS 오디오 플레이어’에서는 불과 6개의 버그가 발견되었다.

커버리티는 소프트웨어 코드 중에서 가장 중대한 보안 취약성이나 코딩 실수 가운데 40종류를 선택해 분석의 대상으로 삼았다. 커버리티는 발견된 취약성의 자세한 내용에 대해서는 공개하지 않았다.

연방 정부의 지원하에서 스탠포드 대학과 커버리티는 인기가 있는 오픈소스 프로젝트에 제공되는 코드를 일일 단위로 검사하는 시스템을 구축했다. 커버리티는 이 시스템에서 얻은 버그 데이터베이스를 개발자들에게 제공해 취약성 수정에 필요한 세부사항을 파악할 수 있게 할 계획이라고 밝혔다.

OpenVPN을 사용을 위한 미니 하우투(한소프트리눅스 오픈에디션 3)

I. 개요

본 문서는 OpenVPN 서버(한소프트리눅스 오픈에디션3), OpenVPN 클라이언트(윈도우 XP SP2)를 구성하여 공개SW기반의 VPN 기능을 사용하기위한 문서이다.

VPN을 이용하면 패킷을 암호화하는 것뿐만 아니라 파이어월을 사용할 때도 매우 편리하다. 외국  출장 등을 이유로 외부에서 접속하더라도 VPN을 통하면 항시 고정된 IP를 사용할 수 있기 때문이다. 따라서 파이어월에서는 접속을 허용해야 할 사용자가 유동 IP를 사용하더라도 단 한 개의 UDP 포트만 허용하면 되기 때문에 보안과 편리함 모두를 만족시킬 수 있다.

OpenVPN 특징)
-OpenVPN은 하나의 UDP 포트를 통해 모든 트래픽을 터널링할 수 있다. 즉 웹 접속(HTTP)을 하거나 DNS 질의를 할 때(UDP/53), ping(ICMP)을 날려도 중간에 패킷을 캡처하면 500/UDP를 통해 전송되는 것처럼 보이게 한다.
-안전한 VPN 통신을 위해 별도의 모듈이 필요없이 널리 사용하고 있는 OpenSSL에서 지원하는 강력한 암호화와 인증 기능 등을 그대로 이용할 수 있다.
-OpenVPN은 시스템 내에서 별도의 데몬 형태로 작동하기 때문에 IPsec 기반의 VPN 프로그램처럼 복잡한 커널 패치나 커널 모듈이 필요하지 않으며, 설치 방법도 간단하다.
-모든 패킷이 VPN을 통해 터널링되고 압축 혹은 암호화됨에도 불구하고 시스템에 부하를 유발하지 않으며, 속도도 빠르다.


II. OpenVPN 서버 설치

설치 전 설치에 필요한 라이브러리를 확인하여, 없는 경우 설치해 준다
OpenSSL(http://www.openssl.org/)
LZO(http://www.oberhumer.com/opensource/lzo/)

1. 소스다운로드(http://openvpn.net/)
[root@localhost src]# wget http://openvpn.net/release/openvpn-2.0.9.tar.gz

2. RPM Build
[root@localhost src]# rpmbuild -tb openvpn-2.0.9.tar.gz

3. 빌드 확인 및 설치
[root@localhost src]# cd /usr/src/Haansoft/RPMS/i386/
[root@localhost i386]# ls
openvpn-2.0.9-1.i386.rpm

[root@localhost i386]# rpm -Uvh openvpn-2.0.9-1.i386.rpm
준비 중...               ##                                          (100%)
#################                           (100%)

4. 스크립트를 이용한 인증키 생성
[root@localhost i386]# cd /usr/share/doc/openvpn-2.0.9/easy-rsa/
[root@localhost easy-rsa]# . ./vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /usr/share/doc/openvpn-2.0.9/easy-rsa/keys
[root@localhost easy-rsa]# ./clean-all
[root@localhost easy-rsa]# ./build-ca

Generating a 1024 bit RSA private key
................++++++
-----
Country Name (2 letter code) [KR]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [SEOUL]:
Organization Name (eg, company) [OpenVPN-OSTSC30]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:ostsc30
Email Address [localhost@locadomain]:

※ Common Name 을 정확히 적어준다

5. 서버 인증키 생성
[root@localhost easy-rsa]# ./build-key-server server
Generating a 1024 bit RSA private key
..............++++++


6. 클라이언트 인증키 생성
[root@localhost easy-rsa]# ./build-key client1
Generating a 1024 bit RSA private key
............++++++
Country Name (2 letter code) [KR]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [SEOUL]:
Organization Name (eg, company) [OpenVPN-OSTSC30]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:client1
Email Address [localhost@locadomain]:

※ Common Name 을 정확히 client1으로 적어준다

7. 암호화에 사용할 키 생성
[root@localhost easy-rsa]# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
...............................+.....+................+..................................................................+...
.................+..............+..................+.........................................................................
+................................+..................

8. ta.key 생성
[root@localhost easy-rsa]# cd keys
[root@localhost easy-rsa]# openvpn --genkey --secret ta.key

9. 서버 환경설정 파일 생성
vi /etc/openvpn/server.conf

local 210.183.235.30
port 5000
proto udp
dev tap0
ca /usr/share/doc/openvpn-2.0.9/easy-rsa/keys/ca.crt
cert /usr/share/doc/openvpn-2.0.9/easy-rsa/keys/server.crt
key /usr/share/doc/openvpn-2.0.9/easy-rsa/keys/server.key  # This file should be kept secret
dh /usr/share/doc/openvpn-2.0.9/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
tls-server
tls-auth ta.key 0 # This file is secret
comp-lzo
verb 4
mute 20

port 5000 : OpenVPN은 기본적으로 UDP를 이용해 패킷을 터널링해 전달하는데, 이때 포트는 사용되지 않은 어떤 포트를 사용해도 관계없다.
proto udp : 기본 값인 UDP를 사용하는 것이 좋다. TCP는 권장하지 않는다.
dev tap : OpenVPN 서버와 클라이언트 상호 통신에 필요한 인터페이스를 지정하는데, TUN이나 TAP을 지정할 수 있다.
ifconfig 10.105.11.1 255.255.0.0 : VPN 서버가 사용할 IP를 지정한다. TAP에 이 IP가 할당돼 원격지 PC와  통신할 수 있게 되는데, 가급적 사용하지 않는 사설 IP를 사용하는 것이 좋다.
keepalive 10 120 : 클라이언트와 서버 간에 VPN 연동이 활성화됐는지 체크하기 위해 사용되는데, 매 10초마다 ping을 발송해 120초 동안 응답이 없으면 원격지의 네트워크가 다운된 것으로 파악한다는 의미다.
comp-lzo : 압축 알고리즘을 사용하도록 한다. 서버에 이 같이 설정했다면, 클라이언트에도 동일하게 설정하도록 한다.
persist-key
persist-tun

user nobody          
group nobody   
: 초기화된 후에 OpenVPN 데몬이 nobody 권한으로 작동하도록 한다.

status       openvpn-status.log
log          openvpn.log              
log-append  openvpn.log
: OpenVPN의 로그를 생성하는 설정이다.

tls-server : SSL 키 교환 시에 서버 역할을 하므로 tls-server로 지정한다.

dh  dh1024.pem
ca  my-ca.crt             
cert  server.crt                  
key server.key
:  CA 파일이나 인증서의 공개키 혹은 비밀키를 지정한다

10. 서버 구동
[root@localhost ~]# /etc/init.d/openvpn restart
Shutting down openvpn:                                     [  OK  ]
Starting openvpn:                                          [  OK  ]


III. OpenVPN 클라이언트 설치

OpenVPN GUI라는 프로그램이 많이 사용되는데, 웹 사이트(http://openvpn.se/) 에서 다운로드해 일반적인 윈도우 프로그램 설치와 동일하게 설치하면 된다.

1. 클라이언트 환경설정
설치 이후 '시작->프로그램->OpenVPN'을 선택
여기에서 OpenVPN GUI를 실행.
이후 우측의 트레이에 생긴 아이콘에 오른쪽 마우스를 클릭하면 사용 가능한 메뉴가 나오는데,
여기에서 Edit Config를 선택하면 메모장이 뜨면서 설정작업을 진행할 수 있다.

2. 클라이언트 환경설정 파일
서버에서 생성한 ca.crt , client1.crt , client1.key, ta.key 파일을 클라이언트의 환경설정 디렉토리(C:\Program Files\OpenVPN\config\)안에 복사하고 아래내용으로 설정파일을 만들어준다 : client.ovpn

client
dev tap
proto udp
remote 210.183.235.30 5000
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client1.crt"
key "C:\\Program Files\\OpenVPN\\config\\client1.key"
tls-auth ta.key 1
comp-lzo
verb 3


설정이 끝나면 트레이의 OpenVPN GUI 아이콘을 더블클릭하면 연결된다
VPN에서 지정된 IP를 할당받게 되고, 비공인 VPN IP로 접속하면 VPN을 통해 안전하게 터널링돼 접속하게 된다.
이때의 VPN 트래픽은 암호화되고 터널링되므로 누군가가 중간에서 가로챘다 하더라도 패킷 내용을 해석할 수 없으므로 스니핑이 불가능하다.

오픈아이디로 사용가능한 웹서비스

스프링 노트

집, 학교, 회사 언제 어디서나 쓸 수 있는 노트 한 권, 스프링노트는 함께 쓰는 인터넷 노트 입니다.
나만의 스프링노트에 글을 쉽게 쓰고 관리할 수 있으며, 노트를 여럿이 함께 쓸 수 있습니다.
오픈아이디로 누구나 스프링노트를 개설하고, 친구들을 초대할 수 있습니다.

라이프팟

라이프팟은 일정관리용 인터넷 캘린더로 내 일정관리는 물론, 일정 공유 기능을 활용하여

애인과 함께 커플일정을 관리하거나, 회사 내 팀원들과 일정을 공유하고 관리할 수 있습니다.

펌핏

자신의 블로그나 새로운 정보를 비롯한 세상의 모든 콘텐츠 중 공유하고 싶은 정보를 만났을 때 간단한 주소(URL) 등록을 통해서 실시간으로 다른 회원들과 공유할 수 있는 서비스입니다.

특히 부가기능인 미니펌핏과 붐바는 자신의 블로그를 가장 빨리, 가장 쉬운 방법으로 홍보할 수 있는 수단으로도 활용할 수 있습니다.

뿐만 아니라 댓글를 통한 토론도 함께 할 수 있습니다. 이렇게 등록된 정보는 추천(펌프업)에 따라 인기도가 산정됩니다.

펌핏의 최종 모델은 온라인 토론 플랫폼입니다. 이를 위해 조만간 회원들이 실시간으로 가볍게 토론하고 설문조사도 할 수 있는 기능을 추가할 계획입니다.
 

레뷰

레뷰는 리뷰를 중심으로 다양한 상품, 문화, 경험에 대한 쇼핑과 선택을 지원하는 소셜 쇼핑 사이트 입니다. 

사용자는 오픈ID를 이용하여 로그인하실 수 있고, 로그인 후 다양한 관심 아이템의 등록, 평가, 태깅을 하실 수 있으며,관심있는 아이템들을 모아서  '내가 추천하는 핸드폰", "최고의 와인바", "여름 피서지 10선"등의 컬렉션도 만드실 수 있습니다. 

여러분이 관심을 갖는 많은 상품이나 서비스에 대해 다른 사용자가 어떤 리뷰를 하고 있는지,어떤 평가를 하고 있는지 참고하시기에 가장 유용한 사이트입니다. 물론 가격이나 위치 정보도 보실 수 있고요.

클래스?
클래스란 객체의 특성을 정의하는 원형이다. 특정한 객체의 자료 구조와 접근 가능한 루틴의 정보를 표현하는 클래스를 개별 ... 하나의 클래스

란 하나의 패키지로 선언된 이름공간을 의미한다. 객체지향이란 그렇게 분리된 이름공간을 활용하는 것이다

서블릿이란?
웹 응용프로그램을 만드는 자바 기술로서 실행 결과값은 html 로 작성된다

보통 서블릿 서버, 서블릿 컨테이너, JSP 컨테이너, 웹서버 라는 등등의 말을 많이 사용합니다. 그렇지만 실제로 각각에 대한 정확한 의미를 알고 있는 경우는 드문데 각각의 의미를 살펴보면 다음과 같습니다.

서블릿서버 : 현재는 거의 사용되지 않는 말입니다. 공식적으로 사용되는 단어라기 보다는 우리나라에서 관습적으로 사용이 되고 있는 의미로 서블릿을 돌릴 수 있는 서버라는 의미입니다. 실제로 서블릿 컨테이너라는 말을 사용하는 것이 좋습니다. (초기에는 서블릿을 돌리기 위해서 아파치 등에 모듈로 연동을 해서 사용을 했기 때문에 이런 말이 생겨난 듯 합니다.)

서블릿 컨테이너 : 서블릿을 동작 시킬수 있는 환경을 제공하는 서버 프로그램입니다. 즉 HTTP 요청을 받아서 해당 서블릿을 동작을 시키고 그 결과를 사용자의 브라우저로 전달을 해줄 수 있는 기능을 제공합니다. 보통 컨테이너라고 하는 이유는 서블릿 프레임워크 안에서 동작을 하고 서블릿이 동작할 수 있는 환경을 제공해주며, 기타 필요한 작업등을 제공해주기 때문에 그렇게 얘기를 합니다. 즉 HTTP 파라미터 파싱 및 결과 전달 컨트롤, Forwarding, Redirecting 등의 기능을 컨테이너에서 제공을 해줍니다. 이때 서블릿 개발자는 자신이 만든 서블릿을 이 컨테이너에 등록을 하게 되고, 실제 동작을 컨테이너가 알아서 하게 되기 때문에 사용되는 언어입니다.

JSP 컨테이너 / 엔진: 실제로 JSP 컨테이너의 의미는 서블릿 컨테이너의 개념과 동일합니다. 그렇지만 조금 자세히 보면 실제로 JSP 컨테이너라는 것은 별도로 존재하지 않습니다. 실제로는 서블릿 컨테이너가 JSP 컨테이너가 됩니다. 그 이유는 JSP는 PHP/ASP와 같이 완전히 스크립트 형식으로 동작하지 않고 서블릿으로 변환이 된 이후에 실행되기 때문입니다. 그리고 JSP를 서블릿으로 컴파일을 해주는 것이 바로 JSP 엔진입니다. 다른 프로그램은 잘 모르겠지만 톰캣의 경우에는 JSP엔진이 바로 JSPServlet 입니다. 즉 JSP를 컴파일하고 동작을 시켜주는 것을 특정 서블릿이 담당하고 있습니다. 여기서 보면 JSP 자체가 완전한 서블릿으로 컴파일 되지 않는 다는 것을 알 수 있습니다. 즉 JSPservlet이 구동 할 수 있는 형태의 서블릿으로 바뀌게 됩니다. 그런 의미에서 보면 별도의 JSP 컨테이너가 있다고 할 수도 있을 것 같습니다.

서블릿특징
html의 정적인 문제점을 해결할 수 있는 동적인 특징을 갖는다.
자바언어로 작성되어 자바의 일반적인 특징을 모두 갖는다.
객체지향적이다.
다른 자바기술과 연동 가능하다. ( JDBC , EJB 등 )
container 라는 특별한 환경에서 실행된다.
Container 종류에 상관없이 작동된다. ( 플랫폼 독립적 )
프로세스 방식이 아닌 스레드 방식으로 실행된다.
Server Side에 적합한 자바기술이다.
보안모델 적용이 수월하다.
저장 파일의 확장자는 java 이고 컴파일된 바이트코드가 container 에서 실행된다.
웹 응용프로그램이기 때문에 브라우저를 통해서 요청한다.



Beans란?

Beans는 일종의 특정한 일을 독립적으로 수행하는 콤포넌트이다.
Beans는 크게 JavaBeans와 EJB(Enterprise JavaBeans)가 있는데, 두 가지는 콤포넌트라는 개념 외에는 많이 다르다.
JSP 문서에서는 JavaBeans와 EJB 모두 사용할 수 있다.
-JavaBeans 자체에 대해서 더 알고 싶은 분은 썬의 JavaBeans 스펙을 참고하기 바란다.

하나의 bean은 속성을 갖는 개체이다. 또한, bean은 그 속성의 값을 설정하고 얻는 방법도 갖고 있다. 뿐만 아니라, 속성을 제어하고 지정한 여러가지 일을 수행하는 방법들도 갖추고 있다. Bean은 한 프로그램에 전속하지 않는 독립적인 객체로서 다른 프로그램에서도 사용할 수 있다.

Bean의 정의는 클래스로서 표현되며 개별 bean은 정의된 클래스의 인스턴스로서 구별된다. 어떤 것도 bean으로 추상화될 수 있다.

왜 Beans를 사용하는가?

크게 세 가지 이유가 있다.

1)form을 통한 데이터 프로세싱이 매우 용이하다는 장점을 들 수 있다.
동적인 웹 페이지 생산의 중요한 요소는 클라이언트로부터 데이터를 입력받아 이를 처리하는 것인데, http 프로토콜을 사용하는 HTML은 GET 또는 POST 방법을 통해 이를 처리한다. JSP 문서에서는 간단하게 request.getParameter()를 통해 GET 또는 POST로 넘어오는 데이타를 전달받을 수 있지만 프로그래밍 코드가 지저분해지기 쉽다. 또한, request라는 JSP Engine(JSP 문서를 Servlet 코드로 변환시키는 일을 한다)이 내부적으로 사용하는 인스턴스를 참조하는 것도 어딘지 석연치 않다. 이후에 살펴보겠지만 beans를 사용하면 번잡한 form 제어를 우아하게 할 수 있다.

2)클라이언트의 데이터를 여러가지 범위에서 지속적으로 유지할 수 있다는 이유가 있다.
간단한 예를 들어보자. 쇼핑몰을 운영하는 사이트는 장바구니 개념이 구현되어야 한다. 소비자가 물건을 사이트에서 살피고 이를 장바구니에 담으면 이 정보는 소비자가 구입을 모두 끝마칠 때까지 유효해야 한다. 이런 장바구니를 구현하기 위해서는 다음의 세 가지 요건이 모두 잘 해결되어야 한다.

3)Beans를 사용하는 가장 중요한 이유는 컴포넌트 기반 개발을 하기 위한 것이다.
Beans를 잘 사용하면 보여주기와 구현하기를 분리하여 비즈니스 로직을 보다 잘 설계할 수 있다.


EJB
EJB는 스펙이다. 그것의 가장 토대가 되는 부분은 Javasoft에 의해 구현되어있으며, 이것을 바탕으로 EJB에 관심을 가진 여러 벤더들이 스펙의 나머지 부분을 구현하였고, 여기에 나름대로의 독특한 기술들을 첨가하여 어플리케이션 서버라는 이름으로 시장에 출시하였다 (물론, 어플리케이션 서버가 EJB 제품군만 있는 것은 아니다.). 그 종류는 세계적으로 40여가지에 이르며, 국내에서는 약 다섯 가지의 제품이 도입되어 어플리케이션 서버시장을 놓고 각축을 벌이고 있다.
EJB는 분산객체 기술에 기반을 둔 컴포넌트 모델이다. 따라서 EJB를 사용하기에 앞서 분산객체 기술에 대해 이해해야한다.
분산 객체 기술은 특정 컴퓨터에서 동작중인 객체를 가깝게는 같은 컴퓨터 내의 다른 프로세스로부터 멀게는 인터넷으로 연결된 원격지 컴퓨터들까지 일관된 방식으로 접근하여 이용할 수 있게 만드는 기술로써,  자바RMI나 CORBA, 그리고 MS 의 DCOM등이있으며, 이러한 분산객체 시스템은 3계층 아키텍처의 근간이된다.


EJB 서버(Server) - 컨테이너(Container) – 빈(Bean) 아키텍쳐
컨테이너는 각 유형의 빈을 위한 EJB객체들과 EJB홈들을 관리한다. 그리고 이것들이 빈 자원들을 관리하고 트랜잭션, 보안, 동시성 제어 및 네이밍 등의 주요 서비스를 적용받을 수있도록 도와준다. 빈은 실제로 우리가 접근하고자 하는 객체이다.
서버-컨테이너-빈의 순서는 상위로부터 하위로 내려가며 포함하는것-포함되는것의 순서로 배열한것인데, 상위는 하위에 대해 라이프 사이클을 관리하고, 동작환경을 제공한다.
빈과 컨테이너 사이에는 분명한 역할의 구분이 있지만, 사실 컨테이너와 서버 사이의 규약은 EJB 스펙에서 정의되지 않았다. EJB스펙에는 빈과 컨테이너 간의 규약에 대해서만 정의하고있는데, 사실상 서버 프로세스가 없이는 EJB는 구동되지 않는다. 이것은 프로그래밍을 약간만 해 본 독자라면 누구나 유추할 수있는 당연한 사실임에도 불구하고, 컨테이너 와 서버간의 규약을 명시하지 않은 것은 EJB컨테이너와 서버간의 역할경계를 불분명하게 만드는 원인이 된다. 이로인해 각 벤더들은 나름대로의 기술을 적용하여 서버와 컨테이너를 분리하였고, 사실상 서로 다른 벤더가 내놓은 EJB서버들과 그들의 컨테이너들은 호환이 거의 불가능한 특성을 갖게되었다. 도미노 효과처럼, 뒤에 나올 컨테이너 관리 빈은 컨테이너 종속적이라는 특성으로 인해, 다른 벤더의 컨테이너에 끼워넣기가 또한 거의 불가능하다.
실제의 개발에 있어서 서버와 컨테이너를 명확하게 구분해야 할 필요는 없다. EJB적인 모든 특징과 기능들은 컨테이너가 하고, 컨테이너를 담기위한 환경 및 여타의 미들웨어적 특성들은 EJB서버가 담당한다라고만 보면 일단은 충분하다. 보다 자세한 사항은 자신이 쓰고자 하는 제품의 벤더가 제공하는 매뉴얼을 참조해야한다.


엔터티 빈(Entity Bean)  - 세션빈(Session Bean) 아키텍쳐
여러분이 프로그래머라면 프로그램이 데이터와 로직으로 구성된다는 것을 알 것이다. 데이터는 영속적인 데이터와 일시적인 데이터로 나뉘어진다. 영속적이라는 것은 파일이나 데이터베이스등의 영구저장매체에 저장되고, 프로그램이 종료된 후에도 다시 로드하여 쓸 수있는 종류의 데이터이다. 반대로 일시적이라는 것은 프로그램 수행중에 변수에 저장되었다가 프로그램이 종료하고, 메모리상의 기억장소가 해제되는 순간에 사라지는 데이터이다. 이러한 일시적인 데이터들은 주로 로직의 진행에 필요한 것으로 로직의 일부로 보는 것이 더욱 타당하다. 이후 데이터라 하면 데이터베이스에 보관되는 영속적인 데이터를 칭하는것으로 이해해주기 바란다.

로직은 데이터의 조작과 처리를 말하며, 업무에 종속적인 로직과 독립적인 로직으로 나뉘어진다. 이러한 업무독립적인 로직들은 라이브러리화되어 대부분의 프로그램이 공유할 수있다. 그러나, 업무에 종속적인 로직은 일반적으로 그렇지못하다. 증권사에서 개발한 증권거래용 프로그램의 증권거래 라이브러리들을 물류회사의 물류관리업무나 일반기업의 인사관리에서 사용할 수는 없다.  이러한 업무종속적인 로직을 일반적으로 비즈니스 로직이라 칭한다. 객체지향 프로그래밍에서는 데이터를 가진 객체는 데이터를 외부와 교환하기위해 데이터 출납용 메소드를 함께 갖는 것이 권장된다. 이러한 데이터 출납용 메소드들은 업무의 흐름에 독립적인 로직을 갖는것으로, 객체지향 프로그래밍에서는 데이터의 일부로 보는 것이 타당하다.

엔터프라이즈 자바 빈의 종류는 두 가지가 있는데, 이는 엔터티 빈과 세션 빈이다.
이 중, 데이터베이스와 맵핑된 영속적인 데이터를 보관하고, 데이터베이스에 직접 접근하여 데이터를 출납하는 일은 엔터티빈이 맡는다.
세션빈은 비즈니스 로직을 포함한다. 이 구조는 EJB스펙에 지정된 것으로 EJB의 가장 핵심적인 프레임웍이다. 이것은 데이터와 비즈니스 로직의 분리를 통한 개발/유지/보수의 편의성 외에도 원거리 호출을 줄임으로써 어플리케이션의 수행성능을 향상시키는 효과도 포함한다.
물론, 서로의 영역을 넘어서 비즈니스 로직을 엔터티빈이 갖는다든지 데이터를 세션빈이 유지한다든지 하는 것도 얼마든지 가능하고, 클라이언트가 세션빈이 가질 로직을 몽땅 갖게되기도한다. 실제적으로 이러한 시도는 빈번하게 발생한다. 하지만, 이렇게 만들어진 어플리케이션은 이미 EJB를 사용하는 의미를 잃는다. 단지 자바와 RMI의 조합만을 이용하는 것일 뿐 EJB 어플리케이션이라고 볼 수가 없다. 결국, EJB가 주는 개발의 신속성과 유지보수의 편의성은 무시되고, EJB도 별 게 아니더라 라는 결과만을 얻게되는것이다.

엔터티 빈에서 제공하는 메소드를 이용하여 빈의 attribute를 변경하면, 이 변경은 Database의 해당 Table의 해당 Attribute에 자동으로 반영되는것이다. 이때, 엔터티 빈을 참조하는 쪽에서는 전혀 Database의 테이블 구조 및, DBMS와의 통신에 신경을 쓰지 않게된다.  DBMS와의 통신에 신경을 쓰지 않는다는 말은 SQL문을 전혀 사용할 필요가 없음을 의미한다.
그러나, 위에서 한 말은 엄밀히 말하면, 이미 만들어진 엔터티 빈을 사용하는 입장의 개발자에게는 100퍼센트 사실일 수 있겠지만, 아래에서 소개할 Bean managed 방식의 빈개발자는 데이터베이스와 객체를 매핑시키는 작업을 스스로 해 줘야만 하므로, 어쩔 수 없이 SQL을 다루게된다. Container managed방식의 경우라면, 매핑 작업을 EJB 서버의 벤더가 제공하는 툴이 대신해주므로, 엔터티 빈을 만드는 쪽이나, 사용하는 쪽이나 SQL을 전혀 사용할 필요가 없다.

커넥션 풀 ( Connection Pool)
풀이란것은 미리 일정량을 비축해두는 장소라고 보면 된다. 어플리케이션이 DBMS와 통신을 하기위해서는 DBMS와의 커넥션이 필요한데, 어플리케이션이 DB에 SQL을 던지고, 그 수행이 끝날때까지의 시간의 대부분은 DBMS와 커넥션을 맺는데 소요된다.
따라서, 미리 몇 개의 커넥션을 맺어서 커넥션 풀에 이것을 저장해두었다가 이를 필요로하는 객체에게 할당함으로써 수행성능을 향상시킬 수있다. 커넥션을 할당받은 객체는 이 커넥션을 통해 원하는 DB 오퍼레이션을 수행하고, 수행이 완료된 후엔 커넥션을 다시금 풀로 되돌린다. 커넥션은 무한히 쓸 수있는게 아니고, 그 수가 DBMS에 따라 제한되어있다. 만일 저장된 커넥션의 수보다 이를 요구하는 객체의 수가 더 많으면 커넥션을 할당받을 수 없는 나머지 객체들은 풀이 가진 커넥션에 여유가 생길 때까지 대기한다


UDDI
 UDDI 프로젝트는 웹 서비스의 상호 운용성과 채택(adoption)을 촉진시킨다. 이 프로젝트는 산업계와 비지니스 리더들 사이의 파트너쉽이고 IBM, Ariba, Microsoft에 의해 설립되었다. 지금 현재 300개가 넘는 기업들이 참여하고 있다. UDDI는 서비스 설명과 서비스 발견(discovery)에 대한 표준 기반의 스팩은 물론 인터넷 기반 구현을 제공한다. UDDI는 계속적으로 빠르게 진화하고 있으며 산업계의 지원을 받고있다. 이 스팩은 빠르게 개발되고 있다.

UDDI는 비지니스의 많은 문제점들에 관심을 기울이고 있다. 첫째, business-to-business (B2B) 인터랙션의 확장과 단순화에 기여한다. 다양한 고객과 많은 관계를 창출해야하는 제조사에게, UDDI는 각 표준과 프로토콜 별로 가상의 모든 인터페이스를 사용하여 매우 유연한 서비스 기술(description)을 지원한다. 예를 들어 전 세계의 모든 시장에 연결을 원하지만 방법을 모르고 있는 호주의 플라워 샵의 경우 UDDI는 이 방법을 제공한다. 이 스팩은 레지스트리에 플라워 샵을 나타내어 그들이 제공하는 비지니스와 서비스를 효율적이며 간단하게 발견할 수 있도록 한다.

공급자용 카탈로그 데이터 뿐만아니라 영수증 서비스, 포장, 선적, 보험관계자와 관계를 원하는 B2B 마켓플레이스 제공자에게 UDDI는 동적 발견과 관련 웹 서비스를 전체 비지니스 프로세스로 통합할 수 있도록 한다. UDDI는 비지니스 및 전자 서비스에 관한 정보에 대해 원스탑(one-stop) 쇼핑을 제공한다. UDDI에 비지니스 및 서비스 정보를 퍼블리쉬 하면 다른 것에 광범위하게 액세스 할 수 있다.

UDDI는 Extensible Markup Language (XML)와 Simple Object Access Protocol (SOAP) 같은 기존 표준에 기반하고 있다. UDDI를 따르는 모든 구현들은 UDDI 스팩을 지원한다. 공식 스팩은 회원들에 의해 공개적이고 포괄적으로 개발되었다. 앞으로 독립적인 표준 단체로 향후 개발 소유권을 넘기기 전에 세 개의 연속적인 버전을 만들고 구현하기 위함이다. UDDI Version 1 스팩은 2000년 9월, Version 2는 2001년 6월에 발표되었다. Version 3 스팩은 지금 개발중이며 2002년 중순에 발표될 예정이다. Version 1이 레지스트리에 대한 기초를 확립했다면 Version 2는 비지니스 관계 같은 기능을 추가했다. Version 3은 보안, 국제화, 레지스트리 상호운용성, 다양한 API 향상과 같은 웹 서비스의 지속적인 개발을 통해 툴링 향상을 목표로하고 있다.

클래스?
클래스란 객체의 특성을 정의하는 원형이다. 특정한 객체의 자료 구조와 접근 가능한 루틴의 정보를 표현하는 클래스를 개별 ... 하나의 클래스

란 하나의 패키지로 선언된 이름공간을 의미한다. 객체지향이란 그렇게 분리된 이름공간을 활용하는 것이다

서블릿이란?
웹 응용프로그램을 만드는 자바 기술로서 실행 결과값은 html 로 작성된다

보통 서블릿 서버, 서블릿 컨테이너, JSP 컨테이너, 웹서버 라는 등등의 말을 많이 사용합니다. 그렇지만 실제로 각각에 대한 정확한 의미를 알고 있는 경우는 드문데 각각의 의미를 살펴보면 다음과 같습니다.

서블릿서버 : 현재는 거의 사용되지 않는 말입니다. 공식적으로 사용되는 단어라기 보다는 우리나라에서 관습적으로 사용이 되고 있는 의미로 서블릿을 돌릴 수 있는 서버라는 의미입니다. 실제로 서블릿 컨테이너라는 말을 사용하는 것이 좋습니다. (초기에는 서블릿을 돌리기 위해서 아파치 등에 모듈로 연동을 해서 사용을 했기 때문에 이런 말이 생겨난 듯 합니다.)

서블릿 컨테이너 : 서블릿을 동작 시킬수 있는 환경을 제공하는 서버 프로그램입니다. 즉 HTTP 요청을 받아서 해당 서블릿을 동작을 시키고 그 결과를 사용자의 브라우저로 전달을 해줄 수 있는 기능을 제공합니다. 보통 컨테이너라고 하는 이유는 서블릿 프레임워크 안에서 동작을 하고 서블릿이 동작할 수 있는 환경을 제공해주며, 기타 필요한 작업등을 제공해주기 때문에 그렇게 얘기를 합니다. 즉 HTTP 파라미터 파싱 및 결과 전달 컨트롤, Forwarding, Redirecting 등의 기능을 컨테이너에서 제공을 해줍니다. 이때 서블릿 개발자는 자신이 만든 서블릿을 이 컨테이너에 등록을 하게 되고, 실제 동작을 컨테이너가 알아서 하게 되기 때문에 사용되는 언어입니다.

JSP 컨테이너 / 엔진: 실제로 JSP 컨테이너의 의미는 서블릿 컨테이너의 개념과 동일합니다. 그렇지만 조금 자세히 보면 실제로 JSP 컨테이너라는 것은 별도로 존재하지 않습니다. 실제로는 서블릿 컨테이너가 JSP 컨테이너가 됩니다. 그 이유는 JSP는 PHP/ASP와 같이 완전히 스크립트 형식으로 동작하지 않고 서블릿으로 변환이 된 이후에 실행되기 때문입니다. 그리고 JSP를 서블릿으로 컴파일을 해주는 것이 바로 JSP 엔진입니다. 다른 프로그램은 잘 모르겠지만 톰캣의 경우에는 JSP엔진이 바로 JSPServlet 입니다. 즉 JSP를 컴파일하고 동작을 시켜주는 것을 특정 서블릿이 담당하고 있습니다. 여기서 보면 JSP 자체가 완전한 서블릿으로 컴파일 되지 않는 다는 것을 알 수 있습니다. 즉 JSPservlet이 구동 할 수 있는 형태의 서블릿으로 바뀌게 됩니다. 그런 의미에서 보면 별도의 JSP 컨테이너가 있다고 할 수도 있을 것 같습니다.

서블릿특징
html의 정적인 문제점을 해결할 수 있는 동적인 특징을 갖는다.
자바언어로 작성되어 자바의 일반적인 특징을 모두 갖는다.
객체지향적이다.
다른 자바기술과 연동 가능하다. ( JDBC , EJB 등 )
container 라는 특별한 환경에서 실행된다.
Container 종류에 상관없이 작동된다. ( 플랫폼 독립적 )
프로세스 방식이 아닌 스레드 방식으로 실행된다.
Server Side에 적합한 자바기술이다.
보안모델 적용이 수월하다.
저장 파일의 확장자는 java 이고 컴파일된 바이트코드가 container 에서 실행된다.
웹 응용프로그램이기 때문에 브라우저를 통해서 요청한다.



Beans란?

Beans는 일종의 특정한 일을 독립적으로 수행하는 콤포넌트이다.
Beans는 크게 JavaBeans와 EJB(Enterprise JavaBeans)가 있는데, 두 가지는 콤포넌트라는 개념 외에는 많이 다르다.
JSP 문서에서는 JavaBeans와 EJB 모두 사용할 수 있다.
-JavaBeans 자체에 대해서 더 알고 싶은 분은 썬의 JavaBeans 스펙을 참고하기 바란다.

하나의 bean은 속성을 갖는 개체이다. 또한, bean은 그 속성의 값을 설정하고 얻는 방법도 갖고 있다. 뿐만 아니라, 속성을 제어하고 지정한 여러가지 일을 수행하는 방법들도 갖추고 있다. Bean은 한 프로그램에 전속하지 않는 독립적인 객체로서 다른 프로그램에서도 사용할 수 있다.

Bean의 정의는 클래스로서 표현되며 개별 bean은 정의된 클래스의 인스턴스로서 구별된다. 어떤 것도 bean으로 추상화될 수 있다.

왜 Beans를 사용하는가?

크게 세 가지 이유가 있다.

1)form을 통한 데이터 프로세싱이 매우 용이하다는 장점을 들 수 있다.
동적인 웹 페이지 생산의 중요한 요소는 클라이언트로부터 데이터를 입력받아 이를 처리하는 것인데, http 프로토콜을 사용하는 HTML은 GET 또는 POST 방법을 통해 이를 처리한다. JSP 문서에서는 간단하게 request.getParameter()를 통해 GET 또는 POST로 넘어오는 데이타를 전달받을 수 있지만 프로그래밍 코드가 지저분해지기 쉽다. 또한, request라는 JSP Engine(JSP 문서를 Servlet 코드로 변환시키는 일을 한다)이 내부적으로 사용하는 인스턴스를 참조하는 것도 어딘지 석연치 않다. 이후에 살펴보겠지만 beans를 사용하면 번잡한 form 제어를 우아하게 할 수 있다.

2)클라이언트의 데이터를 여러가지 범위에서 지속적으로 유지할 수 있다는 이유가 있다.
간단한 예를 들어보자. 쇼핑몰을 운영하는 사이트는 장바구니 개념이 구현되어야 한다. 소비자가 물건을 사이트에서 살피고 이를 장바구니에 담으면 이 정보는 소비자가 구입을 모두 끝마칠 때까지 유효해야 한다. 이런 장바구니를 구현하기 위해서는 다음의 세 가지 요건이 모두 잘 해결되어야 한다.

3)Beans를 사용하는 가장 중요한 이유는 컴포넌트 기반 개발을 하기 위한 것이다.
Beans를 잘 사용하면 보여주기와 구현하기를 분리하여 비즈니스 로직을 보다 잘 설계할 수 있다.


EJB
EJB는 스펙이다. 그것의 가장 토대가 되는 부분은 Javasoft에 의해 구현되어있으며, 이것을 바탕으로 EJB에 관심을 가진 여러 벤더들이 스펙의 나머지 부분을 구현하였고, 여기에 나름대로의 독특한 기술들을 첨가하여 어플리케이션 서버라는 이름으로 시장에 출시하였다 (물론, 어플리케이션 서버가 EJB 제품군만 있는 것은 아니다.). 그 종류는 세계적으로 40여가지에 이르며, 국내에서는 약 다섯 가지의 제품이 도입되어 어플리케이션 서버시장을 놓고 각축을 벌이고 있다.
EJB는 분산객체 기술에 기반을 둔 컴포넌트 모델이다. 따라서 EJB를 사용하기에 앞서 분산객체 기술에 대해 이해해야한다.
분산 객체 기술은 특정 컴퓨터에서 동작중인 객체를 가깝게는 같은 컴퓨터 내의 다른 프로세스로부터 멀게는 인터넷으로 연결된 원격지 컴퓨터들까지 일관된 방식으로 접근하여 이용할 수 있게 만드는 기술로써,  자바RMI나 CORBA, 그리고 MS 의 DCOM등이있으며, 이러한 분산객체 시스템은 3계층 아키텍처의 근간이된다.


EJB 서버(Server) - 컨테이너(Container) – 빈(Bean) 아키텍쳐
컨테이너는 각 유형의 빈을 위한 EJB객체들과 EJB홈들을 관리한다. 그리고 이것들이 빈 자원들을 관리하고 트랜잭션, 보안, 동시성 제어 및 네이밍 등의 주요 서비스를 적용받을 수있도록 도와준다. 빈은 실제로 우리가 접근하고자 하는 객체이다.
서버-컨테이너-빈의 순서는 상위로부터 하위로 내려가며 포함하는것-포함되는것의 순서로 배열한것인데, 상위는 하위에 대해 라이프 사이클을 관리하고, 동작환경을 제공한다.
빈과 컨테이너 사이에는 분명한 역할의 구분이 있지만, 사실 컨테이너와 서버 사이의 규약은 EJB 스펙에서 정의되지 않았다. EJB스펙에는 빈과 컨테이너 간의 규약에 대해서만 정의하고있는데, 사실상 서버 프로세스가 없이는 EJB는 구동되지 않는다. 이것은 프로그래밍을 약간만 해 본 독자라면 누구나 유추할 수있는 당연한 사실임에도 불구하고, 컨테이너 와 서버간의 규약을 명시하지 않은 것은 EJB컨테이너와 서버간의 역할경계를 불분명하게 만드는 원인이 된다. 이로인해 각 벤더들은 나름대로의 기술을 적용하여 서버와 컨테이너를 분리하였고, 사실상 서로 다른 벤더가 내놓은 EJB서버들과 그들의 컨테이너들은 호환이 거의 불가능한 특성을 갖게되었다. 도미노 효과처럼, 뒤에 나올 컨테이너 관리 빈은 컨테이너 종속적이라는 특성으로 인해, 다른 벤더의 컨테이너에 끼워넣기가 또한 거의 불가능하다.
실제의 개발에 있어서 서버와 컨테이너를 명확하게 구분해야 할 필요는 없다. EJB적인 모든 특징과 기능들은 컨테이너가 하고, 컨테이너를 담기위한 환경 및 여타의 미들웨어적 특성들은 EJB서버가 담당한다라고만 보면 일단은 충분하다. 보다 자세한 사항은 자신이 쓰고자 하는 제품의 벤더가 제공하는 매뉴얼을 참조해야한다.


엔터티 빈(Entity Bean)  - 세션빈(Session Bean) 아키텍쳐
여러분이 프로그래머라면 프로그램이 데이터와 로직으로 구성된다는 것을 알 것이다. 데이터는 영속적인 데이터와 일시적인 데이터로 나뉘어진다. 영속적이라는 것은 파일이나 데이터베이스등의 영구저장매체에 저장되고, 프로그램이 종료된 후에도 다시 로드하여 쓸 수있는 종류의 데이터이다. 반대로 일시적이라는 것은 프로그램 수행중에 변수에 저장되었다가 프로그램이 종료하고, 메모리상의 기억장소가 해제되는 순간에 사라지는 데이터이다. 이러한 일시적인 데이터들은 주로 로직의 진행에 필요한 것으로 로직의 일부로 보는 것이 더욱 타당하다. 이후 데이터라 하면 데이터베이스에 보관되는 영속적인 데이터를 칭하는것으로 이해해주기 바란다.

로직은 데이터의 조작과 처리를 말하며, 업무에 종속적인 로직과 독립적인 로직으로 나뉘어진다. 이러한 업무독립적인 로직들은 라이브러리화되어 대부분의 프로그램이 공유할 수있다. 그러나, 업무에 종속적인 로직은 일반적으로 그렇지못하다. 증권사에서 개발한 증권거래용 프로그램의 증권거래 라이브러리들을 물류회사의 물류관리업무나 일반기업의 인사관리에서 사용할 수는 없다.  이러한 업무종속적인 로직을 일반적으로 비즈니스 로직이라 칭한다. 객체지향 프로그래밍에서는 데이터를 가진 객체는 데이터를 외부와 교환하기위해 데이터 출납용 메소드를 함께 갖는 것이 권장된다. 이러한 데이터 출납용 메소드들은 업무의 흐름에 독립적인 로직을 갖는것으로, 객체지향 프로그래밍에서는 데이터의 일부로 보는 것이 타당하다.

엔터프라이즈 자바 빈의 종류는 두 가지가 있는데, 이는 엔터티 빈과 세션 빈이다.
이 중, 데이터베이스와 맵핑된 영속적인 데이터를 보관하고, 데이터베이스에 직접 접근하여 데이터를 출납하는 일은 엔터티빈이 맡는다.
세션빈은 비즈니스 로직을 포함한다. 이 구조는 EJB스펙에 지정된 것으로 EJB의 가장 핵심적인 프레임웍이다. 이것은 데이터와 비즈니스 로직의 분리를 통한 개발/유지/보수의 편의성 외에도 원거리 호출을 줄임으로써 어플리케이션의 수행성능을 향상시키는 효과도 포함한다.
물론, 서로의 영역을 넘어서 비즈니스 로직을 엔터티빈이 갖는다든지 데이터를 세션빈이 유지한다든지 하는 것도 얼마든지 가능하고, 클라이언트가 세션빈이 가질 로직을 몽땅 갖게되기도한다. 실제적으로 이러한 시도는 빈번하게 발생한다. 하지만, 이렇게 만들어진 어플리케이션은 이미 EJB를 사용하는 의미를 잃는다. 단지 자바와 RMI의 조합만을 이용하는 것일 뿐 EJB 어플리케이션이라고 볼 수가 없다. 결국, EJB가 주는 개발의 신속성과 유지보수의 편의성은 무시되고, EJB도 별 게 아니더라 라는 결과만을 얻게되는것이다.

엔터티 빈에서 제공하는 메소드를 이용하여 빈의 attribute를 변경하면, 이 변경은 Database의 해당 Table의 해당 Attribute에 자동으로 반영되는것이다. 이때, 엔터티 빈을 참조하는 쪽에서는 전혀 Database의 테이블 구조 및, DBMS와의 통신에 신경을 쓰지 않게된다.  DBMS와의 통신에 신경을 쓰지 않는다는 말은 SQL문을 전혀 사용할 필요가 없음을 의미한다.
그러나, 위에서 한 말은 엄밀히 말하면, 이미 만들어진 엔터티 빈을 사용하는 입장의 개발자에게는 100퍼센트 사실일 수 있겠지만, 아래에서 소개할 Bean managed 방식의 빈개발자는 데이터베이스와 객체를 매핑시키는 작업을 스스로 해 줘야만 하므로, 어쩔 수 없이 SQL을 다루게된다. Container managed방식의 경우라면, 매핑 작업을 EJB 서버의 벤더가 제공하는 툴이 대신해주므로, 엔터티 빈을 만드는 쪽이나, 사용하는 쪽이나 SQL을 전혀 사용할 필요가 없다.

커넥션 풀 ( Connection Pool)
풀이란것은 미리 일정량을 비축해두는 장소라고 보면 된다. 어플리케이션이 DBMS와 통신을 하기위해서는 DBMS와의 커넥션이 필요한데, 어플리케이션이 DB에 SQL을 던지고, 그 수행이 끝날때까지의 시간의 대부분은 DBMS와 커넥션을 맺는데 소요된다.
따라서, 미리 몇 개의 커넥션을 맺어서 커넥션 풀에 이것을 저장해두었다가 이를 필요로하는 객체에게 할당함으로써 수행성능을 향상시킬 수있다. 커넥션을 할당받은 객체는 이 커넥션을 통해 원하는 DB 오퍼레이션을 수행하고, 수행이 완료된 후엔 커넥션을 다시금 풀로 되돌린다. 커넥션은 무한히 쓸 수있는게 아니고, 그 수가 DBMS에 따라 제한되어있다. 만일 저장된 커넥션의 수보다 이를 요구하는 객체의 수가 더 많으면 커넥션을 할당받을 수 없는 나머지 객체들은 풀이 가진 커넥션에 여유가 생길 때까지 대기한다


UDDI
 UDDI 프로젝트는 웹 서비스의 상호 운용성과 채택(adoption)을 촉진시킨다. 이 프로젝트는 산업계와 비지니스 리더들 사이의 파트너쉽이고 IBM, Ariba, Microsoft에 의해 설립되었다. 지금 현재 300개가 넘는 기업들이 참여하고 있다. UDDI는 서비스 설명과 서비스 발견(discovery)에 대한 표준 기반의 스팩은 물론 인터넷 기반 구현을 제공한다. UDDI는 계속적으로 빠르게 진화하고 있으며 산업계의 지원을 받고있다. 이 스팩은 빠르게 개발되고 있다.

UDDI는 비지니스의 많은 문제점들에 관심을 기울이고 있다. 첫째, business-to-business (B2B) 인터랙션의 확장과 단순화에 기여한다. 다양한 고객과 많은 관계를 창출해야하는 제조사에게, UDDI는 각 표준과 프로토콜 별로 가상의 모든 인터페이스를 사용하여 매우 유연한 서비스 기술(description)을 지원한다. 예를 들어 전 세계의 모든 시장에 연결을 원하지만 방법을 모르고 있는 호주의 플라워 샵의 경우 UDDI는 이 방법을 제공한다. 이 스팩은 레지스트리에 플라워 샵을 나타내어 그들이 제공하는 비지니스와 서비스를 효율적이며 간단하게 발견할 수 있도록 한다.

공급자용 카탈로그 데이터 뿐만아니라 영수증 서비스, 포장, 선적, 보험관계자와 관계를 원하는 B2B 마켓플레이스 제공자에게 UDDI는 동적 발견과 관련 웹 서비스를 전체 비지니스 프로세스로 통합할 수 있도록 한다. UDDI는 비지니스 및 전자 서비스에 관한 정보에 대해 원스탑(one-stop) 쇼핑을 제공한다. UDDI에 비지니스 및 서비스 정보를 퍼블리쉬 하면 다른 것에 광범위하게 액세스 할 수 있다.

UDDI는 Extensible Markup Language (XML)와 Simple Object Access Protocol (SOAP) 같은 기존 표준에 기반하고 있다. UDDI를 따르는 모든 구현들은 UDDI 스팩을 지원한다. 공식 스팩은 회원들에 의해 공개적이고 포괄적으로 개발되었다. 앞으로 독립적인 표준 단체로 향후 개발 소유권을 넘기기 전에 세 개의 연속적인 버전을 만들고 구현하기 위함이다. UDDI Version 1 스팩은 2000년 9월, Version 2는 2001년 6월에 발표되었다. Version 3 스팩은 지금 개발중이며 2002년 중순에 발표될 예정이다. Version 1이 레지스트리에 대한 기초를 확립했다면 Version 2는 비지니스 관계 같은 기능을 추가했다. Version 3은 보안, 국제화, 레지스트리 상호운용성, 다양한 API 향상과 같은 웹 서비스의 지속적인 개발을 통해 툴링 향상을 목표로하고 있다.