1. SOA (Service Oriented
Architecture)의 적용
Turning SOA into a Reality through Web Services
Microsoft Consulting Service
Sung Soo Kim

2. 목차
I. 개요
1. 개요
2. 목적과 범위
II. SOA 적용 전략
1. SOA 적용의 모델
2. SOA 적용의 기대 효과
3. 기술검증 프로젝트의 Review
4. SOA 적용의 로드맵
III. 단계적 SOA 적용 방안
1. 1 단계 적용
2. 2 단계 적용
3. 3 단계 적용
4. 시스템 구성
IV. 리스크 검토 및 방안
1. 사전작업의 필요성
2. 데이터 정합성과 트랜잭션
V. 조직 및 역할의 재정비
VI. 참고자료
January 10, 2006 2/40

3. I. 개요
January 10, 2006 3/40

4. I.1.(1) SOA의 필요성
비즈니스 요구
현재의 IT 차세대 IT
애플리케이션 서비스
Integration(제품화) Assembly(부품화)
비즈니스와
IT의 수렴
필요에 따라 반복되는 구축 필요한 기능은 한번으로 구축
작은 변화의 수용도 쉽지않음 새로운 변화의 수용이 용이
소프트웨어 아키텍쳐
업무와 기술 의존도가 강함 필요 비용과 노동력 절감
솔루션, 기술 및 제품에 따라 다른 방식 솔루션, 기술 및 제품에 따라 다른 방식
재사용성이 떨어짐 재사용성을 높임
Modular하게 분리 사용될 수 없음 Modular하게 기능별로 분리 사용될 수 있음
작은 프로세스의 변화 수용이 재개발로 이어짐 재개발이 아닌 재배열, 재조합으로 요구충족
개발 인원의 업무 및 사용기술에 품질이 전적으로 의존 정의된 프로세스와 정책, Description으로 용이한 사용
플랫폼에 의존 플랫폼에 독립적인 인터페이스
January 10, 2006 4/40

5. I.1.(2) SOA 적용의 접근전략
비즈니스 전략에 따라 IT 조직의 단기 계획 및 중기 전략이 결정되며, 시대의 요구에 따라 더 다양하고 신속한 요구 적용이 필요하고 기술 및
비즈니스 요구에 대해 유연하게 대처 할 수 있어야 합니다.
비즈니스 비즈니스
비즈니스 전략 조직 계획
전략과 비즈니스 조직의 운영
단기 IT 계획 및 중기 전략 기존의 투자를 최대한 보호
Dynamically 소프트웨어 아키텍처를 유연하게 재구성
On-Demand 비즈니스 요구 및 신기술 도입의 저해 요소를
제거
비즈니스 프로세스
특정 기술 종속적이지 않는 방향
생산성 및 호환성 극대화를 위해 표준 도입
애플리케이션 아키텍쳐
데이터
IT 조직 IT 계획
출처: Giga Information Group
기술적으로는 중립적으로(표준 기반), 아키텍처는 비즈니스 프로세스와 서비스 중심으로 재구성하고 “인프라화”
January 10, 2006 5/40

6. I.1.(3) 아키텍쳐 전략
기본 아키텍쳐 전략은 Gartner의 Extended Gartner Architecture Framework, Forrester Research Inc.의 Enterprise Architecture를 참조하였습니다.
아키텍쳐 참조모델 제시는 II-1에서 다루었습니다.
(1)The Extended Gartner Architecture Framework (2) Service-Oriented IT with Business Architecture
출처: Forrester Research Inc.
Customized for
“Each System Only”
진화
출처: Gartner Research (October 2003)
사용자 중심 Transparent 아키텍쳐 전략
서비스 중심 & 계층화(Layering)
프로세스 중심 Virtualization 표준화
Integration
전형적인 기존 시스템 구성
January 10, 2006 6/40

7. I.1.(4) 표준화 전략
SOA의 적용은 현재로선 많은 표준이 만들어지고 적용율이 높은 웹서비스 표준을 채택하는 것을 권고합니다. WS-I 표준은 이미 안정화 궤도에
진입했다고 볼 수 있습니다. 많은 리서치사나 컨설팅사가 SOA는 더 이상 옵션이 아니고 필수라고 권고합니다.
Standards Standards 적용추세
January 10, 2006 7/40

8. I.1.(5) SOA의 특성
SOA의 정의
“SO (Service Oriented) is the provision, consumption and life cycle management of business and technical services
which are self describing and loosely coupled, implemented in a technology neutral manner.”
- Gartner
SOA가
적용되지
않은 경우
누적 재사용성 증가
비용 개발용이성
Integration 용이
SOA가
표준도입 및 적용
적용된
SO 프로젝트
경우
교육
초기구축 내부 새로운 협력업체와의
Integration Integration 채널 Integration
Source: Forrester Research, Inc.
“SOA (Service Oriented Architecture) take a different approach to connecting technology resources. Instead of
customized, hardwired connections, these architectures rely on “Loosely Coupled” ones …(중략)… , can be
joined together easily without friction or customization and just as easily disassembled and reassembled
- Flexible IT, Better Strategy McKinsy Quarterly
January 10, 2006 8/40

