Kt Soa Business Planning Consulting(Summary)

  • 1,167 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,167
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SOA (Service Oriented Architecture)의 적용 Turning SOA into a Reality through Web ServicesMicrosoft Consulting ServiceSung 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 QuarterlyJanuary 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 EngagementJanuary 10, 2006 10/40
  • 11. I.2.(2) 컨설팅 프로세스 검토 프로세스는 SOA 적용의 성숙도를 측정할 수 있는 기준으로 SOMM (Service Orientation Maturity Model)을 사용하고 표준적인 SOA를 위한 참조 아키텍처를 제시하고, 이 Gap을 메우기 위하여 과제를 도출하고 단계적으로 적용하는 방안을 제시한다. 컨설팅 프로세스 참조모델 트랜잭션 구조 전략모델 Gap 분석 방안제시 Start 기본모델정의 현황분석 기술분석 단계적용모델 요건정의 PoC Review SOMM 과제도출 문제분석 적용방안 웹서비스 채택 표준 채택 아키텍쳐 정립 계층화 구조 PoC를 토대로 분석 단계적 적용방안 IntegrationJanuary 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 / POSJanuary 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 EndpointJanuary 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 2004January 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 ServiceClient 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 2005January 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 2003January 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 AgentJanuary 10, 2006 23/40
  • 24. II.2.(1) SOA 적용의 기대효과 각 시스템이 공통된 인터페이스를 가지게 되므로 기존 시스템의 통합이 용이해집니다. 또 통합 사용이 진행이 되면서 데이터의 정합성과 비즈니스 로직의 정비가 자연스럽게 이루어질 수 있습니다. 또 사용자는 기존의 서비스를 이용하는 것이 용이해지고 IT 관리자는 권한과 정책 및 보안정책을 일관성있게 할 수있게 됩니다. 이것은 관리자와 사용자 및 개발자가 모두 효율성있는 작업이 가능해짐을 뜻하므로 생산성이 증대됩니다. 기대효과 비즈니스 프로세스와 정책을 적용하는 것이 용이 서비스 인프라 개발에 직접적으로 연계적용하면 업무를 이해하는데 소요되는 시간이 대폭 감소 Presentation 서비스 UDDI 표준 기반이므로 사내/외 시스템과의 연계가 용이 사용자가 원하는 서비스가 어느 시스템에 있더라도 서비스관리 공통서비스 Composite 애플리케이션 동일한 방식으로 찾고 사용가능 기존의 투자를 보호할 뿐아니라 더욱 활용가능 보안 특정 제품 및 Technology 의존도 감소 IT 자원(시스템 및 애플리케이션 등)이 컴포넌트화된 사용이 가능하므로 재사용성이 증대하고 구조변경이 공유 비즈니스 서비스 용이 사용자 일부 시스템이 교체되거나 큰 변화가 생기는 경우에도 전체적인 구조 관리 용이(Transparency) 데이터 및 레거시 Access 신기술 적용이 용이 비즈니스와 유기적인 IT 구조 노동집약적인 기존의 업무 성격에서 보다 생산적인 업무 성격으로 전환 애플리케이션 아키텍처가 Healthy해짐 고객 CRM 기업간 기타 서비스화 되어 재사용성과 사용 편의성이 높아진 Legacy SystemsJanuary 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 ProcessJanuary 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(저비용) 개통처리완료(처리 정보 메시지) DecouplingJanuary 10, 2006 28/40
  • 29. II.4.(1) SOA 적용의 로드맵: 단계적 구현 Service Oriented 아키텍처의 단계적 구현을 위한 각 단계의 목표는 다음과 같습니다. 서비스 포탈 선택 설계 및 장애지원 포탈 비즈니스 Integrated 지식 DB Rule & 서비스 상태 모니터링 및 분석 운영 및 서비스 레벨 데이터 제공 Process 중심 분석 보고서 기능 구현 SOA 인프라 고도화 보안 및 정책 서비스 방화벽 정교한 정책 프로세스 3단계 비즈니스 룰 적용 구축 서비스 관리 체계 구축 Business Integrated 단계의 마지막을 선택적으로 표시한 것은 비즈니스 프로세스를 완전히 하는 것은 거의 불가능할 뿐 아니라 임계치를 넘어서는 SOA 기본 인프라 구축 비경제적일 수 있기 때문입니다. 서비스표준 서비스관리 표준 채택 서비스 버전관리 웹서비스 채택 서비스 모니터링 개발 표준화 보안모델확립 정책적용체계구축(상속 Web 서비스 기본 아키텍쳐 및 우선순위 등 ServiceService 서비스 레포지토리 관계체계까지 정의) 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 - performanceJanuary 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 기본 인프라 구축 1January 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 ServicesJanuary 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 ServicesJanuary 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 ServicesJanuary 10, 2006 39/40
  • 40. III.4. SOA 적용계획 요약 선택 비즈니스 Integrated SOA 인프라 고도화 3단계 Service Oriented 아키텍처의 단계적 구현을 위한 3 단계의 목표는 다음과 같습니다. 서비스 관리 체계 구축 구축 서비스관리의 SOA 기본 인프라 구축 보안관리의 포인트 포인트 디렉토리 Catalog(서비스레지스트리) 메타데이터 Repository Composite Services Policies, Business Rule Data Access Services Presentation Infrastructure Service Composition Authentication Monitoring 운영관리 트랜잭션 Discovery Authorization 보안 Logging Portal Messaging Integrity UI Encryption Business Process Web UI Synchronous Invocation Asynchronous Invocation Service Logic Business Workflow Business Components Business Entities Data Access Component Service AgentJanuary 10, 2006 40/40
  • 41. III.5. 서비스 인프라의 시스템 구성 2 단계의적용이 끝난 시점에는 다음과 같은 시스템 구성이 예상됩니다. 그림에서 인증을 받은 후 UDDI의 서버에서 서비스 URL을 받은 사용자는 서비스가 있는 서버로 Access 합니다. 시스템 구성은 High Availability를 고려하여 클러스터링이나 다중 서버로 구성되어 있는 것으로 표현하였습니다. 사용자 서비스 인프라 Presentation 서비스 UDDI 서비스관리 공통서비스 Composite 애플리케이션 보안 L4 1 공유 비즈니스 서비스 또는 NLB (Network Load Balancing) 구성 사용자 데이터 및 레거시 Access 웹서버(UDDI 서버) FRONT 3 WISE CReaM K-Hub 기타 BACK Policy 2 BizTalk 서버 인증 NLB 또는 L4 관리콘솔(MMC) 모니터링, 감사, Alert AD01 AD02 4 URL Locating 모니터링서버 (MOM 서버) UDDI SQL 서버 (클러스터) SQL 서버 클러스터 Publishing SQL 서버 클러스터 (MOM, Reporting 서버용) Publishing 서비스 개발서버(별도 로 있는 경우나 웹서비 스지원하는 시스템)January 10, 2006 41/40
  • 42. IV. 리스크 검토January 10, 2006 42/40
  • 43. IV.1. 선결과제 비즈니스 프로세스의 정의 표준화 강력한 내부 SponsorshipJanuary 10, 2006 43/40
  • 44. IV.1. 선결과제 Adoption Levels Products Education Services 4 On Demand • IBM Component Business Business Modeling Transformation • WBI Modeler 3 • Rational XDE • WBI – Message Broker • IBM Assessments for Web Enterprise Wide IT • DB2 Information Integrator Services • Lotus Workplaces • IBM Architecture & Transformation • Tivoli Identity Manager Planning Services for Web • Tivoli Monitor/WebSphere • SOA Roadmap of Best Services Monitor Practices • IBM Strategy & Planning • Red Books (Patterns, SOA Services for Service and Web services) Oriented Architecture 2 • WSAD-IE • SOA Education • IBM Assessments for • WebSphere HATS Service Oriented Service Oriented • WBI Server Foundation Architecture Integration of • CICS Transaction Gateway • IBM Application Renovation • WebSphere Portal • IBM Application Integration Business Functions • Tivoli Access Manager • Tivoli MTP • Speed-start for Web 1 services • IBM Assessments for Web Implementing • WAS ND • Technical Briefings Services Individual Web • WSAD • SOA/Web services Zone • IBM Architecture & • Red Books (Using Web Planning Services for Web Services services for Business Services Integration)January 10, 2006 44/40
  • 45. V. 조직과 역할의 재정비January 10, 2006 45/40
  • 46. V.1. 조직과 역할의 재정비 비즈니스 비즈니스 프로세스 정의 표준/기술/툴 채택 Naming Convention 정책 관리 IT 기획 UI 관리 표준팀 서비스 관리자 서비스 관리 서비스 품질관리 서비스 레포지토리 서비스 버전관리 보안관리 서비스 카탈로그 부서 1 부서 2 부서 3 부서 4 복합 서비스 서비스 설계자 서비스 개발자 단위 서비스 스키마 정의 메시지 정의 단위 서비스 개발 서비스 분석 서비스 설계 서비스 조립 서비스 등록 Workflow 예외 처리January 10, 2006 46/40