어제도 이벤트 디스패치 스레드 구현 코드를 보던중.. 망할 시큐리티 매니저..   내 app의 입장을 넘어
jvm(여러 자바기반 app의 관리자 객체)의 입장에서 생각해 보았다.


내 app에서  클래스에 static을 사용한다는 의미, 클래스의 인스턴스(물론 refelct 관점에서 보면 클래스도 인스턴스(static

영역에 생성되는 object.. Class.forName("xxx.xx.a").newInstance)지만..논외) 를 static으로 접근하게 제공한다는것..

음.. 이해가 부족해 표현이 쉽지 않은데..

public class 계좌  //내 app의 모든 .class 파일에서 전역적으로 사용하기 위해 public 키워드
{
    public static 계좌 instance = new 계좌();
    public void 출금(){}
}

계좌클래스의 인스턴스는 어디에서건 계좌.instance로 "전역적=공유적"으로 접근및 계좌.instance.work() 서비스를 사용할수 
있다.(물론 패키지 선언및 다른 .class 파일에서 접근할땐 import를 하던지.. 아니면 패키지명.클래스명으로 사용하던지)

import 패키지.A;
public class 장호
{
   void 출금()
   {
       계좌.instance.출금();
    }
}


import 패키지.B;
public class 가짜장호
{
   void 출금()
   {
        계좌.instance.출금();
    }
}

물론 일반적으로 로그인 처리단계 -> 로그인 정보에 따라 서버단에서 db에 조회해서 dao를 통해 사용자의 
계좌 객체를 얻고 그것을 "서버단의 계좌 매니저" 객체에 보관하며, 로그인 결과에 따라 "검증하는 작업후" 인증된 사용자에 
대해 설정된 권만 만큼의 계좌 정보를 보여주고-> 사용자의 비지니스 로직(입금,출금,조회) 선택에 따라 다시 서버단에서 트랜
잭션및 예외등을 컨트롤해 가면서 dao를 통해 db단에 쿼리를 전달하고 -> 결과를 받아 사용자에게 피드백을 할것이다.
(뭐랄까.. 예전에 쇼핑몰 로그인 처리 구현했을때.. 19세 이상, 회원, 비회원 등으로 인증및 권한 설정을 통해 분기를 나누고 사용
자에 대한 view를 다르게 했던 것처럼..)

즉.. 장호의 계좌에 대해선 여러가지 비지니스 로직용 클래스의 객체가 공유할수 있지만.. 
장호의 계좌에 대해 "인가되지 않은 가짜장호가 접근"을 해서는 안될것이다.

아직 개념이 제대로 안섰는데.. 이걸 jvm과 여러 app 의 관계로 생각해보면
jvm은 서버의 입장, app는 클라이언트의 입장이 될것이다.
즉 jvm으로선 여러개의 app(app자체도 스레드를 여러개 사용가능)를 관리하게 되고.. 각각의 app는 서로에 대해 
"데이터에 대해 독립성 = heap 메모리, class 인스턴스라면 static 메모리 + 코드의 독립성 = stack 메모리"이 보장되어야 할 
것이다.

보안 개념(인증및 권한설정)을 좀 더 상위단에서 관리하기 위해.. 각 appcontext라는 걸 만들었고.. 각각을 컨테이너에
구성 요소로 관리함으로서 독립성을 보장할 것이다. (물론 이래야.. 여러 app들에 대해 시분할 처리가 될것이고..)
app라는건 jsp에 비유하면.. session의 개념이고 app내에서 발생하는 여러 이벤트(입,출력등 각종 처리)은 request의 개념일 
것이다.(정신이 점점 안드로메다로...OTL)

아직 시큐리티 매니저, appcontext, app의 eventQueue, 전체 시스템(os(jvm포함))의 eventQueue 에 대한 이해가
거의 없다. 또 한번 뜬구름을 잡는구나 ㅠㅠ


JNDI


JDBC와 JNDI

***** 
생각난 김에 예전에 보안문서중 자바 관련파트 확인 1회, java.security패키지와 관련 패키지 한번 더 체크


by givingsheart 2014. 1. 2. 09:30