9. I.2.(1) 기술검증 및 구현 방안
컨설팅 목적 기술검증 및 구현
SOA 적용의 검토
SOA 적용을 위한 아키텍처 모델 방안제시
SOA 적용에 대한 기술적 검토
Tele-Marketer (Smart Client with CTI Toolbar)
단계적 적용 전략
.NET Framework 1.1 Based ESB on Windows 2003 Server
Composite Layer
조사 대상 W/S … …
W/S W/S
.Net 기술 검증 프로젝트의 구현 내용 BizTalk Server 2004
.Net 기술 검증 프로젝트의 대상 시스템 Orchestration Layer
기타 타사 사례 Orche Orche
…
Orche Orche
stratio
stratio stratio
stratio
nn nn
메릴린치의 아키텍쳐
Connectivi
Tuxedo Adapter Siebel Adapter
ty Layer
Tuxedo CRM Oracle WAS CTI PBX
대상시스템 사례
January 10, 2006 9/40

10. I.2.(2) 마이크로소프트 Service Gateway Accelerator
검토 프로세스는 SOA 적용의 성숙도를 측정할 수 있는 기준으로 SOMM (Service Orientation Maturity Model)을 사용하고
표준적인 SOA를 위한 참조 아키텍처를 제시하고, 이 Gap을 메우기 위하여 과제를 도출하고 단계적으로 적용하는 방안을
제시한다.
컨설팅 프로세스
Start Architecture
Design POC/Pilot Planning/
Assessment
Session Engagement
January 10, 2006 10/40

11. I.2.(2) 컨설팅 프로세스
검토 프로세스는 SOA 적용의 성숙도를 측정할 수 있는 기준으로 SOMM (Service Orientation Maturity Model)을 사용하고
표준적인 SOA를 위한 참조 아키텍처를 제시하고, 이 Gap을 메우기 위하여 과제를 도출하고 단계적으로 적용하는 방안을
제시한다.
컨설팅 프로세스
참조모델 트랜잭션 구조
전략모델 Gap 분석 방안제시
Start 기본모델정의 현황분석 기술분석
단계적용모델 요건정의 PoC Review
SOMM
과제도출 문제분석 적용방안
웹서비스 채택
표준 채택
아키텍쳐 정립
계층화 구조 PoC를 토대로 분석 단계적 적용방안
Integration
January 10, 2006 11/40

12. II. SOA 적용 전략
January 10, 2006 12/40

13. II.1. Global Bank Architecture
Payment Systems and Card Mgmt Treasury / Forex
3D Secure
Trading / Back office
Wealth Management
Core Banking
Branch Banking
EAI Internet Banking
Business Intelligence
Straight through Processing
CRM
Aggregation
Wireless
ATM / POS
January 10, 2006 13/40

14. II.1. ESB
Enterprise Service Bus 혹은 Service Gateway란 무엇인가?.
포털·서비스
SOAP
서비스 리퀘스트
(e.g. J2EE,
.NET)
B2B
서비스·플로우 interaction
데이터
기존
어플리케이션
신규
서비스·논리
January 10, 2006 14/40

15. II.1. ESB 또는 Service Gateway
Enterprise Service Bus 혹은 Service Gateway란 무엇인가?.
 ESB 아키텍처
ESB Client
Software
Installed on
every node
Transport and
repository
ESB Client
Software
Installed on
every node .NET J2EE
Application Web Service Application
Endpoint
January 10, 2006 15/40

16. II.1. 마이크로소프트 서비스 아키텍처
Service Consumers
Transport
Message Message Message
Request Reply Duplex One Way
UDDI, WS-Discovery
Service Interface
Policy
Contract WS-Policy, WS-SecurityPolicy
WSDL
Operational Management
Security
Schema Validation
Reliable
Instrumentation
WS-Security, WS-Trust, WS-
Messaging
Dispatcher
Schema SecureConversation
Logging
Discovery
Trace
WSDL
Security
Authentication
Message Age
Authorization
Addressing Transactions
Encryption
WS-Addressing WS-Coordination ...
Integrity
Protocol Routing
SOAP
Service Interface Pipeline
Service
Service Invocation
Binding Throttling Dispatcher
Synchronous Invocation Asynchronous Invocation
Message Receiver
Service Invocation Framework Trace
Instrumentation
Trace Versioning
Service Processing Pipelines
Instrumentation Invocation Scheduler Service Invocation
Eventing Input Queue Transaction
Context Manager Propogation
Reply Caching
Transactions
Idempotent Message
Store
Operational Management
Support Asynchronous / Reliable Reply Delivery
Async Reply
Retrieval
Security
Reply
Service Façade Scheduler
Reply Queue Delivery
Service Implementation
Service Logic
Business Business Business
Workflows Components Entities
Data Access Logic
Service Agents
Component
Data Source Services
Anatomy of a Service Oriented Architecture Version 1.6
6 August 2004
January 10, 2006 16/40

