1장 객체에서 웹 서비스로<br/>___웹 서비스란 무엇인가?<br/>___지역 객체부터 분산 객체까지<br/>___왜 웹 서비스를 사용하는가?<br/>___웹 서비스 고려사항과 대안<br/>___서비스와 느슨한 결합도의 약속<br/>___SOA는 어떠한가?<br/>___정리<br/><br/>2장 웹 서비스 API 스타일<br/>___서론<br/>___웹 서비스 API의 디자인 고려사항<br/>___RPC API<br/>______고려사항<br/>___메시지 API<br/>______고려사항<br/>___리소스 API<br/>______고려사항<br/><br/>3장 클라이언트와 서비스의 상호작용<br/>___서론<br/>___요청/응답<br/>______고려사항<br/>___요청/확인<br/>______고려사항<br/>___미디어 타입 협상<br/>______고려사항<br/>___링크된 서비스<br/>______고려사항<br/><br/>4장 요청과 응답의 관리<br/>___서론<br/>___서비스 컨트롤러<br/>______고려사항<br/>___데이터 전송 객체<br/>______데이터 바인딩 고려사항<br/>______일반적인 고려사항<br/>___요청 매퍼<br/>______고려사항<br/>___응답 매퍼<br/>______고려사항<br/><br/>5장 웹 서비스 구현 스타일<br/>___서론<br/>___웹 서비스 구현을 위한 디자인 고려사항<br/>___트랜잭션 스크립트<br/>______고려사항<br/>___데이터소스 어댑터<br/>______고려사항<br/>___오퍼레이션 스크립트<br/>______고려사항<br/>___커맨드 호출자<br/>______고려사항<br/>___워크플로우 커넥터<br/>______고려사항<br/><br/>6장 웹 서비스 인프라<br/>___서론<br/>___서비스 커넥터<br/>______고려사항<br/>___서비스 설명자<br/>______고려사항<br/>___비동기식 응답 핸들러<br/>______고려사항<br/>___서비스 인터셉터<br/>___멱등 재시도<br/>______고려사항<br/>___SOA 인프라 패턴의 간략한 리뷰<br/>______서비스 레지스트리<br/>______엔터프라이즈 서비스 버스<br/>______오케스트레이션 엔진<br/><br/>7장 웹 서비스의 진화<br/>___서론<br/>___무엇이 파괴적 변경을 초래하는가?<br/>______미디어 타입이나 메시지의 구조적 변경<br/>______서비스 설명자의 변경<br/>___공통 버전 관리 전략<br/>___단일 메시지 인수<br/>___데이터 집합 수정<br/>______고려사항<br/>___톨러런트 리더<br/>______고려사항<br/>___컨슈머 중심 계약<br/>______고려사항<br/>___패턴은 어떻게 서비스의 진화를 촉진하거나 방해하는가?<br/><br/>부록: 외부 패턴 찾아보기<br/>용어집<br/>참고문헌

