레이블이 Camel인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Camel인 게시물을 표시합니다. 모든 게시물 표시

2014년 11월 11일 화요일

Apache Camel을 이용한 마이크로 웹 서비스 개발


1. 들어가며

일반적으로 기업은 사업 상 멀리 떨어진 외부 협력사들이나 자사의 지점들과 정보나 업무를 주고 받아야 한다. 예를 들어 쇼핑몰은 배송지 주소와 물품 배송 정보 등을 인터넷을 통해 배송 업체와 주고 받아야 한다. 즉 쇼핑몰 전자 상거래 시스템은 배송 업체의 물류 시스템과 인터넷에서 원격으로 접속해서 정보를 주고 받아야 한다. 그런데 문제가 되는 점은 이들 개별 회사들이 인터넷의 표준 프로토콜인 TCP/IP 접속을 합의했다 손치더라도 애플리케이션 프로토콜이나 데이터 형식에 대해서는 그다지 합의하지 못했다는 점이다. 즉 각 사의 애플리케이션 프로토콜이나 데이터 형식은 각 사의 환경에 맞춰 각기 달리 발전함으로써 양 사가 통합하려면 한쪽이든 양쪽이든 프로토콜과 데이터 형식을 새로 합의해야 한다.

과거에는 (여전히 현재도) 인터넷 또는 TCP/IP 망에서 떨어진 두 시스템은 데이터 전송에 이미 합의한 TCP/IP 계층의 전송 프로토콜을 적극 이용하는 방향으로 발전해 왔다. 즉 전송을 위해 TCP/IP 소켓을 활용하고, 소켓 접속 수립에 양 애플리케이션이 합의한 절차를 추가하고, 데이터 형식은 전문이라 불리는 (일반적으로 고정 길이 필드를 가진) 메시지를 이용했다. 그런데 이런 방식으로 원격 시스템들을 통합하는 경우 개발자가 부담해야 할 개발 범위와 시간은 상당하게 된다. 통합을 위해 각 사에서 사용하는 다른 프로토콜과 데이터 형식을 서로 맞추거나, 한 쪽에 맞춰야 하고, 통합을 위한 테스트도 양 사가 동시에 수행해야 하기 때문이다. 기업들은 이런 문제를 해결하기 위해 통신과 전문을 편리하게 처리해 주는 통신/전문 라이브러리나 미들웨어 패키지들을 구매하기도 한다. 그러나 벤더 독자적 솔루션을 사용하는 기업은 상이한 솔루션을 사용하는 다른 원격지와 통합하려는 경우 다시 유사한 문제를 해결해야 한다.

이와 같은 문제로 인터넷의 원격지 시스템들 사이 통합에 모두가 동의할 수 있는 수많은 표준들이 제안되었고, 그 중 SOAP(Simple Object Access Protocol)을 많이 사용되고 있다. 그러나 SOAP이 처음 세상에 나왔을 때, SOAP은 이름처럼 간단함을 추구하려 했으나 실제 사용하려면 지나치게 자유도는 높고 사용 절차도 상당히 복잡하다는 문제를 가지고 있었다. 그 결과 관심을 가졌던 전문가들조차 SOAP 사용에 어려움을 호소하거나 심지어 SOAP을 외면하는 사태까지 이르렀었다. 그러나 시간이 지나면서 SOAP을 편리하게 사용할 수 있는 도구들과 프레임워크들이 시행착오를 통해 발전하면서 SOAP의 사용이 과거보다 상당히 편리해 졌고, 인터넷 상의 원격지 시스템들을 통합하는 데 이만큼 잘 정비된 표준도 없기에, 현재는 점차 SOAP을 원격지 통합에 사용해 가는 추세다.

SOAP 이외에 인터넷 상의 원격지 시스템들을 통합하는 표준이나 기술로 XML-RPC, JSON-RPC, Restful, Spring Remote, Camel Remote 등등 HTTP 프로토콜을 기반으로 애플리케이션 계층을 정의하는 여러 프로토콜들이 있다. HTTP 프로토콜은 요청 응답 패턴에 헤더와 본문을 가진 메시지를 사용하고 사용하는 TCP 포트도 기업 인터넷 방화벽이 접속을 허용하므로, 대부분의 애플리케이션 프로토콜들이 HTTP 프로토콜을 전송 프로토콜로 사용한다. 우리가 일반적으로 알고 있는 RPC(Remote Procedure Call) 기술인 CORBA, DCOM, 자바 RMI 등은 사실 인터넷과 같은 WAN 망을 위한 프로토콜이 아니다. 이런 프로토콜은 간단한 요청 응답 패턴 이상의 송수신이 발생하고, 경우에 따라서는 브로커가 개입해야 하고, 사용하는 TCP 포트도 일반적으로 인터넷 방화벽이 개방하지 않는다. 즉 이런 기술들은 LAN에서 사용되는 기술들이다. 그러므로 이런 기술을 WAN 망에 적용하면 도리어 성능이 떨어지거나 플랫폼에 종속되거나 상호 상호 접속이 불가능할 수도 있게 된다. 즉 RPC에 사용되는 프로토콜들도 접속 상황에 따라 적절하게 구분해서 사용해야 제대로 된 효용을 발휘할 수 있는 것이다.

최근에는 마이크로 서비스(Microservice)라는 개념이 확산되고 있다. 마이크로 서비스는 아주 작은 코딩으로 업무를 처리하는 기능 중심의 컴포넌트 애플리케이션을 말한다. 즉 약 100 줄 내외의 짧은 프로그램이나 간단한 설정으로 업무를 수행하게 하는 기술이다. 모든 기능을 집적한 강력한 단일형 애플리케이션에서 기능 별로 전문화된 컴포넌트 애플리케이션으로 분업화하는 기술이라고도 볼 수 있다. 이 기술의 장점은 서비스의 추가/삭제/수정에 다른 서비스들의 영향을 최소화 할 수 있다는 점이다. 모든 서비스를 함께 운영하는 단일형 애플리케이션의 경우 운영되는 서비스들 중 일부를 수정하려면 애플리케이션 내 모든 서비스들도 영향을 받거나 중지해야 하는 문제가 생길 수 있다. 이점은 기업 통합 패턴의 단단한 결합(tight coupling)과 느슨한 결합(Loose Coupling)의 원리 비교와 일맥 상통한다. 마이크로 서비스는 이제 막 등장하는 개념으로 앞으로 어떻게 발전/수정/쇠퇴할 지 좀더 지켜봐야 할 것이다. 그럼에도 필자는 이 글에서 SOAP 웹 서비스를 마이크로 서비스로 구현해 보려고 한다.

SOAP 프로토콜을 이용하려면 웹 서비스를 기술하는 WSDL도 알아야 하고 SOAP 구현체에 맞추어 프로그램도 개발해야 한다. 그러므로 SOAP을 이용한 개발 방법은 SOAP 구현체에 따라 상당히 달라진다. 그리고 SOAP은 웹 서비스에 주로 사용된다. 여기서 말하는 웹 서비스란 인터넷에 HTTP 프로토콜을 통해 노출된 서비스를 말한다. 즉 SOAP 웹 서비스는 인터넷에서 호출 가능한 서비스로 데이터 전송 프로토콜로 HTTP를 사용하고 데이터의 전송 형식과 원격 기능 호출 절차에 SOAP 프로토콜을 사용하는 서비스를 말한다. 그러므로 SOAP 웹 서비스를 구축하기 위해서는 웹 서버가 필요하고 SOAP 프로토콜을 지원하는 구현체(프레임워크)도 필요하다.

SOAP 웹 서비스는 두 가지 접근 방법으로 개발한다. 계약 우선 개발(contract-first development) 방법과 서비스 우선 개발(service-first development) (또는 코드 우선 개발(code-first development)또는 계약 나중 개발(contract-last development)) 방법이다. 계약 우선 개발(contract-first development) 방법이란 WSDL(Web Service Description Language)를 우선 사용해 인터넷 상의 웹 서비스를 정의한 후 웹 서비스 서버나 클라이언트들이 정의된 WSDL에 따라 웹 서비스를 개발 방법이다. 서비스 우선 개발(service-first development) 방법이란 인터넷 상에 웹 서비스를 노출하는 서버가 자바 같은 개발 언어로 서비스를 우선 개발하고 개발된 서비스를 웹 서비스로 노출하는 개발 방법이다. 이때 웹 서비스 서버는 노출된 웹 서비스의 WSDL도 자동으로 노출한다. 이후 웹 서비스 클라이언트들은 웹 서비스 서버가 노출한 WSDL을 사용해 계약 우선 개발 방법으로 웹 서비스 호출을 개발한다. 계약 우선 개발 방법의 장점은 WSDL을 이용해 서비스 구현 없이 서비스의 서명과 입출력을 정의할 수 있다는 점이다. 즉 웹 서비스 서버와 클라이언트가 웹 서비스 구현 없이도 웹 서비스를 문서만으로 우선 정의할 수 있다는 점이다. 반면 서비스 우선 개발은 웹 서비스 서버가 웹 서비스를 우선 구현한 후 웹 서비스 클라이언트에게 WSDL을 알려줌으로써 웹 서비스 클라이언트가 웹 서비스 호출을 구현할 수 있게 한다. 이 방법의 장점은 이미 만들어진 내부 서비스를 웹 서비스로 노출할 때 편리하고, 자동화된 웹 서비스 노출 관례를 따르므로 서비스 개발에 집중할 수 있다는 점이다. 반면 이 방법의 단점은 웹 서비스 노출 시, WSDL이 기계적으로 생성됨으로, WSDL을 직접 기술하는 것보다 웹 서비스 정의 융통성이 떨어질 수 있다는 점이다. 그러나 이런 문제도 웹 서비스 어노테이션이나 설정 등을 통해서 웹 서비스 노출 서명을 수정할 수 있으므로 사실 과거에 서비스 우선 개발이 가졌던 단점은 상당히 완화된다. 필자는 SOAP 웹 서비스 서버 개발에는 서비스 우선 개발 방법을 사용할 것이고, SOAP 웹 서비스 클라이언트 개발에는 계약 우선 개발 방법을 사용할 것이다.

첨언하자면 이 글은 Apache Camel Developer's Cookbook 12장 Web Services가 설명하지 않는 SOAP 웹 서비스의 서비스 우선 개발 방법에 대해 필자가 도전하면서 얻은 노하우를 설명하는 글이다.


2. 웹 서비스 서버 프로젝트 생성

웹 서비스를 구현하기 위해서는 SOAP 기반 웹 서비스 구현을 돕는 아파치 CXF(Apache CXF) 프레임워크와 마이크로 서비스를 가능하게 하는 아파치 카멜(Apache Camel) 통합 프레임워크와 애플리케이션 프레임워크인 스프링(Spring) 프레임워크가 필요하다. 그리고 이들 프레임워크들을 편리하게 추가하고 서비스도 간단히 실행하기 위해 maven(3.1 이상) 프로젝트로 웹 서비스 서버를 개발할 것이다. Maven을 이용해 쉘(명령창)에서 웹 서비스 서버 프로젝트를 다음 같이 생성한다.

생성된 프로젝트 디렉터리 아래 pom.xml 파일에 다음의 의존들을 추가한다.

포함되는 의존들은 CXF를 사용하기 위한 Camel CXF 컴포넌트와 자동으로 의존에 포함되는 CXF 프레임워크와 CXF 웹 서비스를 웹 상에 구동해 주는 CXF jetty 라이브러리들이다.


3. 서비스 입출력 정의