17. II.1. Service Gateway
Service Service Modules
Transport
Se • Messages are sent thru the
SOAP rvi
Service ce Service Firewall to the Service
Messaging Ga
te wa Gateway where they are
Service Service
y validated and dispatched to
Testing
Broker
services.
Service
Dispatcher • Complex legacy integration is
HTTP
HTTP
available via the Service
Client App Integration module.
SOAP
• The Service Manager
coordinates all of the servers
Service
Firewall in the environment via a
Web
Request Request common database.
• Developers and potentially
Service
Gateway customers use the Service
Portal for self-service access
to configuration, reporting,
Service provisioning, and support.
Portal
COM+
Service
• Developers use the Service
Service
Directory Integration Test module to ensure quality.
Service
Monitoring
Web Service • Operations uses Service
BEA Integrator Monitoring to ensure system
Service MQ Series /
Analytics MSMQ
Orchestration
availability.
Legacy Apps
• Service Analytics is used for
reporting / DW on operational
Mainframe
HTTP and functional data.
Databses
• Advanced Authentication and
Service
Manager
TIBCO
Federated Trust uses the
Service Directory.
January 10, 2006 17/40

18. II.1. SOA와 마이크로소프트 제품군
Specialized configuration for
monitoring Web Services.
Extensible to work with all
other modules shown as well.
Reporting and Analysis on
operational data.
Provides details reporting on
Enterprise Application services. Combines identities,
Integration with both pre-built applications, services,
and custom adapters for invocations, response times,
different integration needs. functional data, etc.
SOA
Monitoring
SOA SOA
Integration Analytics
Web Portal for use by
developers and end- Advanced application
users of to provision, firewall for exposing
configure, report, and SOA SOA SOA services and providing
troubleshoot their Web Portals Gateways Firewalls message inspection,
Services. Provides filtering, and throttling for
integration with Web services.
Customer Self-Service.
SOA SOA
Directories Development
SOA
Management
Standard directory services Visual Studio 2005 SDK
available internally and for discovering,
externally. subscribing, using, and
managing services.
Server and Management
Console to manage all aspects of
the Service Platform. Extensible
to support all modules above
(and new ones). Manages the
entire platform.
January 10, 2006 18/40

19. II.1. SOA와 마이크로소프트 제품군 Roadmap
Today Tomorrow Future
 ASMX (aka  ASMX (VS2005  Indigo
ASP.NET Web enhancements  Longhorn
Services) ) Identity
 Windows XP,  WSE 2.0
Server  Windows
 Indigo (Beta) Server
2003, .NET  Visual Studio
 Visual Studio
Federatio
2005 (Beta) n Server
2003  WSE 3.0 (Tech
 WSE 1.0
 Visual Studio
Preview) 2005
 Office System  Longhorn
2003 WS-I
(Beta) Complian
 BizTalk Server  Windows ce
2004 Server (Beta) SDM
 SQL Server
2000  SQL Server
2005
January 10, 2006 19/40

20. II.1.Web Service Leadership
Gartner Magic Quadrant: Major vendor Web
services platform influence
Challengers Leaders
369 CIOs: which platform is
preferred in building Web services*
Microsoft
Microsoft
Microsoft Microsoft .NET 46.5%
IBM
BEA
IBM IBM WebSphere 19%
BEA Systems IBM Sun ONE 8.2%
Oracle SAPSAP
Oracle 44 System Integrators**
BEA
SunSun
Sun Microsoft .NET 58%
Fujitsu
Oracle Microsystems J2EE 40%
CA Novell
Fujitsu CA Novell
Siebel Siebel
PeopleSoft
Hewlett-Packard PeopleSoft
Niche Players Visionaires
Completeness of Vision
Source: Gartner Research, September
Source: Gartner Research, October 2002 2004
October 2003
January 10, 2006 20/40

21. II.1.(1) SOA 참조모델 전략 - 1
기존의 구조(AS-IS)를 서비스 인프라를 구축하여 TO-BE 모습과 같이 재정비합니다. 이를 통해 애플리케이션 아키텍처는 시스템간의
인터페이스가 정비되고 재사용성이 증대되며, Integration된 구조로 변화됩니다. 구축자체의 효과가 클 뿐아니라 향후의 통합과 변화에 유연하게
대처할 수 있으며 표준 기반으로 특정 기술에 종속적이지 않게 변화합니다.
AS-IS TO-BE
고객서비스 고객센터 지점 고객서비스 고객센터 지점
EAI Hub
서비스 인프라
Presentation 서비스
서비스
서비스관리
공통서비스
애플리케이션
보안
인프라, ESB,
공유 비즈니스 서비스
Service Gateway
데이터 및 레거시 Access
고객 CRM 기업간업무
시스템
마케팅 수신/신탁 여신/외환 지식정보 고객 CRM 수신/신탁 여신/외환 지식정보
기타업무시스템 기타업무시스템
January 10, 2006 21/40

