SOA, 서비스 지향 아키텍처라는 용어가 IT 산업에 있어 중요한 이슈로 부각되기 시작했으나, 아직도 제대로 이해하고 있는 사람은 많지 않다. 이 책은 다음과 같은 내용을 중심으로 SOA에 대한 이해를 높일 수 있게 하는 데 중점을 뒀다.

• SOA, 서비스 지향, 웹서비스를 이해한다.
• 웹서비스로 SOA를 구축하는 방법을 배운다.


[ 이 책의 특징 ]

이 책이 아키텍처만 다루고 있는 건 아니다. 서비스 지향 아키텍처, SOA는 새로운 개념과 기술, 선결 문제들을 제시하는 서비스 지향 컴퓨팅 플랫폼의 핵심 부분이므로, 이 책에서는 서비스 지향적인 자동화 솔루션 구축 작업을 다각적인 범위에서 설명하기 위해 이 플랫폼의 중요한 부분들을 상세히 살펴본다. 특히 이 책에서 다루고 있는 SOA 플랫폼의 특성은 다음과 같다.

• 요즘 발생하는 SOA에서의 기초적인 변화에 대해서 현재의 웹서비스와 단계적인 “how to” 프로세스로 설명되는 설계 기법으로 달성할 수 있는 20가지 정도의 공통 특성을 입증하는 것으로 기술한다.
• XML과 웹서비스가 표준 기구와 소프트웨어 업체가 활발히 연계해 어떻게 SOA의 진화에 영향을 주고 기여했는가를 연구하는 방식으로 기초적인 웹서비스 이론을 다루고 있다.
• 서비스 지향의 이론은 상세히 다룬다. 서비스 지향 이론이 웹서비스 설계에 미친 영향을 설명하고, 이 이론은 이후 단계적인 설계 프로세스에 결합된다.
• 10가지 이상의 WS*-스펙이 상세히 설명된다. 이 책의 각 부분은 개념을 평이한 문체로 설명하고 있고, 기술적인 상세한 내용은 예제 소스코드와 함께 보여준다.
• 특정한 서비스 레이어 생성을 포함, 고급 SOA 개념과 설계 이슈도 논의한다. 이를 통해 기업 내의 업무와 기술 도메인을 추상화할 수 있고 업무와 애플리케이션 중심의 서비스 설계에 필요한 기초를 다질 수 있다.

또한 다음과 같은 업무완수 방법에 대해서 단계적으로 설명하고 있다.

• 서비스 지향적인 분석 수행
• 기존 업무 문서에서 도출된 서비스 후보 모델링
• SOA 조합 설계
• 기술 추상화를 위한 애플리케이션 서비스 설계
• 업무 로직 추상화를 위한 비즈니스 서비스 설계
• 서비스 지향 업무 프로세스 설계
• J2EE와 .NET 플랫폼이 제공하는 SOA 지원 요소에 접근


[ 이 책의 구성 ]

이 책은 독자가 단계별로 논리적으로 학습할 수 있고 읽기 쉽도록 내용을 구성했으며, 모두 5개 부로 나뉘어있다.

• 1부: SOA와 웹 서비스의 기초
• 2부: SOA와 WS-* 확장
• 3부: SOA와 서비스 지향
• 4부: SOA 구축: 계획과 분석
• 5부: SOA 구축: 기술과 설계

본질적으로 1부와 2부, 3부는 SOA 개념의 기본과 심화, 4부와 5부를 준비하기 위한 이론을 포함하고 있는데, SOA를 구축하는 방법을 단계적으로 설명하고 있다. 5부는 WS-* 기술, J2EE, .NET이 제공하는 SOA 플랫폼에 대해 더 깊이 다룬다.
이 책 전반에 걸쳐 사례 연구를 지속적으로 활용하고 있다. 125개 이상의 개별 사례 연구는 중요한 주제를 입증하는 데 있어서 실제 활용 참고자료로서의 역할을 한다. 사례 연구는 2장에 소개되고 두 개의 가상 조직에 대한 배경 지식을 제공한다.


[ 이 책의 대상 ]

SOA는 넓은 주제를 다루고 있다. SOA는 특정 벤더의 독점 기술 혹은 벤더 중립적인 기술을 모두 아우르는, 일련의 첨단 기술을 포함하는 새로운 아키텍처 플랫폼이다. 따라서 이 책은 다음과 같은 분야의 다양한 IT 전문가들에게 유용할 것이다.

• SOA 구축 방법
• 서비스 지향 이론
• SOA를 위한 여러 가지 서비스의 설계
• 서비스 지향적인 업무 모델링
• 중요한 WS-* 표준 스펙의 특징
• WS-BPEL을 써서 웹서비스와 비즈니스 프로세스를 조율하는 것
• J2EE와 .NET 플랫폼에서의 SOA 지원
• 업무 중심 서비스 모델링
• SOA 기반 솔루션의 설계 표준 만들기
• SOA 관점의 문맥상에서의 웹서비스 기술

[ 저자 서문 ]

거의 1년이 넘는 기간 동안 이 책을 저술하고 연구했으며, 집필하는 중에도 항상 최신 경향을 따라감으로써 좀더 폭넓은 내용을 책에 담고자 노력했다. 각 장들의 주요 내용들을 벤더 중립적인 관점으로 서비스 지향 아키텍처에 초점을 맞추고자 했지만, 이러한 관점을 정확히 표현하기 위해서 모든 주요 벤더 플랫폼에서 지원하는 SOA를 검토하는 데 공을 많이 들였다. 이러한 연구단계의 일환으로, 백명이 넘는 수석급 IT 전문가와 대화를 나눴으며, 인터뷰나 평가용 플랫폼 검토 작업을 통해 다양한 연구를 수행했다.

