3. Session Bean component contract

    이번장은 세션빈과 컨테이너 사이의 계약을 설명한다.
    그것은 세션빈의 생명주기를 결정한다.

    3.1 A container's management of its working set

        컨테이너는 idle 상태의 세션빈을 임의의 secondary storage 으로의 passivation 및
        반대로 activation(작업이 필요할때 메모리로 올린다) 을 관리한다.

        passivation 은 빈이 트랜잭션내에 있지 않을때에만 가능하다

        세션빈은 다음과 같이 두가지로 구분된다.

            - STATELESS : the Bean contains no conversational state between methods;
                                  any Bean instance can be used for any client.
            - STATEFUL : the Bean contains conversational state which must be retained
                                across methods and transactions.

    3.2 Conversational state

        A STATEFUL session Bean's conversational state 라는것은 직렬화 가능한 field value
        를 의미한다.

        conversational state 는 직렬화될때 open files, open sockets, open database cursors
        등의 열려있는 자원을 포함할수 있으며 세션빈이 passivate 한 동안에는 컨테이너가
        이들 자원을 다시 획득할 수 없다.
        이와같은 빈 개발자들은 ejbPassivate(), ejbActivate() 를 이용하여 이런자원들을
        열거나 닫아야 한다.

    3.3 Instance passivation and conversational state

        컨테이너는 인스턴스상의 ejbPassivate() 메소드가 호출될 경우 그 인스턴스의
        상태를 저장한다.
        빈개발자는 필드가 직렬화 가능하도록 하여야 하며(즉, transient 로 선언하지 말아야함)
        ejbPassivate() 호출이후 직렬화되지 않은 인스턴스들은 컨테이너에 의해 파괴된다.
        Sun 에서는 enterprise Bean's fields 를 "transient" 로 선언하지 않도록 추천한다.

    3.4 The effect of transaction rollback on conversational state

        A session Bean's conversational state is not transactional.
        이것은 세션빈의 rollback 이 컨테이너에 의해 자동적으로 이루어지지 않는다는 말이다.
        따라서 빈개발자는 afterCompletion() 메소드를 호출해서 이를 구현해야한다.

    3.5 The protocol between a session Bean and its container

        3.5.1 The required SessionBean interface

            모드세션빈은 SessionBean interface 를 구현해야만 한다.
            setSessionContext() 메소드는 세션빈 인스턴스와 관련된 context 를 유지하는
            컨테이너에 의해서 호출된다.
            일발적으로 세션빈은 session context 를 conversational state 의 일부분으로서
            재획득한다.

        3.5.2 The SessionContext interface

            모든 컨테이너는 SessionContext 와 함께 그들의 빈 인스턴스를 제공한다.
            이것은 Bean instance 들이 컨테이너에 의해 유지되는 그들의 context 를
            접근할수 있도록 한다.

            SessionContext 는 다음과 같은 메소드를 정의한다.

                - The getEJBObject method returns the EJB object for the instance.

                - The getHome method returns the home interface for the instance's EJB class.

                - The getEnvironment method returns the environment properties list that the
                   Bean was deployed with.

                - The getCallerIdentity method returns the identity of the current invoker of the
                   Bean instance's EJB object.

                - The isCallerInRole predicate tests if the Bean caller has a particular role.

                - The setRollbackOnly method allows the instance to mark the current transaction
                  such that the only outcome of the transaction is a rollback.

                - The getRollbackOnly method allows the instance to test if the current
                   transaction has been marked for rollback.

                - The getUserTransaction method returns the javax.jts.UserTransaction
                   interface that the Bean can use for explicit transaction demarcation .
                   (컨테이너는 빈즈가 TX_BEAN_MANAGED 트랜젝션 속성을 가질때만
                    UserTransaction 인터페이스를 사용가능하도록 한다. )

        3.5.3 The optional SessionSynchronization interface

            세션빈은 추가적으로 javax.ejb.SessionSynchronization 인터페이스를
            구현할수 있다.
            이 인터페이스는 빈이 데이터베이스, 트랜잭션내에 저장된 데이타를 다룰때
           트랜잭션 동기화 호출을 가능하도록 한다.

            afterBegin() 메소드는 세션인스턴스에게 새로운 트랜잭션이 시작되었다는 것을
            알리며 이시점에서 인스턴스는 이미 트랜잭션내에 있으며, 트랜잭션의 범위
            안에서 요구되어진 작업을 수행할 수 있다.

            beforeCompletion() 메소드는 새션빈의 클라이언트가 자신의 현재 트랜잭션하에서
            작업을 마쳤지만, instance's resources 들은 아직 commit 하지 않은상태일때
            호출된다.
            인스턴스가 데이타베이스를 갱신하는 시점에서 세션 컨텍스트상의 setRollbackOnly()
            를 호출함으로써 rollback 트랜잭션을 수행할 수 있다.

            afterCompletion(boolean committed) 메소드는 현재 트랜잭션이 완료 되었다는
            것을 의미하며 true 는 commit, false 는 rollback 이 발생했음을 의미한다.

        3.5.4 Business method delegation

            enterprise Bean's remote interface 내에 정의된 비즈니스 메소드는 클라이언트에
            의해 호출된다.
            enterprise Bean's remote interface 는 컨테이너 툴에 의해 생성된 EJB object class
            에 의해 실행되며 EJB object class 는 이 비즈니스 메소드 호출의 실행을
            enterprise Bean class 클래스에 위임한다.

        3.5.5 Session Bean's ejbCreate(...) methods

            클라이언트는 Bean's home interface 내에 정의된 create() 메소드중의 하나를 호출해
            세션빈의 인스턴스를 생성한다.
            홈 인터페이스는 빈 개발자가 제공해야 하고 그것의 실행은 컨테이너가 담당한다.

            -컨테이너가 세션빈의 인스턴스를 생성하는 3단계

                 (우선 클라이언트가 create() 메소드를 호출한다. )

                1) 컨테이너는 빈 클래스의 인스턴스를 생성하기 위해 newInstance() 메소드를
                  호출한다.

                2)  컨테이너는 인스턴스에 context 객체를 전달하기 위해 setSessionContext()
                    메소드를 호출한다.

                3) 컨테이너는 클라이언트에서 호출된 create() 메소드와 시그네처가 동일한
                    ejbCreate() 메소드를 호출한다.
                    (클라이언트가 보낸 create() 메소드의 전달인자는 ejbCreate() 메소드로
                     전달된다.)

                이제는 Method Ready 상태이다.

        3.5.6 Transaction context of session Bean methods

            session Beans 의 afterBegin(), beforeCompletion() 메소드는 고유의 transaction
            context 와 함께 호출되고 (if the Bean is transactional), afterCompletion(),
            newInstance(), setSessionContext(), ejbCreate(), ejbRemove(), ejbPassivate(),
            finalize(), ejbActivate()  메소드는 항상 transaction 없이 호출된다.

            따라서, session Beans 의  ejbCreate() or ejbRemove() 메소드에서 데이터베이스를
            갱신하는것은 좋은방법이 아니다.

            세션빈즈의 비즈니스로직 메소드가 트랜잭션 내에서 호출되는지 여부는
            deployment descriptor 에 의해 결정된다

    3.6 STATEFUL session Bean state diagram
 
 
 
 

        - 세션빈의 생명은 클라이언트가 create() 를 호출함으로써 시작된다
          그리고 나면 컨테이너는 enterprise Bean 의 새로운 객체를 메모리에 할당하기
          위해 newInstance() 메소드를 호출한다.
          이후 컨테이너는 setSessionContext() 호출하고 이어서 인스턴스상의
          ejbCreate() 메소드를 호출함으로써 EJB object reference 를 클라이언트로
          리턴한다.
          이렇게 생성된 인스턴스는 이제 method ready 상태이다.

        - 클라이언트가 passivated session Bean instanc 를 호출하면 컨테이너는
           인스턴스를 활성화 시킬것이다.
          세션 인스턴스의 활성화를 위해 컨테이너는 secondary storage 로부터
          인스턴스의 state 를 메모리에 로드하고 ejbActivate() 를 호출한다.
          이제 세션인스턴스는 클라이언트의 호출을 위해 다시 준비상태에 있다.

        - 클라이언트가 EJB object 상의 remove() 를 호출하면 컨테이너는 Bean instance
          의 ejbRemove() 를 호출한다. 이때 세션빈 인스턴스는 생명을 다하게 된다.
          클라이언트가 생명을 다한 인스턴스를 호출하면 java.rmi.NoSuchObjectException
          을 발생한다.

        - 세션 인스턴스가 트랜잭션내에 있을때에는 remove() 메소드를 호출할수가 없다.
           만약 이를 어길경우 javax.ejb.RemoveException 을 발생할것이다.

        3.6.1 transactions 제한사항

            - 세션빈 인스턴스는 한번에 한 트랜잭션하에만 관여할수 있다.

            - 세션빈 인스턴스가 트랜잭션 내에 관여하는 동안 클라이언트가 세션빈의
               비즈니스 메소드를 호출할때 transaction context 존재하지 않거나 다르다면
               java.rmi.RemoteException 이 발생한다.
               마찬가지로 세션빈이 트랜잭션내에 있을대는 remove() 메소드를 호출할수 없으며
               호출할경우 javax.ejb.RemoveException이 발생한다.

            - 세션빈에서 rollback 이 발생할 경우 컨테이너가 할수 있는일은 없다.
               데이타를 이전상태로 초기화 하는등의 모든 복구는 클라이언트가 제공해야 한다.

    3.7 Sequence diagrams for a STATEFUL session Bean

        3.7.1 Note

            - 아래 도표에서 "container provided classes" 는 컨테이너 혹은 컨테이너 툴에 의해
              생성된 클래스를 의미한다.

        3.7.2 세션객체의 생성
 
 
 
 

        3.7.3 Starting a transaction
 
 
 
 

        3.7.4 Committing a transaction
 
 
 
 

        3.7.5 Passivating and activating an instance between transactions

            일반적으로 Passivation 은 컨테이너의 필요에 의해 자발적으로 발생하며,
            Activation 은 클라이언트가 메소드를 호출할때 발생한다.
 
 
 
 

        3.7.6 Removing a session object
 
 
 
 

    3.8 Stateless session Beans

        Stateless session Beans 은  conversational state 를 가지지 않는 세션빈 이다.

        stateless session Bean 의 홈인터페이스는 전달인자를 가지지 않는 단 하나의 create()
        메소드만을 정의해야하고 리턴값은 세션빈은 리모트 인터페이스이다.
        이는 session enterprise Bean class 에도 전달인자없는 ejbCreate() 메소드 하나만
        존재한다는 것이다.

        stateless session Bean 들은 모두 동일하며 컨테이너는 클라이언트로부터의 요구를
        수행하기 위해 사용가능한 적당한 세션빈을 선택할수 있다.

        또한 Passivation 은 Stateless session Beans 를 위해서는 필요없다.

        stateless session Beans 는 컨테이너의 실행에 의존하기 때문에 stateful session beans
        보다 자원을 적게 차지한다.
        하지만 이런 이점은 stateless bean 을 사용하는 클라이언트의 복잡도가 증가함에 따라
        감소될수 있다.

        클라이언트는 stateful session Bean 과 같은방법으로 create(), remove() 메소드를
        사용한다.

        클라이언트와 stateless session Bean 사이에는 특별한 매핑이 존재하지 않으며
        컨테이너는 단지 클라이언트로부터의 호출을 method-ready 상태에 있는 임의의
        세션빈에게 위임할 뿐이다.

        3.8.1 Stateless session Bean state diagram
 
 
 
 

            - stateless session Bean 의 삶은 컨테이너가 새로운 메모리 객체를
              생성하기위해 newInstance() 메소드를 호출함으로써 시작된다.
              다음으로 setSessionContext() 를 호출하고 이어서 ejbCreate() 를 호출한다.

              컨테이너는 클라이언트의 create() 호출과 관계없이 언제든지 인스턴스를
              생성할 수 있다.
              이제 빈 인스턴스는 클라이언트로부터의 메소드호출을 위임받을수 있는
              준비를 갖춘 것이다.

            - 컨테이너는 인스턴스가 더이상 필요없을때(주로 method-ready pool 내의
               인스턴스의 수를 줄이고자 할때...) ejbRemove() 를 호출하여
              stateless session Bean instance 의 생을 마감시킨다.

    3.9 Sequence diagrams for a STATELESS session Bean

        3.9.1 Client-invoked create()
 
 
 

        3.9.2 Business method invocation
 
 
 
 

        3.9.3 Client-invoked remove()
 
 
 
 

        3.9.4 Adding instance to the pool
 
 
 
 

        3.9.5 Remove instance from the pool
 
 
 
 

    3.10 EnterPrise Bean provider를 위한 요구사항.

        다음은 session enterprise Bean 제공자가 책임져야할 것들이다.

        3.10.1 Classes and interfaces

            enterprise Bean provider 는 다음 세가지 클래스 파일을 제공해야한다.

           - Enterprise Bean class.

           - Enterprise Bean's remote interface.

           - Enterprise Bean's home interface.
 

        3.10.2 Session Enterprise Bean class 를 위한 요구사항

           - 클래스는 javax.ejb.SessionBean interface 를 구현해야만 한다.

           - 클래스는 public 이어야하고 abstract 이 아니어야 한다.

           - enterprise bean class 는 method 전달인자나 리턴값으로
             부주의하게 this 를 전달하는것을 막기위해
             enterprise Bean's remote interface 를 구현하지 않는다.
             (추천사항..)

           - 클래스는 business methods 와  ejbCreate() method 를
             구현해야만 한다.

           - 클래스는 선택적으로 javax.ejb.SessionSynchronization interface를
             구현할수 있다.
 

        3.10.3 ejbCreate() methods

            enterprise Bean class 는 다음에 나오는 규칙을 준수하는 sigatures를 가지는
            하나이상의 ejbCreate() 메소드를 구현해야한다.

            - The method name must be ejbCreate.

            - The method must be declared as public.

            - The return type must be void.

            - The methods arguments must be legal types for Java RMI.

            - The throws clause may define arbitrary application specific exceptions.

            - The throws clause may include java.rmi.RemoteException.

            - The throws clause may include javax.ejb.CreateException.
 

        3.10.4 Business methods

            class 는 다음에 나오는 규칙을 준수하는 sigatures를 가지는
            0개 이상의 Business methods 메소드를 구현할수 있다.

            - EJB architecture 에 이미 정의된 메소드(ejbCreate, ejbActivate, etc.)
              를 제외한 어떠한 이름을 가져도 된다.

            - business method 는 public 으로 선언되어야 한다.

            - The methods arguments and return value types must be legal types for Java RMI.

            - The throws clause may define arbitrary application specific exceptions.

            - The throws clause may include java.rmi.RemoteException.
 

        3.10.5 Enterprise Bean's remote interface

            - 반드시 javax.ejb.EJBObject interface 를 상속해야 한다.

            - 반드시 public 으로 선언되어야 한다.

            - 이 인터페이스에 정의된 메소드들은 RMI 규칙을따라야만 한다.
              이것은 리턴값이나 전달인자가 RMI 에서 유용한 타입이어야 하고,
              java.rmi.RemoteException 을 발생할수 있어야 한다.

            - remote interface 에 정의된 메소드는 enterprise Bean's class 에 정의된 메소드와
              메소드이름, 전달인자 타입 / 갯수, 리턴타입이 같아야 하고,
              enterprise Bean class 의 일치하는 메소드의 throws 절 속의 모든 예외은
              remote interface 의 메소드의 throws 절로 반드시 정의되어야 한다.
 

        3.10.6 Enterprise Bean's home interface

            - javax.ejb.EJBHome interface 를 상속해야만 한다.

            - public 으로 선언되어야 한다.

            - 이 인터페이스에 정의된 메소드들은 RMI 규칙을따라야만 한다.
              이것은 리턴값이나 전달인자가 RMI 에서 유용한 타입이어야 하고,
              java.rmi.RemoteException 을 발생할수 있어야 한다.

            - session bean's home interface 는 하나이상의 create() 메소드를 정의한다.

            - create() 메소드는 enterprise Bean class 에 정의된 ejbCreate() 메소드중의 하나와
              전달인자 타입 / 갯수 가 일치해야만한다. (리턴타입은 상관없다)

            - create() 메소드의 리턴타입은 enterprise Bean's remote interface 타입이어야만
              한다.

            - enterprise Bean class 의 ejbCreate() 메소드의 throws 절에 정의된 모든 예외는
              remote interface 내의 일치하는 create() 메소드의 throws 절에 정의되어야 하고,
              또한 javax.ejb.CreateException 을 던져야 한다.
 

    3.11 container provider 를 위한 요구사항

        3.11.1 Generation of implementation classes

            container tools 은 enterprise Bean deployment time에  다음과같은 클래스들을
            추가적으로 생성해야만 한다.

           - enterprise Bean's home interface 를 구현하는 클래스 (EJB Home class).

           - enterprise Bean's remote interface 를 구현하는 클래스 (EJB Object class).

            컨테이너 툴은 또한 enterprise Bean class 와 컨테이너 종속적인 코드들이
            섞인 클래스들을 생성할수도 있다.

        3.11.2 EJB Home class

            EJB home class 는 enterprise Bean's home interface 를 구현하는
            컨테이너에 의해 생성된 클래스이다.

        3.11.3 EJB Object class

            EJB Object class 는 enterprise Bean's remote interface 를 구현하는
            컨테이너에 의해 생성된 클래스이다.

        3.11.4 Handle class

            컨테이너는 enterprise Bean 의 handle 클래스를 구현할 책임이 있고,
            handle 클래스는 직렬화 가능해야만 한다.

        3.11.5 Meta-data class

            컨테이너는 클라이언트에게 유용한 meta-data 를 제공하는 클래스를
            구현할 책임이 있다.
            이 클래스는 javax.ejb.EJBMetaData interface 를 구현해야하고,
            사용가능한 RMI/Value class 이어야 한다.

        3.11.6 Thread 동기화된  instances

            컨테이너는 한 쓰레드가 동시에 한 인스턴스만을 실행할수 있도록
            보장해야 한다.

            인스턴스가 클라이언트의 요청을 실행하고 있는중에 또다른 클라이언트가
            요청을 해오면 컨테이너는 두번째 클라이언트에게 java.rmi.RemoteException
            을 발생시킨다.

            즉, session enterprise Bean 은 주로 단일 클라이언트만을 상대하기 때문에
            같은 세션빈 인스턴스에 여러 클라이언트가 호출을 시도하면 에러....

            같은의미로 클라이언트가 session Bean instance 로의 loopback 호출을 불가능하다.

        3.11.7 Transaction scoping, security, exceptions