22. II.1.(1) SOA 참조모델 전략 - 2
기존 시스템을 서비스 인프라를 통해 언제든지 쉽게 재구성하여 사용할 수 있도록 하며, 사용자와 서비스에 관한 관리부터 보안에 이르기 까지를
담당합니다. 서비스 인프라를 통해 사용자는 필요한 서비스를 찾고, 사용하고 가공하는 작업을 할 수가 있습니다. 더 중요한 것은 이 인프라를 통해
서비스가 통합이 될 수 있다는 점입니다. 이 참조 모델의 상세는 다음 장에 표현되어 있습니다.
서비스 인프라 참조 모델 사례참조. 메릴린치 서비스 인프라
서비스 인프라
Presentation 서비스
서비스관리
공통서비스
애플리케이션 UDDI
보안
공유 비즈니스 서비스
사용자
데이터 및 레거시 Access
레거시 시스템
고객 CRM 기업간 기타
January 10, 2006 22/40

23. II.1.(2) SOA 참조모델상세 사용자 및
Resource 인증,
서비스 관리
(Metering 등)
보안정책
서비스 인프라 참조 모델
서비스 인프라 참조 모델
서비스 인프라 디렉토리 Catalog(서비스레지스트리)
Presentation 서비스 메타데이터 Repository Composite Services
서비스관리 Policies, Business Rule Data Access Services
공통서비스
애플리케이션 UDDI
보안
공유 비즈니스 서비스
사용자
Presentation
Infrastructure Service
Composition
데이터 및 레거시 Access Authentication
Monitoring
레거시 시스템
운영관리
트랜잭션
Discovery
Authorization
보안
Logging
Portal
고객 CRM 기업간 기타
Messaging
Integrity
UI
Encryption
Business Process
Web UI
Synchronous Invocation Asynchronous Invocation
Service Logic
Business Workflow Business Components Business Entities
Data Access Component Service Agent
January 10, 2006 23/40

24. II.2.(1) SOA 적용의 기대효과
각 시스템이 공통된 인터페이스를 가지게 되므로 기존 시스템의 통합이 용이해집니다. 또 통합 사용이 진행이 되면서 데이터의 정합성과 비즈니스
로직의 정비가 자연스럽게 이루어질 수 있습니다. 또 사용자는 기존의 서비스를 이용하는 것이 용이해지고 IT 관리자는 권한과 정책 및 보안정책을
일관성있게 할 수있게 됩니다. 이것은 관리자와 사용자 및 개발자가 모두 효율성있는 작업이 가능해짐을 뜻하므로 생산성이 증대됩니다.
기대효과
비즈니스 프로세스와 정책을 적용하는 것이 용이
서비스 인프라 개발에 직접적으로 연계적용하면 업무를 이해하는데
소요되는 시간이 대폭 감소
Presentation 서비스 UDDI 표준 기반이므로 사내/외 시스템과의 연계가 용이
사용자가 원하는 서비스가 어느 시스템에 있더라도
서비스관리
공통서비스
Composite 애플리케이션 동일한 방식으로 찾고 사용가능
기존의 투자를 보호할 뿐아니라 더욱 활용가능
보안
특정 제품 및 Technology 의존도 감소
IT 자원(시스템 및 애플리케이션 등)이 컴포넌트화된
사용이 가능하므로 재사용성이 증대하고 구조변경이
공유 비즈니스 서비스 용이
사용자
일부 시스템이 교체되거나 큰 변화가 생기는 경우에도
전체적인 구조 관리 용이(Transparency)
데이터 및 레거시 Access
신기술 적용이 용이
비즈니스와 유기적인 IT 구조
노동집약적인 기존의 업무 성격에서 보다 생산적인
업무 성격으로 전환
애플리케이션 아키텍처가 Healthy해짐
고객 CRM 기업간 기타
서비스화 되어 재사용성과 사용 편의성이 높아진 Legacy Systems
January 10, 2006 24/40