일반적으로 서비스를 구현하려면 클라이언트 요청과 서비스 응답을 정의해야 한다. (이곳의 입출력 클래스는 앞서 언급한 Apache Camel Developer's Cookbook의 웹 서비스 예를 참조했다. 그런데 Cookbook의 예는 계약 우선 개발 방법을 사용하므로 WSDL로부터 Cookbook의 웹 서비스 입출력 클래스 생성되나, 필자는 서비스 우선 개발 방법을 사용하므로 필자의 웹 서비스는 입출력 클래스를 우선 정의한다.)

그러므로 서비스 입력 출력 클래스를 다음과 같이 정의한다.

입출력 클래스는 com.brm.ws.payment.types 패키지 아래 놓았다. 이 패키지 이름은 나중에 SOAP WSDL 입출력 정의에서 네임스페이스로 사용된다. CXF 프레임워크는 자바의 리플렉션 기능을 사용해 위에 정의한 입출력 클래스를 WSDL 입출력 정의로 생성해낸다. 그리고 생성된 WSDL 입출력 정의는 SOAP 마샬링의 메타데이터로 활용된다. 그러므로 SOAP 원격 통신으로 전송되는 입출력 클래스는 마샬링 정보가 WSDL로 정의되므로 별도의 마샬링 메타데이터는 필요하지 않다. 그러나 예를 들어 자바 RMI나 JMS같은 SOAP 이외의 프로토콜을 이용하는 경우, 입출력 객체를 전달하고자 한다면 해당 기술에 맞도록 마샬링 메타데이터를 정의하거나, 입출력 클래스가 Serializable 인터페이스를 상속하도록 해야 한다. Serializable 인터페이스를 상속하는 방법은 기업 통합 패턴의 "9장 팁코 액티브엔터프라이즈를 이용한 비동기 구현" 예를 팁코 액티브엔터프라이즈 대신 아파치 카멜로 대체하는 "아파치 카멜을 이용한 비동기 구현"이란 글에서 JMS 통신을 위해 사용될 예정이니, 그 글을 참고하기 바란다.

SOAP은, 입출력 마샬링 메커니즘뿐만 아니라, 웹 서비스의 오류 정보를 전달하는 fault 메커니즘도 제공한다. 서비스 우선 개발 방법에서는 서비스 메소드가 하나의 반환 형식이 고정되므로, 이 기능은 예외를 이용해 전달한다. (이 점은 서비스 우선 개발 방법이 계약 우선 개발 방법과 비교하여 융통성이 떨어지는 부분이기도 하다. 그러나 웹 서비스 서버와 클라이언트는 fault 메커니즘 대신 서비스 응답에 '반환 코드'나 '오류 상세 메시지'를 포함하는 방식으로 입출력을 합의할 수 있다. 이 경우 SOAP 서비스 클라이언트는, fault 처리를 위한 별도 예외 처리 로직 대신, 서비스의 응답으로부터 '반환 코드'나 '오류 상세 메시지'를 추출해 예외를 처리한다. 게다가 이 방법은 충분히 편리하다. 그러므로 이 점이 꼭 서비스 우선 개발 방법의 약점이라고만은 할 수 없다.)

이 글에서는 기술적인 측면에서 SOAP fault를 웹 서비스 어떻게 클라이언트에게 전달할 수 있는지를 보여줄 것이므로, 다음과 같이 Fault 클래스를 정의한다.

위 Fault 클래스는 reason 멤버 변수를 하나 정의해 간단하게 오류를 설명한다. 서비스 오류를 설명하는 추가적인 정보가 필요한 경우 이곳에 필드를 추가할 수 있을 것이다.


4. 서비스 인터페이스 정의

서비스 입출력을 정의한 후 서비스 기능을 노출하는 서비스 인터페이스를 정의한다. 이 서비스는 위에서 정의한 서비스 입출력 정의의 입력 클래스와 출력 클래스를 사용한다. 여기서 주목할 점은 아직까지 웹이나 SOAP에 대한 고려가 없다는 점이다. 즉 서비스 인터페이스는 순전히 일반적인 자바 인터페이스와 메소드로 정의한다. 정의된 서비스 인터페이스는 다음과 같다.

위 서비스 인터페이스에서 TransferException 예외에 주목한다. 서비스 우선 개발에서는 예외를 이용해 웹 서비스 서버가 fault를 웹 서비스 클라이언트에게 전달한다. Fault 정보를 포함한 TransferException 클래스 정의는 다음과 같다.

CXF 프레임워크의 동작 메커니즘으로 보면 TransferException가 SOAP fault로 전달되지만 TransferException은 예외를 위한 클래스이므로 의미의 중첩을 피하기 위해 실제 SOAP fault의 상세 정보는 여기처럼 Fault 객체를 사용하는 것이 바람직하다. 이것으로 서비스 우선 개발 방법의 서비스 인터페이스 정의는 완료된다.


5. 서비스 빈 구현

서비스 인터페이스가 정의되면, 일반적인 POJO 스타일의 서비스를 구현한다. 여전히 웹 서비스라든지 SOAP이라든지에 대한 구현 상의 고려는 별달리 추가되지 않는다. 즉 이 일반적인 POJO 스타일의 서비스 빈은 손쉽게 웹 서비스로 전환될 것이다. 이 예는 웹 서비스의 뼈대 구현에 초점을 맞추므로, 서비스 빈은 이체를 성공했다고 가정하고 간단하게 성공을 응답한다. 그러므로 구현된 DefaultPayment 서비스 빈 은 다음과 같다.

위 서비스 빈은 백만 원을 넘는 이체 요청은 예외를 발생시킨다. 정상 거래와 비정상 거래를 모두 테스트 하기 위해 이체 한도를 서비스 기능에 포함시켰기 때문이다. 보다시피 위 서비스 빈은 전형적인 POJO 스타일의 자바 클래스다.


6. 웹 서비스 서버 구현

서비스 우선 개발 방법에 따라, 위와 같이 일반적인 POJO 스타일의 서비스 빈을 완성했으면 이제 이 평범한 서비스 빈을 웹 서비스로 노출시킬 차례다. 이를 위해서는 아파치 카멜이 제공하는 camel 네임스페이스뿐만 아니라 cxf 네임스페이스도 스프링 빈 정의 XML에 포함해야 한다. 이들 네임스페이스를 포함한 스프링 XML의 beans 엘리먼트는 다음과 같은 속성들을 갖는다.

위와 같이 카멜과 웹 서비스를 위한 네임스페이스를 추가했다면, 서비스 인터페이스를 웹 서비스로 노출시키는 웹 서비스 빈을 지정한다. 이 빈에 노출될 웹 서비스의 웹 URL과 서비스 인터페이스를 지정한다. 실제 서비스를 구현한 빈도 지정한다.

웹 서비스 빈과 구현 빈을 지정했다면, 이제 카멜 라우팅 정의에 이 두 빈을 포함시켜 웹 서비스 서버로 동작하게 한다. 웹 서비스 서버를 노출하는 카멜 라우팅 정의는 다음과 같다.

이 카멜 라우팅 정의는 카멜 CXF 컴포넌트를 이용해 PaymentServiceEndpoint 를 웹 서비스 소비자(서버)로 노출하고, 웹 서비스 클라이언트로부터 수신한 요청을 다시 paymentService 빈에게 전달하게 한다. 즉 from 엔드포인트는 웹 서비스 서버를 노출하고 to 엔드포인트는 웹 서비스 구현을 호출한다. 그리고 route에 handleFault 속성을 참으로 지정해 서비스 빈에서 발생한 예외를 SOAP fault 메시지로 전달한다. 카멜 라우팅 정의를 이용한 웹 서비스 노출은 이렇게 간단하다. 아래는 모든 설정을 포함한 완전한 스프링 빈 정의 XML이다.

이것으로써 POJO 스타일의 서비스가 SOAP 웹 서비스로의 확장이 완성됐다. 실질적으로 웹 서비스로 노출하기 위해 추가된 코드와 설정은 다 합해도 100줄도 채 되지 않았다. 카멜의 장점 중 하나는 이렇게 카멜 정의 파일만으로도 즉시 카멜 컨테이너를 실행할 수 있다는 점이다.


7. 웹 서비스 서버 실행

이제 웹 서비스 서버를 실행해 보자. 프로젝트 디렉터리에서 maven camel:run 골(goal)을 실행한다. camel:run 골을 실행할 수 있은 이유는 프로젝트 생성 과정에서 pom.xml에 camel-maven-plugin이 포함됐기 때문이다.

다음은 웹 서비스 서버 실행 결과다.

그런데 눈치 빠른 독자라면 무엇인가 이상한 점을 발견했을 것이다. 이 예의 SOAP 웹 서비스 서버는 Tomcat이나 그 밖의 WAS를 이용해 기동되지 않았을뿐더러, 웹 서비스 서버를 기동하기 위해 Jetty와 같은 내장형 서블릿 컨테이너를 스프링 빈으로 복잡하게 설정한 후 다시 여러 빈을 엮는 작업을 하지도 않았다. 웹과 관련된 유일한 설정은 “웹 서비스 구현”에서 cxf:cxfEndpoint를 정의할 때 주소로 지정한 http://localhost:9090/paymentService가 전부다. 위 로그를 보면 CXF 프레임워크가 ReflectionServiceFactoryBean 등을 이용해 cxf:cxfEndpoint에서 지정한 http://localhost:9090/paymentService 주소로 웹 서버를 자동으로 기동한 것을 볼 수 있다. 그리고 이 모든 과정이 관례(CoC, Convention Over Configuration)에 따라 자동으로 완성된다. 즉 개발자는 일반적인 POJO 서비스 빈을 30줄도 안 되는 아주 적은 설정을 사용해 SOAP 웹 서비스를 완성한 것이다. 이런 점에서 이 웹 서비스는 마이크로 웹 서비스다.


8. 웹 서비스 WSDL

CXF 프레임워크는, SOAP 웹 서비스 서버의 실행과 더불어, 웹 서비스의 SOAP 계약인 WSDL을 자동으로 노출한다. 그러므로 웹 서비스 서버를 실행한 후, 웹 브라우저는 웹 서비스가 노출한 웹 URL 주소 뒤에 “?wsdl”을 추가해 조회함으로 웹 서비스의 WSDL을 읽을 수 있다.


9. 웹 서비스 클라이언트 프로젝트 생성

웹 서비스 클라이언트 프로젝트는 웹 서비스 서버 프로젝트 생성에서 사용한 동일한 maven archetype을 사용한다. 서버와 달라지는 점은 'artifactId'가 wsc-example로 바뀌는 정도다.

생성된 프로젝트 디렉터리 아래 pom.xml에 다음과 같이 의존들을 추가한다.

jaxws-api 의존은 CXF 프레임워크의 wsdl2java가 생성한 클래스가 참조하는 의존이고, junit 의존은 웹 서비스 클라이언트를 JUnit 클래스로 만들기 위해 필요한 의존이다.


10. 웹 서비스 클라이언트 입출력 정의

앞서 웹 서비스 서버를 완성했으므로, 웹 서비스 클라이언트의 입출력 개발은 웹 서비스 서버가 노출한 WSDL을 이용해 보자. WSDL이 이미 완성된 경우, 계약 우선 개발 방법을 이용하는 것이 훨씬 수월하기 때문이다. 이 예에서는 WSDL로부터 자바 클래스들을 생성하도록 돕는 CXF 프레임워크의 wsdl2java 유틸리티를 이용해 웹 서비스 클라이언트가 필요한 자바 클래스들을 생성한다. wsdl2java를 다음과 같이 실행하면, 이 예의 웹 서비스 서버 WSDL로부터 웹 서비스 클라이언트 실행에 필요한 자바 패키지와 클래스들이 생성된다.

위 명령을 통해 생성된 패키지와 클래스들을 웹 서비스 클라이언트 프로젝트 디렉터리의 src/java/main 아래 복사한다. 복사하면 다음과 같은 패키지와 클래스들이 보일 것이다.

위와 같이 복사하면 웹 서비스 클라이언트의 입출력 정의는 완성된다. com.brm.ws.payment 패키지는 웹 서비스 서버 개발에서 Payment 인터페이스를 정의한 패키지 위치와 같다. (패키지 이름은 웹 서비스 서버 개발 시 웹 서비스 어노테이션을 사용해 명시적으로 지정할 수도 있다. 사실 요즘은 웹 서비스 어노테이션을 사용해 서비스 우선 개발이더라도 계약 우선 개발의 WSDL을 개발하는 것처럼 섬세하게 웹 서비스 구조를 정의할 수 있다. 즉 어노테이션을 이용해 네임스페이스에 대응되는 패키지 이름이나 서버의 웹 서비스가 정의된 패키지에 대응되는 웹 서비스 인터페이스 이름 등을 명시적으로 지정할 수도 있다. 문제는 어느 방법이 더 수월한 가다.) 패키지 아래 입출력 클래스인 TransferRequest.java, TransferResponse.java와 fault 클래스인 Fault.java를 볼 수 있다. 이렇게 언어별 소스 생성에 자동화 도구를 사용할 수 있다는 점이 계약 우선 개발 방법의 장점 중 하나다.


11. 웹 서비스 클라이언트 인터페이스 정의

웹 서비스의 클라이언트 인터페이스도 wsdl2java 유틸리티가 WSDL로부터 자동으로 생성한다. com.brm.ws.payment 패키지 아래 PaymentPortType.java가 클라이언트의 웹 서비스 인터페이스다.


12. 웹 서비스 호출 구현

wsdl2java 유틸리티를 사용해 웹 서비스 WSDL로부터 자동으로 웹 서비스 클라이언트의 입출력 클래스와 웹 서비스 인터페이스를 모두 생성했으므로 이제 웹 서비스를 호출하기 위한 웹 서비스 클라이언트를 구현해 보자. 웹 서비스 클라이언트를 구현하려면 스프링 빈 정의 XML 파일에 웹 서비스 클라이언트의 CXF 빈과 카멜 라우팅 정의를 설정해야 하고, 이 XML 파일을 이용해 웹 서비스를 호출하는 웹 클라이언트 단위 테스트 클래스를 개발해야 한다. (웹 서비스 클라이언트의 스프링 빈 정의 XML파일도 "웹 서비스 서버 구현"에서 사용한 네임스페이스와 같은 네임스페이스를 사용하므로 이에 대한 지정은 "웹 서비스 서버 구현"을 참조하거나 아래 구현된 camel-context.xml을 참조한다.) 우선 스프링 빈 XML 파일을 설정해 보자. Maven 프로젝트로 생성한 웹 서비스 클라이언트의 src/main/resources/META-INF/spring/camel-context.xml을 다음과 같이 설정한다.

위 스프링 빈 XML 파일에서 cxf:cxfEndpoint 설정은 웹 서비스 서버의 cxf:cxfEndpoint 설정과 구조가 동일하다. 차이점은 웹 서비스 서버의 address 속성 값은 이 주소로 웹 서비스를 노출하고, 웹 서비스 클라이언트는 address 속성 값은 이 주소로 웹 서비스를 요청한다는 점이다. serviceClass 속성에는 웹 서비스 서버의 WSDL로부터 생성된 웹 서비스의 클라이언트 인터페이스를 지정한다.

카멜 라우팅 정의에서 웹 서비스는 생산자 엔드포인트다. 웹 서비스 클라이언트는 카멜의 direct 소비자 엔드포인트를 통해 웹 서비스(웹 서비스 생산자 엔드포인트)를 호출한다. 카멜에서는 생산자 엔드포인트를 동기적으로 호출하는 일관된 방법으로 direct 소비자 엔드포인트를 이용한다. 테스트 클라이언트가 오류를 처리하므로 카멜이 오류를 중간에서 굳이 가로채지 않게 라우팅 정의에 errorHandlerRef 속성을 사용해 카멜이 오류를 무시하도록 했다. errorHandlerRef 속성 값은 오류를 무시하는 noErrorHandler 빈의 참조다.

웹 서비스 클라이언트는 정상 처리와 비정상 처리를 모두 확인하기 위해 다음과 같이 두 테스트 메소드를 포함한 JUnit 테스트 클래스로 작성했다.

이 단위 테스트 클래스는 이체 한도 이내의 이체 웹 서비스 요청과 이체 한도 초과의 웹 서비스 요청을 실행한다. 웹 서비스 단위 테스트 클라이언트 클래스가 카멜의 동기 요청 호출 메소드인 request…를 이용해 direct 소비자를 호출하면 카멜은 이 요청을 웹 서비스 생산자 엔드포인트로 라우팅한다.

이체 한도 이내의 이체 웹 서비스 요청 메소드인 testSmallAmount는 정상적은 응답 객체를 수신하고, 이체 한도 초과의 이체 웹 서비스 요청 메소드인 testLargeAmount는 fault를 수신한다. testLargeAmount 메소드 예외 처리과정을 좀더 자세히 살펴보자. 앞서 웹 서비스 서버의 Payment 서비스 인터페이스는 다음과 같이 정의했었다.

위처럼 웹 서비스 서버의 인터페이스는 TransferException를 transferFunds 메소드의 예외로 지정했었다. 즉 transferFunds 웹 서비스 호출 시 TransferException를 fault로 반환하도록 지정했다. 그리고 TransferException은 다시 Fault 클래스를 포함하고, 이 클래스가 실제 fault 메시지를 포함하도록 개발했었다. 여기서 카멜과 CXF 프레임워크의 오류 처리 관례를 제대로 이해하는 것은 아주 중요하다. 카멜과 CXF를 이용한 웹 서비스 개발의 관례를 제대로 이해하지 못한다면 웹 서비스 개발에 상당한 혼란을 초래할 수 있기 때문이다. 카멜과 CXF 프레임워크의 호출 처리 흐름은 다음과 같다. 정상적인 호출인 경우 입출력 객체만 활용되므로 특별한 어려움은 없다. 그러나 fault를 응답하는 경우 상당한 주위가 필요하다. 일반적으로 카멜은 라우팅 중 발생한 예외를 붙잡아 원인으로 포함시킨 후 CamelExecutionException을 발생시킨다. 이 예의 경우 카멜 예외의 원인은 웹 서비스 호출 중 발생한 TransferException_Exception 예외가 되며, 이 예외는 다시 실제 웹 서비스 서버가 발생시킨 fault를 (여기서는 TransferException을) 감싼다. 그러므로 카멜 메소드를 이용해 웹 서비스를 호출한 클라이언트는 예외가 발생했을 때 CamelExecutionException을 잡고 CamelExecutionException에서 TransferException_Exception를 추출한 후, TransferException_Exception에서 웹 서비스 서버가 발생시킨 fault를 (여기서는 TransferException을) 추출하고, fault에서 필드를(여기서는TransferException에서 Fault 객체를) 최종적으로 추출한다.

여기서 주목할 점은 CXF 프레임워크가 서비스 우선 개발로 작성한 서비스 메소드의 자바 예외 객체를 언어 중립적인 SOAP 입출력 구조가 되도록 WSDL 표현을 자동 생성한다는 점이다. 이 과정에서 CXF 프레임워크는 웹 서비스 서버의 자바 예외를 fault 필드로 표현이 가능하도록 멤버 객체들만 WSDL의 TransferException로 옮긴다. 즉 이 과정에서 자바 예외 클래스의 구조가 사라지고 예외 객체의 멤버들만 WSLD의 fault 필드에 포함된다. 이런 이유로 해서, 이 예의 웹 서비스 서버의 WSDL로부터 생성한 웹 서비스 클라이언트의 TransferException 객체는 자바 예외가 아닌 자바 빈(bean) 클래스가 된 것이다. (이런 혼란이 발생하지 않도록 좀더 섬세하게 웹 서비스를 구축하려면 웹 서비스 어노테이션과 카멜의 예외 핸들러를 이용해야 한다. 그러나 이런 기술을 포함하는 경우 처음 웹 서비스를 맛보거나 실용적인 웹 서비스 구축을 원하는 독자들에게 지나치게 복잡한 설명을 포함해야 할 것 같아, 이에 대한 설명은 포함하지 않았다.)


13. 웹 서비스 클라이언트 실행

이제 웹 서비스를 클라이언트를 실행해 보자. 웹 서비스 클라이언트를 실행하기 전에 웹 서비스 서버를 먼저 실행해야 한다. 글의 "웹 서비스 서버 실행"을 참조한다. 웹 서비스 서버를 실행했으면, maven을 이용해 웹 서비스 클라이언트 테스트를 실행한다. 우리는 maven의 관례에 따라 JUnit 테스트 클래스를 작성했으므로, 테스트 클라이언트의 실행은 다음과 같이 간단하다.

다음은 테스트 클라이언트의 실행 결과이다.

위 결과를 보면 웹 서비스 클라이언트 JUnit 클래스는 적은 금액의 이체 요청(testSmallAmount)의 결과로는 Response 객체에 reply로 OK 값을 반환 받았고, 큰 금액의 이체 요청(testLargeAmount)의 결과로는 예외를 반환 받았다. 그리고 예외를 반환 받은 경우 웹 서비스 클라이언트는 예외 객체 안에서 실제 Fault 정보를 획득할 수 있었다. 기대했던 결과를 얻은 것이다.


14. 맺음말

우리는 이 글에서 서비스 우선 개발(service-first development) 방법으로 SOAP 웹 서비스 서버를 개발했고, 계약 우선 개발(contract-first development) 방법으로 SOAP 웹 서비스 클라이언트를 개발해 보았다. SOAP 웹 서비스 서버는 일반적인 POJO 서비스를 개발하는 절차에 카멜과 CXF 프레임워크 설정을 포함하는 30줄 이내의 스프링 빈 정의 XML을 작성하고, maven으로 camel:run 골(goal)을 실행함으로 완성했다. SOAP 웹 서비스 클라이언트는 웹 서비스 서버의 WSDL로부터 패키지와 클래스들을 생성하고, 카멜과 CXF 프레임워크 설정을 포함하는 30줄 이내의 스프링 빈 정의 XML을 추가하고, 웹 서비스 클라이언트 JUnit 테스트 클래스를 개발하여 maven의 test 단계를 실행함으로 웹 서비스 클라이언트를 테스트 할 수 있었다.

실질적으로 웹 서비스 서버를 구축하는 데 추가된 스프링 빈 정의 XML의 설정은 30줄 이내였고, 웹 서비스 클라이언트가 웹 서비스를 호출하도록 하는 데 추가된 스프링 빈 정의 XML의 설정도 30줄 이내였다. 이런 정도의 개발량으로 웹 서비스를 구축하는 방법으로는 카멜을 활용하는 것 이외는 달리 없을 것이다. 이점이 바로 카멜이 갖는 강력함이다.

이와 같이 짧은 소스나 간단한 설정으로 구축되는 기능 중심의 서비스를 마이크로 서비스(Microservice)라 부른다. 물론 마이크로 서비스가 갖는 여러 가지 특징들이 있긴 있으나, 현재 이 용어는 완전하게 정립되지는 않았다. 그럼에도 아파치 카멜은 마이크로 서비스를 구현하는 데 가장 적합한 도구라는 것을 필자를 포함해 통합 전문가들이 동의하고 있다. 앞으로는 중앙 집중식 단일 시스템에 의한 서비스들의 제공이 아닌 기능 별 분산 자치식 시스템에 의한 마이크로 서비스로의 패러다임이 다가 올 것이다. 그리고 마이크로 서비스 인프라 솔루션을 구축함에 있어, 기업 통합 패턴의 패턴 언어는 중심 방법론이 될 것이고, 아파치 카멜은 중요한 구축 도구로서 사용될 것이다.

이 글은 기업 통합 패턴 "9장 팁코 액티브엔터프라이즈를 이용한 비동기 구현"을 아파치 카멜로 대체하는 방법을 모색하던 중, 동기 호출 부분을 웹 서비스로 대체하는 과정에서 획득한 기술적인 노하우를 별도의 내용으로 정리한 글이다. 기업 통합 패턴 "9장 팁코 액티브엔터프라이즈를 이용한 비동기 구현"을 아파치 카멜로 대체한 글에 이 기술을 활용할 것이므로 이 글 이후 이후 조만간 게시할 글도 관심 있게 지켜봐 주길 바란다.


참고 사이트

시간: 댓글 2개:
라벨: , , , , , , , , ,

2014년 7월 4일 금요일

실시간 트위터 이미지 사이트 개발기 3


웹소켓(WebSocket)

웹 브라우저에서 오랫동안 사용한 통신 프로토콜은 HTTP다. HTTP는 동기 방식의 요청-응답 프로토콜로 반드시 클라이언트인 웹 브라우저가 요청해야만 서버인 웹 서버가 응답하는 프로토콜이다. 그러므로 HTTP 접속은 요청으로 시작해서 요청-응답을 반복하다가 반드시 응답으로 끝난다. 이 방식은 최초에 웹 혁명을 이끄는 데 있어서 중요한 단순성을 제공했다. 단순한 요청-응답 방식은 극단적인 수준까지 요청-응답을 처리하도록 서버를 개선하도록 했다. 범용 웹 사이트를 가능하게 하기 위해 TCP/IP 스택은 비약적으로 개선됐고, 아파치 웹 서버 같은 견고하고 성능도 좋은 서버들도 개발됐다. 사실 웹 기술이 보급되기 전까지 전통적인 클라이언트 서버 방식의 서버는 수십 클라이언트들의 접속을 처리할 수 있다면 할 일을 충분히 한다고 인정받던 시절도 있었다. 그러나 웹의 보급과 발전 덕분에 서버는 동시에 수천 접속을 유지하고 수만 요청도 처리할 수 있도록 비약적으로 진화했다. C10k 문제(일만 동시 접속 문제)라는 용어가 등장할 정도로 다수 동시 접속 처리 문제는 개발자들을 골치 아프게 했지만, 현재는 다양한 아키텍처 패턴을 이용해 이 문제를 극복하고 있다. 그러나 시대가 발전하면서 요청-응답으로는 처리하기 어려운 시나리오들도 웹 브라우저를 이용해 처리하고자 하는 요구가 끊임없이 확대됐다. 예를 들어 웹에서 실시간으로 변하는 증권 시세를 표시하려면 요청-응답 방식만으로는 해결할 수 없었다. 해결했다손 치더라도 속도나 성능 효용성이 충분하지 못했다. 그래서 자바 애플릿이나 액티브X 컨트롤을 이용해 소켓 통신으로 문제를 우회하려고도 했다. 그러나 이런 플러그인 기술들도 만족스럽지 못했고 보안 취약성이 또 다른 문제가 되기도 했다. 또 다른 예로 웹 채팅 애플리케이션이 있다. 웹 채팅을 구현하려면 Ajax 같은 복잡한 기술을 사용해야 그런대로 가능했다. 이런 방법들은 온전한 비동기 통신 기술이 아니다. 채팅은 상대방이 입력한 글이 웹 브라우저의 요청 없이도 즉시 본인의 웹 브라우저에 도착해야 하는 전형적인 비동기 통신 모델이다. 그런데 Ajax도 반드시 요청해야만 응답을 (비동기로) 수신할 수 있으므로 온전한 비동기 통신 방식은 아니다. 결국 요청-응답 방식의 HTTP 프로토콜 덕에 가질 수 있었던 단순성이 웹의 성공을 이끌었던 반면, 이 단순성은 웹 기반 비즈니스 시나리오가 확대됨에 따라 점점 부족함으로 작용하게 됐다. 완전한 비동기를 웹 브라우저에서 사용하려고 할 때, 단순함이 도리어 복잡한 Ajax 방식을 사용하게 강요한 면도 있었다. 이와 같이 확장되는 웹 기반 비즈니스 시나리오를 충족시키기 위해서는 좀더 편리한 통신 방법이 필요했다. 그리고 그 산물로 완전한 양방향 통신을 지원하는 웹소켓 프로토콜이 등장했다.

웹소켓 프로토콜은 상당히 최근에 등장했다. 2011년에서야 IETF는 웹소켓 프로토콜을 정의한 RFC 6455 문서를 표준으로 제정했다. 이에 따라 웹 브라우저들은 2011년부터 상호 호환성이 보장되는 RFC 6455 웹소켓 표준으로 웹소켓 지원을 통일했다 크롬 16, 사파리 6, 파이어폭스 11, 인터넷 익스플로러 10 이후 웹 브라우저들은 RFC 6455 웹소켓 표준을 준수한다. 웹소켓은 글자 그대로 소켓과 거의 같은 기능을 제공한다. 즉 일반적인 소켓이 제공하는 양방향 통신을 제공한다. (그러나 TCP/IP 계층보다 상위 계층 프로토콜로 독자적인 패킷 구조를 갖는다.) 그러므로 HTTP 프로토콜과 달리 접속이 완성된 후 TCP 소켓 접속처럼 서버의 우선 전송도 가능해 진다. 즉 요청-응답 순서가 클라이언트에서 서버뿐만 아니라 서버에서 클라이언트로도 가능하다. 그러므로 웹소켓은 클라이언트 풀(pull) 뿐만 아니라 서버의 푸시(push)도 어렵지 않게 제공한다. 그 결과 웹소켓은 동기 방식뿐만 아니라 비동기 방식 통신 프로토콜로 완벽하게 구현하게 하는 기반을 제공한다.

웹소켓은 HTTP 프로토콜에서 프로토콜 갱신 핸드쉐이크를 통해 웹소켓 프로토콜로 전환이 되는 구조를 가지고 있어, HTTP 표준 포트인 TCP 80 포트를 그대로 활용할 수 있다는 장점을 가진다고 한다. 그러나 이 부분에 있어서 필자는 다른 견해를 갖는데, 그 이유는 TCP 80 포트를 바인드하는 웹 서버가 HTTP 프로토콜과 웹소켓 프로토콜을 동시에 처리하려면 내부 아키텍처가 상당히 다른 두 프로토콜 스택을 서버 안에 함께 포함해야 한다. 웹소켓은 Stomp 같은 상위 프로토콜의 하부 프로토콜로 사용되기도 하는데 이 경우 또 다른 Stomp 프로토콜 스택도 웹 서버에 포함시켜야 하는 문제가 발생한다. 프로토콜 스택 개발은 웹 서버 개발과는 다른 문제일 수 있다. 그리고 아직 웹 서버들이 충분이 웹소켓을 다루는 기술이 성숙되지 않은 문제도 있다. 그러므로 웹소켓을 사용해야 한다면 웹 서버와 별도로 전용 웹소켓 서버를 운영하면서 TCP 포트를 별도로 개방하거나 방화벽 등의 정책으로 인해 접속 문제가 있을 수 있다면 별도 서버에 또 다른 TCP 80 포트를 개방해 웹소켓 서버를 운영하는 방법이 합리적이지 않을까 생각된다. 아직까지는 웹소켓의 사용 방식에 대해 뚜렷한 일관적인 방식이 등장하고 있지는 않은 것 같다.

웹소켓의 또 다른 문제는 웹소켓 위의 애플리케이션 프로토콜이 충분히 성숙돼지 않았다는 점이다. 웹소켓은 TCP 계층에 아주 얇은 층을 추가한다. 그러므로 웹소켓을 직접 사용하는 것은 마치 TCP 소켓을 직접 사용하는 것과 같다. 일반적으로 개발자들은 TCP 소켓을 직접 사용하기보다 상위 애플리케이션 프로토콜을 이용한다. 이런 예로 Telnet, Ftp, Ssh, HTTP, AMQP, OpenWire, Stomp, MQTT 등등이 애플리케이션 프로토콜이다. 그러므로 웹소켓을 충분히 잘 활용하려면 웹소켓 위의 애플리케이션 프로토콜이 많아지고 또 쓰임새도 정비돼야 한다.


실시간 트위터 이미지 사이트의 웹소켓 사용

웹소켓을 먼저 설명한 이유는 실시간 트위터 이미지 사이트도 웹소켓을 사용하기 때문이다. 실시간 트위터 이미지 사이트는 웹소켓을 아주 쓸모 있게 사용한다. 실시간 트위터 이미지 사이트의 전체적인 정보 흐름과 통신 프로토콜들은 다음과 같다.

1) 미국에 위치한 실시간 트위터 이미지 사이트의 백그라운드 Camel 서비스는 트위터에서 고양이로 트윗을 검색해 결과들을 수신한다. 2) 그 중 이미지를 포함한 트윗을 추출해 한국에 위치한 ActiveMQ 서버에 OpenWire 프로토콜을 사용해 메시지로 전달한다. 3) 메시지를 수신한 ActiveMQ 서버는 메시지를 게시 구독 방식의 토픽에 게시한다. 실시간 트위터 이미지 사이트에서 페이지를 조회한 웹 브라우저는 이미 웹소켓 위의 Stomp 프로토콜로 ActiveMQ 서버에 접속한 토픽 구독자다. 4) 토픽에 게시된 고양이 이미지 트윗 메시지 사본은 웹소켓 위의 Stomp 프로토콜을 통해 ActiveMQ 서버로부터 웹 브라우저로 비동기적으로 전송된다. 웹 브라우저는 비동기적으로 수신된 메시지를 웹 브라우저 화면에 고양이 쎔네일 이미지로 출력한다.

