Tornado 의 블로그

  제목 클릭 후 Play 버튼을 눌러주세요~

   소년/소녀 

   동물

    여행/탐험

   로보트/기사

   요정/초능력

                      모처럼 좋은 그림 감상하닌깐 참..좋네여 ^^

저 원래 잘 안 웃거든요.

이거 보고 웃었어요. ㅋㅋ~

강남스타일 까페에는 더 많은 유머가 있어요. ^^

Commons BeanUtil 에는 참 유용한게 많다..

그중 RowSet 과 비스무리(?) 한 것이 하나 있는데..

바로 RowSetDynaClass 이다...

일반적 JDBC 프로그래밍에서는 아래와 같은 순서를 가진다.

pstmt = t.prepareStatemet(query);

pstmt.setXXX(....);

rs = pstmt.executeQuery();

while(rs.next()){

 ... 작업들.....

}

rs.close();

이런 구조를 가지고 가게 되며, 커넥션이 닫히기 전에 resultSet 을 순차적으로 내려가면서 작업을 한다.

Commons BeanUtils 안에는 RowSetDynaClass 라는 클래스가 있다.

이 클래스는 JDBC 연결이 끊어진 이후에도 사용가능한 CachedRowSet 과 비슷한 기능을 제공해준다.

이것의 사용법은 상당히 간단하다. 참조 코드는 다음과 같다.

   pstmt = t.prepareStatement(query);
   rs = pstmt.executeQuery();
   rsdc = new RowSetDynaClass(rs);
   
   rs.close();

....

finally{   ... conn.close(); }

요기까지가 끝이다.. 이후에는 rsdc 라는 녀석을 이용해서 데이터를 취득하면 된다.

이렇게 데이터를 가져오게 되면

rsdc 에서는 getRows() 메소드를 이용하여 List 객체를 취득할 수 있다.

List arr = rsdc.getRows();

또한 검색해 온 컬럼의 이름들을 Property 로 얻을 수도 있다.

 DynaProperty[] dynas = rsdc.getDynaProperties();
  
 for(int i = 0; i < dynas.length; i++){
  System.out.println(dynas[i].getName());
 }

DynaProperty 클래스는 일반적인 Property 개념으로 보면 된다.

또한 이렇게 얻어온 DynaProperty 배열객체를 이용하여 RowSetDynaClass 를 순환하며 내용을 참조할 수 있다.

List 형태로 반납된 rows 들을 순환하게 되면 DynaBean 이라는 객체를 반납하게 된다.

이 형태를 이용하여 rs.next() 작업과 동일한 결과를 얻을 수 있다.

 Iterator iter = arr.iterator();
 
 while(iter.hasNext()){
  DynaBean bean = (DynaBean)iter.next();
  
  for(int i = 0; i < dynas.length; i++){
   System.out.println(bean.get(dynas[i].getName()));
  } 
 }

사용하다 주의할 것은 테이블 컬럼명이 regiDate 와 같이 중간에 대문자가 끼어있을 경우이다

이렇게 중간에 대문자가 끼어있는 것들은 RowSetDynaClass 를 생성하는 과정에서

전부 소문자로 바뀌게 된다.

SQL 상에서는 대소문자를 가리지 않지만 객체에서 값을 얻어올때는 가린다는것에 주의!!!

그렇기 때문에 bean.get("regidate") 와 같이 프라퍼티를 전부 소문자로 적어야

제대로 출력될 것이다.

DAO Layer 측에서 해야할 일들이 DAO를 이용하는 Layer 에 종속적인 작업이 진행될 경우

RowSetDynaClass 를 이용하여 Action 측에서 사용하면 각 레이어의 할일이 조금더 분명해 질수 있다.

Apache 와 톰캣을 연동 했을경우에 골때리는 문제가 하나 생긴다.

아파치에서는 Domain 별 디렉토리를 가상호스트로 지정하여 사용하여야 하는데 주소는 다음과 같다.

http://aaa.com

이 주소에 대하여 DocumentRoot 를 지정할 경우 아래와 같이 특정 디렉토리를 명시하게 된다.

DocumentRoot /usr/local/tomcat4/webapps/ROOT

만약 가상호스트로 설정되어있다면

<VirtualHost ....>

   DocumentRoot /usr/local/.......

   .....

</VirtualHost>

또한 aaa.com/test/images 라고 요청 할 경우 디렉토리는 당연히

/usr/local/tomcat4/webapps/ROOT/test/images 와 같은 형태로 요청하게 된다.

문제는 test 라는 디렉토리가 하나의 컨텍스트 였을 경우 발생하게 된다.

톰캣에서 하나의 웹 애플리케이션의 구성은 webapps/ 를 기준으로 /ROOT  , /examples 등이 있게 된다.

이것은 하나의 가상호스트처럼 동작하게 되지만 Apache 에서 볼때는 하나의 디렉토리로 인식하게 되는 것 같다.