25. II.2.(2) SOA 적용의 비용과 리스크
SOA를 적용하기 위해서는 비용이 드는데 시간과 금전적인 것을 제외하더라도 다음과 같은 비용이 생기고 리스크가 있습니다.
SOA 적용의 비용과 리스크
교육 등 SOA의 사상을 이해하는데 소요되는 비용과 리스크
PoC 수행 등 기술 및 제품 검증 비용과 리스크
표준 적용 비용 맟 표준화 비용
유연성과 편의성 때문에 투자했으나 또 다른 관리 대상만 생긴 효과
제품 종속적인 면에서 벗어나지 못하게 되는 적용 방식
기존의 개발 Mind를 벗어나지 못하여 같은 방식으로 SOA 적용을 시도하는 경우
SOA의 이해 없이 패키지나 제품 도입 위주의 개발 방식
Too-Much-Customized 되어 일반성이 떨어지게 되는 경우
아키텍쳐 상의 Layer를 정확히 구분하지 않는 경우
위의 리스크와 비용을 줄이는 방안으로 SOA의 단계적 적용이 고려될 수 있습니다. 단계적 적용의 첫 단계는 Connectivity, 즉 웹서비스 표준을
이용한 기존 시스템의 통합(가장 통합 효과가 큰 시스템을 선정)이 효과적입니다. 이번 PoC도 비슷한 효과가 있었다고 판단합니다.
SOA 적용 레벨
선택
비즈니스 Integrated
SOA 인프라 고도화
3단계
구축
서비스 관리 체계 구축 기술검증
프로젝트
SOA 기본 인프라 구축
January 10, 2006 25/40

26. II.3.(1) 기술검증 프로젝트의 Review:사전작업
실제 SOA 적용 테스트를 한 것이므로 실제 프로젝트의 내용과도 크게 다를 것은 없으며, 기능 및 성능 PoC 였으므로 서비스 관리를 위한
기능(UDDI 나 서비스 레퍼지토리, 보안, 로깅, 모니터링 등)을 구현하지는 않았습니다. 실제 프로젝트에서는 이러한 관리 기능을 구현해야 합니다.
또, 트랜잭션 처리는 테스트를 위하여 이루어 진 것이므로 효율성을 위하여 비동기식으로 구현하는 것은 생략되었습니다.
UML을 통한 모델링
분산 2PC 트랜잭션을 동기적으로 구현
Siebel 및 Tuxedo Adapter 개발
사용자
응답대기
업무분석 패키지 제공 기능숙지 제공 서비스 리스트 사전 작업
January 10, 2006 26/40

27. II.3.(2) 기술검증 프로젝트의 Review: 적용내용
기술 검증 프로젝트에서 구현된 내용은 오른쪽 표에서 표시된 부분으로,
Level 기준 Milestone
여기서 레벨은 SOMM (Service Orientation Maturity Model) 레벨의 1, 2
단계를 나타냅니다. Level 1 웹 서비스 표준 SOAP, WSDL, XML 스키마 등의 사용
PoC 구현 사례 채택
WS-I 프로파일
(■ 회색표시부분)
개발 표준화 웹 서비스 표준적용을 위한 툴
개발 프로세스 정의
각 Legacy 시스템은 웹 서비스화 되어있는 경우와 아닌 경우로 다음과
각각 필요 작업 내용이 다릅니다. 여기서, 웹 서비스화 되어 있는 개발 툴 정의
시스템의 작업은 제공되는 서비스를 알아내는 것이 작업의 전부입니다. Best Practice 의 확보
적용 방법 정의
Legacy 시스템의 다른 출발점 Level 2 서비스 카탈로그 서비스의 기술적 정의 Repository
애플리케이션 어댑터 웹 웹 서비스를 제공하는 어떤 서버로부터 접근 가능
분석 준비 서비스
서비스 Layers 웹 서비스 계층 모델
WISE 재사용성 증대 및 인프라 화
서비스화
[Tuxedo] 서비스 적용 모델 웹 서비스 Publishing 프로세스
서비스 로직, 인터페이스와 정책과 Ownership 의 분산
자동화 정도
CReaM 서비스화
[Siebel] 서비스 정책 조직 차원의 정책 채택(메시지 헤더, 보안 옵션, 공통
루틴의 표준화된 사용
서비스 Block 모델 서비스 지원을 위한 표준 기능 모델(Logging, Validation,
Metering 등)
KHUB
Web Service Reuse
공통 스키마 모델 모든 서비스에 공통된 정의를 제공하는 Entity 집합
Iterative Process
January 10, 2006 27/40

28. II.3.(3) 기술검증 프로젝트의 Review: 트랜잭션처리
SOA의 사상에 따라 비동기식으로 트랜잭션을 분리하고 Queuing을 사용하여 데이터 일치를 보장하는 방법이 가능합니다.
동기식처리
사용자응답시간 단축효과
사용자
응답대기 부하분산의 효과
서비스 Granularity를 잘게 쪼개는
효과( 재사용성을 높이는 효과)
기존 개발 습관의 재검토
1) 가능하면 동기식을 비동기식으로, Long
Running을 업무 프로세스와 로직
개선으로 불가결한 경우를 제외하고
비동기식처리
변경합니다.
2) 데이터 정합성을 유지하기 위해선
BeginTrans(WISE)
Queue 관리나 보상(Compensation
개통처리(WISE)
Logic)을 준비합니다.
En-queue
Commit(WISE) 사용자
응답대기
Begin Trans(CReaM) 3) “Real Time”을 재정의합니다.
개통처리결과(처리 정보 메시지)
4) 무조건 Sync처리를 할 것이 아니라
개통처리상태 Request
Polling(고비용) 필요한 처리시간을 제어할 수 있게 구현
개통처리상태(처리 정보 메시지) (조건을 충족하게 설계)합니다.
Commit(CReaM) 5) 동기식 2PC는 오랜 Locking과 자원의
낭비를 의미합니다.
Notification(저비용)
개통처리완료(처리 정보 메시지) Decoupling
January 10, 2006 28/40

