반응형
위험도 분류 설명 점수
심각 서버 소스 객체지향 인터페이스 설계 실패로 인한 각개전투 묻지마 코드.  
1. 도메인 모델을 map으로 사용.  
2. 계층, 모듈화 무시. 인터페이스 설계 없음.  
3. 비슷한 일을 하는 class가 중복으로 존재. class가 1000라인을 넘어감.  
4. 비즈니스로직의 일부 혹은 전체가 SQL or PL/SQL에 탑재  
멀티 스래드 멀티 스래드 객체의 자원 공유(static,singleton) 오류 위험  
일관된 예외 처리 1. 공통 예외처리를 위한 서버(java) & 클라이언트(javascript or actionscript) 로직이 없음.  
2. 예외 발생에도 불구하고 '성공적으로 실행되었습니다'라는 메세지가 발생.  
DB 무결성 1. FK가 잡혀있지 않음. 어플리케이션에서 무결성 관리가 되지 않음. 채번(PK)에 오류.  
2. 트랜잭션 관리가 되지 않음.  
형상관리 형상관리의 부재 : 형상관리 위한 CVS or SVN등을 사용하지 않는다.  
경고 프레임웍 도입 자체 프레임워크를 개발해서 도입 (자바One에서 나온 실패한 프로젝트의 대표적인 원인. 유지보수가 힘듬)  
MVC프레임워크를 사용하지 않음. (즉 MODEL-1 기반의 project.)  
Hibernate등의 ORM을 사용하지 않음.  
선언적 트랜잭션 또는 예외처리(레이어링 or AOP)가 없거나 도입했는데도 사용하지 않음.  
불필요한 코드 소스코드에 불필요한 try-catch문이나 트랜잭션 관련 API가 포함됨,  
단위테스트 자동화된 테스트 케이스(JUnit등)가 부족하거나 없음.  
성능 대용량 요청 등에 관해 성능을 무시한 && 병목구간을 발생시키는 코딩. SQL튜닝이 안되어있음.  
보안 기본적인 보안관리가 안되어 있음 (SQL공격, 인증우회 등등).  
클라이언트 소스 어설픈 Ajax 사용으로 인한 동기화 / 비동기화 처리 실패 인한 산발적 오류 발생  
비지니스로직의 일부가 클라이언트 스크립트로 코딩되어있음.  
DB설계미스 DB설계 미스 & 정규화 실패로 인한 잦은 join과 대량의 중복 & null컬럼 발생  
개발롼경 Ant나 Maven을 사용하지 않음.  
DB중심의 프로그래밍 업무 로직이 SQL 또는 SP에 들어가 있음. DB특유의 프로그램(pakage/function)이 자주 사용됨.  
권고 서버 코드 일반적인 표준/오픈소스 패키지를 사용하지 않고 자체 개발/코딩  
ex) Concurrent패키지의 Executor를 사용하지 않고 new Thread(runnable).start() 등의 명시적인 스래드 생성 코드를 사용.  
ex) Apache의 Util을 사용하지 않고 자체 개발한 StringUtil을 사용  
UI중심의 프로그래밍 클라이언트 스크립트의 비중이 과도하게 많음. 업무로직이 스크립트에 탑재되어 있음.  
개발 표준 네이밍 룰이 없거나 혹은 지켜지지 않음.  
Logging정책이 없거나 지켜지지 않음. (소스코드에 System.out.print... 등의 코드가 출현.)  
DB중심의 프로그래밍 PL/SQL등의 SP가 사용된적이 있음.  
성능 인덱싱 miss 및 SQL튜닝 miss로 인한 속도 저하. 어설픈/잘못된 페이징 처리.  
주석 난잡한 주석 or 필요한곳에 없는 주석 or 틀린주석(갱신이 안된 주석)  
보안 잘못된 공인인증서 사용. (클라이언트에만 인증서 로직이 들어감.)  
의존관계 정의 실패 lib에 많은 jar가 있지만 어디에 사용되는지 확인 불가.  
jar가 각기 다른 버전으로 중복해서 존재.  
서버 코드 일반적인 표준/오픈소스 패키지를 사용하지 않고 자체 개발/코딩  
ex) Concurrent패키지의 Executor를 사용하지 않고 new Thread(runnable).start() 등의 명시적인 스래드 생성 코드를 사용.  
클라이언트 소스 IE 위주의 코딩 (비표준, 마이플랫폼 등의 국산 X-internet, table레이아웃 등)  
JavaScript와 css가 html상에 섞여있음  
개발환경 지속적인 통함툴 또는 이슈 트래커를 사용하지 않음.  
FTP등을 사용하여 문서/자료를 공유함( 즉 온라인 위키 문서 공유를 하지 않음.)  
반응형

