스프링을 보면서 가장 놀라는 점은 그 '추상화'의 능력입니다. 전체적인 구성, 문서를 통해 설명되는 구조 뿐 아니라, 구현된 소스를 살펴보면 놀라지 않을 수가 없습니다.
스프링 배치 역시 단순히 스프링 기반의 배치가 아닌, '배치'에 대한 엘레강스(?)한 추상화를 통해서 전체적인 배치 프레임웍을 구성하고 있습니다. 아래 그림에서 볼 수 있듯이 전체적으로 추상화된 뷰를 제공할 뿐만 아니라, 이를 구성하는 각 컴포넌트가 적절하게 추상화 되어 제공되고 있습니다.
좀 더 자세히 들여다 보면 ItemReader는 소스에서 대상 Item을 읽어들이는 IteamReader, Item을 구성하는 각 FieldSet을 매핑하는데 사용하는 FieldSetMapper, LineToknizer, Validator 등으로 추상화 되어 구성됩니다. 
스프링 배치 레퍼런스 2장에 나오는 그림입니다. 스프링 배치를 기반으로 한 배치 애플리케이션과 그 기반이 되는 프레임웍의 구조를 한 눈에 보여주고 있습니다.
이 그림에는 총 세 가지의 뷰를 통해서 분석할 수 있습니다.
1. 배치 애플리케이션의 논리적인 분류 - 티어 구성
- Run 티어: 스케줄링과 애플리케이션 실행에 관련.
- Job 티어: 일반적으로 배치 잡의 실행을 책임. 연속적으로 배치 step을 실행시키고, 모든 step이 실행되서 정확한 상태에 있고, 모든 정책이 정확하게 적용됐는지를 보장.
- Application 티어: 프로그램을 실행하는데 필요한 컴포넌트를 포함. 배치 기능을 수행하는데 적용되는 특정 태스크와 정책을 적용.
- Data 티어: 데이터베이스, 파일, 큐 등을 포함하는 물리적인 데이터 소스와 통합.
2 and 3. 배치 애플리케이션의 컴포넌트 구성과 책임 범위
- 회색 박스(Scheduler, Request, Message Queue, Database, Data Files, Print Queue...)
: 외부 애플리케이션을 표현. 스케줄링은 회색 박스로 표현되어 있는 것처럼 스프링 배치의 범위에 포함되지 않는다.
- 파란 박스(JobRunner, JobLocator, JobLauncher, Job, Step, JobRepository, ItemReader, ItemWriter, Data Access(Dao)...)
: 애플리케이션 아키텍처 서비스를 표현. 대부분 스프링 배치에 의해서 제공.
- 노란 박스(다양한 Configuration file, Job Script, Business Logic...)
개발자에 의해서 구성되는 부분을 표현한다. Job schedule이나 Job 설정 파일 등.
각 박스들은 컴포넌트를 의미하는 동시에, 색을 통해서 해당 컴포넌트를 제공하며, 책임지는 역할을 구분해주고 있습니다.
이 한장의 그림만으로 모든 내용을 알 수 없지만, 스프링 배치의 추상화된 프레임웍과 책임 범위까지 확인할 수 있습니다. 스프링 배치를 적용했을 때의 가장 큰 장점이라면 이런 추상화된 구조를 바탕으로 배치 애플리케이션을 구축할 수 있다는 점을 들 수 있겠죠.
아직 실무에서 배치에 관련된 경험을 한 적은 없지만, 일전 프레임웍 개발팀에 있을 때 배치 프레임웍 개발하시는 분과 한 팀을 이뤘던 적이 있었습니다. 놀라운 점은 그 때 얘기했던 많은 부분들이 훨씬 더 정제된 방법으로 추상화되어 제공된다는 점입니다.
이제 예제를 돌려봐야겠어요. 예제도 돌리기가 만만치 않은데요, 예제 잘 돌려보고 스프킨 캐스팅으로 올려 보든가 해야겠어요^^; 오늘, 내일은 노트북이 수리가서 패스..
Prev
Rss Feed
