요약

본고는 주로 JBOSS EAP 6.1(또는 JBOSS AS7)에서 모듈이 어떻게 EJB가 실현하는 시종을 관통하는지 소개한다.전문은 두 부분으로 나뉘는데 첫 번째 부분은 가장 간단한 Session bean의 Annotation 방식의 실현을 소개하고 Annotation 방식에 익숙한 친구는 첫 번째 절을 건너뛴다.1절의 깔개가 있고 2절은 생산 중의 한 실례를 도입하여 지난 논문인 의 화제를 이어가며 JBOSS가 모듈 설명식 용기로서의 이러한 특성이 EJB의 실현에서 완전히 관철되었다고 이야기했다.

1. Session bean

JBOSS EAP(AS7)의 기본 EJB는 3.1 버전으로 JSR318 규범을 따릅니다.EJB는 3.0부터 Annotation의 개념을 전면적으로 도입했다. 3.0 이전의 EJB는 XML 파일에서 Bean에 대한 설정을 모두 라벨을 통해 코드에서 실현해야 했다.또한 이전에 공장 모델을 위한 이중 인터페이스인 홈과 리모트는 하나의 업무 인터페이스로 대체되었다.Entity Bean의 개념은 EJB에서 꺼내서 JPA규범에 넣었기 때문에 Session Bean의 가장 기본적인 Annotation 방식의 실현만 소개하고 뒷글에 지식적 기반을 제공한다.
Session Bean은 두 부분으로 구성되어 있는데 하나는 업무 인터페이스와 하나는 업무를 구체적으로 실현하는 JAVA 클래스이다.
비즈니스 인터페이스
일반적인 Java 인터페이스 Interface입니다.
@Local 또는 @Remote로 선언될 수 있습니다. 차이점은 이 EJB의 가시도를 표시하는 것입니다.
@Local은 동일한 컨테이너 범위 내에서만 사용할 수 있는 Session bean이라고 표시합니다.
@Remote는 이 호스트와 통신할 수 있는 곳이면 이 Session bean을 호출할 수 있습니다.

import javax.ejb.Remote;

@Remote
public interface HelloWorldBusiness {
	public String sayHello();
}

