IT/모바일
제공 : 한빛 네트워크
저자 : Tony Hillerson
역자 : 채수원
원문 : Anatomy of an Enterprise Flex RIA Part 13: Building the Flex Service Layer
자, 이제 플렉스의 서비스 레이어(Service Layer)에 대해 살펴보자. 플렉스 서비스 레이어는 우리가 접근하게 될 데이터 서비스들을 정의해 놓은 클래스들과 서비스 메소드들에 대한 정의, 그리고 이들 서비스들을 호출하기 위한 로직과 서비스들이 리턴될 때 해야 할 것들을 포함하고 있다.
Cairngorm으로 구조화하기
첫 번째이기도 하거니와 가장 인기 있는 플렉스 애플리케이션용 프레임워크인 Cairngorm(역주1) 은 iteration::two라는 컨설팅 회사를 운영했던 스티븐 웹스터(Steven Webster)와 알리스테어 맥레오드(Alistair McLeod), 두 사람에 의해 만들어 졌다. (이 회사는 나중에 어도비 컨설팅의 EMEA RIA 지부(역주2)가 된다.) 현재, Cairngorm 은 어도비 랩스(http://labs.adobe.com)에 의해 배포되는 오픈 소스 제품이다.
(역주1) 스코틀랜드의 산지 명에서 유래된 연한 흑색 수정의 이름이기도 하다.
(역주2) 원문에는 EMIA로 나와 있으나 오타이다. Adobe Consulting의 EMEA (Europe, the Middle East and Africa) 지부를 의미한다.
대다수의 사람들이 Cairngorm이라는 이름을 듣고는 이상하다는 식의 표정을 보이니까, 우리도 마찬가지 식으로 넘어가도록 하자. : 사실, Cairngorm 은 우스꽝스런 이름이다. 이 이름은 스코틀랜드에 있는 Nevis 산맥의 어떤 산 이름을 따온 것이다. iteration::two 는 내부 라이브러리의 이름으로 스코틀랜드 산맥들을 사용하고 있었고, 외부 공개 후에 Cairngorm으로 고정됐다.
Cairngorm 은 마이크로 아키텍처이다. 여기서, 마이크로 아키텍처란 애플리케이션을 설계하는데 도움을 주는 패턴 세트에 더 가까운 의미를 갖는다.
그렇기에, 당신이 작성하는 애플리케이션의 뷰(view)를 설계하는 방법에 관해서 이야기 할 내용이 많은 프레임워크는 아니다. 그보다는 당신의 서로 다른 애플리케이션 조각들과 애플리케이션을 지원하는 서비스들 사이의 상호작용들을 어떻게 결합시킬 것인지에 대부분의 초점을 맞추고 있다.
Cairngorm은 개발자들이 모델-뷰-컨트롤러(MVC) 원칙에 따르는 애플리케이션을 설계하는데 도움을 준다. (MVC 원칙은 많은 비주얼 애플리케이션들에서 흔히 사용된다.) MVC는 컴포넌트들의 권한을 세 종류의 클래스로 분산시킨다. 세 종류의 클래스란 데이터를 가지고 있는 모델과 데이터를 표현하는 뷰, 그리고 모델에 있는 데이터와 뷰의 상호작용에 대해 중재자 역할을 하는 컨트롤러를 말한다.
Cairngorm은 개발자들에게 모델 로케이터(Model Locator)에 속하는 모델과 커맨드들의 집합체인 컨트롤러를 제공한다. (이들에 대해서는 짧게 논의할 것이다.) 뷰(View)는 순수한 플렉스이며 플렉스의 파워풀한 바인딩 프레임워크를 사용하는 좋은 예에 속한다.
Cairngorm는 플렉스 애플리케이션이 가능한 한 유연하게(역주3) 설계될 수 있도록 베스트 사례로 꼽히는 디자인 패턴 세트를 채택했다. 테이블10은 이들 패턴들의 일부 목록이다.
(역주3) 이 부분에서 저자는 Flex 를 가장 Flexible 하게 라는 식의 표현을 쓰면서, 단순히 말장난 하려고 Flexible 이라고 쓴 건 아니라고 이야기 하고 있다.
[표 10] CAIRNGORM 에 의해 채택된 베스트 프랙티스 디자인 패턴들
Cairngorm 내부의 상호작용들에 관해 좀더 배우기 위한 최적의 장소는 http://www.cairngormdocs.org 이다.
Cairngorm 의 전형적인 상호작용은 아래와 같다.
내가 툴에 관해 토의 때 언급했던 것처럼, Cairngorm 프로젝트는 약간의 코드 생성을 통해 훨씬 더 부드럽게 진행된다. Cairngen은 유틸리티성 Ant task들과 템플릿파일들을 제공하여 프로젝트의 요구사항을 달성할 수 있도록 도와준다. 이 task들 중 몇 개는 당신의 플렉스 패키지 내에 Cairngorm 공통 디렉터리들을 생성하는 것들과, 모델 로케이터, 서비스 로케이터, 그리고 프런트 컨트롤러를 생성하는 것들을 포함한다. 이들 task 들은 프로젝트의 시작시점에 특히 유용하지만, 그 후로는 그냥 그렇다. 나는 Cairngen이 "시퀀스(sequence)" 라고 이름 붙은 것을 생성해 내는 데에 아주 유용하다는 것을 알게 되었다. : "시퀀스"에는 CairngormEvent, 커맨드, 혹은 비슷한 이름들을 가진 위임, 그리고 이벤트에 있는 문자열 상수가 있다. 문자열 상수는 이벤트를 커맨드로 등록하기 위해 프런트 컨트롤러에 집어넣을 유일한 식별자를 말한다.
만일 당신이 Cairngen을 직접 내려 받는다면, build.xml 과 project.properties 파일, 그리고 config 디렉터리와 template 디렉터리를 갖게 될 것이다. 나는 build.xml 의 내용을 우리의 ui 프로젝트 build.xml 로 옮겼다. build.xml 파일을 자유롭게 살펴보되, 그 안에 있는 것들을 변경할 필요는 없을 것이다.
나는 또한 project.properties 파일의 이름을 cairngen.properties로 변경했다. 그러나 config 디렉터리와 template 디렉터리는 그대로 남겨두었다.
[그림 17]을 보면 templates 디렉터리는 단지 서로 다른 타입의 Cairngorm 2.2 클래스들을 생성하기 위한 템플릿들을 포함하고 있는 것을 알 수 있다. 당신은 당신의 프로젝트 요구사항에 맞게 이들 템플릿들을 수정할 수 있다. (이를테면, 당신 팀에서 사용하는 중괄호의 스타일을 매치 시킨다던가, 코멘트들을 넣는다던가 하는)
[그림 17] Cairngen 파일들
당신이 해야 할 설정은 cairngen.properties 설정파일 안에 들어 있다. (이전에는 project.properties 였었던 파일이다)
(역주5) 여기에서는 cairngen.properties 파일을 지칭함
(역주6) IResponder 인터페이스는 원격이나 비동기 호출시에 응답할 필요가 있는 모든 서비스에 대한 규약을 2개의 메소드로 정의해 놓고 있다. 그 두 메소드는 에러 발생시에 호출되는 fault() 메소드와 반환 값을 받으면 호출되는 result() 메소드이다. 새로운 시퀀스를 생성하기 원할 때마다, 필요한 시퀀스의 이름을 properties 파일에 추가하고, 적절한 Ant task를 실행해라.
플렉스 서비스 레이어를 살펴보는 것을 이것으로 마치고 다음 번에는 Cairngorm의 컴포넌트들을 이어서 살펴볼 것이다. 언제든 전체 시리즈는 여기에서 찾아 볼 수 있다.
저자 : Tony Hillerson
역자 : 채수원
원문 : Anatomy of an Enterprise Flex RIA Part 13: Building the Flex Service Layer
자, 이제 플렉스의 서비스 레이어(Service Layer)에 대해 살펴보자. 플렉스 서비스 레이어는 우리가 접근하게 될 데이터 서비스들을 정의해 놓은 클래스들과 서비스 메소드들에 대한 정의, 그리고 이들 서비스들을 호출하기 위한 로직과 서비스들이 리턴될 때 해야 할 것들을 포함하고 있다.
Cairngorm으로 구조화하기
첫 번째이기도 하거니와 가장 인기 있는 플렉스 애플리케이션용 프레임워크인 Cairngorm(역주1) 은 iteration::two라는 컨설팅 회사를 운영했던 스티븐 웹스터(Steven Webster)와 알리스테어 맥레오드(Alistair McLeod), 두 사람에 의해 만들어 졌다. (이 회사는 나중에 어도비 컨설팅의 EMEA RIA 지부(역주2)가 된다.) 현재, Cairngorm 은 어도비 랩스(http://labs.adobe.com)에 의해 배포되는 오픈 소스 제품이다.
(역주1) 스코틀랜드의 산지 명에서 유래된 연한 흑색 수정의 이름이기도 하다.
(역주2) 원문에는 EMIA로 나와 있으나 오타이다. Adobe Consulting의 EMEA (Europe, the Middle East and Africa) 지부를 의미한다.
대다수의 사람들이 Cairngorm이라는 이름을 듣고는 이상하다는 식의 표정을 보이니까, 우리도 마찬가지 식으로 넘어가도록 하자. : 사실, Cairngorm 은 우스꽝스런 이름이다. 이 이름은 스코틀랜드에 있는 Nevis 산맥의 어떤 산 이름을 따온 것이다. iteration::two 는 내부 라이브러리의 이름으로 스코틀랜드 산맥들을 사용하고 있었고, 외부 공개 후에 Cairngorm으로 고정됐다.
Cairngorm 은 마이크로 아키텍처이다. 여기서, 마이크로 아키텍처란 애플리케이션을 설계하는데 도움을 주는 패턴 세트에 더 가까운 의미를 갖는다.
그렇기에, 당신이 작성하는 애플리케이션의 뷰(view)를 설계하는 방법에 관해서 이야기 할 내용이 많은 프레임워크는 아니다. 그보다는 당신의 서로 다른 애플리케이션 조각들과 애플리케이션을 지원하는 서비스들 사이의 상호작용들을 어떻게 결합시킬 것인지에 대부분의 초점을 맞추고 있다.
Cairngorm은 개발자들이 모델-뷰-컨트롤러(MVC) 원칙에 따르는 애플리케이션을 설계하는데 도움을 준다. (MVC 원칙은 많은 비주얼 애플리케이션들에서 흔히 사용된다.) MVC는 컴포넌트들의 권한을 세 종류의 클래스로 분산시킨다. 세 종류의 클래스란 데이터를 가지고 있는 모델과 데이터를 표현하는 뷰, 그리고 모델에 있는 데이터와 뷰의 상호작용에 대해 중재자 역할을 하는 컨트롤러를 말한다.
Cairngorm은 개발자들에게 모델 로케이터(Model Locator)에 속하는 모델과 커맨드들의 집합체인 컨트롤러를 제공한다. (이들에 대해서는 짧게 논의할 것이다.) 뷰(View)는 순수한 플렉스이며 플렉스의 파워풀한 바인딩 프레임워크를 사용하는 좋은 예에 속한다.
Cairngorm는 플렉스 애플리케이션이 가능한 한 유연하게(역주3) 설계될 수 있도록 베스트 사례로 꼽히는 디자인 패턴 세트를 채택했다. 테이블10은 이들 패턴들의 일부 목록이다.
(역주3) 이 부분에서 저자는 Flex 를 가장 Flexible 하게 라는 식의 표현을 쓰면서, 단순히 말장난 하려고 Flexible 이라고 쓴 건 아니라고 이야기 하고 있다.
| PATTERN | DESCRIPTION |
|---|---|
| 프런트 컨트롤러(Front Controller) | 프런트 컨트롤러 패턴은 애플리케이션의 뷰 레이어와 그 보다는 좀 더 비즈니스 로직에서 기인한 부분들 사이의 상호작용에 대한 중앙집중적인 제어를 특정 레벨로 유지하기 위한 컨트롤러 패턴이다. 기본적으로, Cairngorm의 컨트롤러들은 이벤트들과 그 에 해당하는 커맨드들을 쌍으로 만들고, 비즈니스 로직 구현의 권한을 커맨드들에게로 위임한다. |
| 이벤트 디스패처/이벤트 리스너(Event Dispatcher/Event Listener) | 플렉스와 플래시와 사실상 대부분의 웹이 아닌 비주얼한 개발을 하는 경우에 있어, (애플리케이션의) 서로 다른 부분들 사이의 상호작용이 비동기적인 형태로 얼마나 자주 일어날지, 혹은 얼마나 많은 상호작용이 콜백형태로 발생할지에 대해서 수없이 부딪치게 될 것이다. Cairngorm 은 이벤트 디스패처를 가지고 있다. 이벤트 디스패처는 뷰(view)가 유저의 행위(gesture)에 해당하는 프런트 컨트롤러에게 해당내용을 알리는 방법이다. |
| 커맨드(Command) | 커맨드 패턴은 서로 다른 액션을 실행하는데 책임이 있는 오브젝트들을 정의한다. 여기서의 액션은 일반적으로 유저의 “행위(gesture)”에 대한 응답을 말하며, “행위”란 버튼에 대한 클릭이라던가 메뉴에 대한 선택이라던가 하는 식의 애플리케이션과 유저 사이의 상호작용을 말한다. Cairngorm 커맨드들은 약간의 향기를 품고 있다. 기본 커맨드들은 단순히 (액션을) 실행하고는 그걸로 끝난다. 응답자들(Responders)에 해당하는 커맨드들은 액션을 실행한 다음에, 보통은 서비스 응답에 해당하는, 애플리케이션의 다른 부분으로부터의 응답에 대해서 (비동기적 방식으로) 대기한다. |
| 비즈니스 위임(Business Delegate) | 비즈니스 위임(Business Delegate) 패턴(역주4)은 애플리케이션과 뒷 단에 해당하는 서비스 레이어가 상호간에 결속력을 갖지 않고 유연하게 유지되도록 하는 하나의 방식이다. 만일 근간이 되는 서비스들과 상호작용이 필요한 애플리케이션의 부분부분들이, 호출해야 할 메소드의 이름들이 어떤 것인지, 서비스에 필요한 인자들은 어떤 것인지를 알아야만 했다면, 서비스를 리팩터링 하는 게 어렵게 됐을 것이다. 왜냐하면 서비스에 대한 어떤 식의 호출이라도 철저하게 조사하고 나서야 변경될 것이기 때문이다.
비즈니스 위임패턴은 서비스들을 호출하는 애플리케이션의 다양한 부분들과 서비스들 그 자체 사이에 위치하고 있다. 종종, 위임 메소드들의 이름들은 뒷 단에 있는 메소드들의 이름과 일치하곤 한다. 이런 식으로, 위임(delegate)은 서비스 레이어와 서비스들을 실제로 구현한 “위임들(delegates)”에게 래퍼(wrapper)처럼 동작한다. 위임들을 사용할 때, 만일 어떤 식으로든 서비스의 API를 변경해야 할 필요가 생기면, 위임 내에서 변경이 필요한 애플리케이션의 클라이언트 부분이 어디인지가 확실하다. 그럴듯한 이유가 있지 않고는 위임의 API를 변경할 필요가 없다. 그리고 만일 바꿀 필요가 있을 때는, 모든 위임들의 호출자들이 동일한 언어로 쓰여지게 된다. 결국 리팩터링 작업을 쉽게 하기 위해, IDE를 이용해서 위임에 대한 어떤 호출이든 세심히 조사해야만 하는 작업이 별것 아닌 일이 된다.
(역주4) 비즈니스 위임(Business Delegate)패턴은 J2EE의 기본 패턴중의 하나로 기본적인 목표는 클라이언트의 프레젠테이션 티어(tier)와 비즈니스 서비스 사이의 결합을 최소화 하기 위해 쓰이는 패턴이다. 즉, 비즈니스 서비스의 API등이 변경될 때 프레젠테이션 티어의 변경이 함께 일어나지 않도록 가운데에서 중개자의 역할을 하는 형태로 존재한다. 이때 캐싱 기능이나 lookup 기능 등을 흔히 함께 제공한다. |
| 모델 로케이터(Model Locator) | Cairngorm 팀은 모델 로케이터(Model Locator) 패턴을 만들었다. 이 패턴은, 모델이 필요한 어딘가로 모델에 대한 참조를 전달하는 식의 다소 더 성가신 메소드들을 이용하는 대신, 뷰나 커맨드들이 모델 자신으로부터 특정한 모델에 대한 참조를 얻는 것을 허용하는 싱글톤 모델을 정의한다. |
| 서비스 로케이터 (Service Locator) | 서비스 로케이터 패턴은 다른 로케이터 패턴들처럼 정의된 서비스들에 대한 쉬운 접속을 제공하는 싱글톤을 정의한다. 이 경우에 있어 서비스들은, 자바 오브젝트, 데이터 서비스, HTTP 서비스, 웹 서비스, 메시지 큐, 그리고 나아가서는 애플리케이션의 플렉스 파트를 위해 사용 가능한 데이터 소스들 등등의 LCDS 설정에 들어있는 다양한 서비스 정의들을 참조한다. |
Cairngorm 내부의 상호작용들에 관해 좀더 배우기 위한 최적의 장소는 http://www.cairngormdocs.org 이다.
Cairngorm 의 전형적인 상호작용은 아래와 같다.
- 사용자의 행위(제스처)
- Cairngorm이벤트 디스패처
- 커맨드
- 위임
- 서비스
- 응답용 커맨드
- 모델
- 바인딩을 통한 뷰 변경
내가 툴에 관해 토의 때 언급했던 것처럼, Cairngorm 프로젝트는 약간의 코드 생성을 통해 훨씬 더 부드럽게 진행된다. Cairngen은 유틸리티성 Ant task들과 템플릿파일들을 제공하여 프로젝트의 요구사항을 달성할 수 있도록 도와준다. 이 task들 중 몇 개는 당신의 플렉스 패키지 내에 Cairngorm 공통 디렉터리들을 생성하는 것들과, 모델 로케이터, 서비스 로케이터, 그리고 프런트 컨트롤러를 생성하는 것들을 포함한다. 이들 task 들은 프로젝트의 시작시점에 특히 유용하지만, 그 후로는 그냥 그렇다. 나는 Cairngen이 "시퀀스(sequence)" 라고 이름 붙은 것을 생성해 내는 데에 아주 유용하다는 것을 알게 되었다. : "시퀀스"에는 CairngormEvent, 커맨드, 혹은 비슷한 이름들을 가진 위임, 그리고 이벤트에 있는 문자열 상수가 있다. 문자열 상수는 이벤트를 커맨드로 등록하기 위해 프런트 컨트롤러에 집어넣을 유일한 식별자를 말한다.
만일 당신이 Cairngen을 직접 내려 받는다면, build.xml 과 project.properties 파일, 그리고 config 디렉터리와 template 디렉터리를 갖게 될 것이다. 나는 build.xml 의 내용을 우리의 ui 프로젝트 build.xml 로 옮겼다. build.xml 파일을 자유롭게 살펴보되, 그 안에 있는 것들을 변경할 필요는 없을 것이다.
나는 또한 project.properties 파일의 이름을 cairngen.properties로 변경했다. 그러나 config 디렉터리와 template 디렉터리는 그대로 남겨두었다.
[그림 17]을 보면 templates 디렉터리는 단지 서로 다른 타입의 Cairngorm 2.2 클래스들을 생성하기 위한 템플릿들을 포함하고 있는 것을 알 수 있다. 당신은 당신의 프로젝트 요구사항에 맞게 이들 템플릿들을 수정할 수 있다. (이를테면, 당신 팀에서 사용하는 중괄호의 스타일을 매치 시킨다던가, 코멘트들을 넣는다던가 하는)
[그림 17] Cairngen 파일들
당신이 해야 할 설정은 cairngen.properties 설정파일 안에 들어 있다. (이전에는 project.properties 였었던 파일이다)
############################### FLEX BUILDER PROPERTIES
root.dir =./src/main/flex
################################# PROJECT PROPERTIES
project.name =Bookie
com.dir =lcds
domain.dir =examples
project.dir =bookie
namespace =${com.dir}.${domain.dir}.${project.dir}
project-uri =${root.dir}/${com.dir}/${domain.dir}/${project.dir}
################################## SOURCE MANAGEMENT
overwrite.existing.files =false
################################ CAIRNGORM PROPERTIES
cairngorm.version =2.2
################################# CREATING SEQUENCES
sequence.name =BooksChosen
################################### CREATING VOs
vo.name =HelloWorld
여기에서 우리는 Cairngen에게 소스들이 있는 곳과 프로젝트 이름, 그리고 패키지 구조에 대한 정보를 알려준다. Cairngen tasks 의 목록은 아래와 같다.
- clean (모델과 서비스 로케이터, 컨트롤러, 시퀀스, VO 뿐 아니라 Cairngorm 의 표준 디렉터리들을 모두 다 제거한다.)
- create (Cairngorm 의 표준 디렉터리들을 만든다. 모델과, 컨트롤러, 서비스 로케이터, 시퀀스와 VO를 생성한다.)
- create-cairngorm-directories (Cairngorm의 표준 디렉터리들)
- create-front-controller
- create-model-locator
- create-sequence-exclude-delegate
- create-sequence-include-delegate
- create-service-locator
- create-value-object
- delete-cairngorm-directories
(역주5) 여기에서는 cairngen.properties 파일을 지칭함
(역주6) IResponder 인터페이스는 원격이나 비동기 호출시에 응답할 필요가 있는 모든 서비스에 대한 규약을 2개의 메소드로 정의해 놓고 있다. 그 두 메소드는 에러 발생시에 호출되는 fault() 메소드와 반환 값을 받으면 호출되는 result() 메소드이다. 새로운 시퀀스를 생성하기 원할 때마다, 필요한 시퀀스의 이름을 properties 파일에 추가하고, 적절한 Ant task를 실행해라.
플렉스 서비스 레이어를 살펴보는 것을 이것으로 마치고 다음 번에는 Cairngorm의 컴포넌트들을 이어서 살펴볼 것이다. 언제든 전체 시리즈는 여기에서 찾아 볼 수 있다.
TAG :
최신 콘텐츠