이 책은 웹 서비스를 사용하면서 반복적으로 직면하게 되는 문제의 해결책을 제시한다. 이를 위해 REST 아키텍처 스타일을 따르거나 SOAP/WSDL를 활용한 디자인 방안을 제시하며, 풍부한 예제 코드로 독자의 이해를 돕는다. 여러 문제를 핵심 주제별로 분류해서 근본적 디자인 구성요소를 바탕으로 설명하고 있기 때문에, 패턴의 동작 원리를 쉽고 분명하게 이해하고 효과적으로 적용할 수 있게 해준다. 서비스 개발자나 솔루션 아키텍트, 엔터프라이즈 아키텍트 모두에게 가치 있는 내용을 전달할 것이다. <br/><br/><b>이 책에서 다루는 내용</b><br/><br/>■ 어떻게 웹 서비스 API를 만들며, 어떤 공통 API 스타일이 있고, 특정 스타일을 사용해야 하는 시점은 언제인가?<br/>■ 어떻게 클라이언트와 웹 서비스가 통신할 수 있고, 여러 관계자가 오랜 시간에 걸쳐 서로 데이터를 교환할 수 있도록 복잡한 대화를 생성하는 기반은 무엇인가?<br/>■ 웹 서비스 로직을 구현하는 옵션에는 무엇이 있으며, 특정 접근법을 사용해야 할 때는 언제인가?<br/>■ 서비스가 사용하는 하위 시스템과 클라이언트가 더 낮은 결합도를 갖게 하는 방법은 무엇인가?<br/>■ 웹 서비스에 관한 정보는 어떻게 찾을 수 있는가?<br/>■ 클라이언트나 서비스에서 인증과 유효성 검증, 캐싱, 로깅 같은 범용 함수를 지원하는 방법은 무엇인가?<br/>■ 클라이언트의 중단을 가져오는 서비스의 변경은 무엇인가?<br/>■ 서비스에 버전을 부여하는 일반적인 방법은 무엇인가? 클라이언트를 즉시 갱신할 필요 없이, 웹 서비스가 비즈니스 로직의 지속적인 변화를 지원할 수 있도록 디자인하는 방법은 무엇인가?<br/><br/><b>이 책의 대상 독자</b><br/><br/>이 책은 전문적인 엔터프라이즈 아키텍트와 솔루션 아키텍트, 웹 서비스를 사용 중이거나 사용할 생각이 있는 개발자를 대상으로 한다. 이 전문가들은 크게 두 집단으로 나눌 수 있다. 첫 번째는 소프트웨어 제품(예: 상용 애플리케이션, 오픈소스 SaaS 애플리케이션)을 생산하는 집단이다. 두 번째는 IT 부서와 협력해 엔터프라이즈 애플리케이션을 개발하는 집단이다. 비록 이 카탈로그는 소프트웨어 업계의 종사자를 대상으로 하지만 학계에도 마찬가지로 적용할 수 있다. <br/><br/><b>이 책의 구성</b><br/><br/>1장, 객체에서 웹 서비스로 1장에서는 일반적인 소개를 설명한다. 1장 내용에 이어, 이 카탈로그에 수록된 패턴은 다음과 같은 6개의 장으로 나눠 알아본다.<br/><br/>2장. 웹 서비스 API 스타일 2장은 웹 서비스에서 사용하는 주요 API 스타일을 알아본다. 일단 스타일을 선택하고 나면 방향을 변경하기가 무척 어려워서, 올바른 스타일을 선택하는 일에 따른 결과는 결코 간과할 수 없다.<br/><br/>3장. 클라이언트와 서비스의 상호작용 3장에서는 모든 클라이언트/서버 통신의 기반을 서술한다. 여기서 알아볼 패턴은 어떤 서비스 디자인 스타일과도 함께 사용할 수 있다. 여러분은 이 패턴에 대한 이해를 바탕으로 여러 주체가 특정 주제로 데이터를 교환하는 복잡한 대화를 만들 수 있다.<br/><br/>4장. 요청과 응답의 관리 소프트웨어 애플리케이션은 논리적으로 연관된 엔터티를 포함하는 여러 계층으로 구성되기 마련이다. 4장에서는 웹 요청과 응답에 사용하는 일반적 서비스 계층[POEAA] 엔터티를 알아본다. 여기서 소개하는 패턴의 의도는 서비스가 사용하는 하위 시스템으로부터 클라이언트를 분리(decouple)하는 것이다.<br/><br/>5장. 웹 서비스 구현 스타일 서비스는 다양한 방법으로 구현할 수 있다. 서비스는 데이터베이스 테이블 같은 자원의 지식과 밀접히 연관됐을 수 있고, 객체 관계형 매퍼(ORM, Object Relational Mapper)의 활동이나 레거시 API의 직접 호출 등을 조율할 수 있으며, 외부 엔터티로 작업을 전달할 수 있다. 5장에서는 각 접근에 따른 결과를 살펴본다.<br/><br/>6장. 웹 서비스 인프라 어떤 작업은 너무 일반적이어서 끊임없이 다시 사용되곤 한다. 6장은 가장 일반적이며 기본적인, 클라이언트와 서비스 개발자에게 유용한 인프라 고려사항을 논의한다. 기업 SOA 인프라에 일반적으로 적용되는 여러 패턴도 함께 살펴본다.<br/><br/>7장. 웹 서비스의 진화 개발자는 각기 다른 속도로 변화하는 여러 클라이언트와 지속해서 함께 동작하는 서비스를 만들고자 노력한다. 하지만 이러한 목표는 달성하기가 상당히 힘들다. 7장에선 클라이언트 파괴적 변경(breaking change)을 유발하는 요소와 두 가지 일반적인 버전 관리 전략을 확인한다. 결국, 여러분은 어떻게 소프트웨어 메이저 릴리스를 피하며 클라이언트 요구사항을 만족하도록 서비스를 확장할 수 있는지 보게 된다.<br/><br/>또한 부록과 참고문헌, 용어집을 통해 추가 정보가 제공된다.

