추가 적립 안내

기업 내 복잡한 분산 애플리케이션들을 통합하려면 어떻게 해야 할까? IT 역사만큼이나 오래됐지만 여전히 가장 어려운 이 질문에 기업 통합 패턴은 시대를 초월한 해결책을 제시한다. 이 책의 메시징 기반 65개 패턴과 패턴 언어는 애플리케이션들을 언어와 플랫폼 중립적이고 느슨한 결합되도록 분석, 설계하는 최상의 방법론을 제공한다. 이 책은 통합 분야에 가장 권위 있는 고전으로서, 이를 바탕으로 많은 통합 프레임워크와 통합 제품이 탄생했다.

★ 요약 ★

기업 내 복잡한 분산 애플리케이션들을 통합하려면 어떻게 해야 할까? 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)
메사추세츠의 멜로즈에서



★ 저자 서문 ★

대부분의 책들처럼 『기업 통합 패턴 Enterprise Integration Patterns』 저술에도 오랜 시간이 걸렸다. 메시지 기반 통합 패턴 저술에 대한 생각은 마틴 파울러가 『기업 애플리케이션 아키텍처 패턴(POEAA, Patterns of Enterprise Application Architecture)』을 저술할 때인 2001년 여름까지 거슬러 올라 간다. 처음에 카일 브라운(Kyle Brown)은 애플리케이션의 개발 방법을 설명하는 POEAA에 큰 관심을 두었고, 애플리케이션 통합과 관련해서는 간단하게 접근했었다. 그러다가 레이첼 라이니츠(Rachel Reinitz), 존 크루피(John Crupi), 마크 와이첼(Mark Weitzel), 마틴, 카일이 참여했다. 그 뒤 함께 진행한 연속 회의에서 애플리케이션 통합에 대한 아이디어가 시작됐다. 바비는 2001년 가을, 그레거는 2002년 초에 이 토론에 참여했다. 2002년 여름, 우리 그룹은 프로그램 패턴 언어(PLoP, Pattern Languages of Programs) 컨퍼런스에 두 편의 논문을 제출했다. 하나는 바비와 카일이 공동 저술했고 나머지 하나는 그레거가 저술했다. 컨퍼런스가 끝난 후 카일과 마틴은 다시 그들의 책에 전념했고 그레거와 바비는 이 책의 바탕이 되는 논문들을 정리했다. 동시에 www.enterpriseintegrationpatterns.com 사이트를 열어 전 세계 통합 아키텍트와 통합 개발자들이 내용 발전에 빠르게 참여할 수 있게 했다. 책을 저술하면서 그레거와 바비는 책 제작에 공헌할 수 있는 사람들을 지속적으로 초대했다. 카일이 아이디어를 낸 후 약 2년이 지나 출판사에 최종 원고를 전달했다.

이 책은 수많은 사람이 참여하고 노력한 공동 작업의 결과다. 많은 동료와 친구들 (우리가 책 저술 중 만난 많은 사람)은 사례를 만들 아이디어를 제공해 주기도 하고, 기술적 내용이 정확한지를 확인해 주기도 하고, 의견이나 비판도 제시해 주었다. 그들의 도움은 책의 최종 형태와 내용에 많은 영향을 주었다. 그들의 공헌을 인정하면서, 그들의 노력에 기꺼이 고마움을 표한다.

★ 옮긴이의 말 ★

이탈리아 반도에서 출발한 고대 로마는 “모든 길은 로마로 통한다”란 말이 생겨 나게 할 정도로 수많은 도로를 건설했다. 이렇게 건설된 도로는 로마를 군사, 경제, 문화적으로 통합시켰고, 이러한 기반 시설 덕분에 로마는 거대한 제국으로 성장할 수 있었다. 로마의 도로 포장 기술은 당시 건설했던 도로를 현재까지 사용할 정도로 시대를 초월했다. 독일은 1차 대전 패전 직후임에도 속도 제한 없는 아우토반 고속도로 건설을 시작해 현재 세계 최강을 다투는 자동차 생산 선진국이 되었다. 경제적으로 풍족하지 않던 1970년대에 건설한 대한민국의 고속도로도 산업 발전의 촉매가 됐다. 이들 모두 부강할 때 도로를 건설한 것이 아니라, 도로를 건설함으로 부강해졌던 것이다.

