기업 통합 패턴 Enterprise Integration Patterns [기업 분산 애플리케이션 통합을 위한 메시징 해결책]
- 원서명Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (ISBN 9780321200686)
- 지은이그레거 호프(Gregor Hohpe), 바비 울프(Bobby Woolf)
- 옮긴이차정호
- ISBN : 9788960776128
- 45,000원
- 2014년 09월 30일 펴냄
- 페이퍼백 | 752쪽 | 188*250mm
책 소개
요약
기업 내 복잡한 분산 애플리케이션들을 통합하려면 어떻게 해야 할까? IT 역사만큼이나 오래됐지만 여전히 가장 어려운 이 질문에 기업 통합 패턴은 시대를 초월한 해결책을 제시한다. 이 책의 메시징 기반 65개 패턴과 패턴 언어는 애플리케이션들을 언어와 플랫폼 중립적이고 느슨한 결합되도록 분석, 설계하는 최상의 방법론을 제공한다. 이 책은 통합 분야에 가장 권위 있는 고전으로서, 이를 바탕으로 많은 통합 프레임워크와 통합 제품이 탄생했다.
이 책에서 다루는 내용
기타 통합 기술과 비동기 메시징의 비교, 장점, 한계
필요한 메시지 채널을 애플리케이션이 결정하는 방법, 여러 소비자가 같은 메시지를 받을 수 있도록 제어하는 방법, 무효 메시지를 처리하는 방법
메시지를 발신할 때, 포함할 것과 메시지 속성을 특별하게 사용하는 방법
최종 목적지가 어딘지 모르더라도 최종 목적지로 메시지를 전송하는 방법
발신자와 수신자가 같은 형식의 메시지를 사용하지 않을 때 메시지를 변환하는 방법
메시징 시스템과 연동되는 애플리케이션 프로그램 설계 방법
기업에서 사용되는 메시징 시스템을 관리하고 모니터링 하는 방법
이 책의 대상 독자
메시지 지향 통합 도구를 사용해 애플리케이션을 연결하려는 다음과 같은 애플리케이션 개발자와 시스템 통합 담당자들에게 도움이 된다.
애플리케이션 아키텍트와 개발자 이 책은 애플리케이션들과 통합해야 할, 복잡한 기업 애플리케이션을 설계하고 구축하는 아키텍트와 개발자에게 필요하다. 애플리케이션 개발 환경으로는 자바 2 엔터프라이즈 에디션(J2EE), 또는 마이크로 소프트 닷넷 프레임워크 같은 현대적인 기업 애플리케이션 플랫폼이 있다. 이 책은 애플리케이션들의 메시징 계층을 연결해 서로 정보를 교환할 수 있게 하는 방법을 설명한다. 그리고 애플리케이션 구축보다 애플리케이션 통합에 초점을 맞춘다. 그러므로 애플리케이션 구축에 관해서는 마틴 파울러의 『엔터프라이즈 애플리케이션 아키텍처 패턴(Patterns of Enterprise Application Architecture)』을 참조한다.
통합 아키텍트와 개발자 이 책은 패키지나 커스텀 애플리케이션들을 연결하고 통합하는 방법을 설계하고 개발하는 아키텍트와 개발자에게 필요하다. 일부 독자는 IBM 웹스피어 MQ나 팁코(TIBCO), 웹메소드(WebMethod), 씨비욘드(SeeBeyond), 비트리아(Vitria) 같은 상용 통합 도구들을 사용한 경험이 있을 것이다. 이 도구들은 이 책에 소개된 패턴들을 포함한다. 이 책으로 아키텍트와 개발자는 통합에 대한 기본 개념을 이해하고 벤더 독립적인 어휘로 통합 아키텍처를 설계할 수 있다.
기업 아키텍트 이 책은 기업의 소프트웨어 및 하드웨어 자산의 ‘큰 그림’을 유지해야 하는 아키텍트에게 필요하다. 이 책은 특정 기술만 포함하는 통합이든, 수많은 기술을 포함하는 대규모 통합이든, 동일한 방법으로 설명하는 일관된 어휘와 그림 표기법을 제공한다. 이 언어는 기업 아키텍트, 애플리케이션 아키텍트, 애플리케이션 개발자, 통합 아키텍트, 통합 개발자들 간의 의사 소통에 핵심적인 역할을 한다.
이 책의 구성
이 책의 제목처럼 본문의 대부분은 패턴들로 구성되어 있다. 패턴이란 애플리케이션 아키텍 처, 객체 지향 설계, 비동기 메시징 아키텍처 기반 통합 등 ‘두루 적용되는’ 간단한 해답을 찾기 어려운 분야에서 전문가들의 지식을 수집해 만든 검증된 해결 방법이다.
패턴은 특정한 설계 문제를 제시하고, 그 문제를 둘러싼 고려 사항을 설명하고, 다양한 제약(forces)이나 동인(drivers)으로부터 균형 잡힌 해결책을 제시한다. 일반적으로 패턴은 급조된 해결 방법이 아니고 오랜 시간 실제 사용하면서 발전해 온 해결 방법이다. 그러므로 패턴에는 개발자와 아키텍트들이 반복적으로 해결 방법을 적용하는 동안에 시행착오를 거치며 배운 수많은 경험이 녹아 들어 있다. 다시 말해 패턴은 ‘발명품’이 아니고 현장에서 실제 애플리케이션 구축 중에 ‘관찰되고 발견된 것’들이다.
기업 통합 도구나 비동기 메시징 아키텍처를 사용한 경험이 있는 아키텍트나 개발자라면 이 책에서 설명하는 패턴들이 낯익을 것이다. 이 책의 패턴들도 실무자의 실제 사용 경험으로부터 수집됐기 때문이다. 그렇더라도 이 책을 볼 만한 가치는 여전하다. 이 책에 나오는 상세한 해결책과 해결책 사이의 관계를 읽으면 아키텍트와 개발자는 그동안 어렵게 익혔던 메시징 사용 방법에 확신을 더할 수 있을 것이다. 이 책은 경험이 미숙한 동료에게 효율적으로 정보를 전달하기 위한 통합 참고서로서도 활용될 수 있다. 마지막으로 통합 설계 시 동료들과 효율적으로 논의할 수 있는 공통의 어휘들로 이 책의 패턴 이름들을 활용할 수 있다.
이 책의 패턴은 다양한 프로그래밍 언어와 플랫폼에 적용된다. 패턴을 적용한다는 것은 코드를 잘라내 다른 곳에 붙여 넣는 일을 뜻하는 게 아니라, 특정 환경에 맞는 패턴을 이해하는 일을 의미한다. 이 책의 예에서는 다양한 환경에 패턴을 쉽게 적용 할 수 있도록 JMS, MSMQ, 팁코, 비즈톡(BizTalk), XSL 등과 같은 인기 있는 기술들을 사용해 패턴을 구현해 보였다. 또 좀 더 큰 일부 사례에서는 한 가지 해결책에 여러 패턴을 함께 사용하는 방법도 보였다. 비동기 메시징 아키텍처를 이용해 애플리케이션들을 통합하는 일은 도전적이고 흥미로운 일이다. 이 책을 저술할 동안 가졌던 이런 즐거움을 독자들도 함께 갖기를 바란다.
이 책에 쏟아진 각계의 찬사
금융 서비스 분야의 비즈니스 및 소프트웨어 아키텍처에 대한 최신 트렌드를 상세하게 설명하고, 고객들이 투자한 기존 시스템을 지속적으로 활용하게 하면서도, 통합을 혁신적이고 경쟁력 있게 해주는 책이다. 이 책에서 설명하는 상세한 메시징과 워크플로우 패턴들은 이벤트 기반의 정보 집약적 환경에 즉시 적용 가능하다. ― 글렌 카메론(Glenn Cameron) / 톰슨 파이낸셜(Thomson Financial)의 미들웨어 솔루션 아키텍처 담당 이사
게시 구독과 보장 전송과 같은 기본 패턴을 비롯해 메시징의 실제 사용 방법에 대한 높은 수준의 패턴들을 아키텍트들에게 제공하는 교과서다. 이 책에는 통합과 패턴에 관한 내용뿐만 아니라 메시징 기반 애플리케이션을 설명하는 내용과 개발에 관한 내용도 많이 담겨 있다. 회람표, 수집기, 리시퀀서 같은 패턴들은 통합 프로젝트뿐만 아니라 새로운 애플리케이션 개발 프로젝트에서도 개발자들에게 많은 도움을 줄 것이다. ― 폴 브라운(Paul Brown) / 파이브사이트 테크놀로지스(FiveSight Technologies, Inc.) 대표
『기업 통합 패턴 Enterprise Integration Patterns』는 매우 획기적인 성과다. 그동안 통합 분야는 일관성도 부족했고, 통합에 사용되는 언어는 혼란스러웠으며, 소프트웨어나 프로토콜 표준도 잘 지켜지지 않았다. 이 책을 통해, 통합 분야의 벤더, 컨설턴트, 개발자, 최종 사용자 등 모든 사람이 공통 어휘를 사용해 의사소통을 시작할 수 있는 계기가 마련됐다. 통합의 모범 사례로 옮겨가는 중세의 어떤 개발이 통합 세계를 향한 공식화된 절차를 만들기 위한 르네상스 운동을 시작하려 한다면, 이 책이 바로 해답일 것이다. 모든 IT 아키텍트, 개발자, 통합 담당자 책장에 반드시 꽂혀 있어야 하는 책이다. ― 존 슈미트(John Schmidt) / EAI 인더스트리 컨소시엄(EAI Industry Consortium) 임원
현재와 미래에 있어서 통합에 필요한 지식 토대를 제공해주는 책이다. 저자들은 수많은 지혜와 경험을 갈무리해 공유하는 수단으로 패턴을 이용했다. 나는 이 책을 검토하고 읽으면서 많을 것을 배웠다. 앞으로도 이 책의 조언에 많이 의존하게 될 것이다. ― 루크 호만(Luke Hohmann) / 『소프트웨어 아키텍처 2.0』 저자
이 책은 메시징을 이용한 유용한 통합 접근 방법을 보여줄 뿐만 아니라, 각 접근 방법이 유용한 이유를 제대로 통찰할 수 있게 해준다. 저자들은 메시징을 이용한 통합을 패턴화했고 복잡한 문제를 채널로 해결하는 방법을 명확하게 제시했다. ― 데이브 차펠(Dave Chappell) / 소닉 소프트웨어(Sonic Software)의 부사장 겸 최고 기술 책임자, 『Enterprise Service Bus』, 『Java Web Services』, 『Java Message Service』의 저자
기업 애플리케이션을 운영하거나 개발하는 경우, 새롭게 선호되는 접근 방법인 메시징을 이용한 애플리케이션 통합이 반드시 필요하게 될 것이다. 그때 이 책은 가장 중요한 참고 자료가 될 것이다. 두 저자는 메시징을 이용한 애플리케이션 통합에 관한 지혜를 어려웠을 텐데도 훌륭하게 수집했고, 소프트웨어 전문가들의 의사소통 수단으로 선호되는 양식인 디자인 패턴으로 깔끔하게 정리했다. 이들의 노력으로 소프트웨어 전문가들은 기업 애플리케이션 통합의 설계와 토론을 위한 어휘들과 검증된 해결 방법을 지니게 됐다. ― 랜디 스태포드(Randy Stafford) / 아이큐내비게이터 사(IQNavigator, Inc.)의 수석 아키텍트
추천의 글
새로운 기술이 나오면 어떻게 해야 할까? 해당 기술을 배우면 된다. J2EE가 썬 마이크로시스템즈에서 처음 나왔을 때, 나는 (그것이 논리적인 선택일 듯해서) J2EE를 공부하게 되었다. 그때는 아직 관련 도서도 없을 때라서 명세서를 읽으며 EJB 기술을 공부했다. 그러나 기술 학습은 첫 번째 단계에 불과하고, 기술을 효과적으로 적용하는 방법을 아는 게 실제 목표였다. 플랫폼 기술을 안내자 삼아 작업을 수행할 수 있다는 점이 플랫폼 기술의 장점이다. 그리고 그 기술을 잘 사용하기만 하면 어떤 작업이든 해결할 수 있지만, 반대로 적절하게 사용하지 못하면 자주 어려움에 빠지게 된다.
내가 보기에, 지난 15년 동안 소프트웨어 개발자들은 프로그래밍과 설계라는 두 영역에 집착해 왔다. 더 구체적으로 말하자면, 프로그래밍과 설계를 효과적으로 하는 데 집착해 온 것이다. 자바와 C#을 사용해 가장 효과적으로 프로그래밍 하는 방법을 알려주는 훌륭한 책들은 많은 반면에 효과적으로 설계하는 방법을 알려주는 책은 거의 없었는데, 드디어 이 책이 등장했다. 디팍 알루어(Deepak Alur)와 댄 막스(Dan Malks)와 내가 『코어 J2EE 패턴』을 저술하면서 우리는 J2EE 개발자가 더 나은 코드로 ‘설계’할 수 있게 도와주고 싶었다. 그 당시 우리가 내린 최선의 결정은 설계에 적용할 수 있는 구조물로서 패턴을 사용하는 것이었다. 썬 마이크로시스템즈의 기술자인 제임스 베티(James Baty)도 “패턴은 디자인에 최적인 것 같다.”고 했다. 나도 그 말에 동의하고, 그레거와 바비도 그렇게 생각하고 있어 다행이라고 생각한다.
이 책은 뜨겁게 성장하는 주제인 메시징을 이용한 통합에 초점을 맞춘다. 메시징은 통합의 열쇠일 뿐만 아니라 향후 수년 동안 웹 서비스에 지배적 관심 기술이 될 것이다. 오늘날 웹 서비스 세계는 여러모로 시끄럽다. 규격을 확정하고 기술에 초점을 맞추는 섬세하고 복잡한 노력이 진행 중이다. 그러나 문제 해결을 돕는 게 소프트웨어의 목표라는 점은 변함이 없다. J2EE와 닷넷의 초창기와 마찬가지로 웹 서비스에 도움이 되는 설계 방법이 아직은 많지 않다. 웹 서비스란 통합 문제를 해결하는 새롭고 열린 방법 중 하나라고 많은 사람이 말하고 나도 그 점에 동의하지만 그렇다고 해서 우리가 웹 서비스를 설계하는 방법을 알고 있는 것은 아니다. 그래서 보석 같은 이 책이 우리에게 등장한 것이다. 이 책에는 웹 서비스와 기타 통합 시스템을 설계하는 데 필요한 많은 패턴이 실려있다. 웹 서비스 규격들은 아직도 서로 싸움을 벌이고 있으므로 바비와 그레거에게는 웹 서비스 규격을 많이 적용한 예들은 의미가 없었을 것이다. 그래도 괜찮다. 규격이 표준이 되고 표준을 준수하는 솔루션 설계에 이 책에서 제시하는 패턴을 사용한다면 우리는 실제 보상을 받게 될 것이다. 그리고 그때서야 비로소 서비스 지향 아키텍처 설계의 다음 통합 목표도 알게 될 것이다. 이 책을 옆에 두고 읽으면, 당신의 소프트웨어 경력은 끝없이 높아질 것이다. --존 크루피(John Crupi), 메릴랜드의 베데스다에서
나는 『Patterns of Enterprise Application Architecture(기업 애플리케이션 아키텍처 패턴)』을 저술하던 중, 롤리 더럼(Raleigh-Durham) 시에 위치한 카일 브라운(Kyle Brown)의 사무실에서 개최 된 비공식 워크숍에 참석했다. 운 좋게도 그곳에서 카일 브라운과 레이첼 라이니츠(Rachel Reinitz)가 저술 중인 내 책을 심층적으로 검토해 주었는데, 이때 우리는 내 책에서 비동기 메시징 시스템을 다루지 않은 점을 알게 됐다.
내 책에 빈자리가 많기는 했어도 나는 모든 기업 개발 패턴을 책에 다 담으려고 하지도 않았다. 그러나 그중에서도 통합에서 점점 더 중요한 역할을 담당할 것으로 예상되는, 기업 소프트웨어 개발의 비동기 메시징은 특히 중요했다. 애플리케이션들은 서로 고립되어 운영될 수 없으므로 통합은 중요하다. 상호 협력을 고려하지 않고 설계된 애플리케이션들을 분해하지 않으면서도 통합할 수 있는 기술이 있다면 굉장한 이익을 얻게 될 것이다.
우리 모두는 통합이라는 퍼즐을 해결할 수 있다고 하는 다양한 기술 중에 메시징이 가장 적합한 기술이란 것에 동의했고, 메시지 기술의 효과적인 사용 방법을 어떻게 알릴지를 고민하고 있었다. 그러면서 메시지란 원래 비동기적이고 비동기 설계 방법과 동기 설계 방법 사이에 큰 차이가 있다는 것도 알게 됐다.
기업 애플리케이션 아키텍처 패턴을 저술 중이었던 나는 이 주제를 제대로 다루기에 충분한 공간과 에너지, 아니 솔직히 지식이 부족했다. 그러던 중 이 빈자리를 메워 줄 더 나은 방법을 찾아냈다. 이 일을 할 수 있는 사람을 찾은 것이다. 그래서 그레거와 바비를 찾았고 이들은 이 도전을 받아들였다. 그 결과가 바로 여러분이 손에 쥔 이 책이다.
나는 이들이 한 일에 감사한다. 이미 메시징 시스템을 경험한 독자라면 이 책으로 그동안 어렵게 배웠던 많은 지식을 체계화할 수 있을 것이고 앞으로 메시징 시스템을 사용할 독자라면 이 책에서 메시징 기술의 귀중한 토대를 배울 수 있을 것이다. --마틴 파울러(Martin Fowler),메사추세츠의 멜로즈에서
목차
목차
- 1장_ 패턴을 이용한 통합 문제 해결
- 통합의 필요성
- 통합의 걸림돌
- 통합 패턴이 도울 수 있는 것
- 광범위한 통합의 세계
- 느슨한 결합
- 1분 EAI
- 느슨하게 결합된 통합 솔루션
- Widgets & Gadgets ’R Us: 예
- 내부 시스템
- 주문 수령
- 주문 처리
- 상태 확인
- 주소 변경
- 신규 카탈로그
- 공지
- 테스트와 모니터링
- 요약
- 2장_ 통합 스타일
- 소개
- 애플리케이션 통합 기준
- 애플리케이션 통합을 위한 선택 사항들
- 파일 전송(File Transfer)
- 공유 데이터베이스(Shared Database)
- 원격 프로시저 호출(Remote Procedure Invocation)
- 메시징(Messaging)
- 소개
- 3장_ 메시징 시스템
- 소개
- 메시징의 기본 개념
- 책의 구성
- 메시지 채널(Message Channel)
- 메시지(Message)
- 파이프 필터(Pipes and Filters)
- 파이프라인 처리
- 병렬 처리
- 파이프 필터의 역사
- 메시지 라우터(Message Router)
- 변종 메시지 라우터
- 메시지 변환기(Message Translator)
- 변환 수준
- 결합 제거 수준
- 연쇄 변환
- 메시지 엔드포인트(Message Endpoint)
- 4장 메시징 채널
- 소개
- 메시지 채널의 논제들
- 메시지 채널 선택
- 포인트 투 포인트 채널(Point-to-Point Channel)
- 게시 구독 채널(Publish-Subscribe Channel)
- 데이터 형식 채널(Datatype Channel)
- 무효 메시지 채널(Invalid Message Channel)
- 죽은 편지 채널(Dead Letter Channel)
- 보장 전송(Guaranteed Delivery)
- 채널 어댑터(Channel Adapter)
- 메시징 가교(Messaging Bridge)
- 메시지 버스(Message Bus)
- 소개
- 5장 메시지 생성
- 소개
- 명령 메시지(Command Message)
- 문서 메시지(Document Message)
- 이벤트 메시지(Event Message)
- 요청 응답(Request-Reply)
- 반환 주소(Return Address)
- 상관관계 식별자(Correlation Identifier)
- 메시지 순서(Message Sequence)
- 메시지 만료(Message Expiration)
- 포맷 표시자(Format Indicator)
- 6장 사잇장: 간단한 메시징
- 소개
- 요청 응답 예
- 게시 구독 예
- JMS 요청 응답 예
- 요청 응답 예
- 요청 응답 코드
- 무효 메시지 예
- 결론
- 닷넷 요청 응답 예
- 요청 응답 예
- 요청 응답 코드
- 무효 메시지 예
- 결론
- JMS 게시 구독 예
- 감시자 패턴
- 분산 감시자
- 게시 구독
- 비교
- 푸시 모델과 풀 모델
- 채널 설계
- 결론
- 소개
- 7장 메시지 라우팅
- 소개
- 단순 라우터
- 복합 라우터
- 아키텍처 패턴
- 올바른 라우터의 선택
- 내용 기반 라우터(Content-Based Router)
- 의존성 줄이기
- 메시지 필터(Message Filter)
- 상태 비저장 메시지 필터 대 상태 저장 메시지 필터
- 메시징 시스템에 내장된 필터링 기능
- 메시지 필터를 이용한 라우팅 기능 구현
- 동적 라우터(Dynamic Router)
- 수신자 목록(Recipient List)
- 견고성
- 동적 수신자 목록
- 네트워크 효율
- 수신자 목록 대 메시지 필터를 가진 게시 구독
- 분할기(Splitter)
- 반복 분할기
- 정적 분할기
- 정렬되거나 정렬되지 않은 자식 메시지
- 수집기(Aggregator)
- 구현 상세
- 수집 전략
- 리시퀀서(Resequencer)
- 일련번호
- 내부 동작
- 버퍼 용량 초과 방지
- 복합 메시지 처리기(Composed Message Processor)
- 분산기 집합기(Scatter-Gather)
- 회람표(Routing Slip)
- 기존 애플리케이션과 회람표
- 회람표의 사용
- 회람표를 이용한 간단한 라우터 구현
- 프로세스 관리자(Process Manager)
- 상태 관리
- 프로세스 인스턴스
- 상관관계
- 메시지와 채널을 이용한 상태 관리
- 프로세스 정의 생성
- 프로세스 관리자와 그 밖의 패턴들의 비교
- 메시지 브로커(Message Broker)
- 소개
- 8장 메시지 변환
- 소개
- 의존성 제거
- 메타데이터 관리
- 메시징 이외의 데이터 변환
- 봉투 래퍼(Envelope Wrapper)
- 내용 보탬이(Content Enricher)
- 내용 필터(Content Filter)
- 번호표(Claim Check)
- 키 선택
- 번호표를 사용한 정보 은닉
- 번호표와 프로세스 관리자
- 노멀라이저(Normalizer)
- 메시지 포맷 감지
- 정규 데이터 모델(Canonical Data Model)
- 데이터 정규화 방법
- 이중 변환
- 정규 데이터 모델 설계
- 데이터 포맷 의존성
- 소개
- 9장 사잇장: 복합 메시징
- 대출 모집인 예
- 대출 견적 얻기
- 메시지 흐름 설계
- 실행 방식: 동기 대 비동기
- 주소 지정: 배포 대 경매
- 수집 전략: 복수 채널 대 단일 채널
- 동시성 관리
- 세 가지 구현 방법
- 동기 웹 서비스를 이용한 구현
- 솔루션 아키텍처
- 웹 서비스 설계 고려 사항
- 아파치 액시스
- 서비스 발견
- 대출 모집인 애플리케이션
- 대출 모집인 애플리케이션의 컴포넌트들
- 클라이언트 애플리케이션
- 출력 분석
- 성능 한계
- 솔루션의 한계
- 요약
- MSMQ를 이용한 비동기 구현
- 대출 모집인 생태계
- 토대 세우기: 메시징 게이트웨이
- 공통 기능을 위한 기본 클래스
- 은행 설계
- 신용 평가 기관 설계
- 대출 모집인 설계
- 신용 평가 기관 게이트웨이
- 은행 게이트웨이
- 대출 모집인 리팩토링
- 모두 모으기
- 성능 개선
- 테스트에 대한 간략한 설명
- 이 예의 한계
- 요약
- 팁코 액티브엔터프라이즈를 이용한 비동기 구현
- 솔루션 아키텍처
- 구현을 위한 도구들
- 인터페이스
- 동기 서비스 구현
- 대출 모집인 프로세스
- 동시 경합 관리
- 실행
- 결론
- 대출 모집인 예
- 10장 메시징 엔드포인트
- 소개
- 발신 패턴, 수신 패턴
- 메시지 소비자 패턴
- 메시지 엔드포인트의 논제들
- 메시징 게이트웨이(Messaging Gateway)
- 게이트웨이 체인
- 메시징 예외 처리
- 게이트웨이 생성
- 게이트웨이를 이용한 테스트
- 메시징 매퍼(Messaging Mapper)
- 코딩 부담 줄이기
- 매퍼 대 변환기
- 트랜잭션 클라이언트(Transactional Client)
- 발신/수신 메시지 쌍
- 메시지 그룹
- 메시지/데이터베이스 조정
- 메시지/워크플로우 조정
- 폴링 소비자(Polling Consumer)
- 이벤트 기반 소비자(Event-Driven Consumer)
- 경쟁 소비자(Competing Consumers)
- 메시지 디스패처(Message Dispatcher)
- 선택 소비자(Selective Consumer)
- 영속 구독자(Durable Subscriber)
- 멱등 수신자(Idempotent Receiver)
- 서비스 액티베이터(Service Activator)
- 소개
- 11장 시스템 관리
- 소개
- 모니터링과 제어
- 메시지 트래픽의 관찰과 분석
- 테스트와 디버깅
- 제어 버스(Control Bus)
- 우회기(Detour)
- 와이어 탭(Wire Tap)
- 메시지 이력(Message History)
- 메시지 저장소(Message Store)
- 스마트 프록시(Smart Proxy)
- 테스트 메시지(Test Message)
- 채널 제거기(Channel Purger)
- 소개
- 12장 사잇장: 시스템 관리 예
- 대출 모집인 시스템 관리
- 대출 모집인의 구성 요소들
- 관리 콘솔
- 대출 모집인 서비스 품질
- 신용 평가 기관 작동 확인
- 신용 평가 기관 장애 조치
- 관리 콘솔 개선
- 이 예의 한계
- 13장_ 통합 패턴 실무
- 사례 연구: 채권 가격 시스템
- 시스템 구축
- 아키텍처 패턴화
- 채널 구축
- 메시지 채널 선택
- 패턴을 이용한 문제 해결
- 시장 데이터 갱신 깜빡임
- 운영 시스템 다운
- 요약
- 14장_ 맺음말
- 기업 통합에 떠오르는 표준과 미래
- 표준과 디자인 패턴 간의 관계
- 표준화 절차와 표준화 단체
- 비즈니스 프로세스 컴포넌트와 인트라 웹 서비스 메시징
- ebXML과 ebMS
- 웹 서비스 비즈니스 프로세스 실행 언어
- 웹 서비스 코레오그래피 인터페이스
- 자바 비즈니스 프로세스 컴포넌트 표준들
- WS-*
- 결론
도서 오류 신고
정오표
정오표
[앞 장 별지 내 패턴 목록 중 페이지 참조 부분]
경쟁 소비자(Competing Consumers)(p644) -> 경쟁 소비자(Competing Consumers)(p572)
리시퀀서(Resequencer)(p409) -> 리시퀀서(Resequencer)(p346)
메시징 매퍼(Messaging Mapper)(p619) -> 메시징 매퍼(Messaging Mapper)(p545)
보장 전송(Guaranteed Delivery)(p239) -> 보장 전송(Guaranteed Delivery)(p180)
우회기(Detour)(p619) -> 우회기(Detour)(p617)
[ p59 11행 ]
통합된 애플리케이션과 서비스의 일부가 되므로 IT부서가 특정 애플리케이션만 제어할 수 없게 된다. -> 통합된 애플리케이션과 서비스의 일부가 되므로 IT부서가 특정 애플리케이션만 제어하는 것은 불가능하게 된다.
[ p184 10행 ]
발신자가가 메시지마다 영속성을 지정할 수 있게도 채널을 설정할 수 있다.
->
발신자가 메시지마다 영속성을 지정할 수 있게도 채널을 설정할 수 있다.
[ p227 3, 4행 ]
원래 요청의 응답 메시지들뿐만 아니라 이후 따르는 모든
응답 메시지들에도 동일한 상관관계 아이디가 있다.
->
원래 요청의 응답 메시지뿐만 아니라 이후 따르는 모든 응답 메시지들도 동일한 상관관계 아이디를 사용한다.
[ p548 그림 ]
[ p591 21행 ]
선택 소비자는 단일 채널을 데이터 형식 채널(p169) 역할을 하게 만든다. -> 선택 소비자는 단일 채널을 데이터 형식 채널(p169)들로 역할 하게 만든다.