Spring Batch - 도메인

아래 그림은 배치의 도메인을 가장 중요한 개념들만 나열한 것이다.

Job은 다양한 Step으로 구성되며, 하나의 ItemReader, ItemProcessor 및 ItemWriter를 가진다.

Job에 대한 수행 및 메타데이터를 관리하기 위해 JobLauncher와 JobRepository과 필요하다.

Job

스프링 배치에서 job이란 step을 위한 컨테이너이다. job는 플로우에 논리적으로 함께 위치한 다수의 step으로 구성된다.

재시작과 같은 모든 step에 공통적인 프로퍼티 설정을 적용할 수 있다. job 정의는 다음을 포함한다.

- 작업의 이름

- 스텝의 정의 및 순서

- 작업의 재시작 가능 여부

스프링에서 제공하는 job 인터페이스의 가장 단순한 구현체로서 가장 표준적인 기능으로 SimpleJob 클래스를 제공한다.

하지만 배치 네임스페이스 추상화를 통해 직접적으로 초기화할 필요가 있다. <job> 태그로 정의 할 수 있다.

JobInstance

Jobinstance은 job의 논리적인 실행이다. 일마감시 한번 수행하는 배치 작업을 생각해보다.

위의 다이어그램에서 EndOfDay job은 하나이지만 작업에 대한 개별적인 실행은 분리해서 추적이 되어야 한다.

이러한 경우에 매일 하나의 논리적인 jobInstance가 생성된다.

예를 들어 1월1일 실행, 1월 2일 실행은 각각 jobInstance가 된다. 

만약 1월1일 실행이 첫번째 실패하고, 다음날 다시 실행했다면 그건 1월 1일 실행이다.

그러므로 각 jobInstance는 다수의 executions를 가질 수 있으며, 하나의 jobInstance는 특정한 job에 일치하며, 

실행 시점에 주어진 jobParamters에 의해 식별될 수 있다.

JobParameters

Job과 jobInstance의 다른 점을 논할 때 근본적인 질문은 다음과 같다.

"하나의 jobInstance는 다른 것들과 어떻게 구분되어지나?"

그 답이 jobParameters이다. JobParamters는 배치 작업이 시작할 때 사용되는 파라미터의 집합이다.

그들은 실행 시 참조 데이터 혹은 식별자로 활용된다.

주의 - 모든 job 파라미터가 jobInstance를 식별하는데 필요하진 않다.

JobExecution

JobExecution은 작업 실행을 위한 단일 시도에 대한 기술적인 컨셉이다. 실행은 성공이나 실패가 될 수 있다.

1월 1일 작업을 위한 JobInstance를 고려해 보면 첫 수행에서 실패하였고, 만약 동일한 job parameters로 다시 실행을 한다면 새로운 jobExecution이 생성되게 된다. 이때도 jobInstance는 하나이다. 작업은 어떻게 수행되는지를 명시하고, jobInstance는 함께 수행 및 재수행에 사용될 오브젝트들의 조합으로 명시된다. 그러나 jobExecution은 실제적인 실행시에 생성되고 저장된다. jobExecution을 식별하기 위해서는 특별한 프로퍼티 status, startTime, endTime, exitStatus, createTime, lastUpdated, executionContext, failureExceptions 등을 가진다.

Step

Step은 배치 작업의 독립적이고 순서가 있는 수행을 캡슐화한 도메인 오브젝트이다. 그러므로 모든 작업은 하나 또는 그 이상의 step으로 구성된다.

Step은 실제적인 배치 수행이 정의된 모든 정보를 포함하고 있다. Step은 개발자의 요구에 따라 간단할수도 복잡할 수도 있다.

파일에서 데이터를 읽어서 데이터베이스로 적재하는 단순한 작업은 경우 코드가 거의 없거나 아에 없을수도 있다.

StepExecution

StepExecution은 하나의 step을 수행하기 위한 단일 시도를 표현한다. 새로운 stepExecution은 jobExecution과 마찬가지로 step이 실행될 때마다 생성된다.

하지만 이전 step이 실패한다면, 해당 step은 저장되지 않을 것이다. StepExecution은 실제적으로 step이 시작할 때에만 생성된다.

각 execution은 해당하는 step과 jobExecution에 references를 가지고 transaction 데이터에 대한 정보도 가진다.

추가적으로 각 stepExecution은 배치 작업 전반에 저장되는 정보를 유지하는 executionContext를 정보를 참조한다.

ExecutionContext

ExecutionContext는 프레임웍에 의해 저장되고 컨트롤되는 key/value상의 collection을 대표한다.

ExecutionContext는 stepExecution이나 jobExecution상에서 개발자에 제공되기 위해 존재한다.

Quartz에서 제공되는 jobDataMap과 굉장히 유사하다. 가장 유용한 예는 리스타트 기능이다.

file 입력을 사용하는 예에서 수행중인 개별 라인을 commit point마다 저장을 한다면 다음 수행시 itemReader는 해당 부분을 스킵할 수 있을 것이다.

JobRepository

JobRepository는 위에 언급된 모든 스테레오타입의 저장 매커니즘이다. JobLauncher, job, step의 구현체들에서 CRUD 기능을 제공한다. Job이 처음 구동될 때, jobExecution은 리파지토리로 부터 생성되며, stepExecution과 jobExecution의 수행하는 과정이 repository로 전달된다.

JobLauncher 

JobLauncher는 주어진 jobParamters로 작업을 구동하는 단순한 인터페이스 기능을 한다. JobRepository로부터 유효한 jobExecution을 획득하고 작업을 실행한다.

ItemReader

ItemReader는 step을 위한 input를 검색하는 기능을 담당한다. ItemReader는 제공할 item을 다 소진했을때, null을 리턴함으로서 이 상태를 알릴 수 있다.

ItemWriter

ItemWriter는 step에 추력에 대한 추상화된 표현. 일반적으로 itemWriter는 다음 입력될 데이터에 대한 내용을 알지 못하며, 전달된 아이템에 대한 처리를 수행한다.

ItemProcessor

ItemProcessor는 아이템 하나의 비즈니스 처리에 대한 추상화된 표현이다. ItemReader는 하나의 아이템을 읽고 itemWriter는 쓰지만, itemProcessor는 아이템을 변형하고 다른 비즈니스 처리를 수행한다. 만약 item 처리 중 아이템이 적절하지 않아서 null를 리턴한다면 itemWriter에 그것을 쓰지 않을 것이다.