Tornado 의 블로그

http://blog.empas.com/ahnyounghoe   에서 퍼왔습니다~

http://www.java201.com/

이런데가 다 있었다니...

일단 링크걸어두고 ..

나중에(?) 꼭 전부 봐야쥐 ㅎㅎ

크헐... EJB 해본지 어언 2년 가까이.... 아무것도 생각 안나네 ㅠㅠ

PHP 하다... JSP 하다.. 리눅스 서버 만졌다가..... 네트워크 관리하다가..

IP 분배 하다가... 보니....

EJB 해볼 시간이 전혀 없었다..

퇴근하고 저녁 짜투리 시간에....

간단하게 쇼핑몰이라도 만들어 봐야겠다...

http://otn.oracle.co.kr/products/jdev/htdocs/jdevcategory.jsp

Oracle9i JDeveloper 기술 정보 제품 개요 IDE J2EE 개발 웹 서비스 UML 모델링 데이타베이스 개발 확장(Extensions) 이전(Migration) 기타 리소스 제품 개요 Oracle9i JDeveloper Reviewer's Guide (ZIP) 이 문서는 Oracle9i JDeveloper의 실습을 통해 평가하는 문서입니다. 여기에는 Oracle9i JDeveloper의 개요 및 특징,Oracle9i JDeveloper를 이용하여 J2EE 애플리케이션과 웹 서비스를 개발하는 방법에 대해 자세히 설명되어 있습니다. 9.0.2 9.0.3.x Oracle9i JDeveloper 신기능 9.0.2 9.0.3.x Oracle9i JDeveloper 백서 (PDF) 9.0.2   Oracle9i JDeveloper 9.0.3.x 신기능 (Broadband Demos) New features in the IDE Support for EJBs and BC4J Modeling, Web services & SCM Database Integration View Technologies, ANT and JUnit     Oracle9i JDeveloper FAQ (Java 유저 그룹에서 나온 질문과 답변)     기술 IDE Oracle9i JDeveloper - Hands on Labs 이 문서는 Oracle9i JDeveloper 9.0.3을 바탕으로 구성되었으며 일부 실습에 필요한 추가 요구 사항은 실습 자체 안에 설명되어 있습니다. 요구 사항과 설명은 반드시 읽어 보시기 바랍니다. Developing Custom JSP Tag Libraries in Oracle9i JDeveloper 이 문서는 Oracle9i JDeveloper를 이용하여 사용자 JSP 태그 라이브러리를 생산적으로 구축하는 방법에 대해 설명합니다. 편리해진 Oracle9i JDeveloper로의 마이그레이션 이 문서는 기존 소스를 Oracle9i JDeveloper로 마이그레이션하는 방법에 대한 가이드라인을 제공합니다. 또한 개발자들이 좋아할만한 생산성 향상을 위한 힌트를 제공합니다. JDeveloper extension for developing J2ME applications Oracle9i JDeveloper 9.0.3 설치 가이드   J2EE 개발 Using Struts with Oracle9i JDeveloper - Hands On Exercises Business Components for Java Statement of Direction 이 문서는 BC4J의 현재 상황에 대한 개요 및 오라클의 향후 전략에 대한 프레임워크를 제공합니다. BC4J Performance Report: Sample Response Times Under Load 이 문서는 BC4J와 오라클 J2EE 프레임워크의 성능 및 확장성에 대해 알 수있는 벤치마크 결과를 제공합니다. BC4J Business Rules in BC4J (PDF) 이 문서는 BC4J의 모델링 및 구현 비즈니스 법칙에 대한 메소드를 제공합니다. Introduction to JClient: A Guide for Forms Developers 이 문서는 Oracle9i JDeveloper를 이용하여 Java Clients를 구축하고자 하는 Oracle Forms 개발자를 위한 문서입니다. Overview of Temporary Tables Used by BC4J 이 문서는 임시 데이타들을 저장하기 위해 BC4J를 사용하는 데이타베이스 테이블에 대해 설명합니다. Configuring OC4J to work with BC4J Simplifying J2EE and EJB Development with BC4J 이 문서는 오라클의 J2EE 호환 BC4J 프레임워크를 어떻게 하면 간소화할수 있는지에 대해 설명합니다. Business Components for Java Feature Overview Java Client Statement of Direction Introduction to JClient: A Simplified Guide Business Components for Java Whitepaper Business Components for Java 기술 백서(PDF)   웹 서비스 Oracle9i JDeveloper를 이용한 웹 서비스의 개발 및 구축 (PDF) Web Services Tutorials 자바와 데이타베이스 웹 서비스를 구축 및 게시하기 위한 15개 이상의 스텝 바이 스텝 튜토리얼 자료입니다. Automated Invocation of a .NET Web Service Oracle9i JDeveloper와 .NET 웹 서비스와의 연동 가이드 Database Web Services 데이타베이스 웹 서비스의 게시 및 소비에 대한 예제 및 문서 Web Services Center 웹 서비스에 대한 샘플, 기술자료, 라이브 데모 및 튜토리얼 리소스   UML 모델링 모델링 툴 안내서 Oracle9i Designer 및 Oracle9i JDeveloper 등의 모델링 툴에 대한 방향 Optimizing Development Productivity Using UML in Oracle9i JDeveloper (PDF) 이 문서는 모델링이 개발 환경에 추가될 수 있는 가치에 대해 설명합니다. JDeveloper에 소개된 UML 클래스 모델링 및 액티비티 모델링 등의 특정 기술과 개발자에게 이 모델러가 왜 중요한지에 대해서도 설명하고 있습니다.   데이타베이스 개발 Oracle9i JDeveloper 9.0.3 announces support for PL/SQL development and debugging 이 문서는 PL/SQL 개발을 위한 기능 및 Oracle9i JDeveloper 9.0.3에 포함된 일반 데이타베이스 개발에 대해 설명합니다.   확장(Extensions) Developing Business Intelligence applications using BI Beans within Oracle9i JDeveloper   이전(Migration) WebGain Developer Center WebGain 사용자에게 제공하는 JDeveloper의 이점을 알고 싶으십니까? VisualCafe에서 Oracle9i JDeveloper로의 손쉬운 마이그레이션에 대한 리소스 및 VisualCafe 플러그인을 확인해보십시오. 편리해진 Oracle9i JDeveloper로의 마이그레이션 이 문서는 기존 소스를 Oracle9i JDeveloper로 마이그레이션하는 방법에 대한 가이드라인을 제공합니다. 또한 개발자들이 좋아할만한 생산성 향상을 위한 힌트를 제공합니다. Forms Application을 J2EE로 마이그레이션 Java 및 J2EE 플랫폼은 웹 애플리케이션 구축의 표준으로 알려져있습니다. 이러한 개방형 표준 아키텍처로의 움직임과 함께 조직은 어떤 개발 툴을 사용할 것인가 그리고 기존 Oracle Forms 애플리케이션을 J2EE 플랫폼으로 이전할 것인지에 대해 결정해야합니다.   기타 리소스 Explore the Oracle9i JDeveloper Handbook Chapter 3, "Creating BC4J Applications with the IDE Tools." Chapter 9, "Introducing Business Components for Java." Buy the Oracle9i JDeveloper Handbook from Oracle Press. Read our conversation with the authors. FAQ on JSR 198 and Eclipse related announcement New Free Internet Seminar Series: "Oracle9i JDeveloper - Meet The Developers" Oracle9i JDeveloper Team과 개발자 간의 토의 내용을 들어보세요. J2EE Web Apps Tutorial

Strategic Planning, SPA-19-5971 Research Note

Y. Natis, R. Schulte 14 April 2003

서비스 지향 아키텍처 소개

웹 서비스의 모멘텀에 이끌려 서비스 지향 아키텍처는 첨단 소프트웨어 프로젝트에서 주류로 위상을 옮기게 될 것이다. 하지만 대부분의 기업들이 SOA의 이점에 대해 혼란을 느끼고 있고 리스크는 제대로 이해하지 못하고 있다.

서비스 지향 아키텍처(SOA)는 클라이언트/서버 소프트웨어 설계 방식으로서 이 설계 방식에서 애플리케이션은 소프트웨어 서비스와 소프트웨어 서비스 소비자(또는 클라이언트나 서비스 요청자)로 구성된다. 소프트웨어 구성 요소들간의 느슨한 결합을 중시하고 별도의 독립적 인터페이스를 사용한다는 면에서 SOA는 비교적 보편화된 클라이언트/서버 모델과는 차이가 있다.

SOA 원리는 애플리케이션 설계, 개발 및 배치 중에 반영된다. 이들은 봉입과 유연한 결합이라는 필수 원칙은 공유하지만 자세히 보면 차이가 있다. SOA의 근본 의도는 새로운 실시간 상황에서 소프트웨어 구성 요소(서비스)를 독립적으로 재활용하는 것이다. SOA의 설계와 개발은 이러한 기민한 실시간 환경의 확보를 목적으로 수행된다.

서비스 인터페이스는 SOA 설계의 정수

설계에서 서비스는 서로 구분되어 정의된 한 쌍의 요소들(서비스 인터페이스와 서비스 구축)로 표현되는 포장된 비즈니스 소프트웨어 구성 요소들이다. 인터페이스는 서비스에서 근본적이고 일정한 구성 요소이다. 서비스는 항상 다른 소프트웨어 구성 요소(서비스 소비자)로부터의 프로그램 액세스를 위해 존재한다. 서비스 인터페이스는 서비스에 대한 프로그램 액세스 "계약"을 정의한다.
서비스 구현은 서비스의 비즈니스 기능을 충족시킨다. 설계 작업의 구체화 수준에 따라 서비스 구현은 개발 도중에 시험해 보아야 할 "블랙 박스"로 남을 수 있다. 그 밖의 경우에는 새로운 모듈로서 이전 SOA 모듈에 대한 숨겨진 액세스 또는 새롭고 선행하는 소프트웨어 모듈에 대한 복수의 조건부 호출의 합성물이 될 것이다

서비스 구현의 설계는 SOA의 설계에서 부차적인 문제이지만 서비스 인터페이스의 설계는 중요하다. SOA는 근본적으로 서비스 인터페이스의 흐름 및 관계이다. SOA의 설계에는 서비스 인터페이스간, 그리고 서비스 인터페이스와 서비스 소비자 사이의 인터랙션과 서비스 인터페이스에 대한 정의가 관련된다.

블랙 박스적 속성은 서비스에 필수적이다.