미국에 위치한 실시간 트위터 이미지 사이트 웹 서버의 Camel 서비스와 대한민국에 위치한 ActiveMQ 서버는 메시징 프로토콜로 OpenWire 프로토콜을 사용했다. OpenWire 프로토콜은 다양한 언어나 플랫폼에서 ActiveMQ에 접속할 수 있게 하는 메시징 프로토콜이다. ActiveMQ는 OpenWire, AMQP, XMPP, MQTT 등 다양한 메시징 프로토콜을 지원한다. 웹 브라우저와 ActiveMQ 서버는 웹소켓 위의 Stomp 프로토콜을 사용한다. Stomp 프로토콜을 사용한 이유는 WebSocket 위의 Stomp 프로토콜을 지원하는 STOMP.js라는 JavaScript 라이브러리가 있고, ActiveMQ 서버도 웹소켓 위의 Stomp 프로토콜을 잘 지원하기 때문이다. 참고로 TCP/IP 위의 Stomp 프로토콜과 웹소켓 위의 Stomp 프로토콜은 호환되지 않는다. TCP/IP 위의 Stomp 프로토콜은 Stomp 프로토콜이 TCP 계층 바로 위에 구현되는 반면, 웹소켓 위의 Stomp 프로토콜은 TCP 계층 위에 웹소켓 계층이 있고 그 위에 Stomp 프로토콜이 구현된다. 그러므로 Stomp 프로토콜을 지원한다고 해도 직접적으로 웹소켓 위의 Stomp 프로토콜로 통신할 수 없다. 문자 기반 프로토콜이어서 인지, 웹소켓 위에서 가장 구현하기 쉬워서 인지 상당히 이른 시기에 웹소켓 위의 Stomp 프로토콜은 등장했다. 한편 RabbitMQ의 기본 프로토콜인 AMQP 프로토콜이 웹소켓 위의 JavaScript 라이브러리로 개발이 된다면 웹 브라우저에서도 AMQP 프로토콜을 사용할 수 있을 것이다. 그러나 현재 RabbitMQ 쪽에서는 Node.js와 연결에 주력하고 있는 것 같다. RabbitMQ는 Node.js에서 동작하는 AMQP JavaScript 라이브러리까지만 지원하고 있다. 아마도 이 JavaScript 라이브러리는 TCP/IP 위에서 구현된 라이브러리일 것이다. 즉 AMQP 프로토콜의 하부 통신 계층이 TCP일 것이다. 그러므로 현재 웹소켓 위에서 사용할 수 있는 메시징 프로토콜 라이브러리는 STOMP.js이 유일하다. (글을 쓰면서 좀더 조사해 보니 최근 들어 웹소켓 위의 MQTT 프로토콜도 사용 가능한 것으로 보인다. 이에 대한 검토는 독자들에게 맡긴다!) 여기서 주목할 점은 메시징 프로토콜과 메시지 채널(큐, 토픽)은 서로 다른 종류의 개체라는 점이다. 즉 같은 메시지 채널이라도 여러 프로토콜로 발신, 수신, 게시, 구독이 가능하다. 실시간 트위터 이미지 사이트도 동일한 토픽에 대해 메시지 전송은 OpenWire 프로토콜을 메시지 수신은 웹소켓 위의 Stomp 프로토콜을 사용했다.