즉 이 얘기는 http://aaa.com:8080/test 라고 요청할 경우 test 라는 하나의 컨텍스트로 인식하여

test 웹 애플리케이션을 호출해 주겠지만 아파치와 연동 되었을 경우에는

/test 를 단지 ROOT 애플리케이션의 서브디렉토리로 인식하게 된다는 것이다.

아파치에서 톰캣으로 요청을 넘길때 /test/*.jsp  ... /test/*.do 와 같이 넘기게 되면

톰캣에서는 test 라는 하나의 컨텍스트 차원에서 처리를 하지만 아파치에서는 .jsp 와 .do 를 제외한 모든 자원을 test 라는 디렉토리로 보고 처리를 한다는 것이다.

이때는 이 컨텍스트를 하나의 도메인으로 빼는게 맞는것 같고...

네임서버에서 test.aaa.com 과 같은 형태로 주던지... bbb.com 이라는 완전한 도메인을 빼던지

해주고... Apache 에서 DocumentRoot 를 따로 지정해 주는게 바른 방향 같다.

글쓰다가 회의해서리.. 뭔소린지.. 꼬이네.. 캬캬캬

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가 어떤 역할을 하는지 파악해야 한다.

자전거 VS 오토바이

-

저 때가 좋았지.. 오토바이타고.. 시원하게 국도를 달릴때ㅋ '-'

아 글쎄 저사람이 자전거를 갖고와서 나보고 내기를 하제;;;

ㅎ 결국 졌지만 ㅠ

-

정말 놀랍지 않습니까

여러가지 법칙을 무시한 주행이지만..ㅎ

Hexadecimal Color Wheel

출처:

http://javascript.internet.com/page-details/hexadecimal-color-wheel.html

struts taglib 사용 --- html 태그

html 태그중에서 link 를 걸어야 할 경우가 생기게 되는데 ,
보통 struts 프로그램을 짜다보면 Controller 에서 Model 측을 접근하여
데이터를 가져온 후 해당 데이터를 Java Beans 스타일(또는 Collections) 에
저장하고, 그 객체들을 request 에 담아서 forward 시키게 된다.

jsp 페이지에서는 이러한 객체를 <html:iterate /> 태그와 같은 것들을 이용해서 사용하게 되는데
request 에 저장되어 있는 객체를 ?a=beanValue&b=beanValue 와 같이 사용할
경우에는 아래와 같은 방법으로 이용한다.

BoardConfigBean <-- Action 부분에서 Model 측에 접근하여 Wrapping 한
                              사용자 정의 객체이다.

request.setAttribute("BoardConfigBean", new BoardConfigBean().setIdx(1)); 처럼 저장하겠죠.

이렇게 저장된 객체를 JSP 에서는 아래와 같이 불러다가 씁니다.

<html:link page="/siteMgr/BoardConfig.do?method=delete"
                paramProperty="idx"
                paramId="idx"
                paramName="BoardConfigBean"
                scope="request">삭제</html:link>

html:link 속성 중에 paramName 이라는 속성은 특정 속성에 지정된 객체를
이름으로 지정한다.

paramId 속성은 쿼리스트링 중 key 부분에 해당한다.
paramProperty 속성은 쿼리스트링 중 value 부분에 해당하며
request 와 같은 속성에 저장된 객체의 getter 부분에 해당한다.

html:link 태그에는 map 속성을 이용할 수 있으며
Map 에 담고 그 형태를 html:link 에 넣어줄 경우 자동으로 링크를 만들어 주기도 한다.

편리한거는 자동으로 ?key=value&key1=value1 과 같이 해준다.

자세한 거는 struts 사이트를 뒤져주세용...  또 너무 남용하지 마세용

별건 아니지만.. 자칫 실수하면 짜증나는 문제이기에.. 적어놔야징..

# Struts 에서 Message Resource 를 여러개 설정해야할 경우 방법

조건)

          titleResource.properties   <-- 브라우저의 타이틀 메세지 관리

          adminResource.properties  <-- 관리 페이지의 각종 메세지 관리

          ..... 등등등

이렇게 두개가 있을 경우 먼저 web.xml 파일에 ActionServlet 등록 태그에 아래와 같이 메세지 리소스를 추가.

(web.xml)

 <!-- Struts ActionServlet -->
 <servlet>
  <servlet-name>action</servlet-name>
  <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> 
  
  <init-param>
   <param-name>adminResource</param-name>
   <param-value>conf.adminResource</param-value>
  </init-param>
  
  <init-param>
   <param-name>titleResource</param-name>
   <param-value>conf.titleResource</param-value>
  </init-param>

... 기타 설정들

(strtus-config.xml)

 <message-resources parameter="conf.adminResource" />
 <message-resources parameter="conf.titleResource" />

설정하고

<bean:message key="main.title.index" />

... 기타 필요한 메세지들.... 뿌리면 잘 되더만..

자세한 사항은 struts 사이트에서 참고바람