이 책에서 가장 흥미로운 점을 꼽자면, 웹서비스 상에서 서비스 지향을 정의했다는 점을 들 수 있다. 서비스 지향을 패러다임으로 수립하는 개별 분야를 연구해오면서 SOA가 오래 전부터 있어왔던 혁신을 위한 노력에 바탕을 두고 있다는 것을 깨달았으며, 하나의 아키텍처 모델을 지원하는 데 있어 전통적 개념과 새로운 개념이 혼합되는 양상을 느낄 수 있었다.
매우 새로워 보이는 개념이지만, SOA는 기본적인 수준에 있어서 오래 전부터 이미 있어왔던 개념과 과거 학습에 기반하고 있다. 독자적이면서도 로직 단위를 구별하는 방법으로서의 서비스 지향은 매우 평범한 개념이다. 각 장을 저술해가면서 직접 느낄 수 있는 기회가 되었다. 우리가 접하는 사물이나 사람들, 조직들은 몇 가지 형태의 서비스를 제안하거나 서비스 수행에 참여하고 있다. 여기에 기술 아키텍처를 적용하기만 하면 서비스 지향은 서비스 지향 세계의 특정 분야, 즉 비즈니스 자동화와 관련을 갖게 된다.

비즈니스들이 날로 경쟁적이 되어감에 따라, 각 조직들은 노력은 최소화하되 달성 가능한 전략목표에 대한 기대치는 최대화하도록 체질 개선중이다. 지속적으로 자원을 낭비하는 비효율적인 조직은 필연적으로 뒤떨어지게 마련이다. 조직이 비즈니스를 자동화하는 방식은 효율성의 수준을 결정하는 중요한 요소이며, 궁극적으로 이러한 효율성은 투자에서 얻을 수 있는 성공의 정도를 가늠할 수 있는 척도가 된다.

바로 이것이 SOA의 가치이다. 즉 서비스 지향을 통해 자동화된 로직을 형성함으로써 기존 투자의 효과를 증진할 수 있으며, 비즈니스 정보를 정확하게 표현할 수 있다. 또한 본질적으로는 자율성을 갖는 민첩성을 달성할 수도 있다. 웹서비스 기술 플랫폼을 적용할 때, SOA는 기술과 조직의 외관을 전환할 수 있는 중요하고도 실제적인 잠재적 이점을 제공한다. 이 책의 목표는 여러분이 이러한 잠재적인 이점을 탐구하고 이해하며 깨달을 수 있도록 도와 주는 데 있다.


[ 저자 소개 ]

토마스 얼

토마스 얼(Thomas Erl)은 SOA 시스템즈(www.soasystems.com)의 설립자이며, 엔터프라이즈 솔루션 업체에서 전문적으로 SOA컨설팅과 교육을 하고 있다. 이전에 출간된『서비스 지향 아키텍처: XML과 웹서비스로 통합을 위한 현장가이드(Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services)』라는 책은 웹서비스와 SOA 분야 모두에서 2004년 최고의 판매 서적이 되었다. 그의 이 책은 수많은 통합 이슈와 전략들을 제공하며 SOA로의 전환을 위한 베스트 프랙티스를 소개하고 있다.
토마스는 OASIS의 의결멤버이기도 하며 XML과 웹서비스 통합 프레임워크(XWIF)와 같은 연구에도 관여하여 활동하고 있다. 그는 여러 이벤트와 컨퍼런스에서 강사로 활동중이며, ‘웹서비스 저널(Web Services Journal)’, ‘WLDJ’, ‘애플리케이션 개발 동향(Application Development Trends)’ 등에 수많은 사설과 논문을 게재해오고 있다. 더 많은 정보는 www.thomaserl.com/technology/를 방문해 보기 바란다.


[ 역자 서문 ]

기업의IT환경이 거대해지고 복잡해짐에 따라 비즈니스에 대한 낮은 대응력, 고비용 구조, 다양한 시스템통합 문제 등 심각한 도전에 직면해 있다. 물론 이러한 도전은 오늘날에서야 비롯된 것은 아니다. 이러한 도전을 극복하기 위해 지난 수십 년간 클라이언트 서버 아키텍처 및 컴포넌트 기반의 분산 아키텍처 등 다양한 대안들이 제시되었다. 하지만 이러한 대안들이 모두 만족할만한 해결방안을 제시해 주지는 못했다. 이에 따라 해결방안으로 제시된 SOA라는 기업 IT환경에 대한 접근방법은 최근 뜨거운 이슈가 되고 있다.

사실 SOA라는 개념이 최근에 갑자기 나타난 것은 아니다. 수년 전부터 SOA에 대한 논의는 꾸준히 이어져 왔으나 SOA를 이해하는 방식이나 방향이 조금씩 달랐다. 특히 다양한 이해 관계자에 따라 상이한 이해와 구현방법을 제시해왔다. 그러나 시장 수요에 따라 민첩하게 대응해야 하는 비즈니스 요구에 맞는 IT 환경의 구축방식이라는 대의적인 측면에서 의견이 모아지고, XML과 웹 서비스 기술의 혁신과 글로벌 표준 기구들에 의한 표준 수립을 통해 SOA는 급격히 구체화되기 시작했다.

그럼에도 SOA에 대한 개념 정립의 필요성, 난무하는 웹서비스와 XML표준들, 기존 웹서비스와 XML을 활용한 분산 아키텍처와 SOA의 차이점, 실제 비즈니스 서비스를 추출하고 구현하는 방법 등 속시원하고 명쾌하게 설명해주는 가이드를 찾기 어려운 것이 사실이었다. 또 약간씩 상이한 각 벤더들의 SOA구축 전략도 혼돈을 불러 일으키고 있으며 현장에서는 웹서비스와 XML이라는 개발구현의 관점과 비즈니스 가치를 중심으로 바라보는 관점 등이 SOA를 더욱 혼란스럽게 하고 있다.