웹소켓을 사용하면 웹 브라우저를 기업 통합 솔루션의 비동기 메시징 컴포넌트의 일원으로 포함시킬 수 있게 된다. 실시간 트위터 이미지 사이트는 트위터 이미지 메시지를 비동기로 전송하는 용도로 간단하게 웹소켓을 사용했지만, 앞서 언급했듯이 웹소켓은 웹 브라우저의 요청-응답 또는 폴링 방법으로는 해결하기 어려운 실시간 비동기 정보를 손쉽게 처리할 수 있게 해준다. 예를 들어 실시간 뉴스, 실시간 대시보드, 실시간 제어, 실시간 게임, 실시간 그래프 애플리케이션 같은 것들도 웹 브라우저로 구현할 수 있는 가능성을 열어준다. 이를 위해서는 SVG(SVG(Scalable Vector Graphics)나 Canvas 같은 HTML5의 다른 기능들도 활용해야 할 것이다. 또한 필자도 웹소켓이 요청-응답 형식의 기존 HTTP 프로토콜을 완전히 대체할 수 있다고는 생각지 않는다. 기존 HTTP 프로토콜은 화면 조회, 웹 서비스, Restful, Ajax RPC 등 다양한 요청-응답 패턴을 여전히 잘 수용한다. 그러므로 웹소켓의 역할은 요청-응답 방식의 HTTP 프로토콜로는 쉽게 해결할 수 없었던 실시간 비동기 통신을 웹 브라우저에 제공함으로 웹 브라우저의 사용 범위를 넓혀주는 것으로 봐야 한다. 즉 실시간 비즈니스 시나리오가 포함된 멋진 웹 애플리케이션을 만들려면, HTTP 프로토콜과 웹소켓 프로토콜 중 어느 하나만을 고집하는 것이 아니라 서로의 장점을 함께 활용해야 한다. 편식은 언제나 몸을 해롭게 한다.

웹소켓은 표준이 2011년에 완성됐고 표준을 지원하는 브라우저도 2011년 이후 버전들이고 특히 대한민국에서 많이 사용하는 인터넷 익스플로러는 버전 10부터 지원되므로 아직은 웹소켓을 사용한 사례가 많지 않은 것도 사실이다. 그러나 웹소켓을 범용 서비스가 아닌 기업 통합 등 기업의 특화된 서비스에 이용한다면 실시간 정보의 사용에 있어서 전용 클라이언트 애플리케이션 못지 않게 훌륭한 웹 브라우저 애플리케이션을 개발할 수 있을 것이라 기대한다. 이 글을 통해 독자들도 웹소켓의 가능성에 주목할 수 있는 계기가 됐으면 한다.



참고 사이트


시간: 댓글 없음:
라벨: , , , , , , , , , , ,

2014년 4월 4일 금요일

실시간 트위터 이미지 사이트 개발기 2


시스템 구성

실시간 트위터 이미지 사이트의 웹 서버는 미 동부에 위치한 레드햇 오픈시프트 클라우드에서 운영된다. 그러나 이 서비스에 참여하는 메시징 시스템은 대한민국에 위치한다. 즉 실시간 트위터 이미지 사이트는 범세계적인 분산 시스템이다. 이 실시간 트위터 이미지 사이트의 시스템 구성은 다음과 같다.

위 구성도는 트위터 이미지 사이트의 서버 배치와 실행 순서를 설명한다. 미국 동부에 위치한 오픈시프트에서 운영되는 웹 서버는 트위터 서버로부터 실시간으로 고양이 이미지를 포함한 트윗을 추출하고 메시지로 변환하여, 이 트윗 메시지를 대한민국에 위치한 ActiveMQ 서버의 토픽으로 실시간 전송한다. 웹 브라우저는 미국 동부에 위치한 웹 서버의 트위터 이미지 웹 페이지를 조회하면서 동시에 대한민국에 위치한 ActiveMQ 서버에 웹소켓으로 접속하여 ActiveMQ의 토픽을 구독한다. ActiveMQ 서버에서 트윗 메시지는 실시간으로 토픽에 게시 중이므로 토픽을 구독하는 웹 브라우저는 ActiveMQ 서버의 토픽으로부터 트윗 메시지를 실시간으로 수신한다. 이렇게 실시간 트위터 이미지 사이트에서 “고양이를 보여줘” 웹 페이지에 접근한 웹 브라우저는 두 대륙에 걸쳐 분산되어 있는 서버들을 이용한다.

실시간 트위터 이미지 사이트의 아키텍처가 일반적인 웹 서비스의 아키텍처와는 다른 점은 분산 아키텍처를 위해 ActiveMQ라는 메시징 시스템과 웹소켓 기술을 추가로 사용했다는 점이다.

이 글을 읽는 독자는 왜 일반적인 웹 서비스 아키텍처를 사용하지 않고, 메시징 기반의 아키텍처를 추가로 이용한 것일까? 라는 의문을 가질 수 있을 것이다. 일반적으로 웹 서비스는 요구-응답 방식에 적합한 아키텍처이다. 실시간 트위터 이미지 사이트처럼 지속적으로 데이터 스트림을 처리해야 하는 아키텍처 모델로는 적합하지 않다. 적합하지 않다라는 뜻은 웹 서비스의 요구-응답 통신은 동기 통신 기술로 지속적인 메시지 흐름을 갖는 비동기 통신을 구현하기 위해서는 기술적인 어려움과 복잡성을 부가해야 한다라는 말이다. 또한 요구-응답 방식의 서비스로는 게시-구독 방식의 서비스를 구현하는 것이 쉽지 않다. 더 나아가 메시지의 흐름 제어를 처리하는 것도 쉽지 않다.

반면 메시징 시스템을 이용하는 경우, 참여 시스템들은 느슨한 결합 아키텍처(loosely coupled architecture) 구조를 갖게 된다. 메시징 시스템을 통해 비즈니스 로직들이 서로 분리되어 시스템들 사이 상호 의존성이 감소한다는 말이다. 실시간 트위터 이미지 사이트는 ActiveMQ 메시징 시스템을 이용하여 웹 브라우저와 웹 서버 사이 단단하게 결합될 수 있었던 트위터 비즈니스 로직을 독립적으로 동작 가능하게 분리했다. 그 결과 실시간 트위터 이미지 사이트는 웹 서버의 중단이나 이전 없이 비즈니스 로직을 다른 서버로 이전하거나 심지어 다른 대륙에 위치시킬 수도 있게 됐다. 필자는 실시간 트위터 이미지 사이트를 디버깅하는 과정에서 필자의 PC로 비즈니스 로직을 이동시켜 디버깅을 진행하기도 했다. 디버깅을 위해 비즈니스 로직을 이동시킨 가장 큰 이유는 PAAS 환경이 디버깅이 용이하지 않은 점이 있었기 때문이었다. 단단히 결합된 아키텍처(tightly coupled architecture)를 가진 웹 서비스 방식이었다면, 디버깅을 위해 서비스를 옮기는 경우, 좀더 많은 설정이나 프로그램의 변경이 수반됐을 것이다. 또한 메시징 시스템을 이용하면 실시간 데이터의 비동기적 처리가 가능하다. 즉 데이터 생산자와 데이터 소비자가 메시징 시스템을 매개로 분리됨으로 메시지 수신과 발신이 독립적으로 발생할 수 있게 된다. 그 결과 발신자는 수신자의 대기 없이도 지속적으로 생성한 메시지를 메시징 시스템으로 전송할 수 있고, 수신자는 발신자의 메시지 발신 속도와 무관하게 자신의 처리 속도에 따라 메시징 시스템으로부터 비동기적으로 메시지를 수신하고 처리할 수게 된다. 메시징 시스템을 이용하면 게시-구독 서비스도 구현하기가 쉽다. 가장 대표적인 게시-구독 패턴은 그룹 채팅이다. 그리고 이전 글에서도 언급했듯이 실시간 복수 소비자들이 주가 변화를 지속적으로 수신하는 것과 같은 비즈니스를 쉽게 구현할 수 있게 해 준다. 그리고 ActiveMQ 메시징 시스템의 경우 새롭게 등장한 웹소켓과의 결합도 쉽게 해준다. 실시간 트위터 이미지 사이트에 접속한 웹 브라우저는 웹소켓의 상위 프로토콜로 메시지 프로토콜인 STOMP 프로토콜을 이용하여 대한민국에 위치한 ActiveMQ 메시징 시스템에 직접 접속한다. 웹 브라우저는 이 접속 채널을 통해 비동기적으로 트윗 메시지를 ActiveMQ 메시징 시스템으로부터 지속적으로 수신하여 웹 페이지에 이미지를 표시한다.

실시간 트위터 이미지 사이트는 어떤 패턴의 비즈니스로 발전할 수 있을 지를 생각해 보자. 첫째, 실시간 트위터 이미지 사이트는 트위터에서 실시간으로 트윗을 추출 방법을 보여 준다. 그러므로 이 사이트는 트위터에서 발생하는 유행들을 실시간으로 분석하거나 추출, 저장하는 용도로 쉽게 변경될 수 있다. 필자는 개발 과정에서 사용자가 입력한 검색어를 이용하여 실시간으로 트위터에서 이미지들의 추출하여 표시하는 웹 페이지도 개발했다. 그러나 이 웹 페이지는 사용자들의 과도한 검색으로 트위터의 채널 할당량 정책을 초과할 수 있어 공개하지는 않았다. 검색어를 이용해 트윗 결과를 실시간으로 획득할 수 있는 기능을 이용하면 트위터로부터 필요한 유행 정보를 좀더 쉽게 획득할 수 있을 것이다. 둘째, 실시간 트위터 이미지 사이트는 ActiveMQ 메시징 시스템이 대륙 간의 메시지 통신에도 잘 사용될 수 있다는 것을 보여준다. 그러므로 여러 지역에 분산된 본점과 지점들 사이 메시지 통신이 필요한 비즈니스 모델에 ActiveMQ 메시징 시스템을 이용할 수 있다. 셋째, 실시간 트위터 이미지 사이트는 웹소켓을 이용하여 웹 페이지에 실시간으로 이미지를 보여줄 수 있다는 것을 보여준다. 그러므로 웹 페이지에 실시간 정보를 표시하는 비즈니스는 웹소켓 기술을 이용할 수 있을 것이다. 예를 들어 웹 페이지에 채팅 메시지 서비스를 제공한다든지, 웹 페이지에 주가를 실시간으로 표시하는 서비스를 제공한다든지, 웹 페이지에 비즈니스 이벤트를 모니터링하는 서비스를 제공한다지 등등 웹 페이지에 실시간으로 데이터 전달이 필요한 어떤 비즈니스에도 응용될 수 있을 것이다.

이 글을 통해 독자들은 실시간 트위터 이미지 사이트가 보기와 달리 범 대륙적인 분산 시스템으로 메시징 시스템과 웹소켓을 이용해 이미지가 포함된 트위터를 실시간으로 추출 및 전송하고 웹 화면에 이미지를 실시간으로 표시하는 시스템이라는 것을 알았을 것이다. 이상으로 실시간 트위터 이미지 웹 사이트의 시스템 구성에 대한 설명을 마친다.



참고 사이트


시간: 댓글 없음:
라벨: , , , , , ,

2014년 3월 28일 금요일

실시간 트위터 이미지 사이트 개발기 1


들어가며

우리는 가끔 노래 가사처럼 덜컹거리는 기차를 타고 어디론가 떠나며, 차창 밖에 보이는 풍경을 느긋이 감상하고 싶을 때가 있다. 우리는 가끔 우리가 좋아하는 관심사를 보며 마음을 정화시키기도 한다. 일반적으로 사람들은 관심사를 중심으로 세상의 흐름을 읽는다. 사랑, 행복, 월드컵, 올림픽, 전쟁, 선거 등등 그러나 이런 관심사들을 일일이 찾아 다니는 것도 귀찮은 일이다. 그래서 우리는 TV 앞에 모여든다. 생각하지 않아도 알아서 찾아주고 보여주니 편하다. 그런데 우리가 이렇게 편안하게 우리의 관심사를 둘러보기 위해서는 어디선가, 누군가는 일을 해야 한다. 그것이 자발이던, 지시건, 사람이건, 컴퓨터건, 기계건, 누군가는 편안함을 위해 일해야 한다.

재작년에 런던 올림픽 당시 관람객들은 스스로 영광의 순간을 찍은 사진들을 사회 관계망 서비스를 이용하여 순식간에 인터넷으로 전세계에 확산시켰다. 그 중 트위터는 독보적이었다. 이 영광의 순간들은 트위터로 실시간으로 트윗되었고, 신문, 방송 기사들조차 이 순간을 전달에 트윗을 이용했다. 그러나 당시 트위터로 올라오는 트윗과 리트윗들은 올림픽에 관련된 것뿐만 아니라, 일상 관심사에 대한 것들로 뒤섞여 있었고 올림픽 사진뿐만 아니라 다양한 일상의 사진들도 포함되었다. 올림픽에 관심이 많은 사람일지라도 일일이 트위터에서 올림픽의 순간이 포함된 트윗만을 찾아 보는 것은 쉽지 않았다. 결과적으로 사람들은 올림픽의 영광의 순간을 그 순간이 아닌 이후 매체나 글자가 뒤섞인 트윗을 통해야 확인해야 했다. 그런데 이런 지구적인 이벤트에서 영광의 순간을 가장 빨리 편안하게 보려면 어떻게 해야 할지를 고민한 개발자가 있었다.

이 개발자는 올림픽의 순간을 보기 위한 웹 페이지를 개발했다. 그리고 그는 이 웹 페이지 개발에 Apache Camel 통합 프레임워크를 이용했다. 이 웹 페이지는 실시간으로 올라오는 올림픽의 영광의 순간을 담은 트윗들에서 사진들을 별도로 모아 보여주었다. 이 웹 페이지 프로젝트가 통합 커뮤니티에 알려지면서 커뮤니티는 웹 페이지 개발자에게 찬사를 보냈고 통합의 가치에 자부심을 가지게 되었다.

다음은 당시 이 웹 페이지가 보여주었던 화면이다.

이 웹 페이지는 실시간으로 올라오는 수많은 트윗들 중에서 런던 올림픽과 관련된 트윗을 검색하고 찾아낸 결과 트윗들 중 이미지를 포함한 트윗에서 위 화면처럼 웹 페이지에 썸네일 이미지를 보여준다. 그리고 썸네일을 클릭하면 원래 이미지가 나타난다. 올림픽 사진들은 최소 5초마다 계속 페이지에 추가된다. 놀라운 점은 이 웹 페이지가 중복된 사진을 실시간으로 걸러준다는 것이다. 즉 웹 페이지를 감상하는 사람에게 같은 이미지로 도배된 웹 페이지의 보여 주지 않음으로 영광의 순간들을 하나 하나 의미 있게 한다. 마치 기차를 타며 어딘가를 갈 때 창 밖으로 계속 바뀌는 풍경을 감상하는 것처럼 이 웹 페이지는 지나가는 풍경과 같은 감성을 조회자들에게 전달한다. 그 결과 이 사이트에 접속한 사람들은 올림픽의 순간을 마치 TV처럼 사진으로 편안하게 즐길 수 있었었다.

그런데 기술적으로도 놀라운 점은 이런 멋진 웹 페이지의 핵심 로직의 구현에 단지 수십 줄의 코드가 사용됐다는 점이다. 핵심 로직에 단지 23줄이 사용됐다. 이것은 일반 개발자들뿐만 아니라 통합 개발자들에게도 신선한 반향을 일으켰다. 이 핵심 코드는 다음과 같다.

이 코드는 Apache Camel 프레임워크의 라우팅에 대한 정의이다. 이 핵심 로직을 간단히 설명하면 다음과 같다. 검색어를 이용해 트위터로부터 실시간으로 트윗 결과들을 얻은 후, 이미지가 포함된 트윗을 선별하고, 선별된 트윗의 중복을 배제하고, 이미지를 포함한 정제된 트윗은 5초 동안의 여유가 적용된 수 후 웹소켓에 접속한 페이지들에게 브로드캐스트된다.

위와 같은 핵심 로직을 일반적인 웹 개발 방법을 사용하여 구현한다면 어떤 기술과 얼마의 자원과 시간이 필요할까? 아마도 기술을 깊이 이해하고 있는 개발자나 아키텍트라면 단언하기 쉽지 않을 것이다. 그런데 이런 핵심 기능을 23줄이 가능하게 했다. 통합 커뮤니티에서조차도 이 프로젝트가 통합을 창의적으로 적용한 것에 대해 열광했다. 필자가 볼 때도 이 핵심 로직은 프로그램이기보다 시에 가깝다. 이 프로젝트의 개발자는 "Instant Apache Camel Messaging"이란 책을 쓴 실력자이다.

그런데 올림픽은 끝나면서 올림픽의 순간들은 사람들에게 잊혀져 갔고, 아마존의 공짜 마이크로 인스턴스에서 운영되던 이 사이트도 폐쇄되었다. 아마존은 마이크로 인스턴스를 약 한 달인 750시간까지 사용할 수 있게 해준다. 결국 올림픽이 끝나면서 웹 페이지가 동작되던 마이크로 인스턴스의 생애도 끝나버렸다. 필자처럼 이 웹 페이지 개발자도 공짜를 몹시 밝히는 사람인 것 같다. 그의 블로그를 보면 무려 10달러를 사용했다는 것을 글에 남길 정도로 그도 짠돌이다. 그러나 이런 집착은 오픈 소스를 이용한 개발자들의 미학이다.

필자가 이 프로젝트에 다시 관심을 가진 이유는 얼마 전 레드햇의 오픈시프트 퍼블릭 클라우드 사이트에 가입했기 때문이었다. 현재 레드햇의 오픈시프트 퍼블릭 클라우드는 온라인 가입자들에게 놀라운 정책을 제공하고 있다. 이 놀라운 정책이란 무려 3개의 기어라고 불리는 가상 PAAS 서버를 무료로 사용하게 해 준다는 것이다. 각 기어 당 메모리 512M, 디스크 1G까지 네트워크 트래픽에 대한 언급은 없으므로 무제한(?)을 제공해 줄 것으로 생각된다. 필자가 가지고 있는 라즈베리 파이만한 기계를 가상 환경이지만 3개나 공짜인 제공한다는 것이다. 아마존 웹서비스의 마이크로 인스턴스 정책과 비교해 보라. 정말로 파격적인 정책임을 알 수 있다. 아이러니 한 점은 레드햇의 오픈시프트 클라우드가 아마존 웹서비스 클라우드에서 운영된다는 점이다. 그것도 SUSE Linux로…… 필자는 오픈시프트 기술에 대해 검토하면서 "그래 공짜 서버가 생겼는데 놀리면 안되겠다"라는 생각을 했다. 그러면서 위에 설명한 올림픽의 영광의 순간을 담는 웹 페이지를 필자의 방식대로 새로 만들어 이곳에서 운영하면 좋겠다고 생각하고 만들어 보았다.

다음은 필자가 개선한 새로운 실시간 트위터 이미지 웹 페이지다.

들어가는 글은 이 정도로 마치고 이어지는 글에서는 필자가 실시간 트위터 이미지 웹 페이지를 개발하면서 분석하고, 고민하고, 개선하고, 결정했던 이야기들을 하려고 한다.



참고 사이트


시간: 댓글 1개:
라벨: , , , , ,

2013년 11월 11일 월요일

메시징 매퍼


메시징 매퍼 패턴


기업 통합 패턴(Enterprise Integration Patterns)은 메시징 매퍼(Messaging Mapper) 패턴에 대해 설명한다. 이 패턴은 다음과 같은 상황을 해결한다.


도메인 객체와 메시징 인프라의 독립성은 유지하면서, 이들 사이에 데이터를 이동시키려면 어떻게 해야 할까?

위에서 "도메인 객체와 메시징 인프라의 독립성은 유지하면서"란 말은 메시징 매퍼는 도메인 객체와 메시징 인프라 모두에게 독립적으로 동작해야 한다는 말이다. 즉 도메인 객체에 메시징 매퍼와 관련된 API 등을 포함하지 말아야 하고, 메시징 인프라도 특정 메시징 매퍼에 의존하도록 결합되면 안된다는 의미이다. 그리고 "이들 사이에 데이터를 이동시키려면"이란 말은 도메인 객체를 메시지로 상호 변환할 수 있어야 한다는 말이다. 그 결과 메시징 매퍼는 전략 패턴(Strategy Pattern)에서 알고리즘처럼 도메인 계층과 메시징 인프라 계층 사이에 삽입되며, 대체 가능한 구조를 가지게 된다.

메시징 매퍼(Messaging Mapper) 패턴과 메시지 변환기(Message Translator) 패턴은 모두 변환에 관련된 패턴이다. 기업 통합 문제를 해결함에 있어, 이 두 패턴을 정확히 이해하고 사용해야 한다. 그렇지 않으면 필요한 패턴을 서로 반대로 사용하게 될 수도 있기 때문이다. 이 두 패턴은 계층 내의 이동과 계층 사이의 이동을 기준으로 구분된다. 즉 메시지 변환기 패턴은 메시징 인프라 계층 내에서 메시지가 또 다른 메시지로 변환될 때 사용되고, 메시징 매퍼 패턴은 메시징 인프라 계층의 메시지가 도메인 계층의 객체로 변환될 때 사용된다. 이 구분을 그림으로 표현하면 다음과 같다.

그러나 메시지 변환에 여러 요소들이 개입되거나 복잡한 변환이 요구되는 경우, 출발 메시지를 도메인 객체로 변환한 후 내용 보탬이(Content Enricher)이나 내용 필터(Content Filter)를 이용하여 메시지 내용을 보강한 후, 목적 메시지로 매핑할 수도 있다. 이 경우 메시지 변환의 중간 단계에서 메시징 매퍼가 필요할 수 있다. 이런 경우 두 패턴은 서로 밀접하게 관련된다.

도메인 객체와 메시지의 매핑은 계층 사이의 변환이므로 동일 계층 내의 메시지 변환보다 더 많은 제약 사항이 따른다. 예를 들어 도메인 객체의 참조를 메시지의 필드 값으로 변환해야 하고, 필요한 경우 메시지의 필드 값을 객체 참조로 변환해야 한다. 일반적으로 메시지는 객체처럼 참조 정보를 자유롭게 포함할 수 없기 때문이다. 또 객체는 가변적인 크기를 갖는 컬렉션 형식의 데이터도 표현이 자유로운 반면, 메시지로는 가변적 데이터를 다루기가 쉽지 않을 수 있다.

메시지에 대응되는 객체마다 별도의 프로그램으로 메시징 매퍼를 구현할 수 있다. 이 방법은 가장 간단하기는 하지만, 매핑해야 할 대상이 많은 경우, 개발하기도 어렵고 유지 보수도 어려워진다. 일반적으로 메시지와 객체 사이의 매핑에는 일정한 규칙이 있다. 그리고 특별한 규칙이 있을 수 있고, 필요한 경우 데이터 형식의 변경을 요구할 수도 있다. 만약 이런 정보를 매핑 정의 데이터로 작성하고, 이 정의 데이터를 이용하는 매핑 프레임워크가 개발할 수 있다면, 메시징 매퍼 패턴에 부합되는 구조를 만들기가 더 쉬워질 것이고, 프레임워크화된 메시징 매퍼를 사용하는 프로그램은 좀더 쉽게 메시지와 객체를 매핑할 수 있게 될 것이다. 그러나 매핑 구조를 정의하는 것이 간단하지 않고, 이 정의를 이용하는 프레임워크를 개발하는 것은 많은 시간과 비용이 필요한 일이다.

그동안 메시징 매퍼를 일반화하기 위해 즉 라이브러리나 프레임워크 등 표준 기술을 만들기 위해 많은 노력이 있어 왔다. 그 중에 우리나라의 상황을 돌이켜 보면, 우리나라는 이상하리만치 매핑 정의를 프로그램 로직이나 데이터베이스 테이블로 관리하는 경우를 많이 보게 된다. 일반적으로 소규모 프로젝트는 프로그램 로직이 많이 사용되는데, 이 경우 규모에 맞지 않게 도리어 개발과 유지 보수에 많은 비용과 시간이 들게 된다. 대형 프로젝트에서는 매핑 정의에 데이터베이스를 활용하는 경우가 많은데, 이 경우 데이터베이스 서버를 이용하지만 변경에 따른 프로그램들 사이의 결합을 낮추지도 못해 메시지 포맷이나 객체 구조가 변경된 경우 변경해야 할 대상이 추가적으로 많아져 변경 비용만 추가되는 부작용들이 발생하게 된다. 즉 개발과 유지 보수에 모두 특별한 생산성을 제공해 주지 못한다. 물론 데이터베이스 매핑 정의는 관리 화면을 통해 관리할 수 있는 장점이 있을지 모르지만, 전문의 등록과 변경은 그리 빈번한 작업이 아닌 경우가 많고, 일반적으로 매핑 정의의 변경은 도메인 객체와 도메인 로직의 수정도 수반한다.

메시지 변환에 대해 가장 합리적인 접근은 첫째 객체로 변환하기 쉬운 구조의 메시지 구조를 정의하는 것이고, 둘째는 도메인 객체의 구조를 단순하게 유지하는 것이고, 셋째는 매핑 정의 데이터가 단순하고 이해하기 쉬운 구조를 가지게 하는 것이고, 넷째는 매핑 엔진의 성능을 최적화 하는 것이고, 마지막으로 각 요소의 결합도를 낮추어 느슨한 결합구조를 갖게 하는 것이다. 이런 방향에 대한 많은 노력으로 만들어진 해결책으로는 TLV(Tag Length Value) 구조, ASN.1, BER, DER, Java Serialization, Protocol Buffers, XML, XSLT, JAXB, DOM, SAX, JSON 등등의 기술들이다. 그러나 불행하게도 우리라에서는 여전히 고정 길의 메시지 구조가 자주 선호되고 있고, 매핑 정의는 데이터베이스에 관리되는 방식이 선호되고 있고, POJO 또는 Bean과 같은 단순한 도메인 객체에 대해서는 잘 알지 못하고 있다. 최근에 가장 선호되는 메시징 인프라 계층의 메시지 구조는 JSON 포맷이다. JSON 포맷은 XML보다 도메인 객체로 매핑하는 속도가 현저히 빠르고, JSON 메시지는 별다른 도구 없이도 직접 해석도 가능하고, 웹 환경에서 서버와 클라이언트 모두 잘 이해하는 포맷이기 때문이다.

새로운 기업 인프라나, 차세대 프로젝트나, 리노베이션 프로젝트를 시작하는 경우, 기업은 미래 지향적인 메시지 포맷을 정의하는 것이 합리적일 것이다. 그러나 이런 경우에도 레거시 시스템과 인터페이스해야 하는 경우, 이미 서비스 중인 외부 기관과 통신해야 하는 경우, 해당 시스템의 메시지 포맷을 준수해야 할 필요가 있다. 그러므로 기업 통합의 입장에서 다양한 메시지 포맷의 지원은 필수불가결한 요소이다.


메시징 매퍼의 구현


원론적인 내용은 실무에서 그다지 중요하지 않을지라도 원론에 대한 이해를 바탕으로 실무를 적용해야 합리적인 실무를 구성할 수 있다. 이런 점 때문에 앞서 메시징 매퍼에 대해 원론적인 문제를 잠시 언급했다. 이제 실무적으로 접근해 보자. 이제 개발자들이나 솔루션 아키텍트들에게 도움이 될만한 프로그램에 대해서 설명할 것이다.

실제적인 접근을 위해 실무에서 사용 중인 고정 길이 메시지에 대한 메시징 매퍼를 구현해 보려고 한다. 이 글의 메시징 매퍼는 금융보안연구원에서 발행한 "OTP 전문 기술규격 v1.2"에서 사용되는 메시지들 중 256 바이트 고정 길이의 "OTP 인증 업무 전문"을 도메인 객체로 매핑해 볼 것이다. "OTP 인증 업무 전문"의 메시지 구조는 다음과 같다.

구분 NO DATA 항목 TYPE 길이 SET 비고
요구 응답
공 통
정보부 		0 전문길이 N 4 ○ * 0252
1 트랜잭션코드 AN 6 ○ *
2 전문종별코드 N 4 ○ ○
3 거래구분코드 N 6 ○ *
4 테스트구분 AN 1 ○ *
5 송수신코드 AN 1 ○ ○
6 미통지존재여부 N 1 - ○
7 응답코드 AN 4 - ○
8 요구기관코드 AN 5 ○ *
9 기준일자 N 8 ○ *
10 전문일련번호 N 8 ○ *
11 업무일련번호 N 8 △ *
12 응답기관코드 AN 5 ○ *
13 전문전송일자 N 8 ○ *
14 전문전송시간 N 6 ○ *
15 세션정보 N 5 △ *
16 센터예비필드 AN 15 △ *
17 기관예비필드 AN 20 △ *
업무
공통부 		18 OTP인증벤더코드 AN 3 ○ *
19 사용자식별코드 AN 40 △ *
20 OTP일련번호 AN 12 ○ *
업무
개별부 		21 OTP 응답값 AN 8 ○ -
22 타기관 사고회복 여부 N 1 - ○
23 오류횟수 N 2 - ○
24 Offset AN 16 - -
25 마지막인증성공일자 N 8 - -
26 마지막인증성공시간 N 6 - -
27 마지막제출OTP응답값 AN 8 - -
28 예약 AN 37 - -

참고) A: 영문자 (Alphabetic Characters), N: 숫자 (Numeric Characters)