서비스 인터페이스는 서비스의 정체성과 서비스 호출의 규칙을 수립하는 계약이다. 서비스 인터페이스는 내부 디자인 및 컨텐츠를 고려하지 않고 서비스를 규명(찾고 이해함)하고 사용할 수 있기에 충분한 수준의 정보를 갖고 있어야 한다. 블랙 박스적 성격은 서비스에 필수적이다. 이는 모든 입력 데이터, 모든 응답 데이터(응답 데이터가 있는 경우), 그리고 발생된 모든 예외적 조건들이 인터페이스에 기록되어야 함을 의미한다. 또한 서비스의 목적과 함수를 파악하기 위해 인터페이스에 충분한 메타 데이터가 제공되어야 함을 의미한다. 서비스의 이름에 의존하는 것은 수용할 수는 있지만 약한 형태의 아이덴티티이다. 서비스의 기능을 정의하는 검색할 수 있는 저장소는 보다 세밀한 밀도로 수많은 서비스를 지원할 수 있고 많은 수의 독립적 소스로부터 올 수 있다.
느슨한 결합은 SOA를 기본적인 소프트웨어 모듈와와 차별화시킨다.
SOA는 느슨하게 결합된 형태의 서비스와 서비스 소비자 배치이다. 설계에서 느슨한 결합이란 서비스를 특정 서비스 소비자에게 유사하게 설계하지 않는다는 것을 의미합니다. 서비스 내부에서는 서비스 소비자의 목적, 기술 특성 또는 비즈니스 성격과 관련한 어떤 정보도 전제되지 않는다. 따라서 서비스는 서비스 소비자와 완전히 분리된다.
하지만 서비스 소비자는 서비스에 종속되어 있다(다시 말해 서비스 인터페이스에 대해 엄밀한 의미에서의 참조가 내장되어 있다). 따라서 SOA는 어느 정도는 결합된, 즉 느슨하게 결합된 아키텍처이다. SOA는 모든 참여 소프트웨어 구성 요소들이 다른 구성 요소들과 분리되어 있다는 면에서 사건 기반(event-driven) 아키텍처와 다르며, 모든 소프트웨어 구성 요소가 최초 의도했던 맥락에서만 작동하도록 설계된다는 면에서(다시 말해 논리적으로 타이트하게 결합된) 단일형 아키텍처(monolithic architecture)와 차이가 있다.
설계 당시의 느슨한 결합은 서비스 인터페이스를 비 침해적 재사용을 가능케 하기 때문에 SOA에 필수적이다. 하지만 툴들로는 설계 과정에서의 느슨한 결합을 보장할 수 없다. 논리적으로 서비스 소비자에게 묶이도록 잘못 설계된 서비스는 SOA 스타일의 기술을 사용하고서도 애플리케이션을 단일형 아키텍처로 만들 수 있다.

서비스의 최적 입도는 사용, 툴 및 기술에 좌우된다.

서비스 인터페이스는 여러 개의 엔트리 포인트(메소드) 또는 한 개의 엔트리 포인트를 나타내도록 디자인된다. 고객 관리는 여러 개의 메소드를 노출시키는 서비스의 예가 될 수 있다(예를 들어 고객을 만들고 삭제하거나 고객 정보를 수집). "고객 정보 수집" 메소드는 그 자체로 단일 엔트리 포인트를 갖는 완전한 서비스가 될 수도 있다. 최적의 서비스 인터페이스 입도는 많은 요소들에 좌우된다("Service-Oriented Integration Architectures for Healthcare" 참조).
서비스 인터페이스 개념은 SOA 개발의 핵심이다.
개발 과정에서 서비스 인터페이스는 별개의 독립적인 인터페이스 정의 파일로서 표현된다. 설계 과정에서와 마찬가지로 서비스 인터페이스는 SOA의 필수 구성 요소로 남는다. 인터페이스 파일은 합의된 모든 구문론을 사용해 정의할 수 있지만 표준 기반 구문론을 사용할 경우 서비스의 폭 넓은 도입을 활성화시킬 수 있다.
웹 서비스 기술 언어(WSDL; Web Services Description Language)를 사용해 서비스 인터페이스를 인코딩할 때 서비스는 웹 서비스이다.
WSDL은 새로운 개발 툴 대부분에서 서비스 인터페이스 정의를 위해 사용되는 추천 표준이다. 초기의 SOA 개발은 CORBA IDL(Interface Definition Language), COM/DCOM Microsoft IDL(MIDL), CICS(Customer Information Control System) COMMAREA(common area) 및 기타 좁은 범위로 정의된 사양들을 바탕으로 했다.
전형적인 SOA 애플리케이션 개발 프로세스는 인터페이스 정의로 시작되고 그 뒤에 서비스 구현 소프트웨어와 서비스 소비자 소프트웨어의 개발이 뒤따른다. 대부분의 개발 툴들은 인터페이스 정의의 정확한 언어를 숨기지만 SOA 지향 툴들의 개발 방식은 서비스 인터페이스의 정의, 발견 및 상호 연결을 중심으로 남는다.
서비스 구현 소프트웨어는 고유한 아키텍처를 갖고 있다.
개발 중에 서비스 구현은 어댑터를 통해 오래 된 애플리케이션에 연결하는 새로운 프로그램 또는 래퍼이거나 여러 개의 기존 및 새 프로그램들이 조건적으로 통합된 형태가 될 수 있다. 서비스 구현 개발은 단순히 새로운 프로그래밍 시도, 순수한 레거시 래핑 및 수정, 또는 애플리케이션 통합 시도가 될 수 있다. 각각의 작업을 위해서는 서로 다른 툴과 개발 기법이 필요하다.

충분한 서비스 분리가 이루어지지 못할 경우 결과적으로 애플리케이션이 단일 체제로 된다.

개발 과정에서의 느슨한 결합에는 여러 상황에서 호출할 수 있는 프로그래밍 서비스 구현이 필요하다. 서비스 구현 소프트웨어 개발자들은 서비스의 핵이 새로운 상황에서 재사용될 수 있는가 여부라는 점을 이해해야 한다. 서비스 구현은 서비스 소비자의 기술이나 비즈니스 로직에 관한 어떤 가정도 해선 안 된다. 하지만 툴들은 이러한 요건을 강요할 수 없다. 개발자와 개발자들의 프로젝트 리더들은 서비스 구현의 분리성을 보장해야 한다. 서비스 구현 내부 설계의 분리가 제대로 이루어지지 못할 수록 서비스 재사용 비용이 비싸질 것이다. 충분한 분리가 이루어지지 못하면 SOA 툴과 미들웨어를 사용하더라도 서비스 구현의 재사용이 힘들어지며 최종 애플리케이션이 단일 체제 형태가 된다.
독립적인 서비스의 조합을 위해선 통합이 필요하다.
서비스 분리는 재사용을 가능케 하지만 복잡성이 증대된다. 독립적인 서비스는 독립적이지만 충돌 가능성이 있는 정보와 프로세스 모델을 갖게 된다. 이는 서비스의 조화 유지를 힘들게 만든다. 대부분의 경우 서비스 조합을 위해선 서비스 간 차이점을 해결하고 공통된 상황과 오류 해결을 위해 별도의(통합) 기술이 필요하다.
실시간 SOA는 동적으로 재사용할 수 있는 전사적 범위의 소프트웨어 구성 요소에서 명확하다.
실행 중에 서비스 인터페이스는 일반적으로 인터페이스 정의 파일로부터 개발 툴에 의해 생성되지만 수작업에 의해 개발되어 개발 과정에서 다른 소프트웨어에 내장되기도 하는 서비스 인터페이스 스텁과 서비스 인터페이스 프록시 등 한 쌍의 프로그램으로 유지된다.

이 스텁은
 . 서비스 구현용 서버에 배치된다.
 . 서비스 구현에 적합한 로컬 커뮤니케이션 메소드와 데이터 인코딩을 사용해 서비스 구현과

      상호 작용한다.
    . 프록시는 서비스 소비자에 로컬로 배치된다.
 . 서비스 소비자의 구현에 적합한 로컬 커뮤니케이션 메소드와 데이터 인코딩을 사용해 서비스

      소비자와 상호 작용한다.

일반적인 예로는 Java 서블릿으로서의 스텁과 Visual Basic 구성 요소로서의 프록시를 들 수 있다. 이 프로그램 쌍은 서비스 인터페이스를 구현한다. 모든 새로운 실시간 애플리케이션은 자체 인터페이스 프록시를 통해 서비스에 액세스하여 서비스의 비 침해적 실시간 재사용을 제공한다.

서비스 스텁과 서비스 프록시 커뮤니케이션에서 SOAP가 재사용될 때 서비스는 웹 서비스이다.
이론적으로 생성된 인터페이스 스텁과 프록시 모듈 쌍은 서비스 인터페이스 매개 변수를 전달하기 위해 XML, SOAP 메시지 인벨로프, HTTP, 메시지 지향 미들웨어(MOM) 또는 공유 메모리를 사용한다.
서비스 스텁과 서비스 프록시 커뮤니케이션은 "사적인 비즈니스"이지만 벤더의 형태와 툴 독립성을 유지하기 위해 대부분의 생성 툴은 표준 프로토콜을 사용해 연결을 한다. 하지만 실제로 "표준" 프로토콜은 자동적인 상호운용성을 보장할 정도의 "표준" 자격은 갖고 있지 못하다. 성능 최적화를 위해서도 덜 표준적이면서 융통성이 좋은 커뮤니케이션 프로토콜을 사용할 필요가 있다. 따라서 표준에도 불구하고 2006년까지 서비스 인터랙션을 위해 서비스 스텁 및 서비스 프록시 인코딩 구현의 조정이 필요해질 것이다(확률: 80%).

실시간에서 기술적으로 느슨한 결합은 HTTP 또는 MOM과 같이 기반이 되는 "sessionless" 커뮤니케이션에 의해 이루어진다. 이 낮은 수준의 느슨한 결합은 서비스를 논리적인 느슨한 결합으로 설계하고 개발한 경우에만 효과적이다. 그렇다면 느슨하게 결합된 미들웨어 사용은 새로운 서비스 소비자의 동적인 실시간 추가를 허용한다(즉, 기존 시스템에 사실상의 아무런 영향도 주지 않으면서 실행 중인 시스템에 새로운 사용자 경험을 추가함). 아니면 느슨하게 결합된 미들웨어가 전체 시스템을 위해 더 큰 처리 능력을 제공하겠지만 시스템의 민첩성은 높이지 못한다.
SOA의 실시간 미들웨어는 견고하게 결합된다(예: Java Reomote Method Invocation(RMI) 또는 Microsoft .NET 리모팅). 서비스 설계 및 개발이 논리적으로 느슨하게 결합되면 밀접하게 결합된 실시간 미들웨어에 관계 없이 SOA가 갖고 있는 민첩성이 실시간으로 구현된다.

SOA가 항상 올바른 아키텍처인 것은 아니다.
SOA는 체계적인 애플리케이션 엔지니어링에 유용하다. 특히 요청/응답이 소프트웨어 구성 요소들 간의 자연스런 관계 패턴인 환경에서는 더욱 그러하다. 하지만 SOA는 추가적인 설계 및 개발 시도를 희생함으로써 가능해지며 또한 미들웨어 결합의 필요성이 수반된다. 짧은 시간 동안 사용할 제한적 범위의 애플리케이션들은 가용 수명 기간 중에 비즈니스 로직을 재사용하거나 변경하지 않기 때문에 SOA로부터 아무런 혜택도 받지 못한다. SOA는 또한 비 동기 단방향 인터랙션을 사용하는 애플리케이션 용으로는 좋지 않다. 여기서 SOA의 느슨한 결합은 불필요하고 바람직하지도 않다.
결론: 서비스 지향 아키텍처는 요청/응답 패턴의 애플리케이션을 체계적으로 설계하는 데 있어서는 추천할 만한 아키텍처이다. SOA의 주요 목적은 비즈니스 레벨에서의 소프트웨어 모듈화 및 새로운 환경에서의 빠르면서도 비 침해적인 비즈니스 소프트웨어 재사용에 있다. 사용자들은 SOA의 정수를 이해하고 그와 동시에 장단점을 제대로 인식해 현대적인 전사적 IT의 전체 아키텍처에서 SOA가 어떤 역할을 하는지 파악해야 한다.