29. II.4.(1) SOA 적용의 로드맵: 단계적 구현
Service Oriented 아키텍처의 단계적 구현을 위한 각 단계의 목표는 다음과 같습니다.
서비스 포탈
선택 설계 및 장애지원 포탈
비즈니스 Integrated 지식 DB Rule &
서비스 상태 모니터링 및 분석
운영 및 서비스 레벨 데이터 제공
Process 중심
분석 보고서 기능 구현
SOA 인프라 고도화 보안 및 정책
서비스 방화벽
정교한 정책 프로세스
3단계 비즈니스 룰 적용
구축
서비스 관리 체계 구축
Business Integrated 단계의 마지막을 선택적으로
표시한 것은 비즈니스 프로세스를 완전히 하는 것은
거의 불가능할 뿐 아니라 임계치를 넘어서는
SOA 기본 인프라 구축 비경제적일 수 있기 때문입니다.
서비스표준 서비스관리
표준 채택 서비스 버전관리
웹서비스 채택 서비스 모니터링
개발 표준화 보안모델확립
정책적용체계구축(상속
Web 서비스 기본 아키텍쳐 및 우선순위 등 Service
Service 서비스 레포지토리 관계체계까지 정의) Management
서비스 Layer 구축 정책 Repository
정책정의 및 표준화 테스트 기능강화
인터페이스 정의
서비스관리
서비스모니터링
테스트
January 10, 2006 29/40

30. II.4.(2) SOA 적용의 로드맵: 표준의 채택
SOA의 적용을 위해서는 표준의 채택이 선행되어야 합니다.
웹서비스 표준스택
선택 WS-Security
WS- DIME
(Signing & WS-Routing
WS- Attachments
비즈니스 Integrated WS-Addressing (Binary Stream)
WS-
Encryption)
Encryption) Composable
Service
Metadata
Metadata
Assurances
WS-Trust
WS-
WS-Secure-Conversation
WS- Secure- WS-Policy
WS-
SOA 인프라 고도화 WS-Security-Policy
WS- Security-
3단계 XSD, WSDL, UDDI, Policy, MetadataExchange Description
구축
서비스 관리 체계 구축 SOAP, Addressing Messaging
XML Language
SOA 기본 인프라 구축 HTTP HTTPS TCP SMTP … Transport
컨설팅 산출물 “6.1 표준의 채택” 참조
서비스표준
표준 채택
웹서비스 채택
개발 표준화
서비스 기본 아키텍쳐
서비스 레포지토리
서비스 Layer 구축
정책정의 및 표준화
인터페이스 정의
서비스관리
서비스모니터링
테스트
January 10, 2006 30/40

31. II.4.(2) SOA 적용의 로드맵: 대상의 분석
도메인 모델을 정립하기 위해 Top-Down 방식의 분석 설계가 필요하다.
도메인 모델 Top-Down
도메인구분
도메인Decomposition
비즈니스 프로세스, 비즈니스 Use Case 도출
도메인 인터페이스 정의
Rule/Policy Functional Areas
Subsystems
1
서비스 UI
Framework Framework
비즈니스 프로세스
1
2
Immediately after the
Business Process Layer
Circulating Nurse calls PreOp
1 Hr before surgery is complete
circulating nurse calls, Dorie
calls ASU / Floor for the
patient.
ASU
2
FLOOR
7
OR Circ. Nurse
Time patient left Pre-Op
is noted Reason for
delay
웹서비스
Reason for
delay
6 3
OR Nurse calls to tell After calling ASU / Floor
that OR will be ready
Web Service Layer
Dorie calls transport.
in 15 minutes (usually) Pre-Op (Dorie)
5
Anesthesia Faculty is
4
called as soon as patient Patient Arrival time
arrives to Pre-Op in Pre-Op Noted
Reason for Rule Engine
Bottom-Up
Anesthesia Transport
Faculty delay
8
The Summary of the Reason for Delay from 1 - 7 and the total delay
time is noted. Also any other Miscellaneous information is noted.
Why OR Nurse didn’t call? If OR nurse called, Why patient is not
Reason for
ready in ASU / Floor ? Is there a transport problem? (DELAY
delay CODES 1, 2 and 3)
Reason for
Why is patient still not ready in Pre-Op ? (DELAY CODE 4)
delay
Reason for
delay
Why is patient not ready in Pre-Op ? (Any Anesthesia Problem) , If
Patient is ready then why hasn’t the OR nurse called yet ? Is there
any transport problem ? (DELAY CODES 4,5,6)
Rule Layer 콤포넌트 레거시시스템
KTF Legacy 시스템
(WISE, CReaM, etc)
Domain Workflow
Reusability vs. Granularity -
performance
January 10, 2006 31/40