이 책의 저자는 이러한 SOA에 대한 명확한 개념정의뿐만 아니라 정의된 개념대로 분석, 설계할 수 있는 풍부한 가이드를 제시하고 있다. 좀 따분하게 여겨질 웹서비스의 기초에 대한 상세한 설명에서부터 웹서비스 확장 스펙과 현재 지원하는 자바와 .NET 플랫폼에 대한 분석과 사례에 이르기까지, 현장에서 명확한 개념을 갖고 SOA를 분석/설계하기 위한 풍부한 자료를 제공한다.

이 책의 가치를 요약해서 설명하자면 다음과 같이 정리할 수 있을 것 같다.

- 역사와 배경을 통해 개념과 구조를 이야기하는 책
이 책은 매우 보기 드물게 기업의 IT환경에서 역사와 배경을 통해 SOA의 명확한 개념과 구조를 설명하고 있다. 과거에 대한 이해와 통찰력이 없는 정의와 개념의 나열은 자칫 더 큰 혼란을 야기할 수 있다. 이 책은 오늘날 SOA가 갖는 개념과 구조를 지금까지 기업환경에서 아키텍처가 진화해오고 최신 웹서비스와 XML표준들이 수립된 배경과 함께 설명함으로써 좀더 명확한 SOA의 개념과 구조를 설명한다.

- 개념과 실제 분석, 설계를 관통하고 있는 책
SOA의 성격상, 자칫 개념과 방향에만 집중하다 보면 어떻게 현장에서 분석하고 설계해야 하는지를 놓치는 우를 범할 수도 있다. 그러나 이 책에서는 절반이 넘는 분량을 할애해 계획과 분석, 설계에 초점을 맞춤으로써 실제로 현장에서 SOA를 어떻게 설계하고 적용해야 할지 자세하게 설명하고 있다. 또한 잘못된 SOA의 분석, 설계의 실사례를 설명함으로써 명확한 가이드를 지향한다.

- 125개의 일관된 가상 예제와 쉽게 풀어쓴 책
아마도 이 책의 최대의 강점이 아닐까 생각하는 부분이다. 이 책은 가상의 비즈니스 회사들(레일기공, TLS)을 통해 실제 SOA의 구축사례를 설명하고 있다. 이 구축사례는 동떨어진 개별 예제들이 아니라, 마치 실제 사례처럼 본문설명에 따라 진화해 가고 있다. 설사 본문 내용을 잘 이해하지 못했다 하더라도 이 사례를 접하면 저절로 머리를 끄덕일 수 있다. 특히 웹서비스나 XML 기술을 잘 모르는 사람들에게 있어서 쉽게 이해할 수 있는 오아시스 세차장에 대한 별도 사례는 이 책의 백미라고 할 수 있다.

- 한계와 방향 / 실제와 미래 / 오해와 진실을 이야기하는 책
이 책은 SOA에 대해 과장하지 않고 그 한계와 방향성을 명확히 잡고 있다. 한계와 방향을 얼버무리면서 제기될 수 있는 혼란의 여지를 차단해 현재 수준에서 구축할 수 있는 것과 가능성을 명확히 하고 업계에서 제기되고 있는 각종 오해와 진실을 깔끔하게 설명하고 있다.

- 그 밖의 필요한 사항을 놓치지 않고 이야기하는 책
이 책에서 또한 상당부분을 차지하는 것이 바로 웹서비스와 웹서비스 확장, 관련 플랫폼에 대한 상세한 설명이다(물론 이 내용들을 이미 알고 있다면 건너뛰어도 좋다). 표준기술에 대해 자세히 설명함으로써 실제로 기술표준의 수준을 객관화했으며, 현재 IT를 양분하고 있는 자바와 .NET 플랫폼에 대해 고려해야 할 차이점을 명확히 언급함으로써 실제로 SOA를 적용하려는 현장 실무자들에게 도움이 될 것이다.

끝으로 이 책이 국내에서 SOA를 도입하고자 하는 많은 공공부문과 기업들의 관리자와 실무자들에게 훌륭한 가이드가 되기를 바라며, 지금도 현장에서 씨름하고 있는 응용 소프트웨어 분야의 아키텍트들과 공감하기를 바란다.




[ 역자 소개 ]

장세영
경희대학교 행정학과를 졸업하고 동 대학원에서 도시정보전략을 전공했다. 현재는 삼성 SDS Software Architecture팀에서 소프트웨어 아키텍트로 활동하고 있다. J2EE 교육과 CBD 교육컨설팅, CBD 지원 솔루션 개발, OO/CBD 방법론 컨설팅, 온라인과정 개발, 최근 엠플 마켓플레이스 구축 프로젝트 등 다수의 CBD 프로젝트에 아키텍트로 참여했으며, 현재는 병무청 차세대 프로젝트를 수행하고 있다. 저서로는 『Java Programming』(비트출판, 2002)이 있다.