실현류
그냥 JAVA 클래스예요.
클래스 이름 위에 @Stateless 또는 @Stateful을 사용하여 이 세션 빈의 상태를 표시합니다.(상태의 차이가 있는지 없는지는 힙합 파워의 오리지널 게시물을 참고하세요.http://blog.csdn.net/hippoppower/article/details/4190006자세한 설명이 있습니다.
@Stateless 또는 @Stateful 탭에name 속성을 가지고 이 무상태 Bean의 JNDI 이름을 가리킬 수 있습니다. 가리키지 않으면 실행 클래스의 이름이 JNDI 이름입니다.
주의해야 할 한 가지 변화는 EJB3.0과 달리 EJB3.1의 JNDI는 큰 변화가 있다. 원래 EJB3.0에 있을 때 @Stateless(name="Hello/Kitty"), 클라이언트에서 initContext를 사용할 수 있다.lookup("Hello/Kitty")에서 이 bean을 찾았습니다.하지만 EJB3.1의 JNDI 규범은
java:global[/]//[!]
여기서 WAR 패키지 이름 app-name, JAR 패키지 이름 module-name, 사용자 정의 Bean 이름 bean-name, 인터페이스의 전체 주소 이름fully-quali?fied-interface-name.
따라서 위에서 설명한 @Stateless(name="Hello/Kitty")는 새로운 EJB3.1 JNDI에서 부분만 사용하고 이 EJB를 호출하려면 모든 명칭을 조합해야 하며, 구체적인 JNDI 명칭은 뒤에 있는 블로그에서 소개한다.
바로 위의 가장 간단한 무상태 Bean의 실례:

import javax.ejb.Stateless;

@Stateless(name="Hello/World")
public class HelloWorldBean implements HelloWorldBusiness {
    private static final long serialVersionUID = -1257752919635702689L;
	public String sayHello(){
		return "Hello World.";
	}
}

이것이 바로 가장 간단한 EJBS의 실현이다. 이전의 JBOSS AS에 대해서는 여기에서 실행할 수 있지만 JBOSS EAP6.1(또는 JBOSS AS7)은 EJB를 설정해야 한다. 구체적인 조제 방법은 다음 소절에서 소개한다.
[EJB 학습 내용 확장]
다음은 자주 사용하는 라벨을 열거하여 그것들의 대부분 응용을 다 배우면 충분하다.
@Stateless
@Remote
@Local
@LocalBean
@EJB
@Resource
@Inject
@Stateful
@Init
@PostConstruct
@PreDestroy
@PrePassivate
@PostActivate
@Remove
EJB의 복잡한 실현 기술은 소개하지 않고 깊이 있게 이해하려면 EJB3.1규범 JSR318을 다운로드할 수 있다.
위에서 소개한 것은 모두 서비스 측 EJB의 코드입니다. 클라이언트 측은 다음 블로그인'사랑하고 미워하는 EJB3.1 JNDI'에서 JNDI를 소개할 때 더욱 깊이 있게 소개할 것입니다.

2. 일관된 모듈

모듈에 대한 이야기로 돌아가면 모듈의 구체적인 구성 방법은 의 두 번째 부분을 참조하십시오.이 섹션에서는 EJB가 구현하는 전체 과정에서 모듈이 어떻게 시종일관 일관되는지 설명하기 위해 생산 중인 인스턴스를 사용합니다.
이 시리즈의 첫 번째 글인 에서 소개한'모듈 설명식 용기'의 특성을 살펴보자.
JBOSS EAP는 더 이상lib의 개념이 없습니다. 모든 것은module입니다.시스템이 호출한lib이든 사용자가 작성한lib이든 응용 프로그램이 인용한 제3자lib이든 모두 모듈로 구축하고 사용하는 곳에서 구체적으로 어떤 모듈을 사용했는지 설명한다.
인스턴스:

import com.XX.ngoss.XXX.commonclass.XXXConfiguration;
import com.XX.ngoss.XXX.commonclass.XXXConsts;
import com.XX.ngoss.XXX.commonclass.XXXUtils;
import com.XX.ngoss.XXX.logmanager.server.LogManagerBusiness; 
import com.XX.ngoss.XXX.logmanager.server.LogFileNameInfo;
import com.XX.ngoss.XXX.logmanager.server.LogView;

@Stateless(name="XXX/Log_Manager")
@Remote(LogManagerBusiness.class)
public class LogManagerSession implements LogManagerBusiness, Serializable{
  ……
}

이전 섹션의 쿠션이 있고 위의 삭제된 코드에는 전체 구성 요소의 구조가 기본적으로 표시됩니다. 이것은 제품의 로그를 기록하는 구성 요소입니다. 세 가지 부분을 포함합니다.

LogManager는 EJB의 구체적인 구현입니다. 위의 코드는 LogManager에서 캡처한 것입니다

logManagerCommon은 EJB 저장 인터페이스, 로그 호출 및 저장과 관련된 공공 방법과 변수를 배치하는 곳이다.LogManger는 이 프로젝트에 의존해야 합니다

commonClass는 프로젝트의 전체 범위 내의 각종 자원을 배치하는 데 사용된다.Log Manger와 Log Mananger Common은 이 프로젝트에 의존해야 하며, 이 프로젝트도 일부 제3자 패키지에 의존해야 한다..

다음은 JBOSS EAP 6.1의 구성 방법에 대해 살펴보겠습니다.
logManagerCommon과commonClass는 사용자를 위한lib로 사용되며 모두 JBOSS로 설정된module가 필요합니다.
commonClass는 jboss-eap-6.1\modules\com\xxgoss\xx\commonClass\main에 설치되고 모듈을 설정합니다.xml 파일은 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.xx.ngoss.xxx.commonClass">
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
    <module name="org.jboss.remote-naming"/>
    <module name="org.jython"/>
  </dependencies>
  <resources>
    <resource-root path="CommonClass.jar"/>
  </resources>
</module>

그중 탭의name 속성은 이 모듈을com이라고 명명합니다.xx.ngoss.xxx.commonClass, 그리고 탭에서 commonClass라는 모듈이 의존하는 다른 모듈을 가리킵니다.

commonClass는 JBOSS 용기의javax에 의존합니다.api 모듈, 이것은 이름 서비스와 관련된javax 패키지입니다. 시스템 모듈 jboss-eap-6.1\modules\system\layers\base\javax\api\main에서javax로 설정됩니다.api 모듈..

commonClass는 JBOSS 용기의javax에 의존합니다.transaction.api 모듈, 대응하는 것은 jboss-transaction-api_1.1_spec-1.0.1.Final-redhat-2.jar는 jboss-eap-6.1\modules\system\layers\base\javax\transaction\api\main 디렉터리에 있는jar 패키지입니다. 용기에 기본적으로 javax로 설정되어 있습니다.transaction.api 모듈..

commonClass는 JBOSS 용기의 org에 의존한다.jboss.remote-naming 모듈, 대응하는 것은 jboss-remote-naming-1.0.6.Final-redhat-2.jar는\jboss-eap-6.1\modules\system\layers\base\org\jboss\remote-naming\main 디렉터리에 있는jar 패키지입니다. 용기에 기본적으로 org로 설정되어 있습니다.jboss.remote-naming 모듈..

commonClass는 제3자 패키지 jython에 의존했다.jar, 새로운 JBOSS 모듈로 도입하고 설정해야 합니다.우리는 그것을 jboss-eap-6.1\modules\org\jython\main에 대응하는 모듈에 두었다.xml에서 설정 모듈 이름은 org입니다.jython.

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.jython">
    <dependencies>
        <module name="javax.api"/>
    </dependencies>
		<resources>
			<resource-root path="jython.jar"/>
		</resources>
</module>

LogManageCommon도 같은 방식으로 구성됩니다.com이라는 이름으로 설정되었습니다.xx.ngoss.xxx.commonClass 모듈입니다.
LogManger는 EJB 업무를 실현하는 곳으로 최종 배치할 때 jboss-eap-6.1\standalone\deployments에 배치됩니다.이전의 JBOSS AS와 다른 점은 JBOSS EAP 6.1(AS7)에서 EJB 프로젝트가 JBOSS 모듈에 대한 의존도는 MANIFAST에 명시되어야 한다는 점이다.MF 파일에 있습니다.LogManager/src/META-INF/MANIFEST.MF 파일은 다음과 같습니다. Manifest-Version: 1.0
Dependencies:
com.xx.ngoss.xxx.commonClass,
com.xx.ngoss.xxx.logManagerCommon, org.jboss.log4j.logmanager
Class-Path: 
이렇게 하면 EJB Project가 JBOSS EAP 6.1에 설정한 모듈com을 가리킨다.xx.ngoss.xxx.commonClass,com.xx.ngoss.xxx.logManagerCommon 및 org.jboss.log4j.logmanager의 의존.이제야 EJB가 JBOSS에서 배치하는 작업을 모두 끝냈습니다.업무 박리 실현, 이 로그 구성 요소의 구성은 다음과 같은 세 가지 단계를 포함한다.

타사 패키지를 모듈로 구성합니다

자신이 구축한 패키지를 모듈로 설정하고 모듈이 의존하는 시스템 모듈 또는 제3자 패키지의 모듈을 설정한다

EJB 프로젝트의 MANIFEST.MF에서 프로젝트가 JBOSS 모듈에 대한 의존도를 나타냅니다

시스템 자체 패키지, 제3자 패키지, 사용자 정의 패키지는 모두 모듈로 바뀌었고 모듈과 구성 사이에는 의존 관계를 가리켜야 하며 EJB 프로젝트도 의존 관계가 JBOSS EAP의 구성 요소에 있음을 가리켜야 한다.JBOSS EAP 6.1의 구성 요소의 개념은 골수에 깊이 들어간다고 할 수 있다.

총결산

 
본고는 먼저 가장 간단한 EJB3.1의 실현을 소개한 다음에 실례류를 도입하여 JBOSS 모듈이 어떻게 EJB 프로젝트, 사용자가 만든lib, 제3자의lib, 시스템lib 간에 의존 관계를 명확하게 가리키는지 설명한다.이런 디자인은 JBOSS 용기 최적화에 타당성을 가져왔다.JBOSS EAP 6.1의 시작과 재부팅 속도에서도 충분히 증명되었다.
그러나 개발자의 측면에서 볼 때 개발 환경에서 JBOSS의 이착륙 성능이 크게 향상되었지만 이런 모든lib을module로 설정해야 하는 방식은 원래 lib에 직접 저장하는 방식이 없기 때문에 실현하기 쉽다. 왜냐하면 module는 $JBOSS_에 설정될 수 있기 때문이다.EAP$/modules 디렉터리의 어떤 디렉터리에 어떤 것은 시스템에 이미 있을 수도 있고, 어떤 것은 도입할 필요가 있으며, 어떤 위치에 도입할 것인지는 개발자가 스스로 결정한다.이러한 자유도는 한편으로는 개발자에게 추가 작업량을 가져다 주고, 다른 한편으로는 여러 개발자가 함께 개발하면 서로 다른 모듈이 서로 다른 등급의 디렉터리에 같은 패키지를 도입하여 충돌을 일으킨다.
다시 말하면 모듈 설명식 용기라는 새로운 특성은 성능의 측면에서 볼 때 감상할 만하지만 개발자에게는 이해득실이 반반이다.