기업 내 애플리케이션들도 서비스와 데이터를 이용하기 위해 도로가 필요하다. 그럼 애플리케이션들 간의 도로를 어떻게 건설해야 할까? 다시 말해 애플리케이션들을 어떻게 통합해야 할까? 어떻게 통합해야 로마의 도로처럼 시대를 초월할 수 있을까? 이 책은 이 질문에 해결책을 제시하는 책이다.

이 책은 2003년 마틴 파울러(Martin Fowler) 시리즈로 출간됐다. 당시 애플리케이션 통합 분야는 수많은 시행착오를 경험했음에도 여전히 시행착오를 반복했고, 찾아낸 통합 해결책도 널리 알려지지 않았다. 이런 혼란스러운 시대에 기업 통합 패턴은 애플리케이션 통합의 여러 방법 중 비동기 메시징이 최상의 해결책이라는 점을 제시하고 이에 기반한 65개 패턴과 공통 어휘도 제시함으로, 비로소 패턴과 패턴 언어로 애플리케이션 통합에 대해 의사 소통할 수 있게 했다. 기업 통합 패턴은 UML의 창시자 중 한 명인 그래디 부치(Grady Booch) 교수가 OOPSLA 2005 컨퍼런스에서 가장 영향력 있는 패턴 책으로 언급할 만큼 애플리케이션 통합에 있어서 독보적인 책이다. 출간된 지 10년이 지났음에도 SOA 분야의 베스트셀러로서 여전히 많은 독자들이 찾고 있으며 책에 대한 독자들의 평가가 출간 당시보다 더 좋아지고 있는 독특한 현상을 보이는 책이기도 하다.

특히 이 책이 다른 패턴 책들과 다른 점은 패턴 구현체가 통합 프레임워크나 기업 서비스 버스로 존재한다는 점이다. 통합 프레임워크인 아파치 카멜(Apache Camel), 스프링 인티그레이션(Spring Integration), ESB 미들웨어인 아파치 서비스믹스(Apache ServiceMix), 뮬 ESB(Mule ESB), 탈렌드 ESB(Talend ESB) 등 점점 많은 오픈 소스 프로젝트들이 기업 통합 패턴을 이용하거나 기반으로 삼고 있다. 이들 오픈 소스를 잘 활용하려면 기업 통합 패턴을 반드시 이해해야 한다. 상용 통합 제품들도 점점 기업 통합 패턴에 기재된 어휘를 사용해 가는 추세다.

고대 로마가 도로 건설을 소홀히 하면서 성 건축을 중심으로만 발전했다면, 지역적으로는 부유한 지역들이 생겨났겠지만, 부실한 도로 인프라로 인해 군사, 경제, 문화가 제대로 유통되지 못해 거대한 로마 제국이 될 수는 없었을 것이다. 마찬가지로 기업도 애플리케이션 통합을 소홀히 한다면, 애플리케이션들 간에 서비스와 데이터를 이용하는 일이 한계에 직면하게 될 테고, 이로 인해 기업 성장도 한계에 부딪칠 수 있게 된다. 그러므로 애플리케이션 통합은 기업의 모든 업무 처리 단계에 필수적이다.

이 책은 최상의 애플리케이션 통합 인프라에 필요한 해결책을 시대를 초월해 제시한다. 그러므로 기업 서비스를 위해 애플리케이션들을 통합해야 하는 아키텍트, 개발자, 운영자라면 누구나 이 책을 읽어야 할 것이다.

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장 12장사잇장: 시스템 관리 예
__대출 모집인 시스템 관리
__대출 모집인의 구성 요소들
__관리 콘솔
__대출 모집인 서비스 품질
__신용 평가 기관 작동 확인
__신용 평가 기관 장애 조치
__관리 콘솔 개선
__이 예의 한계

13장_ 통합 패턴 실무
__사례 연구: 채권 가격 시스템
__시스템 구축
__아키텍처 패턴화
__채널 구축
__메시지 채널 선택
__패턴을 이용한 문제 해결
__시장 데이터 갱신 깜빡임
__운영 시스템 다운
__요약

14장_ 맺음말
__기업 통합에 떠오르는 표준과 미래
__표준과 디자인 패턴 간의 관계
__표준화 절차와 표준화 단체
__비즈니스 프로세스 컴포넌트와 인트라 웹 서비스 메시징
__ebXML과 ebMS
__웹 서비스 비즈니스 프로세스 실행 언어
__웹 서비스 코레오그래피 인터페이스
__자바 비즈니스 프로세스 컴포넌트 표준들
__WS-*
__결론