오래된 기술에 기반한 시스템을 보다 현대적인 아키텍처로 통합하려는 시도는 그 역사가 길다. 이종의 환경들, 다양한 소프트웨어 벤더들, 다양한 기술들 간 상호 운용성을 높이기 위해서는 상용 기술 보다는 오픈 표준에 기반한 통합 방식이 필요하다. Java™ 2 Enterprise Edition (J2EE) Connector Architecture (JCA 또는 J2C)는 J2EE 컴포넌트에서 엔터프라이즈 정보 시스템(EIS)에 접근할 수 있는 메커니즘을 지정하도록 바뀌었다. 결과적으로 다른 스팩들도 JCA에서 제공하는 기능들을 확장했다. 예를 들어, 엔터프라이즈 메타데이터 디스커버리(EMD)는 동적인 발견 기능을 제공한다. EIS를 SOA 세계로 가져가려면 서비스 컴포넌트 아키텍처(SCA)가 JCA 리소스 어댑터에 의해 구현될 때 JCA 리소스 어댑터를 통해 EIS에 대한 통합된 액세스 방식을 제공한다.
이 글에서는 EIS에 액세스 하기 위해 J2EE 환경에서 사용되는 기술을 설명한다. 또한 서비스 지향 아키텍처에 맞추기 위해 이러한 기술들이 어떻게 확장될 수 있는지도 설명하겠다. 먼저 기술적인 측면부터 살펴보고, 이러한 기술을 기반으로 구현 작업을 수행하는 툴링과 런타임에 대해 논하겠다. 아울러 태스크 리스트도 설명한다.
J2EE Connector Architecture (JCA)는 J2EE 컴포넌트가 안전하고 확장성 있는 방식으로 트랜잭션 지원을 갖추고 EIS에 액세스 할 수 있도록 하는 표준을 정의하고 있다. JCA 스팩에 의해 정의된 커넥터인 JCA 리소스 어댑터는 최적의 Common Client Interface (CCI)를 제공하여 J2EE 클라이언트가 EIS에 액세스 할 때 사용할 수 있는 통합된 API를 제공한다. JCA 리소스 어댑터는 애플리케이션 서버에 의해 호스팅 된다. 애플리케이션 서버는 JCA 스팩에서 시스템 콘트랙트(System Contracts)로 정의된 Service Provider Interfaces (SPI)를 통해서 수명 주기를 관리한다.
JCA 리소스 어댑터는 J2EE 컴포넌트와 EIS 간 투웨이 통신을 지원한다.
- 아웃 바운드(outbound) 통신은 J2EE 컴포넌트에 의해 초기화 된다. EIS에 액세스 하는 클라이언트 역할을 한다.
- 인 바운두(inbound) 통신은 EIS에 의해 초기화 되어, EIS에서 이벤트용으로 등록된 엔드포인트 애플리케이션(Endpoint Application)으로도 알려진 J2EE 컴포넌트를 공지한다. 인바운드 통신은 메시지 프로바이더 같은 호스팅 애플리케이션 서버에서 제공하는 메시징 인프라를 사용하여 비동기식으로 수행된다.
다음의 다이어그램은 두 개의 가능한 통신 시나리오와 CCI와 시스템 콘트랙트의 사용 모습이다. 리소스 어댑터를 사용하는 J2EE 컴포넌트는 같은 애플리케이션 서버 상에서 어댑터와 공존하거나 원격으로 운영된다.
그림 1. JCA 아웃바운드/인바운드 시나리오
JCA 스팩은 보안, 워크로드 관리, 커넥션 관리 같은 서비스 품질 측면에 대한 더 많은 콘트랙트를 정의한다.
엔터프라이즈 메타데이터 디스커버리(EMD)는 메타데이터 발견을 정의하는 스팩이고 JCA 리소스 어댑터의 기능을 확장하는 반입 모델이다. 이 모델은 툴링과 런타임을 위해 엔터프라이즈 애플리케이션 통합(EAI) 프레임웍을 제공한다.
- 툴링(Tooling): EMD를 사용하여 EAI 툴링은 JCA 리소스 어댑터 개발자들이 메타데이터 발견 장치를 사용하여 EIS의 데이터와 기능에 대한 정보를 얻을 수 있도록 한다. 이렇게 해서 발견된 EIS 데이터와 기능들은 개발자들(JCA 리소스 어댑터를 소비하고자 하는 사람들)이 사용하여 선택된 EIS 데이터와 기능에 대한 서비스 인터페이스를 정의한다. 스팩에서 정의되고 툴링에서 제공된 메타데이터 반입 장치를 사용한다.
- 런타임(Runtime): EAI 런타임은 J2EE 컴포넌트가 EMD 스팩에 순응하는 JCA 리소스 어댑터에 의해 노출된 CCI를 통해서 EIS 데이터와 기능들에 대해 생성된 서비스 인터페이스를 사용할 수 있도록 한다.
분명, EMD는 EIS의 데이터와 기능을 검색하는데 사용되는 방법들을 제공함으로서 리소스 어댑터를 소비하는데 필요한 시간을 줄인다. 이 기능이 없다면 어댑터 소비자는 코드를 작성해야 한다.
IBM WebSphere Adapters는 JCA와 EMD를 구현한다. 더욱이 프로그래밍과 런타임 모델을 확장하여 WebSphere 플랫폼에서 제공하는 확장된 Quality of Service 기능을 활용한다.
그림 2. WebSphere 어댑터는 오픈 표준에 기반하고 있다.
일반적인 통합의 경우 IBM은 두 가지의 어댑터를 도입했다.
- 애플리케이션 어댑터(Applications adapters)는 PeopleSoft Enterprise, SAP Software, Siebel Business Applications 같은 특정 소프트웨어 패키지로 연결한다.
- 기술 어댑터(Technology adapters)는 JDBC, EJB, JMS 같은 특정 기술이나 프로토콜을 사용하여 시스템에 연결한다.
각 세트에는 WebSphere 플랫폼에서 독립적으로 설치, 전개, 설정될 수 있는 어댑터 리스트가 포함되어 있다.
애플리케이션 어댑터와 기술 어댑터는 WebSphere Adapters를 개발하는데 사용되는 프로그래밍 프레임웍을 사용한다. ISV와 개발자들은 이 프레임웍을 사용하여 상용 애플리케이션과 기술 어댑터에서 제공하지 않는 커스텀 어댑터를 작성할 수 있다. 이로서 개발이 수월해진다. 기본적인 JCA 인터페이스에 대한 구현이 제공되고 리소스 어댑터 개발자들은 EIS의 통합 코드에 집중할 수 있기 때문이다. 툴링의 관점에서 볼 때 WebSphere Adapters 툴킷은 WebSphere Adapters 기술에 기반하여 커스텀 리소스 어댑터의 개발을 단순화 하는데 사용된다.
WebSphere Adapters에 잘 맞는 JCA 리소스 어댑터에 대해 알아보자.
WebSphere Adapters 대 WebSphere Business Integration Adapters
WebSphere Adapters와 WebSphere Business Integration Adapters는 다른 유형의 어댑터들로서 WebSphere 플랫폼에 전개되어 EIS에 액세스 한다. 프로세스 통합자, 시스템 어셈블러, 어댑터 개발자들은 JCA 1.5에 완전히 순응하는 WebSphere Adapters를 사용 및 개발하는 것이 장려된다. WebSphere Business Integration Adapters는 JCA 호환이 아니며 애플리케이션 서버의 J2EE 컨테이너 밖에서 실행된다. 자세한 정보는 참고자료 섹션을 참조하라.
J2EE 컴포넌트에서 WebSphere Adapters 호출하기
WebSphere Adapters는 JCA 리소스 어댑터로서 JCA 버전 1.5를 지원하는 J2EE 애플리케이션 서버에 전개될 수 있다. 웹 모듈과 EJB 모듈 같은 J2EE 컴포넌트는 다른 JCA 리소스 어댑터 처럼 CCI API를 통해서 WebSphere Adapters를 사용한다. JCA 리소스 어댑터가 EMD 스팩에 순응하면 엔터프라이즈 메타데이터 디스커버리 섹션에서 언급되었던 생성된 서비스 인터페이스는 CCI를 사용하여 EIS에 연결한다. WebSphere Adapters는 필요할 때 마다 추가 API들을 J2EE 컴포넌트에 노출한다.
Enterprise Information System(EIS)과 서비스 지향 아키텍처(SOA)
SOA에 있어서, EIS는 다른 엔터프라이즈 서비스 버스(ESB) 멤버에 기능을 제공하는 또 하나의 시스템이다. 따라서, 버스 멤버들은 통합된 메커니즘을 사용하여 EIS에서 제공하는 기능을 호출하고 데이터를 EIS와 교환할 수 있어야 한다. EIS로 액세스 하고 구현과 독립된 방식으로 데이터를 교환하는 통합 메커니즘을 사용하면 다양한 벤더들이 제공하는 서비스들 간 상호 운용성이 높아지게 된다. 구현 기술이나 전송은 문제될 것이 없다.
앞서 언급한 것 처럼, JCA와 EMD는 EIS의 데이터와 기능에 액세스 하는 강력한 메커니즘을 제공함과 동시에 J2EE 플랫폼에서 Quality of Service 기능도 더 많이 제공한다. 하지만 JCA는 J2EE 스팩의 일부이기 때문에 이러한 호출 메커니즘은 J2EE 컴포넌트의 지배를 받는다. 이 기술이 오픈 표준이더라도 말이다.
Service Component Architecture
서비스 컴포넌트 아키텍처(SCA) 스팩은 ESB에서 사용할 수 있는 서비스들을 호출하는 통합 방식을 제공한다. 이들을 서비스 컴포넌트로서 추상화 하여 인터페이스를 통해 다른 서비스 컴포넌트들도 사용할 수 있도록 하고 있다.
- 컴포넌트 공급자는 컴포넌트에서 제공하는 기능과 이 기능을 호출하는데 사용되는 데이터 유형들을 리스팅 하는 인터페이스를 정의한다.
- 컴포넌트 소비자는 목표 컴포넌트를 지정하지 않고 호출하는 함수를 지정하는 레퍼런스, 구현 기술, 여기에 액세스 하는데 사용되는 프로토콜을 정의한다.
- 애플리케이션 어셈블러는 레퍼런스를 인터페이스에 연결한다.
인터페이스, 레퍼런스, 와이어는 약결합 되기 때문에 컴포넌트와 구현이 다른 종속 컴포넌트에 영향을 주지 않고 독립적으로 진화할 수 있다. 컴포넌트는 반입을 사용하여 비 SCA 시스템 외부 서비스에 액세스 할 수 있다. 반입은 외부 서비스와의 통신에 사용되는 액세스 메커니즘을 정의한다. 이것을 바인딩(binding)이라고 한다. 반입은 다른 컴포넌트로부터 연결할 레퍼런스에 대한 인터페이스를 정의한다. 소비 컴포넌트는 레퍼런스가 다른 컴포넌트에 연결되는지 아니면 반입을 통해 외부 서비스로 연결되는지 알 필요가 없다. 이 두개에서 제공되는 인터페이스가 같다면 말이다. 둘 중 하나는 레퍼런스를 만족시킨다.
이와 비슷하게 컴포넌트는 반출을 통해서 호출될 수 있다. 반출은 제공될 수 있는 함수 세트를 정의한다. 이때 컴포넌트는 지정하지 않는다. 반출이 컴포넌트의 매칭 인터페이스로 연결될 때 그 컴포넌트는 반출을 통해 호출을 제공한다. 반출은 SCA 컴포넌트나 외부 서비스로 바인딩 되거나 호출 될 수 있다.
서비스 지향 아키텍처에서 서비스 컴포넌트로서의 WebSphere Adapters
리소스 어댑터의 일반적인 정의는 EIS에 대한 시스템 레벨의 드라이버라는 것이다. 리소스 어댑터가 SCA 컴포넌트로서 정의될 때, 리소스 어댑터는 EIS를 다른 컴포넌트 처럼 접근 할 수 있도록 만든다. SCA에 따르면, SCA 컴포넌트를 소비한다고 해서 J2EE 방식으로 리소스 어댑터를 사용하지 않을 것이다. SCA 컴포넌트는 EIS 반입과 반출을 통해서 외부 서비스로서 EIS에 액세스 한다. (Service Component Architecture 섹션 참조.) EIS 반입은 SCA 컴포넌트는 EIS 상에서 기능을 호출하는 아웃바운드 시나리오를 수행한다. EIS 반출은 EIS로 초기화된 액션이 SCA 컴포넌트를 공지 및 호출한다는 인바운드 시나리오를 실현한다. 이 두 개의 시나리오는 J2EE Connector Architecture 섹션에서 언급되었던 것이다.
그림 3. 서비스 지향 아키텍처에서 EIS에 액세스 하는 핵심 요소들
사용자를 위해서 EIS 반출과 반입은 EIS 바인딩(JCA 바인딩)을 가진 EMD 스팩에 순응하는 리소스 어댑터에서 EAI 툴링에 의해 생성될 수 있다. 생성된 반입과 반출 구현들은 필요한 대로 편집될 수 있다. 순수한 J2EE 방식으로 리소스 어댑터를 사용하여 EIS에 액세스 하는 STATELESS 세션 EJB에 반입을 바인딩 한다든가, CCI API를 통해서든, 다른 바인딩 옵션들을 사용할 수 있다. EJB 바인딩은 그 경우에 사용되어야 한다. 웹 서비스는 세션 EJB를 대체하고 웹 서비스 바인딩이 사용될 수 있다. 인터페이스가 같다면 어떤 바인딩 유형을 사용한다고 해서 SCA 컴포넌트 소비에는 영향이 미치지 않는다.
WebSphere Adapter Toolkit: 커스텀 WebSphere Adapters 개발
IBM WebSphere Adapter Toolkit은 툴링, 라이브러리, 샘플 코드를 제공하기 때문에 리소스 어댑터 개발자들은 WebSphere Adapters 기술에 준하여 JCA 리소스 어댑터들을 만들 수 있다. 개발자들은 WebSphere Adapter Toolkit를 사용하여 기본 JCA 1.5 어댑터와, JCA 1.5를 확장한 WebSphere Adapter를 만들 수 있다. 이 툴킷은 Rational® Application Developer와 WebSphere Integration Developer 상단에 설치된다. WebSphere Adapter Toolkit의 경우 Rational Application Developer와 WebSphere Integration Developer가 같은 머신에 설치되어 있어야 한다.
WebSphere Integration Developer: Enterprise Application Integration과 Business Integration
WebSphere Integration Developer는 비즈니스 프로세스 플로우, 상태 머신, 비즈니스 규칙을 만드는 툴이다. 서비스 컴포넌트를 어셈블링 하고, 서비스 인터페이스 정의를 반입하고, 바인딩 정책을 설정하는 어셈블리 에디터를 포함하고 있으며 Service Component Architecture도 지원한다. WebSphere Adapters는 반입된 리소스 어댑터 아카이브(RAR) 파일서부터 WebSphere Integration Developer에 어셈블링 될 수 있고 엔터프라이즈 아카이브(EAR) 파일로 반출되어 WebSphere 플랫폼에 전개된다. SCA 반입과 반출을 바인딩하기 위해서 WebSphere Integration Developer의 어셈블리 에디터는 이들을 쉽게 구현 및 설정한다. EMD 스팩에 순응하는 리소스 어댑터의 경우, 엔터프라이즈 서비스 디렉토리 마법사가 EIS 반입과 반출 컴포넌트를 만들고, 엔터프라이즈 데이터 디스커버리 마법사가 데이터 구조에서 비즈니스 객체들을 만든다.
WebSphere Application Server는 WebSphere 제품군에 있는 기타 애플리케이션 서버의 토대가 된다. J2EE 애플리케이션 서버(J2EE Connector Architecture 지원 포함)로서의 역할과 더불어 엔터프라이즈 서비스 버스(ESB) 아키텍처 패턴의 기본 구현인 Service Integration Bus (SIB)를 포함하고 있다. WebSphere Adapters는 노드 레벨에서 WebSphere Application Server에 전개될 수 있다. WebSphere 엔터프라이즈 서비스 버스는 서비스 요청 변형, 콘텐트 기반 라우팅, 감사용 사이드 로깅 같은 중재 기능을 제공한다. SCA의 관점에서 보면 중재 모듈은 Service Component Architecture 섹션에서 논의한 인터페이스와 바인딩을 가진 SCA 모듈이다. WebSphere Process Server는 비즈니스 통합 기능을 제공한다. WebSphere Adapters는 노드 레벨에서 독립적으로 설치되기 보다는 WebSphere ESB와 WebSphere Process Server에 엔터프라이즈 애플리케이션의 일부로서 전개될 수 있다. (임베디드 개발로도 알려짐.) WebSphere Adapters의 독립적인 전개는 WebSphere Application Server에서만 지원된다. WebSphere Adapters는 엔터프라이즈 애플리케이션에서 SCA 컴포넌트로서 어셈블링 되어 WebSphere ESB나 WebSphere Process Server에 전개될 수 있다.
서비스 지향 아키텍처에서 엔터프라이즈 정보 시스템 액세스의 구현: 바톰업 방식
엔터프라이즈 정보 시스템(EIS)에 액세스 하는데 필요한 개발과 어셈블리 태스크는 어떤 소프트웨어가 설치되고 개발될 수 있는지에 따라 다르다. EIS에 접근 할 소비자의 유형에도 마찬가지로 적용된다. 태스크는 다음과 같이 요약할 수 있다.
- 개발/설치: EIS에 액세스 하는 리소스 어댑터를 개발하고 설치하는 과정이다. WebSphere Adapter Toolkit은 리소스 어댑터를 개발한다. 리소스 어댑터는 WebSphere Application Server에 독립적으로 전개될 수 있고 J2EE 컴포넌트에 의해 사용된다.
- 어셈블 (컴포넌트로 만들기): 리소스 어댑터에서 SCA 컴포넌트를 어셈블리 하는 것이다. 사용되는 리소스 어댑터는 구매 또는 개발하도록 한다. 이 작업은 EIS가 SCA 컴포넌트와 비즈니스 프로세스로부터 접근 할 수 있어야만 수행된다. WebSphere Integration Developer는 컴포넌트 어셈블리에 사용될 수 있다. 어셈블링이 된 SCA 모듈은 엔터프라이즈 애플리케이션에서 패키지 되고 WebSphere Enterprise Service Bus나 WebSphere Process Server에 전개된다.
- 조정: 컴포넌트가 정의되면 비즈니스로 직접 매핑 될 보다 세분화된 서비스들로 구성될 수 있다. 이 단계는 SCA 컴포넌트가 비즈니스에 그렇게 중요하지 않을 경우에 필요하다. 서비스들을 구성할 때에는 WebSphere Integration Developer가 사용된다. WebSphere Enterprise Service Bus나 WebSphere Process Server에 엔터프라이즈 애플리케이션이 전개된다.
- 구성: 조정된 비즈니스 서비스들은 WebSphere Integration Developer를 사용하여 비즈니스 프로세스로 구성될 수 있다. 결과 엔터프라이즈 애플리케이션은 WebSphere Process Server에 전개될 수 있다.
위에 설명한 내용들을 아래 표로 정리했다.
표 1. SOA에서 EIS에 액세스 하기: 인풋, 아웃풋, 툴, 런타임, 소비자
| 태스크(Task) | 인풋(Input) | 아웃풋(Output) | 툴(Tool) | 런타임(Runime) | 소비자(Possible Consumers) |
|---|---|---|---|---|---|
| 개발/설치 | 없음 | Custom Resource Adapter (as RAR) | WebSphere Adapter Toolkit | WebSphere Application Server | J2EE components |
| 어셈블링(컴포넌트 화) | Resource Adapter | EIS Import SCA module (as EAR) | WebSphere Integration Developer | WebSphere Enterprise Service Bus 또는 WebSphere Process Server | SCA 외부 서비스/독립 레퍼런스를 통한 비 SCA 컴포넌트 |
| 조정 | SCA Import + (기타 SCA 컴포넌트) | Composite component SCA modules (as EAR) | WebSphere Integration Developer | WebSphere Enterprise Service Bus 또는 WebSphere Process Server | SCA 외부 서비스/독립 레퍼런스를 통한 비 SCA 컴포넌트 |
| 구성 | SCA 모듈 | Business process (as EAR) | WebSphere Integration Developer | WebSphere Process Server | 비즈니스 프로세스 소비자 |
각 태스크의 아웃풋은 소비자의 유형에 따라 사용될 수 있다. 나머지 태스크 역시 소비자 유형에 따라서 수행되어야 한다.
WebSphere 플랫폼은 EIS를 오픈 표준 스팩과 기술에 기반한 SOA에 통합할 수 있는 툴링과 런타임을 제공한다. 이러한 툴과 런타임을 사용하는 구현 태스크는 목표 소비자에 따라 달라진다. WebSphere Adapters를 설치하면 구현에 있어서 유연성이 높아진다.
교육
-
Introduction to the J2EE Connector Architecture
-
About WebSphere Adapters
-
Technical Overview of WebSphere Process Server and WebSphere Integration Developer
-
Differences between WebSphere Adapters and WebSphere Business Integration Adapters
-
About Enterprise Metadata Discovery
-
What is Service Oriented Architecture?
-
Service-Oriented Architecture expands the vision of Web services, Part 1
-
Service-Oriented Architecture expands the vision of Web services, Part 2
-
Managing Information Access to an Enterprise Information System Using J2EE and Services Oriented Architecture
-
서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1: 서비스 생태계 구현하기
-
서비스 지향 모델링과 아키텍쳐
-
IBM SOA Foundation: An architectural introduction and overview
-
About Service Component Architecture
-
Architecting on demand solutions, Part 15
-
Service Component Architecture로 SOA 솔루션 구현하기 -- Part 1
-
Building SOA solutions with the Service Component Architecture - Part 2
제품 및 기술 얻기