이 글의 메시징 매퍼는 Apache Camel, Spring, BeanIO, Apache Commons Lang 등의 프레임워크와 라이브러리를 사용한다. 그리고 처리 흐름과는 상관없지만 camel-stream를 이용하여 라우팅 중의 메시지를 표준 출력으로 출력한다. 이 프레임워크와 라이브러리들을 위해 다음 Maven 의존이 필요하다.

메시징 매퍼의 소스는 camel.example.beanio 패키지 아래 있다. Eclipse 환경에서 프로그램을 컴파일하고 실행할 수 있도록 프로그램 소스를 Eclipse 프로젝트로 GitHub에 올려 놓았다. 아래 참고 사이트의 프로그램 소스를 참고하기 바란다. Maven을 설치했다면, Eclipse 환경에서 프로그램 소스를 열지 않고도, 다음과 같이 명령창에서 Maven을 이용하여 컴파일과 실행이 가능하다.

먼저 메시징 매퍼를 호출하는 클라이언트 프로그램을 보자. 아래 클라이언트 프로그램은 Apache Camel을 이용하여 서버의 서비스를 호출한다. 이 과정의 내부에서 메시징 매퍼가 동작한다.

클라이언트 클래스는 main 메소드에서 Camel 프레임워크가 제공하는 Main 객체를 생성하고, 발신(생산자) 객체인 ProducerTemplate을 획득한 후, 요청 도메인 객체를 생성하고, 요청 도메인 객체에 필요한 값을 지정한 후, ProducerTemplate 객체를 이용하여 요청 도메인 객체를 서비스 서버를 호출하고, 응답 도메인 객체를 반환 받는다. 이 클라이언트 클래스는 일반적인 POJO 구조의 클래스로 도메인 객체만 인식하고 메시징 매퍼나 메시지 인프라는 전혀 인식하지 않는다. 즉 코드에 메시지나 서비스 서버에 대한 API들이 전혀 등장하지 않는다.

이 클라이언트의 실행 결과는 다음과 같다.

요청 도메인 객체, 요청 메시지, 응답 메시지, 응답 도메인 객체의 정보가 표준 출력으로 출력된다. 중간에 문자열로 표시된 두 메시지가 요청 메시지와 응답 메시지이다. 이 출력에서 요청 메시지는 메시징 매퍼가 요청 객체를 마샬링(매핑)한 결과이고, 응답 메시지는 메시징 매퍼가 응답 객체를 마샬링(매핑)한 결과이다.

메시징 매퍼의 구현보다 메시징 매퍼의 클라이언트와 실행 결과를 먼저 설명하는 이유는, 필자가 구현하는 메시징 매퍼와 프로그램 구조를 따르면 클라이언트는 메시지나 메시징 인프라에 대해 전혀 인식하지 않아도 된다는 점을 강조하기 위해서이다. 즉 클라터이언트 도메인 계층과 메시지 매핑을 포함한 메시징 인프라 계층은 완전히 느슨한 결합(loose coupling) 구조를 가지게 된다.

실행 결과를 확인했으므로 이제 메시징 매퍼의 구현에 대해 구체적으로 살펴보자. 메시징 매퍼를 구현하기위해 BeanIO 프레임워크를 사용한다. BeanIO 프레임워크는 자바 Bean을 Flate 구조의 스트림으로 변환하는 프레임워크이다. 이 프레임워크는 Apache License를 따른다. 이 프레임워크와 기능이 유사한 Smooks 프레임워크가 있는데, 이 프레임워크는 GNU 라이선스이다. 그러므로 BeanIO가 Smooks보다 라이선스의 활용 면에서 더 자유롭다. 그리고 메시징 매퍼 패턴의 입장에서 BeanIO가 Smooks보다 좀더 현대적인 구조의 매핑 정의 구조를 가지고 있다. 그리고 Apache Camel에서도 BeanIO에 대한 언급이 더 많다. 아마도 라이선스 문제 때문에 GNU 라이선스 기반인 Smooks를 Camel 프로젝트에 포함하여 언급하기 힘든 면도 있을 것이다. 그리고 재미있는 사실은 이 두 프레임워크 모두 자신들 스스로도 메시징 매퍼의 구현체이라는 것을 정확인 인지하고 있지 못하다는 점이다. 물론 이 두 프레임워크는 메시징 매퍼로서 뿐만 아니라 파일 스트림, 문자열, CVS, XML, EDI 등 다양한 외부 데이터에 대한 매핑도 지원한다. 그러므로 패턴이란 문제 상황에 대한 일관되고 반복적인 해결책인 점을 생각해 본다면 이들 프레임워크들의 구현 방법이 거꾸로 패턴으로 인식된 것으로도 볼 수 있을 것이다.

BeanIO는 메시지와 도메인 객체 사이의 매핑 정의에 XML 파일을 이용한다. 위 "OTP 인증 업무 전문"을 BeanIO의 매핑 정의로 표현하면 다음과 같이 표현된다.

매핑 정의 파일에서 공통 정보부는 모든 메시지가 공통으로 포함하는 헤더 부분이므로 템플릿(template)으로 만들었다. 템플릿을 활용하면 메시지 헤더와 같은 공통 부분의 매핑 정의가 단순해진다. BeanIO 매핑 정의에서 각 필드는 필요에 따라 정렬 방식, 공백 채움 문자도 정의 할 수 있고, 데이터의 포맷도 정의할 수 있다. 메시지가 반복부를 가지는 경우를 표현하는 최소, 최대 발생 값을 지정할 수도 있다. 메시지는 record 태그를 이용하여 도메인 객체로 매핑한다. segment 엘리먼트를 이용하면 메시지의 일부도 도메인 객체로 매핑할 수 있다. Record와 segment 태그에 class 속성으로 도메인 객체의 클래스를 지정한다. 이 매핑을 그림을 표현하면 다음과 같이 표현된다.

위 그림에서 Msg0200200101 객체는 요청 도메인 객체이고, Msg0210200101 객체는 응답 도메인 객체다. 각 도메인 객체는 내부에 공통 정보부의 값을 포함하는 Header 객체, 업무 공통부 값을 포함하는 BodyCommon 객체, 업무 개별부를 포함하고 있는 Body200101 객체를 포함한다.

이제 도메인 객체의 구조에 대해 살펴보자. 도메인 객체 클래스인 Msg0200200101의 정의는 다음과 같다. (이곳에서는 클래스를 정의하는 방법에 대해서 설명하므로, 나머지 클래스들에 대해서는 참고 사이트의 프로그램 소스를 참고한다.)

Msg0200200101 클래스는 요청 객체 클래스로 요청 메시지의 세 개의 영역에 대응되는 멤버 객체들을 포함한다. 여기에서 주목할 점은 Msg0200200101 클래스의 일반적인 자바의 Bean 클래스 정의와 달리 마치 C 구조체 정의처럼 설정자(setter)와 획득자(getter)가 없이 public 멤버들만 포함한다는 점이다. 이와 같이 객체를 정의해도 자바의 리플렉션을 활용하는 BeanIO 프레임워크는 해당 멤버 객체의 설정과 획득을 자동으로 처리한다. (매뉴얼에는 설정자와 획득자를 지정하고 Bean 생성자도 포함하라고 언급되어 있지만 위와 같이 간략하게 클래스를 정의해도 잘 동작한다.) 그리고 또 하나 주목해야 할 부분은 객체를 문자열로 변환하는 toString 메소드이다. 이 메소드는 Apache Commons Lang 라이브러리를 이용하는데, 이 라이브러리의 ReflectionToStringBuilder 메소드는 자바 리플렉션을 이용하여 각 멤버들을 자동으로 문자열로 변경해 준다. 위 실행 결과에서 Request Object와 Response Object의 표준 출력 결과과 ReflectionToStringBuilder 메소드가 만든 출력의 결과이다. 이와 같은 방법으로 도메인 객체 클래스를 정의하면 도메인 객체 클래스 정의가 굉장히 수월해 진다. 게다가 C 구조체와 유사한 Bean(POJO) 구조의 도메인 객체를 사용함으로, 도메인 객체 구조로 많이 사용되는 맵(Map)이나 DOM보다 객체 당 메모리 사용도 절약되고 IDE의 자동 코드 오류 검증도 가능하게 되어 개발 생산성이 향상된다.

다음은 Msg0200200101 클래스의 멤버 변수 중 하나인 Header 객체의 클래스 정의이다.