'개발도 하냐?' 카테고리의 다른 글

SI개발자 발전단계  (0) 2009.12.06
무능력한 개발자  (0) 2009.12.06
한국에서의 개발방법론이란..  (0) 2009.12.06
XP 개발방법론  (0) 2009.12.06
JAVA Application 한글깨짐 해결  (0) 2009.12.03
반응형
클래스?
클래스란 객체의 특성을 정의하는 원형이다. 특정한 객체의 자료 구조와 접근 가능한 루틴의 정보를 표현하는 클래스를 개별 ... 하나의 클래스

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

서블릿이란?
웹 응용프로그램을 만드는 자바 기술로서 실행 결과값은 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 향상과 같은 웹 서비스의 지속적인 개발을 통해 툴링 향상을 목표로하고 있다.
반응형

'삽질로그' 카테고리의 다른 글

80x15 배너이미지 만들기  (0) 2007.08.02
RSS 관리  (0) 2007.08.02
자바에 사용되는 용어들  (0) 2007.07.26
FCKeditor java 버전 설치  (0) 2007.07.26
PCI-X 와 PCI-Express 의 비교사진  (0) 2007.07.12
반응형
클래스?
클래스란 객체의 특성을 정의하는 원형이다. 특정한 객체의 자료 구조와 접근 가능한 루틴의 정보를 표현하는 클래스를 개별 ... 하나의 클래스

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

서블릿이란?
웹 응용프로그램을 만드는 자바 기술로서 실행 결과값은 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 향상과 같은 웹 서비스의 지속적인 개발을 통해 툴링 향상을 목표로하고 있다.
반응형

'삽질로그' 카테고리의 다른 글

RSS 관리  (0) 2007.08.02
자바에 사용되는 용어들  (0) 2007.07.26
FCKeditor java 버전 설치  (0) 2007.07.26
PCI-X 와 PCI-Express 의 비교사진  (0) 2007.07.12
소프트웨어기술자 등급별 노임단가기준(2008)  (0) 2007.07.09
반응형
원문 : http://www.devx.com/Java/Article/29208


Struts에서 Spring으로의 이주 가이드.

당신은 이 글을 통해 Struts애플리케이션에서 Spring MVC애플리케이션으로 변형하는 방법뿐 아니라 두 프레임워크사이의 논리적인 맵핑과 Struts개념을 Spring MVC개념에 관련시키는 수단을 배울것이다.


사실 Struts프레임워크는 기술발전이나 채택이 감소하기 시작하고 있다고 몇몇 사람들이 제기한다. 사실 Struts의 책임 개발자인 Craig McClanahan또한 Struts사용자에게 새로운 웹 프레임워크로의 이전을 권하고 있는 상황이다. 반면에 J2EE웹 공간에서, Spring MVC는 꾸준한 채택과 자바 개발자의 주의를 끌고 있다. 가장 인기있는 Spring프레임워크는 잘 디자인되었으며, 잘 만들어졌고, 혁신적이다. 그래서 많은 Struts사용자는 Struts를 위한 대체 프레임워크처럼 Spring을 MVC를 사용할것이다.


이 글은 Struts애플리케이션을 Spring MVC로 이전하길 원하는 개발자들을 도와준다. 그리고 다음의 두가지 핵심부분으로 나누어져있다.

Struts와 Spring MVC프레임워크의 기본 개념사이의 논리적인 맵핑.
이전 대체물을 위한 기본적인 추천사항들.

논리적인 맵핑 : 다른 프레임워크간의 유사함.
Struts와 Spring은 MVC패턴 구현에서 본질적으로 유사하다. 둘다 핵심 J2EE컴포넌트인 Servlet과 JSP에 기반한 모델2 타입의 개발방식을 주로 할려는 경향이 있다. Struts에 친숙한 개발자는 하나의 프레임워크에서 다른것으로 개념적으로 쉽게 이주할수 있다. 두가지 프레임워크 모두 View, Controller, Model의 역활을 제공하는 컴포넌트를 명백하게 서술하고 있다. 유사성은 구현레벨에서 멈춘다. Struts디자인은 각각의 사용자지정 action이 Struts Action컴포넌트의 구조적인 상속이 된다는것을 의미하는 견고한 상속에 기반을 둔다. Spring컨트롤러는 인터페이스이기 때문에, 어떠한 컴포넌트도 컨트롤러의 역활을 수행할수 있다. 이것은 애플리케이션 디자이너에게 컴포넌트 디자인의 좀더 나은 유연함을 제공한다.