소프트웨어 개발 방법론 - Software Development Methodology

방법론란 소프트웨어를 개발하기 위해 개발조직환경과 소프트웨어 및 시스템을 사용할 사용자의 환경에 적합한 소프트웨어 개발 방법을 의미한다. 소프트웨어 개발방법은 소프트웨어 공학의 대가에 의해 소프트웨어 개발방법론이라는 학문형태로 자리를 잡고 있다. 따라서 방법이라는 것은 일반적으로 개발 방법론이라 볼 수 있다. 세계적인 소프트웨어 개발방법론은 크게 구조적 분석 및 설계(Structured A/D ), 정보공학(Information Engineering), 그리고 최근에 각광받고 있는 객체지향 방법론(Object_ OrientedMethodology)이 있다. 실제적으로 보면 현재 기업이나 조직에서 사용하는 방법론은 이들을 적절하게 혼합하여 사용하고 있다. 구조적 방법론의 프로세스모델링과 정보공학의 데이타 모델링을 동시에 사용하고 있다. 이는 조직의 환경이나 개발환경에 맞게 적절하게 기본적인 방법론을 변형시켜 적용시키는 것으로 볼 수 있다.

• 구조적분석 및 설계(Structured A/D): 1970년대 중반 ~ 1980년대 중반
• 정보공학(Information Engineering) : 1980년대 후반 ~ 1990년대 중반
• 객체지향 방법론(Object_ OrientedMethodology): 1990년대 초반 ~ 현재

구조적 분석 및 설계

구조적 방법론은 1970년대 이후 현재 까지 가장 널리 사용되어오던 방법론으로 구조적 분석, 구조적 설계, 구조적 프로그래밍으로 이루어져 있다. 구조적 방법론은 하향식 기능 분할(Fuctional Decomposition)에 기반 둔 프로세스 중심의 방법론으로 단순한 업무처리 시스템의 개발에는 효과적이지만 데이터 분석 및 설계 부분이 취약하며, 분석, 설계, 구현에서 상의한 모델을 사용하므로 단계 간의 변환에 많은 노력이 소요된다. 따라서 대규모의 복잡한 시스템 개발에는 적합하지 않다.

구조적 방법론은 크게 자료구조 중심적 방법론과 자료흐름 중심적 방법론로 분류할 수 있다("객체지향소프트웨어공학", 최영근/허계범).
데이터 구조적 방법은 업무나 기능에 의한 데이터의 변환에 관점을 둔다. 반면에 처리지향 방법은 기능을 분할하는 방법으로 문제를 독립적으로 분해하여 재검토되어 진다. 데이터 구조적 방법론이 문제에 관심을 둔것이라면 처리 지향적 벙법론은 해결에 촛점을 맞춘 것이라 할 수 있다. 구조적 방법론을 지원하고 있는 기법은 대표적으로 DFD(Data Flow Diagram), DD(Data Dictionary), Mini- Spec(Mini-Specification)이 있다.

정보공학

정보공학 방법론은 1980년대 후반에 조직 전반에 걸친 정보 모형화 전략을 채택하며 대두되었다. 정보공학 방법론은 전사적인 차원에서 정보시스템 기획을 통하여 단위시스템을 식별하고  이를 CASE 도구를 이용하여 분석, 설계, 구현하는 방법론으로 기획단계가 대폭 강화되고 CASE를 이용한 생산성 향상 등의 장점으로 인하여 대규모의 시스템 개발에 적합하다. 즉 전체의 계획과 모델 작성을 하고 이에따라 연관관계를 가지고 각각의 시스템을 개발한다. 그러나 정보공학 방법론은 복잡한 시스템의 모델링에 부적합하여 현재는 객체지향 방법론으로 대치되고 있는 추세이다.

정보공학 방법을 지원하고 있는 기법은 대표적으로 ERD(Entity Relation Diagram), PHD(Process Hierachy Diagram), 프로세스대엔티티 Matrix 등이다. 각 기법에 대한 자세한 사항은 기법을 참조한다. 이러한 정보공학의 특징은 아래와 같다.("객체지향소프트웨어공학", 최영근/허계범)

객체지향 방법론

소프트웨어와 관련된 방법론, 도구 등은 우수한 소프트웨어 구현을 위하여 지금까지 많이 연구개발되어 왔다. 그러나 현재 소프트웨어에 있어 가장 심각한 문제점은 수요가 확대되는 반면에 공급이 부족하여 소프트웨어 개발이 수요를 따라가지 못하고 있으며, 유지보수 비용의 비약적인 증가로 소프트웨어 개발 비용이 급증하고 있다는 것이다. 이러한 문제점은 근본적으로 우수한 소프트웨어 개발방법이 없었다고 할 수 있다. 이러한 문제점을 해결하기 위향 제안된 방법론이 객체지향적 접근법이다. 객체지향 접근법은 소프트웨어의 확장이나 변화를 용이하게 해줄 뿐만 아니라 기존 소프트웨어의 재사용성을 증가시켜 준다. 객체지향 시스템에서는 데이터를 다루는 프로시저를 하나로 묶어 객체라는 개념을 사용하여 실세계를 표현하고 모델링한다. 객체지향의 개념은 객체(Object), 메시지(Message), 상속(Inheritance)의 세가지 요소가 근간이 된다. 실세계의 엔티티들은 시스템 내에서 객체로 모델링되어 각 엔티티들은 인스턴스로 표현되고 공통된 특성을 가진 인스턴스들이 모여 하나의 클래스로 구성하게 된다. 즉, 객체지향 방법은 시스템을 연산과 데이터를 함께 갖는 객체의 집합체로 보고, 문제영역에서 데이터와 함수를 분리할 수 없는 것으로 취급한다. 함수들과 함수의 처리 대상이 되는 데이터는 문제 범위내에 있는 객체로 취급함으로써 문제 영역의 엔티티가 모델 세계로의 객체로 직접 사상이 가능하기 때문에 응용 영역의 구조와 밀접하게 대응하여 개발 비용의 감소를 가져오며, 시스템을 쉽게 이해할 수 있다. 객체지향 방법론을 발전시켜온 삼인방(Booch, Rumbaugh, Jacobson)에 의해 90년대 중반에 표기법을 통일되었는데, 최근에 객체지향 하면 떠오르는 것이 UML(Unified Modeling Language)이다. 이는 객체지향 방법론이 아닌 이를 지원하는 표기법(Modeling Language)이다. 객체지향을 지원하고 있는 기법으로는 Class Diagram, Use Case Diagram 외에 6개정도의 UML표기법에 의한 다이어램이 있다. Class Diagram과 Use Case Diagram에 대한 사항은 기법(Technique)을 참조한다.

이상으로 구조적 방법, 정보공학, 객체지향 방법을 서로 비교해 보면 아래 표와 같다("객체지향소프트웨어공학", 최영근/허계범)

출처 : http://www-903.ibm.com/developerworks/kr/java/library/j-gss-sso.html

GSS-API와 Kerberos 티켓을 사용하여 SSO를 구현하는 클라이언트/서버 자바 애플리케이션 디자인

Faheem Khan
컨설턴트
2003년 9월 9일

점점 더 많은 패스워드 보안 애플리케이션을 조직의 컴퓨터 환경에 추가한다면 이는 인증의 복잡함도 함께 가중시키는 것이고 결국 개발자와 사용자에게 부담을 주게 된다. 대부분의 엔터프라이즈 애플리케이션 통합 프로젝트들은 싱글사인온(SSO) 기능을 포함하고 있다. 이는 사용자가 다양한 애플리케이션을 사용하기 위해 단 한번만 로그인 하도록 하는 기능이다. 이 글에서 자바 플랫폼에 SSO를 구현하는 방법을 설명한다.

당신의 기업은 많은 자바 애플리케이션들을 구동하고 있으며 그 엔터프라이즈 리소스에 접근하기 위해서는 인증이 필요합니까? 그렇다면 싱글사인온(SSP) 보안 기능을 구현하여 사용자 침입을 최소화 할 필요가 있다. 이 글에서 Kerberos와 Java Generic Security Services API (GSS-API)를 사용하여 SSO를 구현하는 방법을 배우게 될 것이다. 우선 SSO의 정의를 설명하고 강력한 애플리케이션을 설명할 것이다. 그런 다음 Kerberos 기반의 SSO를 구현할 때 발생하는 메시지 교환 시퀀스도 연구한다. 자바 GSS-API와 GSS를 사용하여 SSO를 달성하는 전형적인 자바 애플리케이션 아키텍쳐를 간단히 소개한다. 마지막으로 이 모두를 종합하여 코드 예제를 선보인다. 자바 개발자가 GSS Kerberos 티켓으로 SSO를 어떻게 구현하는지 보게 될 것이다.

'싱글사인온'이란 무엇인가?
근본적으로 싱글사인온 인증이 의미하는 것은 인증 데이터의 공유이다. 예를 들어 웨어하우징 회사의 많은 사원들은 엔터프라이즈 리소스(데이터베이스 테이블 등)에 접근하여 그들의 업무에 필요한 것을 수행해야 한다. 동시에 다른 사원들도 작업 내용에 따라 다양한 리소스가 필요하다. 회계 담당자는 회계 관련 데이터베이스 테이블에 접근해야 하는 반면 판매 담당자는 판매 관련 데이터베이스 테이블에 접근해야 한다. CEO라면 기업의 데이터베이스 어디에나 접근이 필요할 것이다.

분명한 것은, 이 기업은 무엇보다도 제대로 된 인증 메커니즘이 필요하다. 어떤 사원이 특정 리소스에 접근을 시도했는지 결정할 수 있도록 말이다. 일단 기업 인증 모듈이 사원의 존재를 알면 엔터프라이즈 구현 안의 인증 모듈은 인증이 있는 사용자가 적절한 권한을 갖고 리소스에 접근했는지의 여부를 검사할 수 있다.

사원들이 인증용 유저네임과 패스워드를 사용한다고 가정해보자. 이 기업의 인증 모듈은 당연히 유저네임과 패스워드의 데이터베이스를 갖고 있을 것이다. 들어오는 인증 요청은 유저네임-패스워드 쌍으로 동반될 것이다. 이 인증 모듈은 내부 데이터베이스의 쌍과 비교를 하게 된다.

이제 우리의 웨어하우징 회사는 이 범위안에서 실행되는 여러 애플리케이션들을 갖고있다. 다양한 애플리케이션들이 같은 엔터프라이즈의 다른 모듈을 형성한다. 각각의 애플리케이션은 그 자체로 완벽하다. 이것 나름대로 사용자 기반의 여러 다른 티어(백엔드 데이터베이스, 비지니스 로직, 사용자용 GUI)를 갖고있다는 것을 의미한다. 엔터프라이즈 애플리케이션 통합(EAI)는 이와 같은 독립된 애플리케이션들을 하나의 엔터프라이즈에 통합하는 프로젝트를 일반적으로 가르킨다.