Header 클래스도 특이한 멤버들을 포함하고 있다. 즉 한글 이름을 가진 멤버 객체들을 가지고 있다. 자바는 유니코드 기반의 언어이므로 이렇게 한글로 변수를 정의해도 정상적으로 동작한다. 그리고 이 클래스도 Msg0200200101 클래스와 마찬가지로 C 구조체와 유사한 Bean(POJO) 구조의 클래스이다. 이 한글 멤버 변수는 전문 규약에서 사용되는 메시지 필드의 한글명과 직접 대응된다. 이렇게 데이터의 저장이나 이동을 위한 도메인 객체의 멤버 변수를 한글로 지정하면, 프로그램의 가독성도 높아지고 영문 작명에 따른 불필요한 노력도 제거된다. 이 클래스에는 정수, 문자열, 날짜 등의 데이터 형의 멤버 변수들이 정의되는데, BeanIO의 mapping 정의에 따라 메시지 필드가 지정된 형식의 데이터 형의 멤버 객체로 변환되거나 관례(CoC: Convention over Configuration)에 따라 자동으로 메시지 필드가 멤버의 데이터 형으로 변환된다.

Msg0200200101 객체는 서비스를 처리하는 Service0200200101 클래스에서 다음처럼 사용된다.

Service0200200101 클래스는 POJO 형식의 클래스로 Msg0200200101 객체를 입력 파라미터로 받아 서비스를 처리한 후 생성한 Msg0210200101 객체를 응답으로 반환한다. 위 예에서는 단순히 요청 객체를 응답 객체의 참조로 사용하면서 필요한 부분의 응답 값들을 지정했다. 그리고 이 과정에서 각 멤버 객체의 속성을 획득자(getter)없이 직접 참조했다. 이것이 가능한 이유는 도메인 객체로 사용되는 클래스들을 C 구조체와 비슷하게 public 멤버를 포함한 Bean(POJO) 클래스로 정의했기 때문이다. 그리고 이 서비스 클래스도 앞서 설명한 클라이언트 클래스처럼 메시지 구조에 대해서도 전혀 알지 못한다는 점을 주목해야 한다. 즉 서비스 클래스가 동작하는 도메인 계층과 메시지가 이동하는 메시징 인프라가 완전히 분리되어 있다. 도메인 계층과 메시징 인프라와 완전히 분리되면 도메인 계층의 객체들은 원격지의 서버나 클라이언트 없이도 Unit 테스트가 가능해진다. 이 경우 서비스 개발자는 서비스 클래스를 클라이언트 개발자는 클라이언트 클래스를 상대방의 개발 일정이나 진척 상황에 상관없이 각자 독립적으로 개발하면서 Unit 테스트까지 진행할 수 있게 된다. 그리고 두 개발자들 사이의 통합 테스트는 각자의 Unit 테스트가 완료된 후 진행하면 된다. 즉 도메인 객체만을 이용하는 POJO 형식의 클래스는 개발자들 사이의 결합도를 낮춤으로 동시에 병렬 개발을 가능하게 하고 Unit 테스트를 집중적으로 진행할 수 있게 함으로 개발 생산성을 높인다.

지금까지 메시지가 매핑 정의에 따라 도메인 객체로 변환되고 서비스 객체가 실행되는 과정을 설명하였다. 그런데 이런 매핑(변환)과 호출을 매개하는 프로그램은 어떻게 작성해야 하는가? 가장 직관적인 방법은 BeanIO 프레임워크에서 제공하는 API를 이용하는 것이다. 그런데 이 경우 입력과 출력 엔드포인트의 외부의 데이터 흐름에 매핑 로직을 추가해야 한다. 그리고 이 과정에서 메시징 매퍼 패턴을 따르는 구조를 만들어야 한다. 일 넘어 또 일인 것이다. 그러므로 이런 문제를 해결하기 위해 메시징 매퍼의 구현에 통합 프레임워크인 Apache Camel을 사용한다. Apache Camel을 이용하면 메시지나 도메인 객체의 매핑(변환)에 대한 처리 흐름과 서비스 호출을 DSL(Domain Specific Language)로 간단하게 만들 수 있다. 메시징 매퍼 프로그램의 Camel 라우팅 정의 DSL은 Spring Bean 정의 XML 기반의 DSL을 사용했다. 다음은 Camel의 라우팅 DSL을 포함하는 메시징 매퍼 프로그램의 Spring Bean 정의 XML이다.

이 정의 파일에서 라우팅 정의는 세 부분으로 구성된다. 첫째, toServer 라우팅 정의는 수신한 도메인 객체를 메시지로 마샬링(매핑)하여 서버(direct:server) 엔드포인트로 메시지를 전송한다. 둘째, Server 라우팅 정의는 수신한 메시지를 도메인 객체로 언마샬링(매핑)하고 도메인 객체를 처리하는 서비스를 호출한다. 처리된 결과 도메인 객체는 응답 메시지로 마샬링(매핑)되어 클라이언트(direct:client) 엔드포인트로 전송된다. 셋째, toClient 라우팅 정의는 수신한 응답 메시지를 응답 도메인 객체로 언마샬링(매핑)한다. 중간에 메시지는 stream 라우팅을 통해 표준 출력으로 출력된다. BeanIO의 매핑 정의는 Camel의 beanio 태그에서 참조되고, marshal과 unmarshal 태그를 통해 자동으로 호출된다. 서비스 클래스는 Bean(POJO) 클래스이므로 Spring Bean으로 정의되고, Camel은 이 서비스를 요청 도메인 객체를 파마미터로 포함하여 호출하고 그 반환 객체를 응답 메시지로 언마샬링한다.

이 글에서 구현한 메시징 매퍼는 각 엔드포인트로를 direct 컴포넌트로 사용했는데, 클라이언트와 서버로 분리된 네트워크에서 사용하려면 direct 컴포넌트 대신 Camel의 Mina나 Netty 컴포넌트를 사용할 있다. 그리고 복수 개의 전문도 수용하지 않는 구조를 가지고 있다. 즉 인증 전문 하나에 대한 호출과 매핑과 서비스를 구현하였다. 복수 개의 전문을 서비스들과 매칭시키려면 메시지 디스패처(Message Dispatcher)가 필요하다. 이 글은 완전한 메시지 서비스 솔루션이 아닌 메시징 매퍼의 구현에 초점을 맞추었으므로 메시지 디스패처까지는 다루지 않는다. BeanIO의 매핑 정의를 수정한다면 고정 길이 전문으로의 매핑 뿐만 아니라 XML이나 CSV와 같은 메시지로도 쉽게 매핑할 수 있다. 즉 이상적인 상황이라면 도메인 계층의 프로그램 수정 없이 고정 길이 전문 서비스에 사용된 동일한 도메인 객체를 Web Service 서비스를 요청하는 곳에도 사용할 수 있게 된다.


맺음말


필자는 이 메시징 매퍼 프로그램을 통해 그동안 필자가 설계, 개발 등으로 경험했던 전문 서비스 프레임워크, 전문-HTTP 인터페이스 서버, 메시지 포워딩 프록시 서버, 비동기 서비스, 메시징 매퍼 등등이 가진 개발 생산성의 문제, 유지 보수의 문제, 불필요한 개발 및 운영 요소 등을 될 수 있으면 기업 통합 패턴을 통해 합리적으로 해결해보려고 시도해 보았다. 설명된 내용이 다소 부족하고 이해하기 어려울 지 모르겠으나, 메시징 매퍼를 통해 다음과 같은 것들을 시도하였다. 기업 통합 패턴의 관점에서 메시징 매퍼가 가져야 할 계층 분리와 은닉성에 대한 특징을 언급했고, 기업 통합 패턴 프레임워크를 이용해 메시지 매핑에 필요한 요소들의 손쉬운 결합을 보이려고 했고, 잘 정의된 매핑 프레임워크의 매핑 정의는 가독성을 높이고 개발 생산성 및 유지 보수성을 좋게 한다는 것을 보이려고 했고, C 구조체 스타일의 자바 클래스와 리플렉션의 장점을 설명하려고 했고, POJO 기반의 서비스 개발 모델은 불필요한 연동 테스트의 낭비를 제거할 수 있다는 것을 설명하려 했다. 메시지 통신이 포함된 애플리케이션의 개발은 시스템 프로그램의 영역과 비즈니스 영역의 프로그램이 모두 필요한 부분이고 개발 및 테스트가 상당히 까다로운 분야이다. 그러나 좋은 실행 예를 참조한다면 메시지 애플리케이션을 개발하는데 합리적인 기술을 선택하고 불필요한 시행착오를 줄여 개발 생산성과 유지보수 비용을 줄일 수 있을 것이다. 그리고 거창한 솔루션을 도입하는 것이 능사가 아님도 알아야 한다. 필요한 곳에 필요한 전문가가 필요한 기술을 적절히 활용하는 것이 기술 종속을 피하는 길이고 필요 이상의 비용도 절약하는 방법일 것이다.

메시징 패턴에 대한 이 글을 모티브로 자신들의 프로젝트에 맞는 메시징 매퍼 패턴을 적용하는 개발자나 아키텍트가 있다면 기쁠 것이고, 메시지 매핑과 통신 및 기업 통합에 대하여 필자의 도움이 필요한 곳이 있다면 필자의 자문을 받는 것도 메시지 애플리케이션 프로젝트에 도움이 될 것이라 믿는다.


참고 사이트

시간: 댓글 없음:
라벨: , , , ,

2013년 10월 10일 목요일

Apache Camel, Hello, world!


1. 들어가며

Apache Camel은 기업 통합에 없어서는 안될 중요한 통합 프레임워크이다. Camel 프레임워크는 일반적인 애플리케이션에 내장 가능한 경량 프레임워크로, 프레임워크 내부에 라우터 엔진, 프로세서, 컴포넌트, 메시징 시스템을 포함하여, 애플리케이션의 내부를 외부 세계와 손쉽게 인터페이스할 수 있게 해준다. 즉 Camel 프레임워크는 애플리케이션, 시스템, 서비스들 사이에서 데이터(Data)와 기능(Function)을 통합(인터페이스)하는 중재자(Mediator)로서 역할한다. 이 글은 Camel 프레임워크가 어떻게 애플리케이션의 통합에 기여하는지를 간단한 "Hello, world!" 애플리케이션의 통합 과정을 통해 보여줄 것이다.

일반적으로 애플리케이션은 외부 세계와 인터페이스하기 위해 다양한 기술을 필요로 한다. 예를 들어 파일을 복사하기 위해서는 Java File Stream API를 사용해야 하고, 데이터베이스를 이용하기 위해서는 JDBC 드라이버를 사용해야 하고, 웹 서비스에 접속하기 위해서는 Apache HttpClient 라이브러리를 사용해야 하고, 이메일을 발신하기 위해서는 JavaMail API를 사용해야 한다. 게다가 새로운 Twitter 서비스를 이용하려 한다면 OAuth에 기반한 Twitter 서비스를 이용해야 한다. 즉 외부 애플리케이션이나, 서비스, 시스템들과 인터페이스 하려는 애플리케이션은 각 인터페이스에 맞는 기술을 애플리케이션 안에 모두 포함해야 한다. 따라서 애플리케이션을 개발하는 개발자가 외부와 인터페이스하는 각각의 기술에 대한 사용하는 방법을 알아야 한다. 그런데 일반적으로 애플리케이션 개발자는 비즈니스 로직 개발자들이다. 그러므로 외부 세계와 인터페이스에 많은 어려움을 호소하곤 한다. 실제로 인터페이스가 연결되지 않아 비즈니스 로직을 개발이 지연되는 경우가 상당히 많이 발생한다. 다음은 애플리케이션이 다양한 외부 시스템들과 인터페이스하는 방식을 그림으로 표현한 것이다.

그러나 애플리케이션이 Camel을 이용하는 경우, 애플리케이션은 Camel을 통해 외부 세계와 인터페이스할 수 있게 된다. 이 경우 Camel이 애플리케이션을 대신해 외부 세계와 인터페이스하게 된다. 이런 구조를 갖게 되면 애플리케이션은 Camel의 인터페이스 기술만으로, 어떤 외부 세계와도 인터페이스 할 수 있게 된다. 즉, 비즈니스 애플리케이션 개발자는 Camel 개발자하고만 의사소통하고, Camel 개발자는 인터페이스 하려는 외부 시스템의 개발자와 소통한다. 이 경우 비즈니스를 개발하는 애플리케이션 개발자의 외부 인터페이스에 대한 개발 부담은 현저하게 줄게 될 것이다. 물론 그 부담을 Camel 개발자가 떠안게 되지만, Camel은 외부 인터페이스 연동을 위해 이미 수백 가지 컴포넌트를 제공하고 있으므로, Camel 개발자는 외부와의 인터페이스에 새로운 프로그램을 작성하기 보다 Camel이 제공하는 컴포넌트를 활용할 수 있다. 이런 개발 과정이 얼마나 극적인 효과를 주는 지 곧 보게 될 것이다. 다음은 Camel을 사용한 애플리케이션의 인터페이스 방식을 그림으로 표현한 것이다.


2. Hello, world to Console

이제 Camel을 사용하는 간단한 애플리케이션을 작성해 보자. "The C Programming Language"에 처음 등장하는 "Hello, World!"를 콘솔에 출력하는 프로그램을 평범한 POJO 형식의 Java 프로그램과 Camel을 이용한 POJO 형식의 Java 프로그램으로 작성해 보자. 먼저 콘솔에 "Hello, World!"를 출력하는 Java 프로그램은 다음과 같다.

위 소스는 Java 개발자라면 모두 이해할 수 있는 간단한 프로그램이다. 이제 위 Java 프로그램과 동일한 결과를 출력하는 프로그램을 Camel를 이용해 작성하면 다음과 같다.

위 프로그램 소스를 살펴보자. 위 소스에서는 기본 Java 프로그램에서는 없었던, Spring Bean 정의 XML 파일인 ToConsole.xml을 Camel Main 객체에 지정한다. (Spring Bean 정의 XML을 사용한 이유는 느슨한 결합(loose coupling)이 가능하도록 Camel을 설정하기 위해서이다. 결합도(coupling)를 고려하지 않는다면 Java 프로그램 소스안이 이 XML을 프로그램적으로도 삽입 할 수 있다.) 프로그램의 main 메소드는 Camel Main 객체를 이용하여 Camel 컨텍스트를 시작한 후, Main 객체로부터 Camel과 통신할 수 있는 생산자(발신자) 객체인 ProducerTemplate를 얻어, "direct:start" URL과 "Hello World!" 문자열을 파라미터로 ProducerTemplate 객체의 requestBody 메소드를 호출한다. (생산자(producer) 또는 발신자(sender)는 기업 통합 패턴에서 사용하는 용어로 메시지를 발신하는 개체를 말한다.) 그리고 main 객체를 종료한다. Camel Context의 초기화와 종료를 제거하고 보면 처음의 Java 프로그램에 비해 그렇게 복잡하지 않다. 그렇다면 ToConsole.xml 파일이 혹시 복잡한 것은 아닐까? ToConsole.xml을 살펴 보자.

위 XML 설정을 보면 Camel Context를 정의하고 그 안에 라우팅 로직을 하나 지정했다. 이 설정은 "direct:start" 엔드포인트에서 출발하여 "stream:out" 엔드포인트로 도착하는 라우팅을 지정한다. ToConsole.xml을 기업 통합 패턴(EIP) 다이어그램으로 보면 다음과 같다.

여기에서 "direct:start" 엔드포인트는 Camel이 애플리케이션으로부터 동기 호출을 수신하는 출발 지점이다. "stream:out" 엔드포인트는 Camel이 표준 콘솔로 메시지를 발신하는 지점이다. 즉 위 라우팅은 Camel의 "direct:start" 엔드포인트로 수신된 메시지를 "stream:out" 엔드포인트로 전달하라는 정의를 담고 있다.

프로그램을 컴파일하고 실행하기 위해서는 다음의 Maven 의존이 필요하다.

하나는 Camel을 Spring 프레임워크와 함께 사용하기 위해 필요한 의존이고, 하나는 Camel의 Stream 컴포넌트 라이브러리에 필요한 의존이다.

Eclipse 환경에서 프로그램을 컴파일하고 실행할 수 있도록 프로그램 소스를 Eclipse 프로젝트로 GitHub에 올려 놓았다. Maven을 설치했다면, Eclipse 환경에서 프로그램 소스를 열지 않고도, 다음과 같이 명령창에서 Maven(mvn)을 이용하여 컴파일과 실행이 가능하다.


3. Hello, world to Log

지금까지 작성한 Console 출력 애플리케이션을 log4j를 통해 로그로 기록하는 프로그램으로 수정해 보자. 수정된 프로그램 소스는 다음과 같다.

위 소스에서 Console로 출력하는 프로그램과 달라진 점은 Spring Bean 정의 XML 파일이 ToConsole.xml에서 ToLog.xml로 달라진 것 밖에 없다. Spring Bean 정의 파일을 새로 지정한 이유는 단지 이곳의 예를 위해서 필요했기 때문이다. 실제 프로그램에서는 애플리케이션 소스를 수정하지 않고 Spring Bean 정의 XML 파일의 라우팅 정의를 수정함으로 애플리케이션의 출력을 즉시 Console에서 Log로 변경할 수 있다. ToLog.xml을 살펴 보자.