황상철
경희대학교 산업공학과를 졸업하고 동 대학원에서 경영과학을 연구했다. 현재 삼성 SDS Engineering 혁신팀에서 통합개발환경 Engineering 지원과 ITO프로세스 혁신을 지원하고 있으며, 삼성화재 차세대 등의 프로젝트에서 소프트웨어 아키텍트로 활동했다. 주 관심사는 다양한 Engineering 툴과 오픈소스, SW아키텍처 등이며 Agile과 실용주의에 대해서 다루는 실용주의 이야기(http://www.moai.co.kr)라는 블로그를 운영하고 있다.

이현정
서울대학교 수학과를 졸업하고 전산학을 복수전공했다. CBD와 J2EE 관련 교육 컨설팅, SCM 솔루션 개발 프로젝트, 행정자치부 시도행정 정보화 프로젝트 등에 소프트웨어 아키텍트로서 참여해왔다. 현재 삼성 SDS Engineering 혁신팀에서 SOA 방법론과 SOA를 적용한 Ubiquitous City 도시통합 운영센터의 레퍼런스 아키텍처를 만들고 있으며, 주 관심사는 자바 관련 기술과 웹2.0 패러다임, SOA이다.

조문옥
고려대학교 컴퓨터학과를 졸업하고 현재는 삼성 SDS Engineering 혁신팀에서 소프트웨어 아키텍처 분야를 담당하고 있다. 주로 J2EE와 .NET의 기술 컨설팅 및 애플리케이션 아키텍처, 개발 방법론에 관해 연구하고 있으며, 크고 작은 다수의 프로젝트에서 소프트웨어 아키텍트로 활동했다. 삼성 멀티캠퍼스에서 『Struts Framework』, 『UML 기반 분석/설계』 등의 교재를 집필했으며, 짬짬이 개인 블로그(http://blog.naver.com/jodarchitect)도 운영하고 있다.

목차

• 1장 개론
  
  • 1.1 이 책이 중요한 이유
    • 1.1.1 잘못된 SOA
    • 1.1.2 이상적인 SOA
    • 1.1.3 실제 SOA
  • 1.2 집필 목적
    • 1.2.1 SOA, 서비스 지향, 웹서비스의 이해
    • 1.2.2 웹서비스를 활용한 SOA 구축 방법
  • 1.3 이 책을 읽어야 할 독자
  • 1.4 이 책에서 다루지 않는 것
  • 1.5 구성
    • 1.5.1 1부: SOA와 웹서비스 기본
    • 1.5.2 2부: SOA와 WS-* 확장
    • 1.5.3 3부: SOA와 서비스 지향
    • 1.5.4 4부: SOA 계획과 분석
    • 1.5.5 5부: SOA 기술과 설계
    • 1.5.6 관례
  • 1.6 추가 정보
    • 1.6.1 XML과 웹서비스 통합 프레임워크
    • 1.6.2 www.serviceoriented.ws
    • 1.6.3 저자 연락처
      
• 2장 사례연구
  • 2.1 사례연구 활용
    • 2.1.1 편집 스타일
    • 2.1.2 실 사례와 개념의 관계
    • 2.1.3 코드 샘플
  • 2.2 사례 1 배경: 레일코
    • 2.2.1 역사
    • 2.2.2 기술 인프라
    • 2.2.3 자동화 솔루션
    • 2.2.4 비즈니스 목표와 문제점
  • 2.3 사례 2 배경: TLS
    • 2.3.1 역사
    • 2.3.2 기술 인프라
    • 2.3.3 자동화 솔루션
    • 2.3.4 비즈니스 목표와 문제점
      
      
• 1부 SOA와 웹서비스 기본
  
• 3장 SOA 소개
  • 3.1 SOA 기본
    • 3.1.1 서비스 지향의 개념
    • 3.1.2 서비스의 로직 캡슐화 방식
    • 3.1.3 서비스간의 연결 방식
    • 3.1.4 서비스간의 커뮤니케이션 방식
    • 3.1.5 서비스 설계 방식
    • 3.1.6 서비스 구축 방식
    • 3.1.7 초기 SOA
  • 3.2 최신 SOA 특징
    • 3.2.1 서비스 지향 컴퓨팅 플랫폼의 핵심
    • 3.2.2 서비스 품질 향상
    • 3.2.3 자율성
    • 3.2.4 공개 표준 기반
    • 3.2.5 다양한 벤더 지원
    • 3.2.6 서비스 발견성
    • 3.2.7 상호운영성
    • 3.2.8 통합용이성
    • 3.2.9 아키텍처 조합
    • 3.2.10 재사용성
    • 3.2.11 확장성
    • 3.2.12 서비스 지향 비즈니스 모델 지원
• 　　　3.2.13 추상화된 레이어 구현
  • 3.2.14 느슨한 결합관계
  • 3.2.15 조직적 민첩성
  • 3.2.16 블록 쌓기 방식의 구축
  • 3.2.17 진화의 산물
  • 3.2.18 계속되는 진화
  • 3.2.19 실현가능 한 아이디어
  • 3.2.20 SOA 정의
  • 3.2.21 특징 요약
• 3.3 SOA에 대한 오해
  • 3.3.1 웹서비스를 사용하는 애플리케이션은 서비스 지향 솔루션이다
  • 3.3.2 SOA는 웹서비스의 마켓팅 용어일 뿐이다
  • 3.3.3 SOA는 분산컴퓨팅의 마켓팅 용어일 뿐이다
  • 3.3.4 SOA는 분산컴퓨팅을 단순화한 것이다
  • 3.3.5 WS-* 확장을 사용하는 웹서비스 애플리케이션은 서비스 지향 솔루션이다
  • 3.3.6 웹서비스만 이해하면 SOA를 구축할 수 있다
  • 3.3.7 SOA를 적용하면 모든 것이 연계된다.
• 3.4 SOA의 실익
  • 3.4.1 향상된 통합성
  • 3.4.2 본질적인 재사용성
  • 3.4.3 아키텍처와 솔루션 간소화
  • 3.4.4 기존 시스템 재투자 감소
  • 3.4.5 데이터 표현 방식의 표준화
  • 3.4.6 커뮤니케이션 인프라 투자
  • 3.4.7 최적의 대안
  • 3.4.8 조직적 민첩성
• 3.5 SOA 적용의 함정
  • 3.5.1 기존 분산아키텍처 방식의 답습
  • 3.5.2 표준화 되지 않은 SOA
  • 3.5.3 계획 없는 전환
  • 3.5.4 XML 기반이 아닌 아키텍처
  • 3.5.5 성능요구사항에 대한 오해
  • 3.5.6 웹서비스 보안에 대한 오해
  • 3.5.7 플랫폼을 고려하지 않은 개발
    
• 4장 SOA의 진화
  • 4.1 SOA 연대기
• 　　　4.1.1 XML 역사
  • 4.1.2 웹서비스 역사
  • 4.1.3 SOA 역사
  • 4.1.4 SOA에서 XML과 웹서비스의 재구성
• 4.2 SOA의 계속되는 진화
  • 4.2.1 표준, 스펙, 확장
  • 4.2.2 표준 기구
  • 4.2.3 주요 벤더
• 4.3 SOA의 근원
  • 4.3.1 아키텍처의 개념
  • 4.3.2 SOA와 클라이언트 서버 아키텍처
  • 4.3.3 SOA와 분산 인터넷 아키텍처
  • 4.3.4 SOA와 하이브리드 웹서비스 아키텍처
  • 4.3.5 서비스 지향과 객체 지향 (1)
    
• 5장 웹서비스와 초기 SOA
  • 5.1 웹서비스 프레임워크
  • 5.2 웹서비스에서의 서비스
    • 5.2.1 서비스 역할
    • 5.2.2 서비스 모델
  • 5.3 WSDL 서비스 명세
    • 5.3.1 서비스 접점과 서비스 명세
    • 5.3.2 추상 명세
    • 5.3.3 실제 명세
    • 5.3.4 메타데이터와 서비스 계약
    • 5.3.5 의미적 명세
    • 5.3.6 서비스 명세 통지와 발견
  • 5.4 SOAP 메시징
    • 5.4.1 메시지
    • 5.4.2 노드
    • 5.4.3 메시지 경로
      
      
• 2부 SOA와 WS-* 확장
  
• 6장 웹서비스와 최신 SOA (액티비티 관리와 구성)
  • 6.1 메시지 교환 패턴 (MEP)
    • 6.1.1 기본적인 MEP
    • 6.1.2 MEP와 SOAP
    • 6.1.3 MEP와 WSDL
    • 6.1.4 MEP와 SOA
  • 6.2 서비스 액티비티
    • 6.2.1 기본 서비스 액티비티와 복합 서비스 액티비티
    • 6.2.2 서비스 액티비티와 SOA
  • 6.3 코디네이션
    • 6.3.1 코디네이터 구성
    • 6.3.2 코디네이션 유형과 프로토콜
    • 6.3.3 코디네이션 환경과 참여자
    • 6.3.4 서비스 활성화와 등록 프로세스
    • 6.3.5 완료 프로세스
    • 6.3.6 코디네이션과 SOA
  • 6.4 최소단위 트랜잭션
    • 6.4.1 ACID 트랜잭션
    • 6.4.2 프로토콜
    • 6.4.3 코디네이터
    • 6.4.4 프로세스
    • 6.4.5 최소단위 트랜잭션과 SOA
  • 6.5 비즈니스 액티비티
    • 6.5.1 프로토콜
    • 6.5.2 코디네이터
    • 6.5.3 상태
    • 6.5.4 비즈니스 액티비티와 최소단위 트랜잭션
    • 6.5.5 비즈니스 액티비티와 SOA
  • 6.6 오케스트레이션
    • 6.6.1 비즈니스 프로토콜과 프로세스 정의
    • 6.6.2 프로세스 서비스와 파트너 서비스
    • 6.6.3 기본 액티비티와 구조적 액티비티
    • 6.6.4 시퀀스, 흐름, 연결
    • 6.6.5 오케스트레이션과 액티비티
    • 6.6.6 오케스트레이션과 코디네이션
    • 6.6.7 오케스트레이션과 SOA
  • 6.7 커리어그래피
    • 6.7.1 협업
    • 6.7.2 역할과 참여자
    • 6.7.3 관계와 채널
    • 6.7.4 상호작용과 작업단위
    • 6.7.5 재사용성, 구성용이성, 모듈성
    • 6.7.6 오케스트레이션과 커리어그래피
    • 6.7.7 커리어그래피와 SOA
      
• 7장 웹서비스와 최신 SOA (진보한 메시징, 메타데이터, 보안)
  • 7.1 어드레싱
    • 7.1.1 엔드포인트 참조
    • 7.1.2 메시지 정보 헤더
    • 7.1.3 어드레싱과 전송 프로토콜 독립성
    • 7.1.4 어드레싱과 SOA
  • 7.2 신뢰성 있는 메시징 (RM)
    • 7.2.1 RM 공급지와 목적지, 애플리케이션 공급지와 목적지
    • 7.2.2 시퀀스
    • 7.2.3 수신확인
    • 7.2.4 전달 보장
    • 7.2.5 신뢰성 있는 메시징과 어드레싱
    • 7.2.6 신뢰성 있는 메시징과 SOA
  • 7.3 상관관계
    • 7.3.1 상관관계 개념
    • 7.3.2 MEP에서 상관관계와 액티비티
    • 7.3.3 코디네이션에서 상관관계
    • 7.3.4 오케스트레이션에서 상관관계
    • 7.3.5 어드레싱에서 상관관계
    • 7.3.6 신뢰성 있는 메시징에서 상관관계
    • 7.3.7 상관관계와 SOA
  • 7.4 정책
    • 7.4.1 WS-Policy 프레임워크
    • 7.4.2 정책 선언과 대안
    • 7.4.3 정책 선언 유형과 어휘
    • 7.4.4 정책 주제와 범위
    • 7.4.5 정책 표현과 첨부
    • 7.4.6 핵심사항
    • 7.4.7 코디네이션에서 정책
    • 7.4.8 오케스트레이션과 커리어그래피에서 정책
    • 7.4.9 신뢰성 있는 메시징에서 정책
    • 7.4.10 정책과 SOA
  • 7.5 메타데이터 교환
    • 7.5.1 WS-MetadataExchange 스펙
    • 7.5.2 Get Metadata 요청과 응답메시지
    • 7.5.3 요청과 응답 메시지 구하기
    • 7.5.4 메타데이터에 대한 선택적 접근
    • 7.5.5 메타데이터 교환과 서비스 명세 발견
    • 7.5.6 메타데이터 교환과 버전 컨트롤
    • 7.5.7 메타데이터 교환과 SOA
  • 7.6 보안
    • 7.6.1 확인, 인증, 권한관리
    • 7.6.2 싱글사인온(SSO)
    • 7.6.3 기밀성과 무결성
    • 7.6.4 전송 레벨 보안과 메시지 레벨 보안
    • 7.6.5 암호화와 디지털 서명
    • 7.6.6 보안과 SOA
  • 7.7 알림과 이벤트처리
    • 7.7.1 발행과 구독의 개념
    • 7.7.2 하나의 개념에 두 개의 스펙
    • 7.7.3 WS-Notification 프레임워크
    • 7.7.4 WS-Eventing 스펙
    • 7.7.5 WS-Notification 과 WS-Eventing
    • 7.7.6 알림, 이벤트처리, SOA
      
      
• 3부 SOA와 서비스 지향
  
• 8장 서비스 지향의 원칙
  • 8.1 서비스 지향과 엔터프라이즈
  • 8.2 서비스 지향 아키텍처의 구성요소
    • 8.2.1 웹서비스 프레임워크의 논리적인 구성요소
    • 8.2.2 자동화 로직의 논리적인 구성요소
    • 8.2.3 SOA 구성요소
    • 8.2.4 SOA 구성요소간의 연관성
  • 8.3 서비스 지향의 원칙
    • 8.3.1 재사용성
    • 8.3.2 공식 계약
    • 8.3.3 느슨한 결합
    • 8.3.4 추상화
    • 8.3.5 조합성
    • 8.3.6 자율성
    • 8.3.7 무상태성
    • 8.3.8 발견용이성
  • 8.4 서비스 지향 원칙간의 관계
    • 8.4.1 재사용성
    • 8.4.2 공식 계약
    • 8.4.3 느슨한 결합
    • 8.4.4 추상화
    • 8.4.5 조합성
    • 8.4.6 자율성
    • 8.4.7 무상태성
    • 8.4.8 발견용이성
  • 8.5 서비스 지향과 객체지향
  • 8.6 웹서비스에 내재된 서비스 지향 원칙
    
• 9장 서비스 레이어
  • 9.1 서비스 지향과 최신 SOA
    • 9.1.1 SOA 특성과 근원
    • 9.1.2 직접 지원하지 않는 SOA 특성
  • 9.2 서비스 레이어 추상화
    • 9.2.1 서비스 레이어로 해결할 수 있는 문제
  • 9.3 애플리케이션 서비스 레이어
  • 9.4 비즈니스 서비스 레이어
  • 9.5 오케스트레이션 서비스 레이어
  • 9.6 독립적인 서비스
  • 9.7 서비스 레이어 구성 시나리오
    • 9.7.1 시나리오 1: 복합 애플리케이션 서비스
    • 9.7.2 시나리오 2: 복합 및 유틸리티 애플리케이션 서비스
    • 9.7.3 시나리오 3: 태스크 중심 비즈니스 서비스, 유틸리티 애플리케이션 서비스
    • 9.7.4 시나리오 4: 태스크 중심 비즈니스 서비스, 엔티티 중심 비즈니스 서비스, 유틸리티 애플리케이션 서비스
    • 9.7.5 시나리오 5: 프로세스 서비스, 복합 애플리케이션 서비스, 유틸리티 애플리케이션 서비스
    • 9.7.6 시나리오 6: 프로세스 서비스, 태스크 중심 비즈니스 서비스, 유틸리티 애플리케이션 서비스
    • 9.7.7 시나리오 7: 프로세스 서비스, 태스크 중심 비즈니스 서비스, 엔티티 중심 비즈니스 서비스, 유틸리티 애플리케이션 서비스
    • 9.7.8 시나리오 8: 프로세스 서비스, 엔티티 중심 비즈니스 서비스, 유틸리티 애플리케이션 서비스
      
• 10장 SOA 구축 전략
  • 10.1 SOA 구축 라이프사이클 단계
    • 10.1.1 SOA 구축 라이프사이클의 기본 단계
    • 10.1.2 서비스 지향 분석
    • 10.1.3 서비스 지향 설계
    • 10.1.4 서비스 개발
    • 10.1.5 서비스 테스트
    • 10.1.6 서비스 배치
    • 10.1.7 서비스 관리
    • 10.1.8 SOA 구축 전략
  • 10.2 하향식 전략
    • 10.2.1 프로세스
    • 10.2.2 찬반 양론
  • 10.3 상향식 전략
    • 10.3.1 프로세스
    • 10.3.2 찬반 양론
  • 10.4 기민한(Agile) 전략
    • 10.4.1 프로세스
    • 10.4.2 찬반 양론
      
• 11장 서비스 지향 분석 (도입)
  • 11.1 서비스 지향 분석 개요
    • 11.1.1 목적
    • 11.1.2 프로세스
  • 11.2 비즈니스 중심 SOA의 장점
    • 11.2.1 기민한 비즈니스 모델
    • 11.2.2 오케스트레이션을 위한 프로세스 준비
    • 11.2.3 재사용 지원
    • 11.2.4 서비스 지향 엔터프라이즈 시스템 환경 구현
  • 11.3 비즈니스 서비스 도출
    • 11.3.1 비즈니스 서비스의 출처
    • 11.3.2 비즈니스 서비스의 유형
    • 11.3.3 비즈니스 서비스와 오케스트레이션
      
• 12장 서비스 지향 분석 (서비스 모델링)
  • 12.1 서비스 모델링
    • 12.1.1 "서비스"와 "서비스 후보"
    • 12.1.2 프로세스 설명
  • 12.2 서비스 모델링 가이드
    • 12.2.1 프로세스간 잠재적 재사용성 고려
    • 12.2.2 프로세스내 잠재적 재사용성 고려
    • 12.2.3 프로세스 관련 의존 관계 고려
    • 12.2.4 애플리케이션간 재사용
    • 12.2.5 분할에 대한 고려
    • 12.2.6 작업의 논리적 단위 식별
    • 12.2.7 로직 경계 중복 방지
    • 12.2.8 프로세스 서비스 흉내내기
    • 12.2.9 균형 있는 모델
    • 12.2.10 서비스 모델링 로직 분류
    • 12.2.11 적절한 모델링 자원 할당
    • 12.2.12 비즈니스 서비스 모델링 표준 제정 및 공표
  • 12.3 서비스 모델 로직 분류
    • 12.3.1 SOE(Service-oriented Enterprise) 모델
    • 12.3.2 엔터프라이즈 비즈니스 모델
    • 12.3.3 "빌딩 블록"과 "서비스 모델"
    • 12.3.4 기본 모델링 빌딩 블록
  • 12.4 여러 서비스 모델링 접근법
    
• 13장 서비스 지향 설계 (도입)
  • 13.1 서비스 지향 설계 개요
    • 13.1.1 목적
    • 13.1.2 "설계 표준"과 "산업 표준"
    • 13.1.3 프로세스
    • 13.1.4 전제조건
  • 13.2 WSDL관련 XML스키마 언어 기본 엘리먼트
    • 13.2.1 schema
    • 13.2.2 element
    • 13.2.3 complexType, simpleType
    • 13.2.4 import, include
    • 13.2.5 다른 중요 엘리먼트
  • 13.3 WSDL 언어 기본 엘리먼트
    • 13.3.1 definitions
    • 13.3.2 types
    • 13.3.3 message, part
    • 13.3.4 portType, interface, operation
    • 13.3.5 operation에서 input, output
    • 13.3.6 binding
    • 13.3.7 binding에서 input, output
    • 13.3.8 service, port, endpoint
    • 13.3.9 import
    • 13.3.10 documentation
  • 13.4 SOAP 언어 기본 엘리먼트
    • 13.4.1 Envelope
    • 13.4.2 Header
    • 13.4.3 Body
    • 13.4.4 Fault
  • 13.5 서비스 인터페이스 설계도구
    • 13.5.1 자동 생성
    • 13.5.2 설계 도구
    • 13.5.3 직접 작성하기
      
• 14장 서비스 지향 설계(SOA 조합 가이드라인)
  • 14.1 SOA 구성단계
    • 14.1.1 스텝 1: 서비스 레이어 선택
    • 14.1.2 스텝 2: 중요 표준 배치
    • 14.1.3 스텝 3: SOA 확장 선택
  • 14.2 서비스 레이어 선택 시 고려사항
  • 14.3 핵심 SOA 표준 배치 시 고려사항
    • 14.3.1 산업표준과 SOA
    • 14.3.2 XML과 SOA
    • 14.3.3 WS-I 기본 프로파일
    • 14.3.4 WSDL과 SOA
    • 14.3.5 XML 스키마와 SOA
    • 14.3.6 SOAP과 SOA
    • 14.3.7 네임스페이스와 SOA
    • 14.3.8 UDDI와 SOA
  • 14.4 SOA 확장 선택 시 고려사항
    • 14.4.1 SOA 특징 선택
    • 14.4.2 WS-* 스펙 선택
    • 14.4.3 WS-BPEL과 SOA
      
• 15장 서비스 지향 설계 (서비스 설계)
  • 15.1 서비스 설계 개요
    • 15.1.1 설계 표준
    • 15.1.2 프로세스 설명
    • 15.1.3 전제조건
  • 15.2 엔티티 중심 비즈니스 서비스 설계
    • 15.2.1 프로세스 설명
  • 15.3 애플리케이션 서비스 설계
    • 15.3.1 프로세스 설명
  • 15.4 태스크 중심 비즈니스 서비스 설계
    • 15.4.1 프로세스 설명
  • 15.5 서비스 설계 가이드
    • 15.5.1 명명 표준
    • 15.5.2 적절한 수준의 인터페이스 크기
    • 15.5.3 확장 가능한 서비스 오퍼레이션 설계
    • 15.5.4 서비스 요청자 식별
    • 15.5.5 모듈화된 WSDL 문서 활용
    • 15.5.6 네임스페이스 주의사항
    • 15.5.7 SOAP의 document와 literal 어트리뷰트
    • 15.5.8 WS-I 프로파일 사용
    • 15.5.9 메타데이터로 서비스 문서화
      
• 16장 서비스 지향 설계 (비즈니스 프로세스 설계)
  • 16.1 WS-BPEL 언어 기본
    • 16.1.1 BPEL4WS와 WS-BPEL의 역사
    • 16.1.2 필요조건
    • 16.1.3 process
    • 16.1.4 partnerLinks, partnerLink
    • 16.1.5 partnerLinkType
    • 16.1.6 variables
    • 16.1.7 getVariableProperty, getVariableData 함수
    • 16.1.8 sequence
    • 16.1.9 invoke
    • 16.1.10 receive
    • 16.1.11 reply
    • 16.1.12 switch, case, otherwise
    • 16.1.13 assign, copy, from, to
    • 16.1.14 faultHandlers, catch, catchAll
    • 16.1.15 다른 WS-BPEL 엘리먼먼트
  • 16.2 WS-Coordination 개요
    • 16.2.1 CoordinationContext
    • 16.2.2 Identifier 및 Expires 엘리먼트들
    • 16.2.3 CoordinationType
    • 16.2.4 RegistrationService
    • 16.2.5 WS-BusinessActivity 코디네이션 유형 지정
    • 16.2.6 WS-AtomicTransaction 코디네이션 유형 지정
  • 16.3 서비스 지향 비즈니스 프로세스 설계
    • 16.3.1 프로세스 정의
      
• 17장 WS-* 확장 기본
  • 17.1 WS-Addressing 언어 기본
    • 17.1.1 EndpointReference
    • 17.1.2 메시지 정보 헤더 엘리먼트
    • 17.1.3 WS-Addressing 재사용성
  • 17.2 WS-ReliableMessaging 언어 기본
    • 17.2.1 Sequence, MessageNumber, LastMessage
    • 17.2.2 SequenceAcknowledgement, AcknowledgementRange
    • 17.2.3 Nack
    • 17.2.4 AckRequested
    • 17.2.5 그 밖의 WS-ReliableMessaging 엘리먼트
  • 17.3 WS-Policy 언어 기본
    • 17.3.1 Policy 엘리먼트와 일반적인 정책 선언
    • 17.3.2 ExactlyOne 엘리먼트
    • 17.3.3 All 엘리먼트
    • 17.3.4 Usage 어트리뷰트
    • 17.3.5 Preference 어트리뷰트
    • 17.3.6 PolicyReference 엘리먼트
    • 17.3.7 PolicyURIs 어트리뷰트
    • 17.3.8 PolicyAttachment 엘리먼트
    • 17.3.9 정책 선언들의 추가적인 유형
  • 17.4 WS-MetadataExchange 언어 기본
    • 17.4.1 GetMetadata 엘리먼트
    • 17.4.2 Dialect 엘리먼트
    • 17.4.3 Identifier 엘리먼트
    • 17.4.4 Metadata, MetadataSection, MetadataReference 엘리먼트
    • 17.4.5 Get 메시지
  • 17.5 WS-Security 언어 기본
    • 17.5.1 Security 엘리먼트 (WS-Security)
    • 17.5.2 UsernameToken 및 Username, Password 엘리먼트 (WS-Security)
    • 17.5.3 BinarySecurityToken 엘리먼트 (WS-Security)
    • 17.5.4 SecurityTokenReference 엘리먼트 (WS-Security)
    • 17.5.5 Security 엘리먼트 내용 구성하기 (WS-Security)
    • 17.5.6 EncryptedData 엘리먼트 (XML-Encryption)
    • 17.5.7 CipherData 및 CipherValue, CipherReference 엘리먼트 (XML-Encryption)
    • 17.5.8 XML-Signature 엘리먼트
      
• 18장 SOA 플랫폼
  • 18.1 SOA 플랫폼 기본
    • 18.1.1 블록 쌓기로 구축하는 기본 플랫폼
    • 18.1.2 일반적인 SOA 플랫폼 레이어
    • 18.1.3 SOA 레이어간 관계와 기술
    • 18.1.4 서비스 기술 아키텍처 기본
    • 18.1.5 벤더 플랫폼
  • 18.2 J2EE의 SOA 지원
    • 18.2.1 플랫폼 개요
    • 18.2.2 초기 SOA 지원
    • 18.2.3 서비스 지향 원칙 지원
    • 18.2.4 최신 SOA 지원
  • 18.3 .NET의 SOA 지원
    • 18.3.1 플랫폼 개요
    • 18.3.2 초기 SOA 지원
    • 18.3.3 서비스 지향 원칙 지원
    • 18.3.4 최신 SOA 지원
  • 18.4 통합 시 고려사항
    
• 부록 A 사례 연구: 결론
  • A.1 레일기공 사
  • A.2 TLS 주식회사
  • A.3 오아시스 세차장
    

[ p169 아래에서 9행 ]

요청-응답 오퍼레이션(Request-response operation): 서비스 공급자가 메시지를 받으면, 서비스 요청자는 표준 메시지나 실패 메시지를 보내야만 한다.
기대-응답 오퍼레이션(Solicit-response operation): 서비스 공급자가 서비스 요청자에게 메시지를 전송하고 나서, 서비스 요청자로부터 표준 메시지나 실패 메시지를 기다린다.

→ 요청-응답 오퍼레이션(Request-response operation): 서비스 제공자가 요청 메시지를 받으면, 서비스 요청자에게 응답 메시지나 실패 메시지를 보내야만 한다.
기대-응답 오퍼레이션(Solicit-response operation): 서비스 제공자가 서비스 요청자에게 응답 메시지나 실패 메시지를 기대하면서, 요청 메시지를 전송한다.

[ p170 7행 ]

이전 패턴의 반대인 출력-입력 패턴: 서비스 제공자가 요청을 전송함에 따라 교환을 초기화 한다(WSDL 1.1의 기대-응답 오퍼레이션과 같다).
→ 위 패턴의 반대인 출력-입력 패턴: 서비스 제공자가 요청을 전송함에 따라 메시지 교환을시작한다 (WSDL 1.1의 기대-응답 오퍼레이션과 같다).