EAI 프로젝트에서 인증 프로세스에 두드러지는 하나의 일반적인 요소가 있다. 특정 애플리케이션의 사용자는 그 엔터프라이즈 내의 또 다른 애플리케이션에 액세스 해야한다. 예를 들어 판매 데이터베이스를 사용하고 있는 판매 담당자가 특정 부품을 검색하기 위해 재고 데이터베이스에 액세스 해야 할 경우도 있다. 이러한 유형의 크로스-애플리케이션 인증을 실현시킬 수 있을까?

두 가지 선택이 있다:

• 두 애플리케이션에서 유저네임과 패스워드 데이터베이스를 중복시킬 수 있다. 따라서 이러한 두 개의 애플리케이션들이 웨어하우징 회사의 모든 사원들을 위해 인증 요청을 효율적으로 처리할 수 있도록 하는 것이다. 사용자는 두 개의 애플리케이션에서 개별적으로 인증을 처리하게 된다. 다시 말해서 자신의 유저네임과 패스워드로 들어가면서 두 애플리케이션 중 하나에 액세스하고 그 애플리케이션은 모든 인증 단계를 수행하게 된다. 유저네임과 패스워드 데이터베이스를 중복할 뿐만 아니라 인증 프로세스 오버헤드까지 중복하는 것이다. 이 솔루션에서 중복의 양은 명확해진다.
  
  
• 두 번째 선택은 판매 애플리케이션과 재고 애플리케이션 간 싱글사인온을 통한 인증 데이터 공유를 가능하게 하는 것이다. 만일 사용자가 한 애플리케이션 인증을 갖고 있다면 그의 인증 정보는 다른 것에 전달 될 수 있다. 이 두 번째 애플리케이션은 그 모든 인증 단계를 거치지 않고도 인증 정보를 수락한다. 이 솔루션에는 중복이 없다. 두 개의 애플리케이션이 서로 신뢰하여 각 애플리케이션이 서로의 인증 데이터를 수락할 수 있도록 하는 것이 유일한 필요조건이다.

일반적으로 SSO는 개별 인증 모듈로서 구현된다. 사용자 인증이 필요한 모든 애플리케이션들은 SSO 기반의 인증 모듈에 의지하여 사용자를 확인한다. 이 인증 정보에 따라 다양한 애플리케이션들은 각자의 인증 정책을 발효한다.

이 웨어하우징 기업 예제는 사용자 관점에서 SSO가 무엇인지를 설명한 것이다. 다음 질문은 당연히 "SSO를 어떻게 구현하는가?"이다. 여러 방법이 있다. SSO를 포함하여 다양한 보안 서비스를 제공하는 Kerberos에 대해 알아보자.

Kerberos 사용하기
Kerberos는 Internet Engineering Task Force (IETF) 표준으로서 전형적인 키 교환 메커니즘을 정의한다. 애플리케이션들은 Kerberos 서비스를 사용하여 사용자에게 인증을 주고 암호 키를 교환한다. Kerberos는 티켓 발상에 기인한다. 하나의 티켓은 암호 키와 몇몇 정보 조각을 래핑하는 데이터 구조일 뿐이다. 키 발급 센터(KDC)는 Kerberos 티켓을 인증 사용자에게 발급한다. KDC는 두 가지 유형의 티켓을 발행한다:

• 마스터 티켓(티켓 발행 티켓 (TGT))
• 서비스 티켓

KDC는 우선 TGT를 클라이언트에 발행한다. 이 클라이언트는 TGT에 여러 서비스 티켓을 요청할 수 있다. TGT와 서비스 티켓의 작동 방법을 설명해주는 다음의 키 교환 시나리오를 보자:

1. 클라이언트가 TGT의 발행을 요청하며 KDC에 메시지를 보낸다. 이 요청은 평이한 텍스트 형식(암호화 되어있지 않음)이고 클라이언트의 유저네임이 포함되어있다. 패스워드는 포함되지 않는다.
   
   
2. KDC는 TGT를 클라이언트에 발급한다. TGT는 암호화된 형식안에 세션 키를 포함하고 있다. 이 세션 키를 암호화하려면 KDC는 클라이언트의 패스워드에서 나온 키를 사용한다. 클라이언트만이 TGT의 암호를 해독할 수 있고 세션 키를 가져올 수 있다는 것을 의미한다. 따라서 클라이언트 애플리케이션이 TGT를 요청하기 위해 패스워드를 알 필요는 없어도 TGT를 처리하고 사용할 패스워드는 필요하다.
   
   
3. 클라이언트가 TGT의 암호를 해독하고 여기에서 세션 키를 추출한다. 클라이언트는 서비스 티켓을 위한 요청을 작성한다. 서비스 티켓은 양방간 커뮤니케이션용으로만 가능하다. 즉 클라이언트와 그 클라이언트가 통신하기 원하는 엔터티. 어떤 누구도 이 서비스 티켓을 사용할 수 없다. 따라서 서비스 티켓을 요청하는 동안 클라이언트는 서비스 티켓으로 사용 할 서버 이름을 지정한다. 이 서버는 KDC에 이미 존재하고 있어야 한다.
   
   
4. KDC는 서버용 서비스 티켓을 작성한다. 이 티켓은 클라이언트의 인증 데이터와 새로운 암호 키(하위 세션 키)를 포함하고 있다. KDC는 서버의 비밀 키로 서비스 티켓을 암호화한다. 오직 서버만이 서비스 티켓 암호를 해독할 수 있다.
   
   
5. KDC는 메시지를 작성하고 이 안에 서비스 티켓을 래핑한다. KDC는 이 메시지 내부에 하위 세션 키를 복사한다. 하위 세션 키는 메시지에 두 번 포함되었다는 것을 기억하라.
   
   
6. KDC는 2, 3 단계에서 나온 세션 키로 전체 메시지를 암호화한다. 따라서 오직 클라이언트만 메시지를 해독하고 하위 세션 키와 서비스 티켓을 추출할 수 있다. 클라이언트가 서비스 티켓 암호를 해독하지 못하면 오직 서버만이 할 수 있다. 따라서 어떤 누구도 다른 목적으로 서비스 티켓을 사용할 수 없다. 그런 다음 KDC는 메시지를 클라이언트에 보낸다.
   
   
7. 클라이언트는 KDC에서 받은 메시지를 해독하고 메시지 내부에 있는 하위 세션 키와 서비스 티켓을 가져온다. 서비스 티켓은 서버에 보낸다.
   
   
8. 서버는 서비스 티켓을 받고 이를 해독하여 요청 클라이언트의 인증 데이터와 하위 세션 키를 가져온다. 서버는 클라이언트의 요청을 확인하고 새로운 보안 세션이 클라이언트와 서버 사이에 만들어진다. 클라이언트와 서버 모두 같은 하위 세션 키를 마련하고 있고 서로 보안 통신을 위해 이를 사용할 수 있다.

클라이언트는 3 단계에서 8 단계 까지 또 다른 서버 애플리케이션에 반복할 수 있다. Kerberos 서비스가 인증 데이터를 공유하는 데 사용될 수 있고 같은 클라이언트가 다른 애플리케이션에도 인증을 받을 수 있다는 것을 의미한다. 이는 SSO를 효과적으로 만든다 .

Java Generic Security Services API
IETF는 Generic Security Services API (GSS-API)를 고급 보안 API로 정의했다. 이것은 Credential성, 메시지 무결성, 보안 등의 기능을 제공한다. GSS-API는 클라이언트-서버 환경에서 쉽게 작동한다. IETF는 GSS-API를 언어 독립 방식으로 정의했다.

자바 GSS-API는 자바 스팩 형식의 GSS-API이다. Sun은 Java Community Process를 통해 자바 GSS-API를 개발했고 레퍼런스 구현도 제공했다. 이는 JDK 1.4 버전에 번들 될 것이다. (참고자료).

보다 간단히 하기 위해 GSS-API를 GSS로 통칭하겠다.

GSS는 다른 저급 보안 서비스의 상단에 고급 추상 레이어를 제공하는 것이 목적이다. Kerberos는 GSS 추상화에서 사용할 수 있는 기술 중 하나이다. GSS 추상 레이어에서 프로그래머는 보안 메커니즘을 개발 할 수 있다. 보다 낮은 레벨에서 어떤 메커니즘이 작동하고 있는지 걱정하지 않아도 된다. 이 글에서 GSS 하에서 작동하는 저급 보안 메커니즘으로서 Kerberos의 사용법에 초점을 맞추겠다.

GSS는 GSSName, GSSCredential, GSSContext의 개념에서 작동한다. GSSName은 이메일을 확인하기 위해 입력하는 유저네임 같이 당신을 개별적 존재로 구분한다. GSSCredential은 당신의 존재를 증명하기 위해 내보이는 어떤 것이다. 이메일 확인 시 입력하는 패스워드와 같다. Kerberos 서비스 티켓은 GSSCredential의 또 다른 예제이다. GSSContext는 보안 관련 정보(암호 키)를 캡슐화하는 보안 세션 같은 것이다. GSS 기반의 애플리케이션은 GSSContext를 사용하여 안전하게 통신한다.

GSS 클라이언트/서버 애플리케이션
이 섹션에서는 GSS 기반 보안 자바 애플리케이션의 실제 구현을 설명하겠다. 재사용 가능한 JavaBeans 컴포넌트 두 개를 개발 할 것이다. 하나의 빈은 요청 클라이언트로서 작동하여 새로운 GSS 세션의 초기화를 요청한다. 다른 빈은 서버로서 작동하여 요청을 리스닝하고 클라이언트에서 오는 요청을 수락한다. 그런 다음 보안 컨텍스트를 만들고 클라이언트와 통신한다.

이 글에서 SSO를 설명해야하기 때문에 제 삼자에 의해 호스팅되는 애플리케이션으로 KDC를 사용하여 우리 애플리케이션을 단순하게 할 것이다. 클라이언트와 서버 모두 이 KDC를 믿고 있으며 여기에서 오는 인증 데이터를 받아들인다. 따라서 이 글에 쓰인 샘플 코드를 사용하기 위해서는 Kerberos 실행이 필요하다. 하지만 GSS 호완의 KDC를 사용할 수 있다. ("KDC 설정하기" 참조)

JAAS 인증 클라이언트
일단 KDC 서비스를 실행하면 계속 진행하여 TGT를 발급하도록 KDC에게 요청할 수 있다. 요청하는 GSS 클라이언트는 KDC에게 TGT를 발급하도록 요청 할 것이다.

작은 문제가 있다. GSS는 사용자에게서 온 유저네임-패스워드 쌍을 가져올 메소드가 없다. 따라서 GSS 애플리케이션은 다른 비 GSS 메커니즘에 의존하여 로그인 정보를 얻어야 한다. 우리는 여기서 Java Authentication and Authorization Service (JAAS)를 사용하여 요청 클라이언트가 유저네임과 패스워드를 제공하고 TGT를 얻도록 하겠다.

Listing 1에서는 GSSClient 라는 클래스를 보게 될 것이다. 이 클래스는 원격 GSS 서버와 보안 세션의 설치를 원하는 GSS 클라이언트의 기능을 나타낸다. GSSClient 구조체는 많은 매개변수를 취한다:

1. 클라이언트 피어 이름
   
   
2. 클라이언트 피어의 패스워드
   
   
3. 원격 서빙(serving) 피어의 이름
   
   
4. 원격 서빙(serving) 피어의 주소
   
   
5. 서버의 포트
   
   
6. Kerberos 영역 또는 도메인
   
   
7. KDC 주소
   
   
8. 로그인 설정 파일의 이름과 위치 경로
   
   
9. 클라이언트 설정 이름

main() 메소드는 간단한 애플리케이션을 시뮬레이팅하고 있다. Listing 1에 이 메소드를 추가했다. 명령행에서 이를 실행하여 이 클래스의 작동을 설명하기 위해서이다. main() 메소드는 명령행에서 매개변수 값을 읽고 GSSClient() 구조체를 호출하면서 매개변수 값을 이 구조체에 보낸다.

GSSClient() 구조체는 다른 필드에 있는 명령행에서 오는 매개변수를 저장하고 세 개의 시스템 프로퍼티를 지정한다. java.security.krb5.realm 시스템 프로퍼티는 KDC 범위를 지정한다. java.security.krb5.kdc 프로퍼티는 KDC 서버의 주소를 지정한다. java.security.auth.login.config 프로퍼티는 로그인 설정 파일의 이름과 위치 경로를 지정한다. GSS 프레임웍은 이 속성들을 내부에서 사용 할 것이다.

GSSClient 객체를 인스턴스화 한 후에, main() 메소드는 GSSClient.login() 메소드를 호출한다. 이 메소드는 LoginContext 객체를 인스턴스화 하는데 JAAS 프레임웍의 일부이다. LoginContext 구조체는 두 개의 매개변수를 취한다. 두 번째는 BeanCallBackHandler 클래스이다. 이 둘을 자세히 살펴보자.

confName과 설정파일
confName은 JAAS 설정의 이름을 수반한다. 아홉 번째 명령행 매개변수는 클라이언트가 인증용으로 사용할 JAAS를 설정한다. 여덟 번째 매개변수로 지정된 JAAS 설정 파일에는 한 개 이상의 클라이언트 설정이 포함되어 있다. 클라이언트는 이 중 하나를 사용할 수 있다.

JAAS 설정은 인증에 사용될 메커니즘을 정의한다. 설정 파일은 자바 애플리케이션이 인증 로직과 독립된 인증 메커니즘을 선택할 수 있도록 한다.

JAAS 설정은 .conf 파일로 저장된다. Listing 2 의 JAAS 설정 파일 샘플에는 두 가지 설정이 있다. GSSClient 설정은 다음과 같다:

 GSSClient { com.sun.security.auth.module.Krb5LoginModule required; }; 

이 JAAS 설정은 com.sun.security.auth.module.Krb5LoginModule 라는 자바 클래스 이름을 지정한다. 이 클래스는 JAAS의 Kerberos 로그인 모듈이고 GSSClient 설정은 로그인에 이것을 사용한다. 따라서 이 설정을 지정한다는 것은 인증 메커니즘으로서 Kerberos를 사용한다는 것을 의미한다.

 /**** Login.conf ****/ GSSClient{ com.sun.security.auth.module.Krb5LoginModule required; }; GSSServer{ com.sun.security.auth.module.Krb5LoginModule required storeKey=true; }; 

BeanCallBackHandler
Listing 1의 클라이언트를 다시 살펴보자. LoginContext 구조체 메소드 호출과 함께 전달된 두 번째 매개변수는 인증 과정 중에 콜백을 핸들할 객체를 지정한다. Callback은 자바 애플리케이션이 인증 프로세스 중에 JAAS 구현과 인터랙팅 할 수 있도록 한다. 정상적으로 콜백 기능을 사용하여 유저네임과 패스워드를 Kerberos 인증 모듈에 전달 할 수 있다. BeanCallBackHandler 구조체 call에 있는 username과 password를 전달했다는 것에 주목하라.