라우팅 정의에서 출발지는 "start:direct"로 ToConsole.xml에서와 같고 도착지의 "log:ToLog?level=WARN"로 ToConsole.xml의 "stream:out"와 다르다. Camel에서는 라우팅의 엔드포인트(도착지, 출발지)에 따라 인터페이스하는 외부 세계가 달라진다. 즉 ToLog.xml의 외부 세계는 이제 로그 라이브러리가 된 것이다. 상단의 logFormatter Bean 객체의 정의는 로그 기록 포맷을 지정하는 포맷터로 로그 기록 포맷을 자유롭게 커스터마이징할 수 있게 해 준다. 이곳에서 사용한 HelloFormatter는 메시지 본문의 문자열을 로그로 기록한다. HelloFormatter 소스는 프로그램 소스가 올라가 있는 GitHub를 참조한다. ToLog.xml의 EIP 다이어그램은 다음과 같다.

프로그램을 컴파일하고 실행하기 위해서는 다음의 Maven 의존이 필요하다.

Log 컴포넌트는 Camel Core 라이브러리에 포함되어 있으므로 stream 컴포넌트처럼 별도의 라이브러리가 필요하지 않다. Eclipse에서 프로젝트를 열지 않는 경우, 다음과 같이 명령창에서 Maven(mvn)을 이용하여 컴파일과 실행이 가능하다.


4. Hello, world to Mail

지금까지는 별로 특이한 사항은 없다. 이제 좀더 특별한 애플리케이션을 만들어 보자. 애플리케이션에서 메일을 발신하려고 한다. 애플리케이션은 어떻게 수정돼야 할까? 메일을 발신하는 ToMail.java는 다음과 같다.

위 소스도 ToCosole이나 ToLog 애플리케이션과 동일하다. 단지 Spring Bean 정의 XML 파일이 ToMail.xml로 달라진 것 밖에 없다. 즉 애플리케이션은 "Hello, world!"를 메일로 발신하기 위해서도 수정되지 않는다. ToMail.xml을 살펴 보자.

라우팅 정의에서 "start:direct" 엔드포인트는 이전 프로그램들 설정들과 동일하고 도착지 엔드포인트가 메일 엔드포인트인 "smtp:barunmo.com?username=testuser&password=testpassword"로 바뀌었다. 메일을 발신하기 위해서는 SMTP 서버와 메일 주제, 발신자, 수신자 등이 추가적으로 필요한데, 이런 정보들은 XML에 설정으로 지정했다. ToMail.xml의 EIP 다이어그램은 다음과 같다.

이전 라우팅 정의와 달리 중간에 setHeader 태그로 지정된 부분은 메시지 변환기(Message Translator)로 표시되었다. 이 메시지 변환기는 EIP 패턴 다이어그램 중 하나이다. 더 많은 패턴 다이어그램이 기업 통합 패턴(Enterprise Integration Patterns)에 정리되어 있다.

프로그램을 컴파일하고 실행하기 위해서는 다음의 Maven 의존이 필요하다.

Camel Mail 컴포넌트는 내부적으로 JavaMail API를 이용한다. Camel Mail 컴포넌트의 의존이 필요한 관련 라이브러리를 자동으로 추가해 줌으로 애플리케이션에서는 별도로 추가할 의존은 없다. Eclipse에서 프로젝트를 열지 않는 경우, 다음과 같이 명령창에서 Maven을 이용하여 컴파일 및 실행이 가능하다. 단 GitHub의 소스에서 내려 받은 소스에는 메일 정보들이 가상의 값으로 채워져 있으므로, 이 예를 실행 전에 메일 수신자와 발신자 정보 그리고 smtp 엔드포인트의 SMTP 서버 정보, 사용자, 패스워드를 테스트 하는 시스템과 개발자의 정보로 수정해야 한다.

다음은 ToMail 프로그램을 실행하여 필자가 수신한 메일이다.

ToMail 애플리케이션도 Spring XML 설정을 가리키는 부분 이외의 프로그램의 수정이 없으면서, 메일을 발신하는 기능을 갖게 되었다. 다음은 마지막으로 Twitter와 인터페이스하는 애플리케이션을 작성해 보자.


5. Hello, world to Twitter

요즈음 애플리케이션들은 소셜 네트워크와 뗄래야 뗄 수 없는 환경에 있다. 그러므로 이제 우리의 애플리케이션도 트위터로 트읫을 전달하게 만들어 보자.

트위터 애플리케이션을 만들기 위해서는 https://dev.twitter.com/apps/new 사이트에서 애플리케이션을 등록하고 OAuth 등의 정보를 획득해야 한다. 필자도 이 사이트에 접속하여 Barunmosoft 계정으로 접속하는 애플리케이션을 등록했다. 이 애플리케이션을 테스트하기 위해서는 독자들도 이 사이트에 접속하여 트위터 애플리케이션을 등록해야 한다. 다음은 Hello, world를 트윗하기 위한 ToTwitter.java의 소스이다.

위 소스도 ToCosole이나 ToLog나 ToMail 애플리케이션과 마찬가지로 소스상에 변화는 없다. 단지 Spring Bean 정의 XML 파일이 ToTwitter.xml로 달라진 것 밖에 없다. 즉 애플리케이션은 트윗을 사용하기 위해서도 수정이 필요 없다. ToTwitter.xml을 살펴 보자.

라우팅 정의는 이전 프로그램들처럼 도착지 엔드포인트가 트위터 엔드포인트인 "twitter://timeline/user"로 바뀌었다. 트윗하기 위해서는 트위터에 애플리케이션을 등록해야 하는데, 이 등록 과정을 진행하고 나면 트위터 사이트는 consumerKey, consumerSecret, accessToken, accessTokenSecret 값을 생성해 준다. 이 생성된 값을 twitter 컴포넌트의 Bean 정의에 속성으로 지정한다. 위 설정에서는 트위터 관련 토큰들이 엔드포인트 URI에 키-값으로 지정됨으로 엔드포인트 URL이 길어지는 것을 방지하기 위해, twitter 컴포넌트의 팩토리 Bean에 해당 값들을 속성으로 지정했다. 위 라우팅 정의의 EIP 다이어그램은 다음과 같다.

프로그램을 컴파일하고 실행하기 위해서는 다음의 Maven 의존이 필요하다.

Camel Twitter 컴포넌트는 내부에서 Twitter4J 를 이용한다. Camel Twitter 컴포넌트의 의존이 필요한 관련 라이브러리를 자동으로 추가해 줌으로 애플리케이션에서는 별도로 추가할 의존은 없다. Eclipse에서 프로젝트를 열지 않는 경우, 다음과 같이 명령창에서 Maven을 이용하여 컴파일 및 실행이 가능하다. 단 프로그램 실행 전에 트위터 사이트로부터 받은 consumerKey, consumerSecret, accessToken, accessTokenSecret 값을 Twitter.xml에 올바르게 지정해야 한다.

다음은 ToTwitter 프로그램을 실행하여 필자가 수신한 트윗의 타임라인이다..


6. Camel의 애플리케이션 적용 패턴

지금까지 프로그램은 JVM 환경의 Java 애플리케이션에 Spring 프레임워크와 결합된 Camel을 내장하는 Camel의 사용 패턴을 사용했다. 이것은 Camel이 애플리케이션에 얼마나 쉽게 내장할 수 있는지를 보여 주는 하나의 예에 불과하다. Camel Core는 약 2.5M bytes 정도의 작은 크기를 가지면서도 POJO 방식을 지원하여 애플리케이션에 쉽게 내장될 수 있다. 이 작은 프레임워크는 애플리케이션에 내장되든, 독립된 애플리케이션으로 동작하던 애플리케이션들을 손쉽게 통합할 수 있게 해 준다. 이점이 기존 애플리케이션 통합 제품인 EAI 제품들이 일반적으로 메시징 미들웨어를 기반으로 통합하는 방식과 다른 점이다. 다음은 애플리케이션에서 Camel을 적용하는 몇몇 패턴들을 보여준다.


7. 맺음말

이 글에서는 애플리케이션이 Apache Camel 프레임워크로 외부 세계와 소통하는 예로 "Hello, world!" 메시지를 콘솔에 출력하는 애플리케이션에서부터 "Hello, world!" 메시지를 트위터의 타임라인으로 트윗하는 애플리케이션까지 개발해 보았다. 이 과정에서 애플리케이션은 일관되게 Camel의 ProducerTemplate 객체를 사용하여 "Hello, world!" 메시지를 전송했으며, Camel 설정의 수정을 통해 이 "Hello, world!" 메시지는 점점 더 복잡한 프로토콜을 가진 외부 시스템으로 전송되었다. 이 글의 마지막에 보인 애플리케이션처럼 애플리케이션을 트위터 시스템과 연동하게 하는 방법에 있어서, Camel보다 더 간단하게 애플리케이션을 트위터 시스템과 연동하게 할 수 있는 솔루션이나 EAI 제품이 있을까?

이 글을 꼼꼼히 읽은 독자라면 Camel이라는 통합 프레임워크의 가능성을 잘 이해했을 것이다. 즉 Camel 프레임워크를 이용해 애플리케이션에게 일관된 통합 인터페이스를 제공했고, 애플리케이션으로부터 통합 로직을 분리했으며, 외부 시스템의 변경은 설정으로 대응하도록 했다. 그러나 이 글에 등장하는 패턴은 기업 통합 패턴 중 하나인 메시징 게이트웨이(Messaging Gateway) 패턴을 적용한 것으로 볼 수 있으며, 또한 Camel의 많은 기능들 중 극히 일부분 이곳에 사용되었다. 이 글에서는 Camel의 능력을 과시(?)하기 위해 외부 시스템에 대한 인터페이스에 집중해서 Camel의 사용을 보여 주었지만, 사실 중요한 것은 어떻게 인터페이스할 것인가 보다 어떻게 통합할 것인가 이다. 즉 나무보다는 숲을 보는 통합 아키텍처 관점이 더 중요하다. 그런 관점에서 이 곳에 설명한 프로그램 예는 단지 기업 통합이라는 신세계의 입구를 본 것뿐이다.

일반적으로 우리는 프로시저 호출(procedure call) 방식의 동기 패러다임의 아키텍처에 익숙하다. 그러나 기업 통합 패턴(Enterprise Integration Patterns)은 메시지 전달(Messaging) 방식의 비동기 패러다임으로 기업 아키텍처를 접근한다. 이런 관점의 전환이 Apache Camel이라는 통합 프레임워크를 탄생시켰고, 지금도 난제로 여겨지고 있는 애플리케이션 통합에 신선한 전환점을 만들어 주고 있다.

Apache Camel은 Red Hat의 JBoss Fuse Middleware에도 포함되어 있다. JBoss Fuse는 오픈 소스로 구성된 메시징 서버(ActiveMQ), ESB 엔진(ServiceMix), 통합 프레임워크(Camel), OSGi 컨테이너(Karaf)의 애플리케이션 통합 미들웨어 제품군이다. JBoss Fuse는 기존 기업 내 애플리케이션 통합에 사용되던 독점적 폐쇄적 EAI 제품을 대체할 수 있다. 그리고 Red Hat에서 제품으로 출시되고 있으므로 필요한 경우 상용 제품과 동일한 수준의 기술 및 제품을 지원 받을 수 있다. 그러므로 오픈 소스인 Apache Camel에 대해 관심을 가진 누구라도 오픈 소스를 직접 다운받아 활용해 보거나, Red Hat을 통해 기업 통합에 필요한 컨설팅을 받을 수 있을 것이다. 필자의 회사도 Red Hat과 Fuse 제품의 기술 지원 파트너이다.

Spring 프레임워크의 창시자인 Rod Johnson이 2012년에 출판된 "Spring Integration In Action" 책의 서문 첫 문장에 다음과 같이 썼다. "Integration is currently a hot topic" (통합은 현재 뜨거운 주제이다.) 즉 미국에서도 현재 애플리케이션들 사이의 통합이 뜨거운 주제인 것이다. 그리고 Spring Source에서도 Apache Camel 보다는 늦었지만 Spring Integration 프레임워크를 만들어 열심히 발전 중에 있다. (참고로 필자는 Spring Integration의 채널 중심의 통합 접근 방법을 별로 좋아하지는 않는다.) 그리고 Camel이나 Spring Integration이나 그 사상은 모두 기업 통합 패턴(Enterprise Integration Patters) 책에 기반한다. (이 책은 필자가 번역해 "기업 통합 패턴, 에이콘 출판"으로 출간됐다.) 우리나라 사정은 어떤가? 우리나라도 애플리케이션들 사이의 통합이 심각한 문제이나, 전체 아키텍처 측면에서는 어떻게 접근해야 하는지 별다른 방안을 갖지 않는 것 같다. (물론 독점적 EAI 제품을 도입한다거나 스파게티 구조의 인터페이스를 가지기도 한다.) 통합에 있어서, 인터페이스를 개별적으로 고민하지 말고 전체 아키텍처를 고민해야 한다. 그래야 인터페이스의 추가에 따르는 개발 비용과, 유지보수에 따르는 비용을 절감할 수 있게 된다. 이런 통합 문제를 해결하기 위한 중심에 기업 통합 패턴(Enterprise Integration Patterns)이 있고 Apache Camel이 있다.


참고 사이트

시간: 댓글 4개:
라벨: , , , , ,

2013년 7월 16일 화요일

Camel, Spring 기반 이메일 전송 라이브러리


1. 들어가며

전에 블로그에 올린 "Apache Camel 기반 이메일 전송 라이브러리"에서는 Apache Camel 프레임워크와 메일, Velocoty 컴포넌트를 이용하여 이메일 전송 라이브러리를 개발해 보았다. 이번 글에서는 동일한 라이브러리 개발에 Apache Camel 프레임워크를 Spring 프레임워크와 결합하여 개발하는 방법을 보이고자 한다.


2. Spring XML

Apache Camel은 메시지 라우팅을 다양한 DSL(Domain Specific Language, 도메인 특화 언어)로 기술할 수 있게 해준다. Camel이 Spring 프레임워크와 결합되는 경우, Camel은 Spring의 XML Schema Extension을 이용하여 Spring의 Bean 정의 XML 파일에 XML DSL로 메시지 라우팅을 설정할 수 있게 해준다. 이 XML 기반 DSL은 Java DSL의 거의 모든 기능을 그대로 지원하므로, Spring XML DSL을 이용하면, 메시지 라우팅을 설정하는 Java 클래스를 컴파일이 필요 없는 Spring XML 설정으로 옮겨 놓을 수 있다.


3. 메시지 라우팅

"Apache Camel 기반 이메일 전송 라이브러리"에서는 메시지 라우팅을 RouteBuilder 인터페이스를 구현한 Java 클래스로 설정했었다. 이번에는 Spring XML을 이용하여 메시지 라우팅을 설정할 것이다. Spring Bean 정의 XML인 MailSender.xml에 다음과 같이 Camel Context와 메시지 라우팅을 정의한다. 이 설정 파일은 "Apache Camel 기반 이메일 전송 라이브러리"의 MailSenderBuilder 클래스의 메시지 라우팅을 설정을 대체한다.

메시지 엔드포인트인 MailSender 객체는 component-scan 태그를 사용하여 자동 주입했다. 참고로 MailSender 클래스는 이미 이전 글에서 @Service 어노테이션을 이용하여 Bean으로 정의했다. 그리고 MailSenderBuilder 클래스의 설정자(setter) 메소드들은 XML에서 속성으로 참조하게 구조를 변경했다. 이를 위해 Spring이 제공하는 PropertiesFactoryBean을 이용하여 Bean XML 정의 파일에 속성을 직접 정의했다. (이 기법은 Spring 프레임워크의 숨겨진 기능 중 하나이다.) 이 속성 Bean은 camelContext의 propertyPlaceholder에서 참조하게 한다. (Camel 프레임워크 웹 사이트 문서는 이 참조 방법을 잘 설명하지 않는다.) 일단 이렇게 Bean 정의와 참조를 설정하고 나면, Camel의 설정에서는 속성 정보들을 {{}}를 이용하여 참조할 수 있게 된다. MailSenderBuilder 클래스의 configure 메소드에 설정된 메시지 라우팅은 Spring XML의 route 태그에 XML로 정의한다. 이렇게 함으로 MailSenderBuilder 클래스는 모두 Spring XML로 대체된다. 이제 Camel Context는 MailSenderBuilder 클래스가 없더라도 메시지를 라우팅할 수 있게 된다.


4. 메시지 엔드포인트

메시지 엔드포인트는 "Apache Camel 기반 이메일 전송 라이브러리"에서 구현한 클래스인 MailSender.java를 재사용한다..

이전 글을 올릴 때, 이미 Spring 프레임워크와의 결합을 고려했었다. 이때 이미 Spring의 @Service 어노테이션을 포함했다. 또 Camel의 @Produce 어노테이션은 Camel의 ProducerTemplate 객체를 자동으로 주입한다.


5. 테스트

