Spring Integration 과 함께 - 마무리

-

마무리...

Chigai Kuginuki Emblem - Spring Integration Icon@seekpng.com

 Spring Integration 예제를 만들며 느낌과 생각을 공유한다.

단순하게 만들자.

 Spring Integration 의 IntegrationFlow는 단순하게 만들자. Spring Integration 단일 시스템으로 실행할 수 있고 여러 시스템을 연동해서 사용한다. 연동으로 데이터를 전달할 때, 구성 요소(Transformer, Splitter, Service Activator...)에 지나친 처리로직으로 Blocking이 생기면 지연 문제가 생길 수 있다. (만약 IntegrationFlow가 비동기라면 더 심각할 수 있다.)

길을 만드는 Programming

 자바에서 try-catch나 throws로 예외를 처리한다. 이 때, 비즈니스 로직을 멈출 수 있고 우회 방법으로 실행한다. 하지만, Spring Integration 도 errorChannel 혹은 Route 기능을 사용해서 오류를 처리해줄 IntegrationFlow 를 만들자. (드라마 명대사 중 '암세포도 생명(?)' 처럼, 오류도 처리하기 위한 길(路)이 필요하다)

DSL로 만들자.

 Spring Integration은 3가지로 설정할 수 있다. XML File, @Configuration, 그리고 DSL 이다. 3가지 모두 해본 결과, DSL 이 더 가시적이었다. 물론 STS에서 Spring Integration Component Editor 를 이용하면 그림을 그려준다. 하지만 막힐 때, 인터넷에서 구할 수 있는 답과 예제는 DSL이 더 많고 깔끔했다.

마치며...

 약 3주를 하나의 Framework에 꽂혀 본업을 잊을 정도로 재밌게 경험한 것 같다. 삽질도 많아서 지병이 도질 정도로 스트레스를 받았지만, 그래도 나름 의미있는 Back-end 프로그램이었다. 나처럼 고생하는 사람들이 이 글을 통해 포기하지 않고 도움 받길 바란다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

JPA 와 함께 - 느낀점

-
이미지
Java Persistence API(JPA)  김영한님의 JPA 기초편 을 끝까지 수강했다. 작년부터 새벽에 짬내서 들었지만, 아이들의 방해(?)로 6개월 걸렸다. 듣고 많은 내용에 대해서 생각이 들었다. JPA 란?  자바 퍼시스턴스 API 이라 불리는 객체와 관계형 DB 를 관리하는 자바 API다. 2006년 1.0을 발표했으며 현재 2.1버젼까지 발전했다. Mybatis도 좋지만...  Mybatis로 Web개발을 하면, 마음 한켠이 찝찝(?)했다. 분명 Mybatis가 직관적으로 SQL을 관리해서 편하다. 하지만 점점 SQL 중심 개발로 진행할 수록, Spring의 역활에 의구심이 들었다. Web 서버, JSON 변환 외 비즈니스 로직은 점점 Mybatis 중심으로 만들어졌다.  그러다 객체설계 책을 접하고, Spring JPA를 알게 되었고, 유료 강의수강를 수강했다. Oracle Forms와 비교   가장 오래한 직업인 Oracle Forms 개발 관점에서 봤을 때, 비슷하면서 더 발전한 API라고 생각한다. 비슷한 점은 Primary Key 기준 CRUD Transaction 자동 실행과 부모-자식 관계 자동 설정이다.   더 발전한 API로 느낀 이유는 특정 DB를 위한 API가 아닌 범용 API라는 점이다. ANSI 표준 SQL과 Dialect로 DB Vendor별 차이를 좁히기도 한다. 그래서 개발자는 SQL보다는 객체에 좀더 집중할 수 있도록 도와준다. 객체지향으로 가는 길.  이제 비즈니스 로직을 객체에 자연스럽게 녹일 수 있다. 비즈니스 로직과 SQL 문장을 만들필요 없이 객체의 로직의 결과가 저장되어야 한다면 JPA를 사용하면 된다.  마치며... 홍보글은 아니지만, 꼭 듣기를 바란다. 이제 DB 없는 프로그램은 상상하기 힘들다. 객체와 DB설계 중 고민 하나를 덜어낼 수 있는 좋은 기회다. (물론 DB를 전혀 신경쓰지 않아도 되는 건 아니다.)
자세한 내용 보기

Scott 과 함께 - Recursive Query 구현하기

-
이미지
Recursive Query   Recursive Query는 계층형(hierarchical) 데이터를 조회할 때 사용하는 쿼리다. 기업에서 흔히 조직도와 BOM(Bill of Materials)에서 사용한다. Oracle은 'Connect By' 그리고 타 DB는 CTE(Common Table Expressions)로 계층형 데이터를 조회할 수 있다. Java의 경우, Entity를 연결해 Graph탐색할 수 있다. 이번 Post는 JPA로 Employee객체의 조직도를 구현하는 기록을 남긴다. Oracle Native Query 결과.  EMP 테이블은 직원 1명에 관리자 1명으로 구성되어 있다. 관리자는 다른 상위 관리자 1명과 연결한다. 'KING'은 사장님이시기 때문에 관리자 값이 Null이다.   'Connect By' 문장은 연결할 데이터 컬럼을 정의한다. 'Start with'는 계층형 데이터의 시작이 어디인지 알려준다. 'Prior' 은 상향식과 하향식으로 데이터 조회 방향을 결정한다. SELECT LEVEL , lpad ( ' ' , LEVEL * 3 , '.' ) || decode ( LEVEL , 1 , NULL , '└▶ ' ) || e . ename AS hierarchy , e . * FROM emp e WHERE 1 = 1 START WITH e . mgr IS NULL CONNECT BY e . mgr = PRIOR e . empno 상향식 결과 SELECT LEVEL , lpad ( ' ' , LEVEL *...
자세한 내용 보기
-
Clean Code - 형식 맞추기. 형식을 맞추는 목적  형식을 맞추는 것은 프로그래머들의 소통을 위해서 가장 중요한 업무다.  개녑은 빈 행으로 분리한다.  member 변수는 행으로 분리하지 않지만, method는 빈행으로 분리하자. 세로 밀집도 변수 선언 : 변수는 사용하는 위치에 최대한 가까이 선언한다. 종속 변수  : 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 개념적 유사성 : 중요한 개념을 먼저 표현한다. 그리고 그 개념을 지원하는 함수들을 순서대로 작성하면 '내려읽기'가 편해진다.  팀규칙  프로그래머는 각자 선호하는 규칙이 있다. 하지만 팀이 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.
자세한 내용 보기