Listing 3은 BeanCallBackHandler 클래스이다. 이 클래스는 CallBackHandler 라는 인터페이스를 구현한다. 이 인터페이스는 JAAS 프레임웍의 일부이고 단 하나의 메소드인 handle()을 포함하고 있다.

 /**** BeanCallbackHandler.java ****/ import java.io.*; import java.security.*; import javax.security.auth.*; import javax.security.auth.callback.*; public class BeanCallbackHandler implements CallbackHandler { // Store username and password. String name = null; String password = null; public BeanCallbackHandler(String name, String password) { this.name = name; this.password = password; }//BeanCallbackHandler public void handle (Callback[] callbacks) throws UnsupportedCallbackException, IOException { for(int i=0; i<callbacks.length; i++) { Callback callBack = callbacks[i]; // Handles username callback. if (callBack instanceof NameCallback) { NameCallback nameCallback = (NameCallback)callBack; nameCallback.setName(name); // Handles password callback. } else if (callBack instanceof PasswordCallback) { PasswordCallback passwordCallback = (PasswordCallback)callBack; passwordCallback.setPassword(password.toCharArray()); } else { throw new UnsupportedCallbackException(callBack, "Call back not supported"); }//else }//for }//handle }//BeanCallbackHandler 

CallBackHandler 객체의 handle() 메소드는 인증이 이루어지는 동안 제어를 자동으로 받는다.

JAAS 프레임웍은 CallBack 객체의 어레이를 CallBackHandler 인스턴스의 handle() 메소드로 전달한다. CallBack 객체의 어레이에는 다른 유형의 콜백 객체들이 포함되어 있다. 하지만 여기에서는 두 가지 유형(NameCallBack과 PasswordCallBack)을 중심으로 설명하겠다.

NameCallBack 객체는 JAAS 프레임웍에 username을 제공하는데 사용된다. PasswordCallBack은 인증 동안 password를 수반한다. 핸들 메소드(Listing 3)내부에서 NameCallBack 객체의 setName() 메소드를, PasswordCallBack의 setPassword() 메소드를 호출했다.

LoginContext 구조체 호출에 따르는 두 개의 매개변수에 대한 위 논의를 요약해보면 사용자 인증에 필요한 LoginContext 객체에 모든 정보를 제공해 줄 수 있다. 따라서 Listing 1의 다음 단계는 LoginContext.login() 메소드를 호출한다. 이는 실제 로그인 프로세스를 수행할 것이다.

인증 프로세스 중에 무엇인가 잘못된다면-예를 들어, password가 정확하지 않다거나-javax.security.auth.login.LoginException이 던져진다. 로그인 메소드 호출의 결과로 어떤 예외도 없다면 인증 프로세스가 성공했다는 것으로 간주할 수 있다.

Kerberos 로그인을 사용하고 있기 때문에 JAAS 프레임웍은 내부적으로 KDC와의 모든 통신을 관리하고 Kerberos TGT를 보내면서 고급의 사용이 편리한 JAAS 인터페이스 뒤에 모든 기술적 상세들을 숨긴다.

성공적인 인증은 LoginContext 객체 안에 Kerberos TGT를 로딩하게 된다. LoginContext 클래스의 getSubject() 메소드를 호출할 수 있다. 이것은 Subject라는 클래스 인스턴스를 리턴한다. Subject 인스턴스는 TGT를 래핑한다.

이 Subject 클래스를 사용하여 우리가 로그인 했던 액션을 수행할 것이다. 보안 GSS 콘텍스트를 설치하는 것이다. 인증이 성공한 후 필요한 액션을 호출하는 방법을 보자.

Subject 클래스에는 doAs()라는 정적 메소드가 포함되어 있다. 이것은 두 개의 매개변수를 갖는다. Listing 1의 Subject.doAs() 메소드 호출을 보자. 첫 번째 매개변수 값은 Subject 인스턴스로서 성공적인 인증 후에 획득한 것이다. doAs() 메소드는 인증된 Subject를 사용하여 권한 결정을 내린다. 이 Subject가 주어진 작동을 호출할 권한을 받았는지를 판단하는데 사용하는 것이다.

지금까지 Subject 클래스는 TGT를 보내는데에만 사용했다. 따라서 GSSClient에 대한 권한 정책을 지정하지 않았다. 어떤 사용자라도 이 클라이언트를 실행할 수 있다. GSSClient는 주어진 작동을 실행할 때 보안 권한을 요구하지 않는다. 하지만 애플릿 같은 웹 클라이언트는 엄격한 보안 콘텍스트 하에서 실행된다. Setup.txt에는 애플릿 기반의 GSS 클라이언트를 위한 권한 정책을 작성하는 지침이 포함되어 있다.

doAs() 메소드 호출의 두 번째 매개변수 값인 this는 GSSClient 객체(Listing 1)를 지정한다. 이 매개변수는 PriviledgedAction 인터페이스를 노출하는 객체를 기대한다. GSSClient는 그 PriviledgedAction 인터페이스를 구현한다. 하나의 클래스에 모든 클라이언트측 코드를 조합했지만 PriviledgedAction 인터페이스를 구현하는 개별 클래스를 가질 수 있다. 원한다면 말이다. 만일 그렇게 한다면 그 객체를 인스턴스화 하고 doAs() 메소드 호출과 함께 두 번째 매개변수 값으로서 이를 전달한다.

PriviledgedAction 인터페이스에는 단 하나의 메소드 run()이 포함되어 있다. 권한 정책이 Subject로 하여금 GSSClient 클래스의 run() 메소드에 액세스 할 수 있도록 한다면 그 메소드는 개별 쓰레드 실행에서 제어를 받는다. run() 메소드가 제어를 받으면 보안 콘텍스트(TGT)가 따라온다. GSS 로직은 자동으로 그 보안 콘텍스트를 사용하고 TGT를 보낸다.

GSS 클라이언트 디자인
Listing 1의 run() 메소드에서 다음 단계를 수행하여 GSS 세션을 만들어야 한다:

1. GSSManager를 인스턴스화 한다. GSSManager 클래스의 getInstance() 정적 메소드를 호출했던 Listing 1을 주목하라. 이것은 GSSManager 객체를 리턴한다. 이 GSSManager 객체는 적어도 Kerberos 메커니즘을 지원하고 그 밖에 다른 메커니즘도 지원할 것이다. GSSManager 클래스에는 GSS 애플리케이션이 다른 보안 메커니즘을 정의하기 위해 호출할 수 있는 메소드들이 포함되어 있다. 지금은 Kerberos 메커니즘을 중심으로 설명하는 것이니 만큼 getInstance() 메소드를 호출하여 Kerberos 메커니즘을 사용한다. Listing 1의 GSSManager 객체를 인스턴스화 한 후에 kerberos라는 Oid (Object ID) 객체를 인스턴스화 했다. 이것은 Kerberos 메커니즘을 확인한다. ."
   
   
2. GSSName 객체를 만든다. 이것은 GSS 엔터티를 나타낸다. 투웨이 통신을 하는 동안 GSS 엔터티를 통신 피어로 생각할 수 있다. 따라서 두 개의 GSSName 객체를 만드는 것이다. 하나는 요청 클라이언트 피어(clientPeerName)용이고 또 다른 하나는 원격 피어(remotePeerName)용이다.
   
   
3. Credential 세트를 만든다. GSS는 일반적인 보안 메커니즘이다. 따라서 기저의 기술에 의존하여 이러한 Credential을 만든다. Kerberos를 사용하고 있으므로 Kerberos 티켓은 실제 Credential이다. GSSCredential 객체를 얻으려면 GSSManager 클래스의 createCredential() 메소드를 사용한다. createCredential() 메소드는 GSSCredential 인터페이스를 노출하는 객체를 리턴한다.
   
   
4. 보안 GSS 콘텍스트를 만든다. 이것은 두 개의 통신 피어 간 보안 통신을 확립하는데 사용된다. GSSManager의 createContext() 메소드는 GSSContext 인터페이스의 인스턴스를 만들어 리턴한다. GSSContext 객체는 실제 보안 콘텍스트를 래핑한다. Listing 1에서 GSSName과 GSSCredential 객체를 전달했다는 것에 주목하라.

보안 콘텍스트를 래핑하는 GSSContext 객체를 가졌지만 콘텍스트 그 자체는 아직 설치되지 않았다. GSSContext 객체를 얻은 후 요청 피어가 이것의 requestConf() 메소드를 호출 할 것이다. 이 메소드는 애플리케이션이 기밀성과 데이터 무결성을 요청하게 하여 원격으로 보내는 모든 데이터가 암호화된 형식이 되도록 한다.

Listing 1에서 requestConf() 메소드를 호출 한 후에 byteToken이라는 바이트의 어레이를 선언했고 이를 제로 사이즈 바이트로 인스턴스화 했다. byteToken 어레이는 GSS 클라이언트가 서버에서 송수신하는 데이터 바이트를 갖고있게된다.

GSSContext 인터페이스의 initSecContext() 메소드를 while 루프에서 반복적으로 호출한다. 이 메소드는 실제 바이트 교환을 수행하여 요청 피어와 서빙 피어 간 보안 콘텍스트를 확립한다.

while(!peerContext.isEstablished()) 블록(Listing 1)은 실제로 GSS 클라이언트와 서버 간 투웨이 통신을 수행한다. 이 블록은 보안 콘텍스트가 설치되었을 때에만 종료된다.

while 루프가 첫번째로 실행될 때 byteToken 어레이에는 데이터가 없다. peerContext.isEstablished() 메소드는 false를 리턴할 것이다. 보안 콘텍스트가 아직 설치되지 않았기 때문이다.

while 루프 내부에서 우리가 수행하는 첫 번째 일은 byteToken 어레이상에서 initSecContext() 메소드를 전달하는 것이다. 이 메소드는 두 가지의 일을 한다. 클라이언트가 서버에 보내는 바이트를 만들어내고 서버에서 오는 바이트를 받아들인다. 바이트 교환은 GSS 콘텍스트가 확립될 때 까지 계속된다.

처음에 initSecContext() 메소드를 호출 할 때 전달할 바이트가 없다. 따라서 비어있는 byteToken 어레이에서 첫 번째 호출용 메소드에 전달한다. initSecContext() 메소드는 몇몇 바이트를 리턴하는데 이것은 같은 byteToken 어레이에 저장되었다. 그 다음 byteToken을 아웃풋 스트림에 작성하고 스트림을 플러시 하여 byteToken 어레이가 원격 서버로 보내지도록 한다.

원격 서버에 보내진 바이트에 대한 응답으로 원격 서버는 어떤 것을 보낼것으로 기대할 수 있다. 따라서 우리는 인풋 스트림에서 바이트를 읽고 같은 byteToken 어레이에 이 바이트를 저장하고 byteToken 어레이를 다시 initSecContext() 메소드에 보낸다. 이 메소드는 다시 바이트 어레이를 리턴한다. 이러한 바이트 교환은 while 루프 내부에서 보안 콘텍스트가 확립되고 peerContext.isEstablished() 메소드가 true를 리턴할 때 까지 지속된다.

보안 콘텍스트의 설치가 의미하는 것은 적절한 Kerberos 키들이 클라이언트와 서버 양측에서 사용가능한 상태가 된다는 것을 의미한다. 양측에서 이 키들을 사용하여 보안 통신에 쓴다. 보안 콘텍스트가 성립되면 GSSContext 객체를 리턴한다.

GSS 콘텍스트 사용하기
GSSClient 클래스의 main() 메소드에서 GSSContext 객체를 사용하는 방법을 살펴보겠다. login() 메소드를 호출한 후 login() 메소드가 리턴한 GSSContext 이 null인지를 확인한다. null이 아니라면 보안 콘텍스트가 원격 서버와의 보안 통신에 사용될 수 있다.

main() 메소드는 원격 서버가 기밀성과 메시지 무결성이라는 클라이언트 요청에 합당한지를 점검한다. 서버가 요청에 합당하면 GSSContext 클래스의 getConfState() 메소드는 true를 리턴한다.

main() 메소드는 원격 메소드로 보내는 데이터가 무엇이든 보낼 수 있다. sendMessage() 헬퍼 메소드를 작성하여 데이터를 서버에 보냈다. GSSContext 클래스의 wrap() 메소드는 데이터의 바이트 어레이를 받아들이고 바이트 어레이를 리턴한다. sendMessage() 메소드는 플레인 텍스트 데이터를 wrap() 메소드에 보내고 응답으로 암호화된 바이트 어레이를 받는다. 아웃풋 스트림 상에서 바이트 어레이를 작성하여 암호화된 바이트 어레이를 원격 서버로 보낼 수 있다.

sendMessage() 메소드는 서버에서 오는 인커밍 데이터를 리스닝한다. 서버에서 데이터를 받으면 인커밍 데이터를 GSSContext 클래스의 unwrap() 메소드에 보낼 수 있다. 이것은 평이한 텍스트 형식의 데이터를 리턴한다.

GSS 서버 애플리케이션
지금까지 GSS 클라이언트 애플리케이션이 작동 방법을 보았다. 이제 이것과 인터랙팅 할 서버를 구현해본다.

Listing 4는 GSSServer 클래스용 코드이다. GSSServer의 startServer() 메소드는 GSSClient 클래스의 login() 메소드를 설명하면서 거론되었던 것과 같은 기능을 수행한다.

GSSServer 클래스의 run() 메소드 내부에서 GSSManager와 GSSName 객체를 만들었다. 지금까지 클라이언트측 코드와 서버측 코드 사이에 차이점이 거의 없었다. 하지만 좀더 자세히 보면 서버는 단 하나의 GSSName 객체를 만든다는 것을 알 수 있다. 이것은 서버를 나타낸다. GSSName을 만든 후에 이 서버는 createCredential() 메소드를 호출하여 GSSCredential 객체에 credentials를 로딩한다.

다음 단계는 GSS 콘텍스트를 만들기 위해 createContext() 객체를 호출하는 것이다. createContext() 메소드 호출은 GSS 클라이언트 애플리케이션에서 이루어진 createContext() 호출과는 다르다. 지금의 createContext() 메소드는 단 하나의 매개변수의 서버의 credential을 갖는다. 이 서버측 콘텍스트가 양측 사이에 있지 않다는 것을 의미한다.

다음에는 통신용 인풋과 아웃풋 스트림을 만든다. 그런 다음 보안 콘텍스트가 설치될 때까지 계속 루핑 할 while 루프로 들어간다. 이 루프 안에서 요청 클라이언트를 기다려 연결 구축 요청을 보낸다. while 루프 내부의 인풋 스트림 상에서 데이터를 받으면 데이터를 바이트 어레이로 읽고 바이트 어레이 토큰을 GSSContext 클래스의 acceptSecContext() 메소드에 제공한다. acceptSecContext() 메소드는 데이터 바이트를 리턴한다. 이것은 아웃풋 스트림으로 되돌아간다.

GSSContext의 initSecContext()와 acceptSecContext() 메소드는 결합하여 작동한다. GSS 클라이언트 애플리케이션을 설명하면서 initSecContext() 메소드의 사용법을 설명했다. initSecContext() 메소드는 GSS 클라이언트가 GSS 서버 애플리케이션으로 보내는 초기 바이트를 만들어낸다. acceptSecContext() 메소드는 이러한 인커밍 바이트를 받아들이고 이것의 바이트 어레이를 만들어낸다. 이것을 클라이언트로 보낸다. 이러한 바이트 교환은 보안 GSS 콘텍스트가 구축될 때 까지 지속된다.

GSS는 모든 통신을 바이트 어레이 토큰으로서 핸들한다. 클라이언트에서 서버로 바이트 어레이를 나르기위해 어떤 유형의 전송 서비스를 사용할 수 있다. GSS는 데이터 전송에 사용되는 것에는 관심이 없다.

보안 세션의 구축 과정은 요청 클라이언트의 인증으로 끝을 맺는다. GSSContext 클래스의 getSrcName() 메소드를 호출하여 인증된 클라이언트의 GSSName을 보낼 수 있다. 반면 GSSContext 클래스의 getTargName() 메소드는 원격 클라이언트의 요청을 수락한 서버의 GSSName을 리턴한다.

while (!context.isEstablished()) 루프가 리턴한 후에(Listing 4) run() 메소드는 클라이언트로 부터 통신을 기다린다. 인커밍 데이터를 계속해서 리스닝하고 인커밍 바이트 스트링을 받게되면 GSSContext 클래스의 unwrap() 메소드를 통해 스트링을 보낸다. unwrap() 메소드는 클라이언트에서 온 평이한 텍스트 형식의 메시지를 리턴한다.

브라우저 속의 GSS
Listing 5는 애플릿이 Listing 1의 GSS 클라이언트를 사용하여 Listing 4의 GSS 서버와의 보안 통신을 구축하는 방법이 나와있다.

이 애플릿은 HTML 페이지에서 실행될 것이다. (Listing 6):

 <!-- E-Commerce Login.html --> <HTML> <HEAD> <TITLE>E-Commerce Login... </TITLE> </HEAD> <BODY> <p align="center"> <table bgcolor="Gray"> <tr> <td align="center"> <b>E-Commerce Site Login Page </b> </td> </tr> <tr> <td> <Applet CODE="GSSClientApplet.class" archive="GSSClientApplet.jar" name="GSSClientApplet" width="500" height="280"> </Applet> </td> </tr> </table> </p> </BODY> </HTML> 

이 애플릿이 e-커머스 웹 사이트의 메인 페이지에서 실행된다고 생각해보자. 그림 1은 실행 모습을 나타낸 것이다. 두 개의 텍스트 엔트리 필드, 버튼 세 개, 하나의 텍스트 영역이 있다. 세 개의 버튼 각각은 e-커머스 웹 사이트의 파트너의 서버측 구현에 상응한다.

그림 1. GSS 애플릿 사용

e-커머스 웹 사이트 고객은 어떤 사이트 파트너라도 인증받을 수 있다. 애플릿의 텍스트 필드에 유저네임과 패스워드를 입력하고 인증을 원하는 파트너 사이트에 해당하는 Login 버튼을 누른다. 이 버튼의 이벤트 핸들러는 GSSClient 구조체에 필요한 매개변수를 제공한다. 나머지 작업은 GSS 클라이언트가 할 일이고 이것은 이미 설명했다.

참고자료

• 소스코드 다운로드.
  
  
• RFC 1510.
  
  
• RFC 1508 & RFC 1964.
  
  
• GSS page: Sun Web site.
  
  
• KDC implementation: MIT.
  
  
• CSG group & Heimdal.
  
  
• "Enhance Java GSS-API with a login interface using JAAS" : Thomas Owusu (developerWorks, November 2001).
  
  
• "Java security, Part 2: Authentication and authorization" : Brad Rubin (developerWorks, July 2002).
  
  
• "A Kerberos primer: Bruce Rich, Anthony Nadalin, Theodore Shrader (developerWorks, November 2001).
  
  
• RFC 2025.
  
  
• developerWorks Java technology zone.
  

6.x --> weblogic.ant.taskdefs.ejb.DDInit
7.x, 8.x
EJB --> weblogic.marathon.ddInit.EJBInit
WEB --> weblogic.marathon.ddInit.WEBInit

아직 안해봤음.. ㅋㅋ

나도 ejb 결부해서 플젝 하고퍼~

 J2EE의 개론과 EJB개념, 구현시의 디자인패턴적용등에 대해 실사례를 들어

쉽게 풀어낸 자료입니다.

 J2EE 플랫폼이 제공하는 여러 제품, 표준 등을 살펴보고 그 곳에서 제시되는 아키텍처를 활용하는 것은 선택이 아닌 필수적 상황으로 점차 변하고 있습니다. EJB를 설명하기 전에 EJB를 포괄하는 전체적인 틀로서의 J2EE를 소개하고 있고,디자인 패턴의 중요성을 설명하고 있습니다.

 사실, 디자인 패턴이 또 다른 앤티패턴(Anti-pattern)이 될 수도 있습니다.

즉, XP(eXtreme Programming) 진영에서 지적하는 것처럼, 디자인 패턴이 최적화된 시스템을 만들기 보다는 막연한 확장 가능성을 위해 많은 시간을 투입하고, 소프트웨어의 복잡도만을 증가시키는 최악의 상황을 연출해 내는 걸림돌이 될 수도 있습니다.

그럼에도 불구하고 디자인 패턴의 중요성을 강조하는 것은, 단점이 있다 해도 나름대로 많은 장점을 갖고 있기 때문입니다. 이미 많은 숙련된 개발자들은, 다른 사람들과의 커뮤니케이션에 있어 패턴의 사용은 우월감의 표현이라기 보다는, 빠른 시간 내에 정확한 의사 전달을 하기 위한 수단으로 활용하고 있습니다. 즉, 방법론 내부의 객체/컴포넌트 모델링 단계에서 디자인 패턴의 표현은 소프트웨어 아키텍처의 보다 구체적인 이해와 명확한 커뮤니케이션을 위해 필수적인 요소가 되어가고 있습니다.

 신규개발자 또는 기존개발자라도 개념을 정리하기 위한 문서로 적당한 수준으로 생각됩니다.

<글의 목차>

       1. J2EE

1.1 시스템 아키텍트와 아키텍처..

1.2 J2EE 기반 아키텍처 정립..

1.3 J2EE Best Practices and Guidelines.

2. EJB(Enterprise JavaBeans)

2.1 EJB Framework.

2.2 Session Beans.

2.3 Entity Beans.

2.4 Transactions in EJB.

2.5 EJB Security.

3. Design Patterns in Application.

3.1 Factory Pattern.

3.2 Facade Pattern.

3.3 Singleton Pattern.

3.4 Reflection Pattern.

3.5 MVC Pattern.

3.6 Observer Pattern.

3.7 Mediator Pattern.

       4. 웹/컴포넌트 기반 소프트웨어 개발 방법론 정립에 관한 사족

개요

object생성을 위한 interface를 정의,해당 interface의 상속class의 FactoryMethodPattern(object를 생성후 반환하는 메소드)가 구체적인 object생성을 맡음.

생성할 object의 종류마다 상속class를 따로 만듦.

사용 

application-specific한 object정보를 분리하여 볼 수 있다. 생성처리 부분이 간단해 지고 새로운 종류의 object 생성기를 추가할 시 기존 생성처리클래스는 고치지 않고 상속하여 처리할 수 있다. 반드시 interface를 상속하여 구현해야 한다는 점이 있으므로, 상속해서 처리하는 게 좋다고 생각할 때 사용함

--------------------------------------------------------------------------------------

퍼옴...http://network.hanbitbook.co.kr/view_news.htm?serial=719

저자: 김대곤

Abstraction

필자는 패턴을 단순화(또는 추상화 Abstraction)시켜서 이해한다고 말했다. Gang of Four의 Design Patterns에는 "Consequences", "Implementation"라는 소제목들이 등장한다. 하지만 필자는 거의 읽어본 적이 없고, 관심도 없다. 그러므로 필자에게 패턴이라는 단어와 "Consequences"나 "Implementation"이라는 단어와 연관되지 않는다. 이렇듯이 관심사항이 아닌 것을 제거해버리는 것을 추상화(Abstraction)이라고 할 수 있다.

Factory Method 패턴이 Object가 생성되어야 하는 시점은 알고 있으나 어떤 Object가 생성되어야 하는지 알 수 없을 때, 객체의 생성을 Subclass에 위임하는 방식으로 문제를 해결할 수 있다고 말하고 있다. 첫 번째 질문은 왜 이런 상황에 직면하게 되었는가이다. 어떻게 이런 일이 발생할 수 있는가? 그것은 여러 종류의 객체를 추상화(Abstraction)시켜서 사용했기 때문이다.

게임의 예를 들어보자. 이 게임은 병사와 탱크를 가지고 전투를 하는 게임이고, 병사와 탱크를 만들기 위해서 병사를 만들어 내는 막사와 탱크를 만들어 내는 공장이 있어야 된다. 게임의 기능은 "생성", "공격", "이동"이 있다. 생성의 기능을 자세히 살펴보자. 게임상에 존재하는 어떤 물체를 선택하고 "생성" 버튼을 눌렀다고 가정하자. 먼저 선택한 물체가 생성이라는 기능을 가지고 있는 객체인지를 확인하고, 막사이면 병사를 공장이면 탱크를 만들어야 한다. 만약, 실제 객체(막사와 공장)을 사용하였다고 가정하자. 그런데 비행기를 만드는 새로운 공장이 생기면 생성 기능은 수정되어야 한다. 선택한 객체가 새로운 공장인지를 체크해야 하고, 새로운 공장이면 비행기를 만들어야 하기 때문이다. "생성"이라는 기능의 입장에서는 그게 막사인지, 공장인지, 아니면 새로운 공장인지는 관심의 대상이 아니다. "생성" 기능의 입장에선 오직 선택한 객체가 "생성"이라는 기능을 가지고 있는가만 알면 된다. 실제로는 존재하진 않지만 생성이라는 기능을 가진 것들을 Factory라는 개념으로 추상화하여 사용하면, 빈번한 수정과 High Coupling을 피할 수 있다. 객체의 종류에 따라 행동양식이 바뀌는 경우, 조건문을 사용하지 말고 다형성(Polymorphism)를 사용하라는 GRASP 패턴의 "Polymorphism" 원칙을 적용하여 Interface를 만들어서 생성 기능안에서는 Factory Interface만 사용하고 실제 객체들은 Factory Interface 타입의 변수 안에서 모두 숨겨진다. 새로운 공장이 만들 때 Factory Interface만 구현하면 "생성"버튼의 코드는 전혀 수정될 필요가 없다.

"생성" 기능 버튼을 사용자가 클릭하면, 객체를 생성해야 한다. 시점은 알지만 어떤 객체가 생성될 것인지는 선택되는 객체에 따라서 다르다. 그러면 당연히 Factory 객체는 객체의 생성을 담당하는 메소드(병사, 탱크, 비행기 등을 만들어야 함으로)를 가지고 있어야 한다. 이것이 Factory Method 패턴이 직면하는 상황인 것이다. 사실 이 문제는 객체의 생성 뿐 아니라 일반적인 행동(메소드)도 마찬가지이다. "이동" 기능에 대해서 생각해보라.

객체 생성을 (생성자가 아닌) 메소드를 통해서 하고자 하는 이유

실제 코드 예제를 보기 전에 객체를 생성자가 아닌 메소드를 통해서 생성하려고 하는 이유에 대해서 살펴보자. 메소드를 통해서 생성한다는 것은 Singleton 패턴에 나오는 Singleton 클래스 또는 Static 메소드를 통한 자기 자신 타입의 객체 생성이 아닌 경우에는 객체를 자기 자신의 메소드가 아닌 다른 객체의 메소드 안에서 생성한다는 의미이다. GRASP 패턴에 나오는 Creator 패턴에서 설명했듯이 이런 경우 컨텍스에서 제공받아야 하거나 제약사항들을 체크할 수 있다. 어떤 객체가 Interface를 구현한 객체의 경우, Interface를 쓴 이유는 실제 객체를 숨기기 위해서 한 작업인데, 생성자를 통해서 하면 실제 객체가 드러나 목표하는 효과를 볼 수 없게 되기 때문이다.

너무나 유명하고, 흔한 예제

필자가 아는 선배는 글을 쓰거나 프리젠테이션을 할 때는 항상 예제를 제공하는 것이 기본적인 예의이지 원칙이라고 했다. 설명을 하면 어려운 것도 예제를 보면 쉽게 이해가 되기 때문이겠지만 사실 이해하기 쉬운 예제를 제공하는 것은 쉬운 일이 아니다. Factory Method 패턴은 너무 유명하고 흔해서 검색엔진으로 검색하면 금방 찾을 수 있다. 솔직히 말하면, 필자도 이 예제를 그런 방식으로 구했다. 1분 전에.

import java.sql.*;                               

public class JDBCExample {
  private static String url    = "";
  private static String user   = "";
  private static String passwd = "";

  public static void main(String args[]) {
    try {
      Class.forName("oracle.jdbc.driver.OracleDriver");
      
      Connection connection = DriverManager.getConnection(url,user,passwd);
      Statement statement = connection.createStatement();
      ResultSet resultSet = statement.executeQuery("Select to_char(sysdate) from dual");

      while (resultSet.next())
      {
        System.out.println("It is " + resultSet.getString(1)); 
      }

      resultSet.close();
      statement.close();
      connection.close();           
    } catch (Exception e) {
    } finally {
    }
  }
}

몇 가지이 수정이 가해지지 않으면, 이 예제는 실행되지는 않을 것이다. 그러나 Factory Method 패턴을 사용한 클래스가 무려 2개나 된다. 그것도 연결해서 사용했다. Connection 객체는 createStatement() 메소드를 통해서 Statement 객체를 생성하고 Statement 객체는 executeQuery() 메소드를 통해서 ResultSet 객체를 생성하고 있다. Connection, Statement는 모두 Interface이다. 만약 실제 객체를 사용했다면 위의 코드는 다음과 비슷한 모습이 될 것이다.

public class OracleJDBC {
 
  private static String   url    = "";
  private static String   user   = "";
  private static String   passwd = "";

  public static void main(String args[]) {
    try {
      Class.forName("oracle.jdbc.driver.OracleDriver");
      
      OracleConnection connection  = new OracleConnection(url,user,passwd);
      OracleStatement  statement   = new OracleStatement();
      OracleResultSet  resultSet   = statement.executeQuery("Select to_char(sysdate) from dual");

      while (resultSet.next())
      {
        System.out.println("It is " + resultSet.getString(1)); 
      }

      resultSet.close();
      statement.close();
      connection.close();           
    } catch (Exception e) {
    } finally {
    }
  }
}

위 코드는 실행되거나 컴파일이 되거나 하지는 않는다. 실제 오라클을 사용할 경우 쓰이는 객체들이지만 이렇게 코딩하는 사람은 없다. 만약 오라클 안쓰면 다 고쳐야 되는데 누가 이렇게 쓰겠는가? 위의 작업을 하는 사람들에겐 실제 무슨 객체가 쓰이는가는 관심사항이 아니다. 단지 어느 곳에 저장되어 있는 데이터를 읽어서 가져오는 것이 주요 목표인 것이다. JDBC는 각 데이터베이스들을 추상화했지만 더 높은 추상화를 적용한 JDO(Java Data Object)도 있다. JDO는 Persistence에 대한 추상화를 시도하고 있다.

결어

그럼 추상화(Abstraction)를 어떻게 할 것인가? 이런 문제는 아무도 설명해 주지 않는다. 필자도 누구에게서 추상화의 원리나 관련된 강의를 받은 적이 없다. 필자가 항상 염두에 두는 생각이 있다면 "내가 필요로 하는 최소한의 것만 받아들이겠다"는 자세이다. 누가 나에게 무언가를 요청한다면 "네가 좀 알아서 해 주면 안돼?"라고 말하는 자세 말이다.(실제로 이렇게 살면 맞아 죽겠지만 말이다.) 그렇게 해서 남은 최소한 것을 Interface로 정의해서 사용하자.

필자가 쓰고 있는 패턴에 관한 기사도 Design Pattern를 설명한다기 보다는 Design Pattern이라는 주제에 대해 버리고 버려서 남은, 비슷해 보이지만 전혀 다른 내용이 아닐까 생각한다. 필자는 상속을 좋아하지 않는다. 그래서 SubClass, SuperClass와 같은 용어보다는 Interface라는 용어를 많이 사용한다. 그러나 상속에 대해서도 적용될 수 있음을 밝혀두는 바이다.

모델: 애플리케이션 객체

뷰 : 디스플레이하는 방법

컨트롤러 : 사용자 인터페이스가 사용자 입력에 반응하는 방법

* 데이터가 변경될때마다 모델은 자신과 관련된 뷰에 알려주고 이에 따라 뷰는 스스로 자신의 외형을 변경하여야 한다.

* MVC는 워크 플로우와 표현부로부터 비즈니스로직을 분리시키는 것이며 애플리케이션의 구조와 사용자에게 표현되어지는 정보로부터 모델을 분리시키는 것이 핵심임

- 모델 컴포넌트

  EJB를 사용하는 경우 빈에서 받은 value object지칭

- 뷰 컴포넌트 

  HTML, JSP등으로 구성된 표현부

- 컨트롤러 컴포넌트

  서블릿 또는 자바클래스 또는 빈으로 되어 있으며 비즈니스 오퍼레이션을 실행( 어플리케이션의 행위를 정의)

* EJB를 첨 사용했을 때 배치 스크립에 대하여 그리 크게 신경쓰지 않았다...간단한 stateless 세션빈으로만 작성했으니까..  그때 궁금했던 것중 하나가 다른 빈은 어떻게 참조할까였따...분명 될것 같은데....잘 안되고 그렇다고 차근차근 공부할 시간은 없었고....  생각나서 정리했따..

 첨부 파일은 배치스크립터에 대한 좀더 자세한 자료임

-----------------------------------------------------------------------------------------

배치디스크립터

배치디스크립터에 포함된 설정정보는

1. 구조정보

l 엔터프라이즈 빈 유형(Session, Entity, Message Driven Bean)

l 홈 인터페이스

l 리모트 인터페이스

l 엔터프라이즈 빈 클래스

구조 정보는 엔터프라이즈 빈 개발자가 설정합니다. 어플리케이션 어셈블러, 디플로이어는 구조 정보에 대한 사항 중에서 <display-name>,<ejb-name>을 변경할 수 있지만 다른 부분은 변경할 수 없습니다.

2. 실행정보

l 리소스 팩토리(Resource Factory)의 참조 정보

l 다른 빈의 참조 정보

l 트랜잭션 제어(Transaction Control)

트랜잭션 제어는 컨테이너 관리 트랜잭션(Container Managed Transaction)일 경우 각 메소드에 트랜잭션 속성(Transaction Attribute)을 설정하는 것을 말합니다. 배치 툴에서 실행 정보의 설정은 각각의 화면으로 구분됩니다. 배치 툴을 실행시켜 실행 정보 각각의 설정 화면을 지금 보는 것도 이해에 도움이 됩니다.

3. 보안정보

l 보안 식별 정보(Security Identity)

l 메소드 허용 정보(Method Permission)

l 리소스 등에 대한 접근 정보

엔터프라이즈 빈의 보안관련 정보를 설정하는 부분으로 배치 툴에서 하나의

화면으로 되어 있습니다.

그럼 실행 정보중

* 환경정보

: 배치 디스크립터 (Deployment Descriptor)의 이름(Name), 값(Value), 데이터 타입(Data Type)의 정보이다.

※ 변경 가능한 데이터에 대한 하드 코딩을 피하기 위한 EJB에서의 환경 정보(Environment Entry)는 배치 디스크립터에 설정되어 서버 배치 시 네이밍 서비스에 등록됩니다. 엔터프라이즈 빈 개발자는 빈에서 JNDI를 이용해 네이밍 서비스에 등록된 환경 정보를 얻어 이용합니다.

예)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