엔터프라이즈 애플리케이션을 이야기할 때 빼놓을 수 없는 진부한 이야기 중 하나는 엔터프라이즈 애플리케이션은 서로 동떨어져 있는 섬이 아니라는 말이다. 여러분은 특정 비즈니스 문제를 해결하기 위해 노력하겠지만, 여러분이 필요한 모든 데이터를 스스로 모으거나 모든 프로세싱을 직접 개발할 수는 없다. 충분한 시간이 있더라도 이런 데이터와 프로세싱은 어디에선가 이미 이뤄지는 중일 수 있고, 중복된 처리는 낭비일 뿐만 아니라 어지러운 불일치를 초래한다. 그 결과 대부분의 엔터프라이즈 애플리케이션은 여타 애플리케이션과의 통신이 필요하다. 그리고 이런 외부 시스템은 종종 동일한 조직 내에 있지 않을 뿐만 아니라, 때론 서드파티 조직이 제공하기도 한다.
지난 여러 해 동안, 이런 유형의 협력에서 가장 어려웠던 부분은 통신 경로의 확보 같은 일이었다. 이런 애플리케이션은 각기 다른 운영체제에서, 각기 다른 언어로, 각기 다른 플랫폼에서 작성됐기 때문에 지원하는 통신 프로토콜이 다른 경우가 많았다. 하지만 지난 10년 사이에 웹이 연결 문제를 해결하는 방법으로 떠올랐으며, 이제 대부분의 시스템은 80번 포트를 열고 이를 통해 텍스트로 이야기할 수 있다.
하지만 여전히 애플리케이션이 서로 어떻게 이야기해야 하는지와 관련한 많은 문제가 남아 있다. RPC 스타일 API나 메시지 지향 API, 최근에 주목받고 있는 REST 등을 사용해야 하는가? 로직은 서비스에 바로 포함해야 하는가, 아니면 하위 객체에 위임해야 하는가? 어떻게 클라이언트를 중단시키지 않고 사용 중인 서비스를 변경할 수 있는가?
일반적으로 내 시그너처 시리즈 책들은 다른 곳에서 많이 다루지 않은 주제를 담고 있지만, 이미 웹 서비스의 갖가지 측면을 다룬 매우 다양한 책들이 출간됐다. 그래서 어느 날 로버트의 초고가 도착했을 때 내가 그의 원고에 흥미를 느끼리라고는 생각지 않았다. 내 생각을 바꾼 것은 그의 초고가 앞서 언급한 주요 질문을 단 하나의 책 안에서 다뤘다는 점이었다. 이는 책을 읽는 데 투자하는 시간을 충분히 가치 있게 하는, 내가 늘 기술 서적에 기대해온 특징이었다.
우선 로버트는 주제 분야를 패턴으로 쪼개어가고, 우리는 이를 통해 함께 이야기할 때 사용할 용어집을 얻는다. 이어서 그는 각 패턴을 파고들며 패턴이 어떻게 동작하며, 여러 패턴 중 올바른 패턴을 선택하는 방법은 무엇인지 설명한다. 결국, 여러분은 웹 서비스 디자인의 다양한 접근법을 살펴보며, 여러분이 놓인 상황에 어떤 패턴이 적합한지를 결정할 수 있다. 그는 여러 예제 코드를 통해 실제로 어떻게 패턴을 사용하는지를 보여주며, 패턴은 일반적이기 때문에 다양한 기술 스택에 폭넓게 적용할 수 있다.
기술의 변화 속에서도 언제나 그 가치를 잃지 않을 원칙에 초점을 맞추며, 웹 서비스 사용의 중요 디자인 결정 지점을 한곳에 모은 책이 여기에 탄생했다.

- 마틴 파울러(Martin Fowler)