프레임워크 컴포넌트 레벨에서 Struts는 Form Beans (정적이거나 동적인), Actions, Action Mappings, Action Forwards, 그리고 Request Processors와 같은 Struts 특유의 객체 사용을 요구한다. Spring MVC는 주요한 컴포넌트가 인터페이스처럼 정의된것처럼 좀더 유연하다.


Struts는 오직 웹 프레임워크일 뿐이다.
Struts는 애플리케이션 개발에서 오직 presentation계층에만 할당한다. 반면에 Spring MVC는 비지니스 컴포넌트에다가 Spring 기업용 개발의 다른 부분을 관리하는 Spring 프레임워크의 다른 부분과 완벽하게 통합되는 Spring프레임워크의 주요한 부분일뿐이다. 이제 좀더 상세하게 프레임워크 컴포넌트를 보자.


Struts Actions는 대략 Spring Controllers이다.
Struts에서 Action은 프레임워크의 핵심 "processing"객체이다. 그것들은 MVC패턴에서 컨트롤러의 역활을 수행한다. Struts Actions의 Spring이 가진 대안은 Controller인터페이스이다. 반면에 Controller는 Spring에서 사용자 입력을 처리하고 View컴포넌트로 전달한다. Struts Actions과 Spring Controller사이의 가장 명백한 차이점은 Actions는 추상 클래스이고 Controllers는 인터페이스라는 것이다. Spring MVC 컨트롤러처럼 설정되기 위해서, 객체는 오직 다음의 메소드를 구현할 필요가 있을것이다.


ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception; 


이 디자인(인터페이스에 의한 디자인)은 애플리케이션과 프레임워크간의 커플링을 최소화한다. 또한 이것은 Controllers의 디자인에서 구조적으로 좀더 유연성을 제공한다. 이것을 염두해 두고, Struts에서 Spring으로의 가장 간단한 중계역활을 하는 이전(transition) 단계는 Action을 다시 쓰는 것이다. 그래서 그것들은 Controller인터페이슬ㄹ 구현하고 존재하는 코드를 재사용하는것이다. 이것은 애플리케이션 작동을 유지하는 동안 모든 Struts의존성의 제거를 증가시키는것을 허용한다.


Spring은 다른 Action대체물도 제공한다. 많은 수의 프레임워크가 제공하는 Controller구현물은 가장 공통적인 웹애플리케이션 작업에 대응된다. 몇몇 제공되는 Controller는 당신이 친숙한 Struts Action에 좀더 특성화된 것에 대응된다. 예를 들어, 당신이 DispatchActions을 사용한다면, MultiActionControllers와 좀더 잘 다듬어진 AbstractWizardFormControllers가 도움을 줄것이다. 다른 Controller구현문은 Spring MVC에 딸려나온다.


Action Forms이 없다.
Spring프레임워크내에서 가장 크고 가장 긍정적인 차이점중에 하나는 특성화된 ActionForm객체가 없다는 것이다. 프레임워크는 HTTP폼 값을 직접적으로 POJO에 바인딩하는것을 지원한다. 이 기능은 생성하고 유지할 클래스의 수를 제한하여 애플리케이션 유지관리를 단순화한다. 이 경우, 이전(migration)은 폼빈즈를 삭제하고 직접적으로 도메인 객체를 사용하는것을 의미한다. 어쨌든, 이것은 당신이 폼입력과 도메인 객체간의 맵핑처럼 Form Bean객체를 사용할수 있다면 필수단계는 아니다. Spring MVC에서, AbstractFormController구현물을 확장하는 특수한 목적의 Controllers는 폼을 지지하는 빈즈를 지원한다. AbstractFormController의 사용자지정 하위클래스는 폼객체처럼 폼을 지지하는(Command) Beans를 사용한다. 다시 말해, 이러한 빈즈를 정의하는 요구사항은 없다. Command객체는 java.lang.Object의 어떠한 하위클래스도 될수 있다.