<ejb-jar> 

<display-name>LoanBean</display-name> 

<enterprise-beans>   

<session>     

<display-name>LoanEJB</display-name>     

<ejb-name>LoanEJB</ejb-name>     

<home>com.sds.ejb.ch5.LoanHome</home>     

<remote>com.sds.ejb.ch5.Loan</remote>     

<ejb-class>com.sds.ejb.ch5.LoanEJB</ejb-class>     

<session-type>Stateless</session-type>     

<transaction-type>Bean</transaction-type>     

<env-entry>       

<env-entry-name>loan/interest</env-entry-name>       

<env-entry-type>java.lang.Double</env-entry-type>       

<env-entry-value>0.067</env-entry-value>    

</env-entry>

<security-identity>       

<description></description>       

<use-caller-identity></use-caller-identity>     

</security-identity>   

</session> 

</enterprise-beans>

</ejb-jar>

 ※ 서비스호출과는 관계가 없이 배치스크립터에 이자율을 정의하는 부분이다. 배치 스크립터에서 loan/interest 로 기술된 부분을 찾아 정의된 타입과 값을 얻어 사용할수 있다. 

( 배치스크립터에 기술된 0.067을 리턴한다. ) 

u소스에서 활용

public double interestByYear(double amount) 

{                        

. . .                   

                                   ctx = new InitialContext();                             

                           String codedName = "java:comp/env/loan/interest";

                           Double interest = (Double)ctx.lookup(codedName);

                           if(interest==null)                                           

                                        throw new EJBException("Check the env-entry. - "+codedName);

                                        return amount*interest.doubleValue();                         

}           