32. II.4.(4) SOA 적용의 로드맵: SOMM Level 1
Service Oriented 아키텍처의 단계적 구현의 기준으로 SOMM (Service Orientation Maturity Model)을 사용하였습니다. SOMM은 각 단계의
Milestone을 제공합니다. 4개의 레벨이 있습니다.
Level 기준 Milestone 특징
Level 웹 서비스 표준 SOAP, WSDL, XML 스키마 등의 사용 웹 서비스 활성화
1 채택 1 기본 표준 준수
다양한 적용 기술 확보
WS-I 프로파일 1
개발 표준화 웹 서비스 표준적용을 위한 툴1
개발 프로세스 정의1
개발 툴 정의1
Best Practice의 확보1
적용 방법 정의1
Level 1의 주요 기대효과 애플리케이션 및 시스템의 상호 연동성
선택
비즈니스 Integrated
SOMM Level은 주로 기술적인 기준으로 나누어져 있어 제안한 3단계 구축과
SOA 인프라 고도화 3 정확하게 일치하지 않습니다. 3단계 구축에서 처음 단계는 SOMM Level의 1,2
단계의 내용을 대부분 포함합니다.
3단계
구축
서비스 관리 체계 구축
2 그것은 첫 단계 구축에서도 현실에서는 기본적인 관리 기능의 구현이
필수이기 때문입니다.
SOA 기본 인프라 구축
1
January 10, 2006 32/40