분산 애플리케이션의 개발은 보통 순탄하게 출발하지만, 그만큼 결국엔 좋지 않게 끝나는 경우도 많다. “가리키고, 웹 참조를 추가해, 클릭한다.” 이 말은 여러분이 신중히 만든 서비스 인터페이스가 있을 때, 어느 개발자가 이에 로드된 클라이언트를 가리키는 행위를 묘사한다. 우리는 왠지 모르게 디자인을 위한 도구의 사용을 대신해, 모든 느슨한 결합(loose coupling)을 단순하고 무책임한 난장판 속으로 몰아넣고야 만다. 결국, 릴리스할 시점이 다가오면, 우리는 모두가 같은 작업에 매달려 함께 밤을 새워야 하는 상황에 처한다.
좀 더 조심스러웠던 시대에 살고 있었다면, 아마도 그저 “안돼. 분산하지 마.”라고 말했을지도 모른다. 그리고 오늘날의 많은 경우에서도 여전히 이 조언은 옳다. 레이어(layer)는 티어(tier)와는 다르며, 여러분이 구현한 다양한 공개 표준이 무엇이든 3단 레이어 애플리케이션 아키텍처를 무너트리고 여러 부분으로 나눠 분산시키는 행동은 분명 바보 같은 짓이다.
하지만 오늘날에는 애플리케이션이 섬처럼 고립된 경우가 드물다. 비즈니스 역량이 조직의 경계를 넘어 흩어져 있다면, 이를 자동화하는 시스템 역시 그러하다. 우리가 기업 내부든 기업 간이든 현대 공급망의 분산적 특징을 지원하고자 한다면, 서비스 지향을 따르는 형태가 필요하다.
웹과 웹을 지탱하는 다양한 기술은 이런 면에서 굉장히 유용하다는 점이 증명됐다. 분산 시스템의 역사에서 웹이 차지하는 중요한 위치를 알지 못하거나 아예 무관심하더라도, 여러분이 직접 만들었거나 이제까지 사용해온 매우 다양한 서비스를 보면 웹이 반드시 필요한 존재임을 부인할 수 없다. 웹 전송 불가지론(transport agnosticism)으로 알려진 모든 사례는, SOAP 같이 HTTP라는 열차를 얻어타려는 경향을 보인다. 웹은 드러나지 않더라도 사라질 수는 없으며, 그렇게 몇 년 동안이나 서비스라는 무거운 짐을 어깨에 짊어지고 있다.
오늘날 웹 서비스의 모습을 바라보면, 우리가 구축하는 소프트웨어가 웹을 수용하는 방법이 적어도 세 가지 이상 있음을 알 수 있다. 웹의 성공은 웹을 구성하는 요소의 절대적 정확성 때문이 아니라, 그 경계에 서 있고 때론 경계를 넘나드는 다양한 아키텍처 스타일을 허용하는 내구성 때문이다. 어떤 서비스나 애플리케이션은 그저 웹의 뒤편에 숨어 있다. 이들은 웹을 반가워하지 않지만, 그럼에도 웹을 객체와 프로시저에 접근하는 데 필요한 좁은 관문으로 사용할 수밖에 없다. 눈을 돌려보라. 여러분은 웹상의 여러 서비스를 발견할 것이며, 이는 서비스가 HTTP를 단순한 전송 수단 정도로 대하는 데 머무르지 않고, RFC 2616에서 설명하는 강건한 조정(coordination)과 전송의 프로토콜로 활용함을 의미한다. 마지막으로, 여러분은 웹을 구성하는 일부(아주 소수의) 요소를 발견할 것이다. 이들은 컨슈머에게 데이터(어떻게 더 많은 데이터에 접근하고 조작할 수 있는지를 설명하는 데이터를 포함한)의 웹을 제공하기 위해, 웹을 구축하는 데 사용된 URI와 HTTP, 일반화된 하이퍼미디어 표현 형식(예: HTML) 등의 웹 초기 기반 기술을 사용한다.
이 책은 분산 환경을 지원하는 다양한 웹 사용법을 바탕으로, 시스템을 분산시킬 때 필요한 신중하고 방어적인 디자인의 필요성을 다룬다. 전략과 기술의 믿을 만한 지침서로서, 이 책은 내 소트웍스(ThoughtWorks)의 여러 친구나 동료가 어렵게 얻은 경험에 상응하는 내용을 담고 있다. 웹상에서 진행되는 일을 어떻게 해치울지 설명하며, 여러분이 어려움에 빠지지 않도록 돕는다. 내부 품질과 서비스 지속성을 높이는 단순성(simplicity)을 통해 엉망인 클라이언트 군단으로부터 서비스 도메인과 데이터를 보호하기 위한 복잡성(complexity)의 균형을 이룬다면, 한밤의 배포 작업에 모두가 함께 지쳐가는 상황을 피할 수 있다.
이안 로빈슨(Ian Robinson)