OR

public double interestByMonth(double amount)            

{                         . . .

Context ctx = new InitialContext();                                   

Context envCtx = (Context)ctx.lookup("java:comp/env");                              

Double interest = (Double)envCtx.lookup("loan/interest");

if(interest==null){                                              

                                   throw new EJBException("Check the env-entry. "+

                                             "- java:comp/env/loan/interest");                               

}                                                        

return amount*interest.doubleValue()/12.0;                       

. . .

}

*

* EJB 리소스 팩토리

엔터프라이즈 빈은 서버에서 제공하는 여러 리소스 즉, JDBC 커넥션, JMS 커넥션 등을 이용하는 경우가 있습니다. 리소스 팩토리는 서버가 시작할 때 서버 네이밍 서비스에 등록되기 때문에 엔터프라이즈 빈 개발자는 JNDI 프로그래밍 방법으로 서버에서 제공하는 리소스 팩토리를 사용합니다. 이런 리소스 팩토리에 대한 참조 정보도 서버 설정에 의해 변경되는 정보들인데 리소스 팩토리 참조 정보를 엔터프라이즈 빈 클래스에 직접적으로 하드 코딩하는 것은 좋지 못한 방법이라 할 수 있습니다.

※ 엔터프라이즈 빈이 리소스 팩토리를 참조한다는 정보를 배치 디스크립터에 <resource- ref> 태그를 이용해 설정함

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

 . . . . .

<security-identity>       

<description></description>       

<use-caller-identity></use-caller-identity>     

</security-identity>     

<resource-ref>       

<res-ref-name>jdbc/empDB</res-ref-name>       

<res-type>javax.sql.DataSource</res-type>       

<res-auth>Container</res-auth>       

<res-sharing-scope>Shareable</res-sharing-scope>     

</resource-ref>   

</session> 

</enterprise-beans> 

<assembly-descriptor>   

 . . .

u소스에서 활용

                  Context ctx = new InitialContext();

             ds = (DataSource)ctx.lookup("java:comp/env/jdbc/EmpDB");

             con = ds.getConnection();

( 배치디스크립터에 기술된 데이터소스 클래스 인스턴스를 리턴하겠지... )

다른 EJB 빈 참조

² 세션 빈은 비즈니스 로직을 처리하는 컴포넌트이고, 엔티티 빈은 비즈니스 데이터를 표현하는 컴포넌트임

² 하나의 세션 빈에서 여러 개의 엔티티 빈 컴포넌트를 참조하는 경우도 있고, 세션빈에서 다른 데이터베이스에 접근할 수도 있음

² 세션 빈에서 엔티티 빈을 참조하는 경우가 다른 빈을 참조하는 일반적인 예임

l 리소스 팩토리를 참조하는 경우와 동일하게 처리함 

l EJB 클라이언트 프로그램과 동일한 방법으로 해당 빈을 사용함 (엔터프라이즈 빈 개발자가 참조 빈의 JNDI 이름을 알 수가 없음)

l 빈 개발자는 임의의 이름("Coded Name")으로 참조 빈의 Home Object를 네이밍 서비스에 룩업(Lookup) 함

l 엔터프라이즈 빈이 다른 빈을 참조하고 있다는 것을 배치 디스크립터에 설정함

l 엔터프라이즈 빈은 디플로이어가 서버에 배치 시에 코딩 된 이름과 실제 JNDI 이름을

l 연결하여 설정함

. . .

<ejb-ref>

<ejb-ref-name>ejb/CabinHome</ejb-ref-name>

<ejb-ref-name>Entity</ejb-ref-type>

<home>com.titan.cabin.CabinHome</home>

<remote>com.titan.cabin.Cabin</remote>

</ejb-ref>

. . .

u소스에서 활용

InitialContext jndiContext = new InitialContext();

Object ref = jndiContext.lookup("java:comp/env/ejb/CabinHome") ;

CabinHome home = (CabinHome)

PortableRemoteObject.narrow(ref, CabinHome.class);