33. II.4.(4) SOA 적용의 로드맵: SOMM Level 2
Level 기준 Milestone 특징
Level 서비스 카탈로그 서비스의 기술적 정의 Repository 1 조직 전반에 걸쳐 웹 서비스를
2 생성/적용하는 프로세스
웹 서비스를 제공하는 어떤 서버로부터 접근 Component와 infrastructure의
가능1 효율적이고 일관성 있는 사용
추가 서비스 적용에 비용 감소
서비스 Layers 웹 서비스 계층 모델1 스키마 및 서비스 인터페이스에서의
일관성 있는 패턴 사용
재사용성 증대 및 인프라 화1 23 사내 전체 웹 서비스 구조 정의
서비스 적용 모델 웹 서비스 Publishing 프로세스1
서비스 로직, 인터페이스와 정책과
Ownership의 분산1
자동화 정도1 23
서비스 정책 조직 차원의 정책 채택(메시지 헤더, 보안
옵션, 공통 루틴의 표준화된 사용1
서비스 Block 모델 서비스 지원을 위한 표준 기능 모델(Logging,
Validation, Metering 등) 1 2
공통 스키마 모델 모든 서비스에 공통된 정의를 제공하는
Entity 집합 1 2
Iterative Process 1 23
Level 2의 주요 기대 효과 서비스 구축 및 적용 비용 감소
January 10, 2006 33/40

34. II.4.(4) SOA 적용의 로드맵: SOMM Level 3
Level 기준 Milestone 특징
Level 버전관리 서비스 버전 관리 2 서비스 안정성을 위한 인프라 구축
3 상태, 감시 및 Troubleshoot에 필요한
Migration 증대를 위한 Abstraction 제공 2 Visibility를 확보해야 함
서비스 사용자가 내용에 확신을 가지고
서비스 모니터링 Real-Time 서비스 모니터링1 2 사용할 수 있는 기반 마련
조직 차원의 운영 및 관리가 지원되어야
서비스 이력 관리 2
함
모니터링 표준2 도구(Instrumentation)
모니터링
표준 보안 모델 각 서비스 Layer별 보안 모델2 Alerts/Notifications
권한 관리 영역 정의 2
Token 핸들링 및 Trading 루틴 2
정책 저장소 정책 정보 Repository 2
각 서비스에 대한 정책 프로세스 2
서비스, Layer, 그룹별 정책 2
서비스 포탈 설계 및 Runtime 장애 지원 포탈 3
서비스 Flow 可視性(가시성, Visibility) 3
Sample, FAQ, Notice와 Tip 등 제공 3
Testing 환경 Back-End 시스템 사용 없이 테스트 Call
가능 1
Validation, 샘플 응답, Feedback 제공 2
Header Tag을 통하여 Triggering 3
Level 3의 주요 기대 효과 서비스 안정성 및 가시성 증대
January 10, 2006 34/40

35. II.4.(4) SOA 적용의 로드맵: SOMM Level 4
Level 기준 Milestone 특징
Level 정책 관리 서비스 정책의 Update 자동화 2 복합적이고 보다 복잡한 요구를 보다
4 빨리 수용 및 적용하기 위하여 서비스의
서버간 Interaction과 정보 공유 3 재구성이 지원됨
서비스 적용을 위한 표준적인 서비스
서비스 협업 기존의 서비스로부터 신규 서비스 구성 가능 준비 단계가 있음
2 서비스 분석을 위한 Tracking 및
Reporting 조작 가능
Subscription과 Notification Handling 제공 3 분산적인 정책 관리와 강제 적용이
설계 툴과 Runtime 3 제공됨
서비스 Orchestration과 Workflow가
Provisioning 모델 Provision 될 수 있는 서비스를 위한 모델 3 지원됨
Metering, Auditing, Health Monitoring와
서비스 Provisioning 3
서비스 분석 서비스 동작 분석 3
운영 및 서비스 레벨 데이터 제공 3
Reporting Customization 3
서비스 방화벽 상용 웹 서비스 보안을 위한 Gateway 3
Token 조사, 메시지 Validation과 Blacklisting
지원 3
서비스 정책 강화 비즈니스 룰 적용지원과 서비스 및 서비스
Block Evaluation 3
정책 반영 강제성 및 모든 Granularity 레벨
지원 3
Level 4의 주요 기대 효과 자동화 및 Revenue 창출
January 10, 2006 35/40

36. III. 단계적 SOA 적용 방안
January 10, 2006 36/40

37. III.1. 1 단계 적용: SOA 기본 인프라 구축
선택
비즈니스 Integrated
SOA 인프라 고도화
3단계
Service Oriented 아키텍처의 단계적 구현을 위한 1 단계의 목표는 다음과 같습니다. 서비스 관리 체계 구축
구축
SOA 기본 인프라 구축
디렉토리 또는 RDB
Catalog(서비스레지스트리)
메타데이터 Repository
Composite Services
Policy & Business Data Access Services
Rules
(관계형 DB, 디렉토리)
Infrastructure Service
Presentation
Composition 1) 노란색으로 표시된 부분은 일부 기능을
Authentication 구현하지만 확정된 정책이나 템플릿이 없이는
완성이 어려운 부분입니다.
Monitoring
운영관리
트랜잭션
2) 첫 단계에서는 기본 기능을 구현하면서
Discovery
Authorization 보안
Portal
Logging Requirement를 수집하여 정책수립과 운영 관리
표준화 방안을 완성합니다.
Messaging
Integrity 3) 기본적인 기술구조는 갖추게 됩니다.
UI
Encryption
Business Process
Service Logic
Business Workflow Business Components Business Entities
Data Access Component Service Agent
기본기능구현
상대적 성숙도 높음
Data Source Services
January 10, 2006 37/40

38. III.2. 2 단계 적용: 서비스 관리체계 구축
선택
비즈니스 Integrated
SOA 인프라 고도화
3단계
Service Oriented 아키텍처의 단계적 구현을 위한 2 단계의 목표는 다음과 같습니다. 서비스 관리 체계 구축
구축
SOA 기본 인프라 구축
디렉토리 또는 RDB
Catalog(서비스레지스트리)
메타데이터 Repository
Composite Services
Policy & Business Data Access Services
Rules
(관계형 DB, 디렉토리)
Infrastructure Service
Presentation
Composition
Authentication
Monitoring
운영관리
트랜잭션
Discovery
Authorization 보안
Portal
Logging
Messaging
Integrity
UI
Encryption
Business Process
Service Logic
Business Workflow Business Components Business Entities
Data Access Component Service Agent
기본기능구현
상대적 성숙도 높음
Data Source Services
January 10, 2006 38/40

39. III.3. 3 단계 적용: SOA 인프라고도화
선택
비즈니스 Integrated
SOA 인프라 고도화
3단계
Service Oriented 아키텍처의 단계적 구현을 위한 3 단계의 목표는 다음과 같습니다. 서비스 관리 체계 구축
구축
SOA 기본 인프라 구축
디렉토리 또는 RDB
Catalog(서비스레지스트리)
메타데이터 Repository
Composite Services
Policy & Business Data Access Services
Rules
(관계형 DB, 디렉토리)
Infrastructure Service
Presentation
Composition
Authentication
Monitoring
운영관리
트랜잭션
Discovery
Authorization
보안
Portal
Logging
Messaging
Integrity
UI
Encryption
Business Process
Service Logic
Business Workflow Business Components Business Entities
Data Access Component Service Agent
기본기능 구현
상대적 성숙도 높음
Data Source Services
January 10, 2006 39/40