ActionForwards vs. ModelAndView
Struts ActionMapping에서, 객체는 표현자원(Actions, JSPs, Tiles, HTML 파일들 등등.)을 가리킨다. Spring MVC에서 ActionMapping에 대해 가장 가까운 의미의 컴포넌트는 ModelAndView인터페이스이다. Spring Controllers는 사용자에 의해 구현될수 있는것처럼 ModelAndView인터페이스의 구현물을 반환한다. 또는 당신이 원한다면 Spring MVC에 의해 제공되는 ModelAndView구현물을 사용할수도 있다. 내포하는 이름처럼, ModelAndView객체는 Model과 View컴포넌트를 가진다. Model컴포넌트는 View컴포넌트를 통해 표시되기 위한 비지니스 객체를 포함한다. 시나리오에 따르면, ModelAndView구현물은 포함된 어떠한 Model컴포넌트를 가지지 않는다. 그것들은 아마도 실질적인 View컴포넌트(JSP, XSLT, Tiles, HTML, XML, 등등)의 몇몇 형태로 이끌것이다. Controller구현물에서 처럼, 나는 Spring MVC가 제공하는 Model의 구현물과 View인터페이스 그리고 View해석자(Resolver)를 조사하는것을 강력히 권한다.


사용자지정 JSP 태그들
Spring MVC는 표준 JSP태그 라이브러리의 의미있는 힘을 신뢰한다. Struts와는 달리, Spring MVC는 HTML, logic, 또는 bean처리를 위한 분리된 태그 라이브러리를 제공하지 않는다. 이것은 Command객체에서 Web form으로의 바인딩을 가능하게 하는 작은 태그라이브러리만을 제공한다. 당신은 다른 모든 작업을 위해 표준적인 템플릿 라이브러리(JSTL)를 사용할것이다.


유효성체크(Validation)
만약 당신이 Struts의 Commons Validator을 사용한다면, 당신은 Spring내에서 완벽하게 재사용할수 있을것이다. Spring 1.2는 Commons기반 유효성체크를 지원하지 않지만 Spring MVC의 "sandbox"버전은 Commons Validator마크업 (validator.xml 과 validation-rules.xml)으로 쓰여진 유효성체크 정의의 재사용을 지원한다. 유효성체크 선언를 가진 당신의 XML파일을 버리지 마라. 그것들은 Spring내에서 재사용가능할것이다.


Error 와 Validation Messages
좀더 좋은 소식이 있다. Spring은 동일한 형태로 Struts message번들을 인식한다. Spring MVC내 존재하는 Message자원들을 재사용하기 위해서, 당신은 Spring MVC 설정파일내 messageSource가 다음처럼 설정한다.


<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
 <property name="basename">
  <value>resources.ApplicationResources</value>
 </property>
</bean> 


또한, 당신은 Controller구현물내 messageSource프라퍼티로써 당신의 Controller처럼 이것을 사용할 필요가 있다. 요구되는 변경사항은 없다.


Dispatcher Servlet
Spring MVC는 Request Processor/Action Servlet의 자신만의 버전을 가진다. 이것은 URL표시그룹으로 맵핑되는 DispatcherServlet이다. Dispatcher Servlet의 개념을 이해하기 위해서, Controller를 Spring MVC내 설정하는 방법을 보자.


설정파일들
Struts사용자라면, 당신은 모든 forward, action mapping, form definition 그리고 플러그인 선언등을 가지는 적어도 하나의 struts-config.xml파일을 사용한다. Spring MVC에서, 모든 웹 애플리케이션관련 컨트롤러 선언은 Spring Beans처럼 설정된다. 하나이상의 Dispatcher Controller는 웹자원을 위한 모든 요청을 적당한 Controller로 보낸다. 예를 들면, 만약 당신이 ".do"애플리케이션을 Spring MVC애플리케이션으로 다시 맵핑시키길 원한다면, 당신은 애플리케이션의 web.xml에 다음처럼 서블릿 맵핑을 등록하라. (나는 당신이 .do 확장자를 사용하는것을 실질적으로 권하지 않는다. Struts만 사용하는 규칙처럼 ".do"를 남겨두라.)


<servlet>
 <servlet-name>applicationDispatcher</servlet-name>
 <servlet-class>
  org.springframework.web.servlet.DispatcherServlet
 </servlet-class>
 <load-on-startup>1</load-on-startup>
</servlet>

        ...

