클래스?
클래스란 객체의 특성을 정의하는 원형이다. 특정한 객체의 자료 구조와 접근 가능한 루틴의 정보를 표현하는 클래스를 개별 ... 하나의 클래스
란 하나의 패키지로 선언된 이름공간을 의미한다. 객체지향이란 그렇게 분리된 이름공간을 활용하는 것이다
서블릿이란?
웹 응용프로그램을 만드는 자바 기술로서 실행 결과값은 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 향상과 같은 웹 서비스의 지속적인 개발을 통해 툴링 향상을 목표로하고 있다.