테스트 실행에 필요한 라이브러리는 Maven의 pom.xml로 포함시켰다. 다음은 Camel과 Spring 프레임워크를 결합시킬 때 필요한 Maven의 라이브러리 의존 설정이다. 의존 라이브러리 전체는 "프로그램 소스"의 pom.xml 파일을 참조한다.

Spring 프레임워크를 사용하므로 Spring Test 어노테이션을 이용하는 JUnit 테스트 클래스를 작성한다. 다음은 Spring Test 어노테이션을 사용한 MailSenderSpringTest.java 클래스이다.

Spring Bean 정의 XML 파일인 MailSender.xml은 Spring이 제공하는 @ContextConfiguration 어노테이션을 사용하여 소스에 바로 지정한다. MailSender 객체는 Spring의 @Autowired 어노테이션으로 자동 주입된다. Test 메소드는 이전에 Java와 Camel 기반 이메일전송 라이브러리의 메소드와 거의 동일하다. 단지 설정자(setter) 메소드들이 XML 설정에서 속성으로 변경되었으므로 설정자를 호출하는 부분이 테스트 소스에서 사라졌다. 주입된 MailSender 객체에 메일 발신에 필요한 정보와 메일 본문 템플릿 입력 개체를 설정하고 발신하면 테스트는 완료된다.


6. 이전 라이브러리와 비교

Spring 프레임워크를 사용함으로 "Apache Camel 기반 이메일 전송 라이브러리"에서 사용된 메시지 라우팅 클래스는 제거되었고, 대신 컴파일이 필요 없는 Spring Bean 정의 XML 파일에 메시지 라우팅이 설정되었다. 컴파일이라는 단단한 결합을 설정 파일이라는 느슨한 결합으로 전환한 것이다. 이메일 전송 엔드포인트 클래스는 재활용되었다.

동일하게 이메일 전송을 처리하는 라이브러리로 이번 버전은 Java 소스는 줄었고, XML 설정은 추가 되었다. DSL이 Java 소스에서 XML로 바뀐 것이다. 그러나 Spring 프레임워크의 장점을 Camel에서 활용할 수 있는 구조가 되었다. Camel은 Spring의 Context는 컴포넌트 레지스트리로, Bean 객체는 메시지 엔드포인트로 활용한다.

Spring 프레임워크는 J2EE 기반 솔루션을 대체할 수 있는 강력한 엔터프라이즈 프레임워크이다. 그리고 대부분의 프레임워크들은 Spring 프레임워크와의 인터페이스를 지원한다. (모든 프레임워크는 Spring 프레임워크로 통한다!) Camel도 역시 Spring 프레임워크와 잘 결합된다.


7. 맺음말

Camel과 Spring을 이용하여 메시지 라우팅을 XML 설정으로 변경했고, Spring 어노테이션과 자동 주입을 이용하여 객체들의 초기화 과정을 생략하여 애플리케이측 소스를 좀더 간결하게 만들었다. 이렇게 Camel과 Spring 프레임워크는 서로 잘 결합되고 각 프레임워크의 장점을 서로 융합한다. 그러므로 Camel과 Spring 프레임워크를 결합하는 방식으로 애플리케이션에서 사용할 것을 권장한다.

기업 통합 패턴이 처음 패턴 언어로서 정리됐을 때, 우리들은 아직 통합 프레임워크를 갖지 못했었다. 그 결과 패턴을 이용한 통합의 구현은 애플리케이션을 개발하는 개발자가 직접 개발하거나 EAI 솔루션이 제공하는 방법에 따라 개발해야 했다. 그러나 모듈과 모듈, 애플리케이션과 애플리케이션, 시스템과 시스템, 애플리케이션과 미들웨어 등 기능과 기능을 중재(mediation)하는 기업 통합 패턴의 사상이 녹아 든 Apache Camel이나 Spring Integration과 같은 통합 프레임워크(Integration Framework)가 등장하면서 애플리케이션의 통합에 위의 이메일 전송 라이브러리처럼 극적인 단순함과 생산성, 유연성을 제공할 수 있게 되었다. 그리고 또다시 이 통합 프레임워크는 애플리케이션 프레임워크인 Spring 프레임워크와 결합함으로 장점이 더 극대화된다.

Camel, Spring의 또 다른 예로 바른모 사이트의 "기상청 사이트 서울 날씨 주간 예보 조회 - Spring Framework"를 참조하기 바란다.

이 라이브러리를 실제 업무에 사용하려면 예외 처리나 특정 환경에 맞게 로직들을 추가해야 할 것이다. 이 라이브러리는 기본적인 기능만 제공하기 때문이다. 그럼에도 불구하고 이보다 더 간결하고 확장 및 수정이 가능한 이메일 전송 라이브러리를 만들 수 있는 다른 프레임워크가 있을 수 있을까? 이렇게 Camel과 Spring은 애플리케이션 라이브러리 개발에 아주 유용한 도구이다.


참고 사이트

시간: 댓글 없음:
라벨: , , , , , ,

2013년 7월 11일 목요일

Apache Camel 기반 이메일 전송 라이브러리


1. 들어가며

"기업 통합 패턴과 메일러 애플리케이션"이란 이전 글에서 메일 발신을 기업 통합 패턴의 관점에서 해석하고 간단한 메일러 배치 애플리케이션을 개발하는 과정을 보였다. 이 메일러 애플리케이션은 독립된 애플리케이션으로 데이터베이스와 메일 서버를 통합한다. 그럼 애플리케이션들 사이의 통합이 아닌 애플리케이션 내부의 기능들의 통합에도 기업 통합 패턴을 이용할 수 있을까? 이번 글은 이 문제를 다루어 보려고 한다.


2. 상황

어떤 기업에서 고객 관리 애플리케이션을 개발하고 있다고 가정해 보자. 이 애플리케이션의 주요 기능은 고객 관리 기능이다. 그런데 필요한 경우 고객에게 안내 이메일을 전송해야 한다. 그런데 이메일 전송에 필요한 고객의 정보들은 이미 애플리케이션에서 관리하고 있다. 그러므로 현재 개발 중인 고객 관리 애플리케이션의 입장에서는 애플리케이션으로부터 전달 받은 고객 정보를 이용하여 메일을 전송하는 라이브러리가 있으면 된다. 그런데 안내 이메일의 특성상 메일 본문이 자주 변경될 수 있다. 그리고 메일 발신 대상 고객마다 별도의 메일 본문을 생성하기에는 안내 내용이 너무 크다. 즉 이럴 경우 메일 전송 요청을 위해 불필요한 저장 공간이 사용된다. 그러므로 메일 전송 라이브러리는 고객 정보와 안내 메일의 본문을 분리할 수 있어야 한다.


3. 요구 분석

개발하고자 하는 고객 관리 애플리케이션의 메일 전송 라이브러리는 다음과 같은 요구를 충족해야 한다.

  • 1) 메일 발신 기능이 필요하다.
  • 2) 메일 발신에 필요한 정보는 애플리케이션에서 모두 전달한다.
  • 3) 메일 본문은 별도의 템플릿을 관리해야 한다.
  • 4) 애플리케이션에서 사용할 수 있는 라이브러리로 개발돼야 한다.

여기에 나열된 요구들은 고객을 관리하는 애플리케이션들에게서 흔하게 볼 수 있는 요구들이다.


4. 기업 통합 패턴 설계

기업 통합 패턴의 관점에서 메시지는 애플리케이션으로부터 메일 전송 라이브러리를 거쳐 메일 서버로 전달된다. 이를 위해 애플리케이션에서 메시징 시스템으로 데이터를 전달하기 위한 "메시지 엔드포인트"가 필요하다. 즉 애플리케이션에서 메시징 시스템을 액세스하는 얇은 API 계층이 필요하다. 그리고 이 라이브러리 내에는 메일 본문 템플릿에 고객 정보를 보태는 필터가 있어야 한다. 그리고 메일 전송 컴포넌트가 필요한데, 이 컴포넌트는 이전에 블로그에 올린 "에서도 사용된 컴포넌트이다. 이런 컴포넌트들을 포함한 아키텍처를 기업 통합 패턴의 EIP(Enterprise Integration Patterns) 다이어그램으로 그리면 다음과 같이 그릴 수 있을 것이다.

이 다이어그램은 애플리케이션과 메시징 시스템을 연결하는 "메시지 엔드포인트", 메일 전송과 관련된 고객 정보와 메일 본문을 결합하는 "내용 보탬이(Content Enricher), 메일 서버에게 메일을 전달하는 메일 컴포넌트의 메일 엔드포인트로 구성된다.


5. 사용 기술

메일 전송 애플리케이션을 개발하기 위해서 두 기술이 필요하다. 첫째, 메일 전송 기술이다. 이 기술은 Camel 메일 컴포넌트를 활용할 수 있다. 둘째, 템플릿 활용 기술이 필요하다. 이 기술 중 널리 알려진 기술은 Apache Velocity 템플릿 엔진이다. Camel은 Velocity 컴포넌트를 통해 이 기술을 이용할 수 있게 해준다. 각 Camel 컴포넌트에 대한 설명은 다음 웹사이트를 참조한다.

필자는 Eclipse 개발 환경에서 m2eclipse(maven plugin)을 사용하는 것을 좋아한다. 왜냐면 사용하는 라이브러리들을 자동으로 포함시켜 주기 때문이다. 위 두 Camel 컴포넌트 라이브러리와 관련 jar들은 다음 두 엘리먼트를 pom.xml 의 의존 엘리먼트 영역에 추가하면 maven repository에서 다운받을 수 있다.


6. 메시지 라우팅 구현

이제 간단하게 메시징 흐름 설계(?)를 마쳤으므로 본격적으로 구현(?)해 보자. 다음 클래스는 위 EIP 다이어그램에 따라 메시지 라우팅을 Camel 도메인 특화 언어(DSL, Domain Specific Language) 중 Java DSL로 정의한 MailSenderBuilder .java이다.

위 클래스는 Apache Camel의 RouteBuilder 인터페이스를 구현하여 메시지 라우팅을 정의한다. 이 클래스는 메일 서버의 접속 정보는 설정자(setter)를 통해 주입 받는다. Spring 프레임워크를 고려하여 설정자를 노출한 것이다. 위의 소스의 라우팅 정의에서 to("velocity 로 시작하는 메시지 소비자(내용 보탬이)의 정의를 보면, 메시지 라우팅은 Apache Velocity 엔진 컴포넌트를 이용하고 있음을 알 수 있다. 단 한 줄로 Velocity 기능을 추가했다! Velocity 템플릿인 letter.vm 파일의 위치는 클래스 패스 아래 camel/example/client/template/letter.vm 이다. 참고로 템플릿 파일의 위치는 메일 접속 정보를 설정자를 주입하는 것처럼, 설정자를 외부에서 주입되게 바꾸는 것은 어렵지 않다. 메일 전달 기능도 smtp 소비자 엔드포인트 한 줄로 추가한다! 발신되는 메일의 형식이 HTML 형식의 이메일임을 지정하기 위해 URI의 입력 파라미터로 "contentType=text/html"을 지정했다.


7. 메시지 엔드포인트 구현

Apache Camel Context 객체는 자체가 컨테이너이면서 메시징 시스템이다. 그러므로 메시지 엔드포인트가 애플리케이션이 Camel의 메시징 시스템으로 데이터를 전달할 수 있게 API를 노출해야 한다. 이를 위해 구현된 메시지 엔드포인트 클래스가 MailSender.java이다.

MailSender 클래스는 semd 메소드를 애플리케이션에게 노출한다. 이 메소드는 header 파라미터로 이메일 전송 정보를 입력 받고, model 파라미터로 메일 본문의 입력할 고객 정보를 입력 받는다.


8. 메일 템플릿

메시지 라우팅 정의에서 언급했듯이 메일의 본문은 HTML로 작성해야 한다. HTML 템플릿은 Velocity의 템플릿 파일인 "letter.vm"로 저장된다. 이 파일은 메일을 전송하기 전에 생성하거나 수정한다. 이 파일은 메시지 라우팅 정의에 따라 클래스 패스 아래 camel/example/client/template/letter.vm에 놓인다. 다음은 필자가 개콘의 황해를 흉내 낸 안내 메일 템플릿이다.

위 파일에서 ${body.name} 부분은 MailSender.send 메소드의 model 파라미터에 "name" 키로 put한 값으로 대체된다. 동일한 방법으로 대체하고자 하는 곳에 ${} 안에 "body." 을 접두사로 하는 키 값을 지정한다.


9. 테스트

벌써 개발이 완료되었다. 이제 테스트를 해보자. 테스트는 JUnit을 활용한다. 다음은 MailSender 클래스를 테스트하는 MailSenderTest.java이다.

필자가 개발한 메일 전송 라이브러리는 Camel 프레임워크를 사용하므로 setup 메소드에서 Camel Context를 생성하고, 메시지 라우팅 로직을 추가하고, 테스트하고자 하는 MailSender 객체를 생성하고, ProducerTemplate 객체를 생성하여 MailSender 객체에 전달한다. 그리고 test 메소드에서 메일 발신과 관련된 정보와 고객 정보를 추가하여 MailSender 객체의 send 메소드를 호출한다. 소스가 보이는 것처럼 복잡하지 않다.


10. 테스트 결과

필자는 테스트 결과로 다음과 같은 메일을 수신했다.




11. 타 구현과의 비교

인터넷을 검색해 보면 이메일 전송에 Apache Velocity 템플릿 엔진을 이용하는 방법에 대하여 설명한 사이트들이 꽤 나온다. 이 사이트들은 주로 Spring 프레임워크를 이용하여 구현하고 있다. 왜냐면 Java Mail API를 직접 사용하는 것보다 Spring API를 이용하는 것이 코드 량을 줄여 주기 때문이다. 이런 사이트들은 Spring 프레임워크를 활용함으로 Bean 정의와 Spring 프레임워크의 메일 전송 API, Velocity API를 호출하는 방법을 설명한다. 즉 프레임워크의 사용과 코딩 방법을 중심으로 설명한다. 이를 확인할 수 있도록 참고 사이트에 구현 사이트 중 한 곳의 링크를 걸어놓았다.

이에 반해 필자는 동일한 문제에 대해 기업 통합 패턴의 시각에서 데이터의 흐름 즉 메시지 라우팅의 관점으로 문제를 접근했다. 그리고 메시지 라우팅을 수립하고 나서 실제 코딩을 진행했다. 이 접근 방법의 장점은 문제에 대한 해결을 미시적인 구현에 집중하는 것이 아니라 전체적인 데이터의 흐름을 볼 수 있게 해준다는 점이다. 또 이렇게 파악된 메시지 흐름을 Camel DSL로 간결하게 표현함으로 코딩의 량을 극적으로 줄일 수 있었다. 메일 전송에 구현된 로직의 코딩은 실제 60줄도 채 안된다. 그리고 추가적인 장점으로 메시지 라우팅은 컴포넌트들 사이를 느슨한 결합(loose coupling)으로 정의한 것이므로, 이곳에서 구현된 메일 전송 라이브러리는 향후 추가 또는 변경되는 요구들에 대해서도 신속하게 대응할 수 있게 되었다.


12. 맺음말

이 글에서는 애플리케이션 내부에서의 기능 통합으로 볼 수 있는 메일 전송 라이브러리를 개발해 보았다. 기업 통합 패턴을 이용하여 문제를 접근하였고, 구현은 Apache Camel 프레임워크를 이용하여 구현하였다. 제시된 요구대로 Velocity 템플릿 엔진을 이용하여 메일의 본문을 별도 파일로 분리함으로 프로그램과 메일 본문 사이의 단단한 결합(tight coupling)을 제거하였다. 그러면서도 소스는 아주 간결하게 구현하였다. 이 과정을 통해 기업 통합 패턴이 애플리케이션이 활용하는 라이브러리에도 잘 활용될 수 있음을 보여주었다.

여기에 구현된 메일 전송 라이브러리는 기업 통합 패턴 중 "내용 보탬이(Content Enricher)" 패턴의 전형적인 예이다. 그리고 이 내용 보탬이 패턴을 Apache Camel 프레임워크가 제공하는 Velocity 컴포넌트를 이용하여 간결하게 구현하였다. 이렇게 일반적인 애플리케이션 내부의 통합 문제에 있어서도 Apache 프레임워크를 이용하면 다른 어떤 프레임워크를 사용하는 것보다 더 간결하게 프로그램 할 수 있다. 물론 Apache Camel 프레임워크를 잘 활용하기 위해서는 기업 통합 패턴을 잘 알아야 한다.

애플리케이션을 개발(통합)한다는 것은 각 기능들을 구현, 조립 또는 상속하여 상위의 서비스를 제공하는 것을 말한다. 이 기능들의 개발(통합)은 거시적으로는 기업 통합(Enterprise Integration)의 형태로 미시적으로는 애플리케이션 통합(Application Integration)의 형태로 진행된다. 그리고 기업 통합 패턴은 거시적이든 미시적이든 애플리케이션 개발(통합)의 모든 경우의 분석과 설계에 유용하고, Apache Camel 프레임워크는 이 모든 경우의 구현에 훌륭한 도구이다.


참고 사이트

시간: 댓글 없음:
라벨: , , , , , ,
피드 구독하기: 글 (Atom)