<servlet-mapping>
 <servlet-name>applicationDispatcher</servlet-name>
 <url-pattern>*.do</url-pattern>
</servlet-mapping>   


지금 당신은 Spring MVC Controller선언을 가진 Spring 설정파일(applicationDispatcher-servlet.xml)을 가진다. "-servlet.xml"는 applicationDispatcher파일을 위한 접미사이다. 이것은 Spring MVC맵핑파일을 자동 리로드하는 DispatcherServlet을 가능하게 하는 Spring MVC규칙이다.


Spring MVC내에서 웹 action을 적당한 컨트롤러로 맵핑하는것은 매우 쉽다. 이것은 Spring애플리케이션의 일부처럼 같은 "wiring"형태로 수행된다. 다음의 예제는 URL expression /showCatalog.do를 Controller showCatalog로 포워드하는 방법을 보여준다.


<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
 <property name="mappings">
  <props>
          <prop key="/showCatalog.do">showCatalog</prop>
  </props>
 </property>
</bean> 


Controller showCatalog는 Controller인터페이스를 구현하는 클래스에 의해 구현된 다른 빈처럼 설정될것이다. 이 예제에서, showCatalog는 URL요청을 카테고리로 명명된 ModelAndView컴포넌트로 포워드하는 간단한 포워딩 컨트롤러에 지나지 않는다.


<bean id="showCatalog" name="showCatalog"
class="org.springframework.web.servlet.mvc.ParameterizableViewController">
 <property name="viewName" value="catalog"/>
</bean> 


Struts에서 Spring MVC로의 이전 경로.
Struts애플리케이션을 Spring MVC로 이전하기 위해서는 3가지 접근법이 있다. 몇몇은 애플리케이션을 점차적으로 이전할것이다. 다른것들은 Struts프레임워크를 완벽하게 포기하고 완전히 다시 쓰는 작업을 수행할것이다. 접근법들은 아래에서 개요를 말하고, 이전의 완벽함 순서대로 정렬된다.


1. Spring은 Struts컴포넌트를 가능하게 한다. 천천히 이전하길 원하는 사람들을 위해, 첫번째이고 완벽하게 이전에 따른 무리가 없는것은.? Spring Beans처럼 Struts Actions를 가능하게 하는것이다. 이것은 간단한 작업이고, Spring문서에 잘 설명되어 있다. 이것은 Struts코드에 대한 변경을 요구하지 않지만, 이것은 Spring Beans처럼 처리되기 위해 Struts Controller컴포넌트, Actions를 가능하게 한다. 이 처리로, Actions은 Spring Beans의 상태를 상속한다. 그러므로, Spring Controller처럼 많은 것을 보기 시작하라. 늦으면서 단계별로 현명한 이전은 이 처리로 가능하다. 각각의 Action은 애플리케이션 재작성과 현재 웹 연속물의 중단없이 Spring Controller에 의해 한번에 대체될수 있다.


2. Tiles를 사용하는 Spring Spring프레임워크에 의해 완전히 제공되는 다른 대체물은 순수한 "view" 프레임워크처럼 Tiles를 유지하는 동안 Spring MVC컴포넌트로 Struts Controller과 관련 컴포넌트(Actions, Form Beans, 등등)를 대체하는것이다. Spring MVC는 Tiles에 대한 특정 대안을 가지지 않는다. 그래서 구조는 Tiles에 대한 것을 유지하기로 결정하고 Spring MVC를 통해 그 작업을 하도록 만든다. 이 접근법의 하나의 심각한 단점은 당신이 웹애플리케이션내 두개의 다양한 웹 프레임워크를 효과적으로 유지관리하기 위해 유지관리를 위한 많은 노력과 두가지 프레임워크를 위한 추가적인 학습이 필요하다는 것이다.


3. 완전한 이전 완전한 이전은 Struts프레임워크의 모든 컴포넌트를 Spring MVC로 교체하는것을 의미한다. 이 처리의 마지막에는 Struts특성의 컴포넌트는 애플리케이션에 남지않는다.
반응형

'개발도 하냐?' 카테고리의 다른 글

웹접근성  (0) 2008.01.03
오픈아이디로 사용가능한 웹서비스  (0) 2007.07.27
사파리 윈도우용 출시  (0) 2007.07.03
미래를위한선택-웹호환성  (0) 2007.06.18
EMAIL 에러메세지  (0) 2007.04.19

+ Recent posts