Java EE agent와 standalone Agent
ODI 11g는 Agent 설치가 필수가 아닌 옵션이다.
물론 일정 구성을 위해서는 Agent를 설치하여야 하겟지만, 여기서 말한 옵션이란, Agent를 웹로직에 어플리케이션으로 설치할 것인지 말것인지를 선택할 수 있다는 말이다.
11g Agent는 기본적으로 클러스터링, 로드 밸런싱, 데이터 소스(?)나 Connection Pooling 기능을 웹로직 서버와 함께 사용할 수 있다.
Agent의 수행 방법은 10g 버전에서 사용됐던 혼자 달랑 떠있는 상태의 Standalone Agent 방식 과 위에 언급된 Weblogic에 올리는 형태로 나눌 수 있는데, 11버전에서는 두가지 방법을 다 사용가능하다.
Standalone 방식의 장점은 WLS가 설치될 수 없는 구조의 시스템에 Agent가 설치되어야 한다고 했을 경우, 해당 시스템에 Java 만 설치되어 있으면 Agent 역시 설치가 가능하기 때문이다.
Agent는 특성상 Data와 같은 시스템에 존재하여야 좀더 나은 성능을 보여줄 수 있는 구조가 있을 수 있다. 예를 들어 File에 접근한다던지 하는 경우?
그래서 지금 알아보려고 하는건 10g 버전의 JVM 위에 바로 올라가는 작은 프로세스와 WLS 위에 올라가는 HA 가 보강된 11g 버전의 Agent의 차이점과 장단점이다.
standalone agent 는 쉽게 어디에나 deploy가 가능하나, 클러스트링이나 커낵션 풀링 기능을 지원하지 않는다. Oracle Process Manager and Notification Server(OPMN)와 함께 구동되어서 agent 프로세스 모니터링과 로드밸런싱 기능을 사용할 수 있다.
Java EE agent 는 조금 더 복잡한 형태로 WLS 를 설치하고 도메인을 구성한다음 deploy 하여 사용 가능하다. 대신 기능이 더 많다. 클러스터링, 로드 밸런싱, 중앙 관리 형태 등의 기능이 있다.
두 방식중 어떠한 방식을 사용하느냐는 사용자의 선택이다. 그리고 두 방식을 섞어서 사용하는것 또한 가능하다는 것을 잊지 말길 바란다.
Java 기반으로 구성된 Agent 는 작업들을 하나하나의 세션으로 처리하여 쓰레드를 이용하여 병렬적으로 실행한다.
Agent는 작업을 수행하기 위한 기본적인 데이터만 저장하고 있고 대부분의 데이터는 Repository에 저장하여 읽기, 쓰기를 반복하며 작업을 진행한다.
Master Repository - Topology & Security
Work Repository - Designer & Operator
ODI의 Session Lifecycle
작업 실행 요청
- 작업 준비
1. Master Repository에 접속 (Agent)
2. User Credentials 확인
3. Session 생성 (Waiting 상태)
4. 작업 진행시 사용되는 모든 데이터서버 커넥션 생성
- 작업 시작
5. 작업 시작 (Running 상태)
6. 작업 완료 (Done, Warning, Error 상태)
...
...
final 작업 종료
Agent Startup
1. Read Configuration
2. Connect Master Repository
3. Clean Stale sessions in Work Repositories
4. Retrieve Schedules from Work Repositories
5. Wait for Session Requests
6. Do Work! (Start Scheduled Session & Process Session Request)
s