system z soa와esb참고. eai vs. esb? eai란(광의의eai)? "eai encompasses approaches,...

© 2008 IBM Corporation IBM Systems

System z SOA와 ESB

Sunho SungSystem zTM Software

2 IBM Systems

목차

SOA 등장의 배경

SOA란?

SOA와 ESB

SOA를 위한 System z 고유의 가치

3 IBM Systems

목차


SOA란?

SOA와 ESB


4 IBM Systems

SOA 등장의 배경: 비즈니스 환경의 변화2006년 IBM이 전세계 CEO에 대한 설문 조사에서, 87%의 CEO들은 혁신(Innovation)을 이끌어 갈 변화가 필요하다고 믿고 있습니다.

65%A lot22%

Moderate

13%

Little or no

‘향후 2년 내에 급격하고도 본질적인 변화가 필요한가?’에 대한 답변

Source: 2006 IBM Global CEO Survey

Rapidly evolving market forces drive the need for innovation

CEO에게 중요한 혁신 (Innovation) 과제

Top Innovation Priorities:

Extend the abilityto collaborate inside & outside

Innovatebusiness models & processes

Leverage informationfor business optimization

혁신은 전적으로 변화에 대해 말합니다.SOA는 더 쉽게 변화하게 만듭니다.

5 IBM Systems

생존을 위한 지속적 혁신

기업 전반에 관련된 최신 정보를 사용하여 핵심적인 프로세스에서의 지연요소를 지속적으로 제거함으로써 경쟁력을 갖추기 위한 지속적 혁신이 필요합니다. 이러한 혁신을 가능하게 하도록 IT 시스템이 지원을 할 수 있어야 한다는 요건이 SOA 등장의 배경이 됩니다.

최신 정보를 필요한 곳에 지체 없이 제공기업의 Visual 화에 따른 정보의 통합 요구투명경영을 위한 실시간 정보 공유

운영 및 의사결정 지원비즈니스 수행 내용 및 결과에 대한

예측 및 분석 지원핵심적이고 차별적이며, 높은 부가가치를

창출하는 프로세스

6 IBM Systems

비즈니스와 IT의 GAP

•업무 요구사항과 구현된 시스템의요건 차이를 어디서 줄여야 할까?

•각 영역 담당자의 역할을 명확하게할수록 그 둘의 차이는 멀어진다.

• 업무 부서의 예산과 요구로 만들어진시스템이 업무에 도움이 되지 않고, 오히려 부가적인 작업을 필요로 하고 업무능률을 저하 시킨다.

• 전사 IT시스템의 방향성과 필요성은인정하지만, 보다 혁신적인 시스템을요구하기 보다는 원래 있는 그대로를선호하게 된다 Busin

ess D

irecti

on

Business와 IT의괴리

지속적인 혁신을 위해서는 변화하는 업무 요건을 IT에 신속하게, 그리고 정확하게 반영하여야 합니다. 하지만 현실은 업무 요구사항과이를 바탕으로 구현된 IT 시스템에 많은 차이를 보이게 됩니다. 이러한 차이를 최소화하기 위해 SOA가 등장하게 됩니다.

7 IBM Systems

IT 유연성과 느슨한 결합의 중요성

변화하는 비즈니스를 지원하기 위해서는 IT의 유연성이 요구되며, 이를 확보하기 위하여 계층 간의 느슨한 결합이 필요합니다.

Service LayerHow do you connect sales to customers?

.NETLinux

J2EE Unix

OS/390MQ

DB2

Technology LayerHardware, NetworkHow do you connect J2EE to .NET?

Finance

PeopleSoft

SAP

SiebelDir

Outlook

Application LayerApplications, Components, SoftwareHow do you connect SAP to Siebel?

Implies the need for a connectivity layer (ESB)

Business Process LayerCross Functional End-to-end Sales Order Process

CustomerEmployee

SalesProduct

8 IBM Systems

IT 기술의 발전

SOA는 Object Technology를 계승 발전시킨 IT 아키텍처 전략으로서 기존 OO, CBD가 주로 개발자 관점의 재사용에 중심을두는 반면, SOA는 사용자 중심의 서비스 및 프로세스에 기반한 업무 프로세스 및 IT 서비스 재사용에 중점을 두는 전략입니다.

OO

CBD

SOA

Value

ComponentsComponents

ApplicationsApplications

BusinessBusinessProcessesProcesses

방법론방법론 및및시스템시스템구축구축 범위범위

모델링모델링적용적용 범위범위

미들웨어미들웨어개방형개방형 표준표준

단위프로그램

단위시스템전사 프로세스 및 시스템

Object서비스

단위 시스템IT 서비스

전사 비즈니스프로세스& IT서비스

CORBA

J2EE/CORBA

WSDL/SOAP/UDDI/CORBA

OOOO CBDCBD SOASOA ITIT패러다임의패러다임의 진화진화재활용성이 높고 다양한 운영 환경을 지원하기 위한 방향으로 발전

9 IBM Systems

목차


SOA란?

SOA와 ESB


10 IBM Systems

Service Oriented Architecture: 정의SOA는 서비스의 개념을 바탕으로 하는 통합 아키텍처로서 느슨한 결합(Loose Coupling)과 캡슐화(Encapsulation) 를 전사 차원의 통합(Integration)에 반영하는 것을 목표로 합니다.

- 객체 지향 개발(Object Oriented Development)

- 컴포넌트 기반 설계(Component Based Design)

- 전사 어플리케이션 통합 기술(Enterprise Application Integration Technology)

Client Registry

Machine 1

Service A

Service B

Machine 2

Service C

Machine 3

Service A

1. Service Lookup

2. Lookup Response

3. Service Invocation

4. Service Response

느슨하게 결합된 서비스(Loosely coupled service)란?서비스 요청자 또는 소비자의 어플리케이션코드와 서비스 제공자의 어플리케이션 코드가서로에 대해서 알아야 하는 것들을 제한한다는의미입니다. 서비스의 여러 측면 중 서로결합되어있는(Coupled) 부분에 어떤 변경이발생할 경우, 요청자 또는 제공자 어플리케이션코드, 또는 양쪽 모두 수정을 하여야만 합니다. 만약, 결합되어 있지 않은(Decoupled) 측면이라면 요청자, 제공자, 또는 중재를담당하는 기반구조 어떤 곳도 수정이 필요없습니다.

11 IBM Systems

Service Oriented Architecture: Service란?

명시적인, 구현에 독립적인 인터페이스

지역투명성(Location transparency: 정확한 Location을 몰라도 사용 가능, 예를 들면 IP주소를 외우는 대신 Domain Name을사용해 접근)

상호운용성(Interoperability: 다른 시스템이나 제품과 함께 잘 동작하기 위한 능력)

재사용 가능한 비즈니스 기능의 캡슐화

Technical functions (예를 들면, logging)

Business functions (예를 들면, getBalance)

Business transactions (예를 들면, openAccount)

Business processes (예를 들면, applyForMortgage)

12 IBM Systems

SOA is like building blocks…

Building blocks represent business services

SOA allows you to modularly assemble and reassemble the blocks to suit your business needs

Checking Patient Records

Opening Account

Checking flight status

13 IBM Systems

SOA is like your golf clubs…

Think of each golf club represents a business service

Depending on the hole, SOA allows to you configure your clubs flexibly and easy to suit your needs.

Par 5

Par 4

Par 3

14 IBM Systems

목차


SOA란?

SOA와 ESB


15 IBM Systems

IBM SOA Reference ArchitectureSOA 레퍼런스 아키텍처는 SOA의 기본적인 구조로서 SOA 구현에 투입될 서비스의 집합을 벤더 중립적으로 인식하고 계획하는 방식입니다. 즉, 사용하는 제품이나 서비스와 상관 없이, SOA를 구현하려는 경우에 고려해야 할 요소들입니다.

c

비즈니스 혁신 및 최적화 서비스

개발서비스 인터랙션 서비스 프로세스 서비스 정보 서비스

파트너 서비스 비즈니스 어플리케이션서비스

접속 서비스

솔루션자산의

디자인과개발을

위한 통합환경

서비스, 애플리케이션 및자원의관리및보안

실시간 비즈니스 정보를 통한 더 좋은 의사결정 가속화

사람, 프로세스 및 정보 사이의협력을 가능하게 함

비즈니스 프로세스의 관리및 자동화

통일된 방식으로 다양한데이터 관리

비즈니스 파트너와의 연결강력하고 확장 가능한 보안

서비스 환경 구축

기존 정보와 어플리케이션자산과의 인터랙션 가속화

ESB서비스 사이의 커뮤니케이션 조정

IT 서비스관리

인프라스트럭쳐 서비스산출물, 가용성 및 성능 최적화

16 IBM Systems

Enterprise Service Bus (ESB)SOA의 참조 아키텍처의 핵심은 Enterprise Service Bus (ESB)입니다. ESB는 전사적인 서비스 아키텍처 구현에 필요한 연결 능력(Inter-Connectivity Capabilities)을 제공합니다.

장래, 모든 서비스는 서비스 지향의 허브(버스)에 접속됨

서비스·플로우

신규서비스·논리

B2Binteraction

포털·서비스SOAP

서비스 리퀘스트(e.g. J2EE, .NET)

데이터

기존어플리케이션

ESB의 기능:• 중계서비스··· 라우팅, 메세지 변환• 이벤트서비스··· Publish and Subscribe • 트랜스포트서비스···동기/비동기, 영속적/비영속적,Loosely/Tightly • 표준 기반··· HTTP/HTTPS, JMS, JAX-RPC, SOAP 등

17 IBM Systems

ESB and Advanced ESB

ESB:

WebSphere ESB for z/OS

Advanced ESB:

WebSphere Message Broker for z/OS

실제 SOA구현에는 다양한 ESB 요건이 존재하며, 경우에 따라 ESB 또는 Advanced ESB, 또는ESB와 Advanced ESB 모두 필요할 수 있습니다.

Web Services

JMS

WebSphere MQ

HTTP

XML

WebSphere Adapters

JMS

TIBCO Rendezvous®

Web Services

Weblogic JMS®

WebSphere MQ

TIBCO EMS JMS®

HTTP

SonicMQ JMS®

Biztalk®

MQe Tuxedo®

Real-time IP

FTPMulticast

MQTT

XML

COBOLCopybook

EDI-X.12

ACORD

EDI-FACT

ebXMLAL3

HIPAA HL7

SWIFT FIX Custom FormatsWord/Excel/PDF

Plus the following:WebSphere

Adapters

Web Services 연결성 및 데이터 변환 범용 연결성 및 데이터 변환

• ESB는 어플리케이션 및 서비스 통합을 위한 유연한 인프라스트럭처를 제공하며, 인터페이스 개수/사이즈/복잡성을 감소시켜 줍니다. WebSphere ESB 는 J2EE/JCA 표준을 사용하여 개발한 WAS 기반의 ESB 입니다. Advanced ESB인 WebSphere Message Broker는 다양한 인터페이스와 이벤트 처리, 데이터 변환 등을 복합적으로 지원합니다

18 IBM Systems

Enterprise Service Bus: SOA with ESB

ESB 를 사용하지 않을 경우의 SOA구조는 가능하지만, 이 경우 인터페이스에 대한 개발 부담이 증가하게 됩니다.

Turn this… …into this.Application Application Application Application

ApplicationApplicationApplicationApplication

Service Service Service Service

Service ServiceService Service

Interface Interface Interface

Interface Interface Interface Interface

= interface

Service Service Service Service

Service ServiceService Service

Enterprise Service Bus

Decouples the point-to-point connections from the interfaces

Dynamic selection, matching, Substitution

More flexible coupling & decoupling

Application & Interfaces for resue

19 IBM Systems

Enterprise Service Bus의 형태

SOA를 구현을 위해서는 대량의 개별 상호작용을 지원하기 위해 더 정교하고, 관리가 가능한 기반구조를 필요로 합니다. 또한 더 정립된 통합 방법, 예를 들어 메시지 지향 통합(Message-oriented Integration), 이벤트 구동 통합(Event-driven Integration), 또는최소한 기존 기반구조와의 통합을 지원하여야 하며, 전사적인 서비스의 품질을 지원하여야 합니다. ESB는 그러한 기반구조를 위한 개념입니다.

ESB는 버스(Bus)의 한 형태로 정의되기도 하지만, 허브(Hub)의 한 형태로 정의되기도 합니다.

•BUS

•HUB

20 IBM Systems

ESB: 구현

분산된 버스(Bus)와 중앙 집중된 허브엔스포크(Hub-and-spoke) 솔루션을 명확히 구분하는 것은 중요하지 않습니다. 관리의 중앙집중화와 기반구조의 분산 관점에서, 초기 작은 규모의 통합 솔루션의 물리적인 구현은 단일 허브에 집중될 것입니다. 그러나 구현이 발전되어가면, 논리적으로 여전히 중앙 집중화된 관리를 유지하면서도 물리적으로 기반구조는 버스의 개념으로 더욱 분산될 수 있을 것입니다. 따라서 결과적으로 ESB는 아래와 같이 구현됩니다.

21 IBM Systems

ESB: ESB와 다른 SOA 컴포넌트의 역할

Business Service Directory: SOA에 참여하는 시스템에 사용 가능한 서비스의 자세한 정보와 분류를 제공

Business Service Choreography: 연속된 일련의 서비스 상호작용들을 비즈니스 프로세스로서 통제 (Orchestration)

ESB Gateway: 서비스에 ESB가 연결을 제공하지 않는 외부로의 통로를 제공, 여러 ESB들을 연결하여 ESB 연합(Federate)을 구성

22 IBM Systems

ESB의 기본적인 기능

서비스 명, 서비스 호출 등에 대한 하나의 관리 포인트 제공

실제 서비스 프로토콜과 구현으로부터 어플리케이션 코드를 분리

다양한 운영 환경에서의 통합 지원

지역투명성(Location transparency)

비고

관리 기능 (Administration Capability)관리

(Management and autonomic)

서비스 인터페이스 정의

서비스 메시징 모델

서비스 구현의 대체

서비스 상호작용

(Service Interaction)

여러 통합 형태 또는 아답터

프로토콜 변환

통합 (Integration)

Routing

Addressing

최소 하나이상의 메시징 형태를 지원

(Request/Response, Pub/Sub)

널리 사용되어 지고 있는 통신 프로토콜 중 최소 하나 이상을 지원

통신 (Communication)

기능항목

ESB는 SOA의 통합 인프라스트럭처(Integration Infrastructure)를 지원하는 구성요소로서 다음의 기본 기능을 제공합니다.

23 IBM Systems

ESB PatternESB 패턴(Pattern)은 SOA 인프라스트럭처 내부의 ESB 컴포넌트를 설계하기 위해 사용되어 질 수 있는 어플리케이션 통합 패턴(Application Integration Pattern)입니다.

24 IBM Systems

참고. EAI vs. ESB?

EAI란 (광의의 EAI)?

"EAI encompasses approaches, methodologies, standards, and technologies allowing very diverse but important systems to share information, processes, and behavior in support of the core business."

- David Linthicum (CEO, Bridgewerx) 의 Blog (8/8/2005)

http://blogs.ittoolbox.com/eai/cto/archives/esb-vs-eaigive-me-a-break-5303

EAI(구현기술)

ESB(구현기술)

EAI (개념) • 표준기반예) WS-Standard

• 저비용• 서비스 지향

• 특정 기업의 고유의 기술요소를 기반으로 표준 지원 포함

예) MQ (MS, IBM),WebMethods,SeeBeyond사의 EAI 제품

• 고비용• 서비스 지향 가능

25 IBM Systems

목차


SOA란?

SOA와 ESB


26 IBM Systems

SOA의 구현을 위한 고려: 운영환경의 선택을 위한 고려사항SOA는 플랫폼이나 구현기술 또는 이들을 제공하는 업체에 독립적인 아키텍처 모델입니다. 하지만, SOA 어플리케이션을 구현하고, 이를 운영할 Infrastructure를 선택하는 데 있어서는 SOA 구현과 운영을 위한 기능적, 비기능적 요소와 SOA 운영환경으로서의 각플랫폼이 제공하는 서비스 품질(Quality of Services) 등, 여러 다양 측면을 고려하여야 합니다.

System z

UnixWindows

WebService

XMLXML SOAP

SOAP

ESB

WPS

CICSUDDI

WSDL

BPEL

기능적 요소• 설계 및 개발• 비즈니스 혁신 및 최적화• 프로세스 및 정보의 관리• ESB• 비즈니스 어플리케이션• 내, 외부 어플리케이션, 정보, 자산과의 연계• IT 서비스의 모니터링 및 관리

구현

비기능적 요소• 경제성(Cost Effectiveness)• 통합의 용이성• 비즈니스와 IT의 연계(Alignment)• 신뢰성(Reliability)• 전사적인 IT와 통제(Governance)• 자산의 재사용

27 IBM Systems

c




접속 서비스

솔루션자산의디자인과개발을

위한 통합환경









ESB서비스 사이의 커뮤니케이션 조정

IT 서비스관리

인프라스트럭쳐 서비스 (비기능적 요건)단위시간당 작업량, 가용성 및 성능 최적화

c




접속 서비스

솔루션자산의디자인과개발을

위한 통합환경









ESB서비스 사이의 커뮤니케이션 조정ESB서비스 사이의 커뮤니케이션 조정

IT 서비스관리

인프라스트럭쳐 서비스 (비기능적 요건)단위시간당 작업량, 가용성 및 성능 최적화

SOA 및 SOA 운영환경의 기능적, 비기능적 요건SOA를 구현을 고려할 때, SOA 참조 아키텍처는 SOA 구현에 투입될 서비스의 집합, 다시 말해 SOA의 구성요소들에 대한 정의와기능적, 비기능적 요건을 제공합니다. SOA 참조 아키텍처에 정의된 구성요소들의 기술적인 컴포넌트나 실제 하드웨어, 소프트웨어로의 변환에는 이러한 기능적, 비기능적 요건이 지표가 됩니다. 아키텍처 상에 다소 불명확하게 표현되어 있는 일부 비기능적 요건들은 아키텍처의 기반이 되는 Infrastructure에 의해 충족되어 져야 합니다.

IBM SOA Reference Architecture

SOA와 SOA 운영환경의 요건(비기능적 요건)•경제성, 효율적인 비용의 플랫폼•Accounting, 로깅(Logging), 감사(Auditing) 기능•일관적이고 예측 가능한 성능•온디멘드 용량•표준기반의 통합•관리의 중앙집중•IT 자산의 재사용•신뢰성과 보안성을 제공하는 운영환경

기능적 구성요소

28 IBM Systems

IT 자산의 재활용에 대한 고려2004년 기준, 전 세계 자본 투자의 약 25%가 IT에 투자 되었습니다㈜. 비용 효율적인 방법으로 IT 및 비즈니스를 혁신하기 위해서는이와 같이 IT에 기 투자된 자본을 최대한 활용하는 것입니다.

“Many of the I/T assets required to enable an on-demand business already exist and have been supporting the business for years or even decades. Enabling these I/T assets to participate in integrated business processes is key to improving responsiveness”.DH Brown Associates, Inc.Application Transformation: Leveraging Existing I/T Assets to Build Competitive Advantage (September 2004)

CICSCICS

IMSIMS

ERP / CRMERP / CRM

DistributedPlatform

DistributedPlatformDistributed

Platform


Platform

DistributedPlatform

현재 메인프레임 대부분의 프로그램은CICS 또는 IMS 기반에서 플랫폼

종속적인 방법으로 사용자 및 타 시스템과연계되어 있습니다.

CICSCICS

IMSIMS

ERP / CRMERP / CRM

DistributedPlatform


Platform


Platform

DistributedPlatform

내부사용자

외부사용자

대외 기관기존 자산 (Application) 재 활용다양한 사용자 및 채널 지원시스템간 연계의 효율화

SOA를 통한 기존 자산의 재활용

29 IBM Systems

자산의 서비스화 및 재활용의 확대: 기존자산의 용이한 서비스화System z에서는 CICS 또는 IMS 프로그램의 변경 없이, WDz를 이용하여 이들 어플리케이션을 표준화된 Web Services로 구현하여SOA의 중요한 구성요소인 비즈니스 어플리케이션 서비스를 제공합니다. 이를 통해 SOA의 중요한 과제 중의 하나인 기존의 자산에 대한 재활용의 최대화를 이룰 수 있습니다.

WebSphere Developerfor System z (WDz)

HFS CSDURIMAP

PIPELINE

WEBSERVICE

WSDL

WSBIND

COBOLCopybook

(CICS/IMS)

CICS V3.1

WSDL

XML Adapter

ServiceProvider

CICS SOAPPIPELINE

SOAP Message

SOAP Message

30 IBM Systems

서비스와 데이터에 대한 근접성(Proximity)

WPS 및 WESB를 이들이 이용하고자 하는 서비스 및 데이터에 가장 근접하게 위치시킴으로써, 보다 나은 성능과 Throughput을 제공할 수있습니다.

미국의 대형 운송 업체의 Benchmark 결과에 따르면, Business Logic을 z/OS data와 동일한 LPAR에서 구현했을 시,

EJB Transaction당평균 CPU 사용량이 77% 감소하고이동되는 데이터의 bytes가 99% 감소합니다.

31 IBM Systems

기존 플랫폼 기술의 활용SOA는 기존의 z/OS 기술을 사용할 수 있는 새로운 기회를 제시합니다. SOA 모델에서는 더 이상 서비스가 어떤 언어로 작성되느냐는 그다지 중요하지 않고, 서비스를 얼마나 쉽게 통합할 수 있느냐가 훨씬 더 중요합니다.

기존의 프로그래밍 기술의 활용

CICS, DB2 등의 웹서비스 지원

4GL인 EGL의 활용 – 기존 COBOL 개발자가 Java를 배우거나, 그 반대의 경우가 필요하지 않음

SOA 프로그래밍 모델은 다양한 개발 언어를 지원하며, 개발자에게 익숙한 개발언어를 사용할 수 있음

시스템 관리자는 기존 메인프레임 기반의 정책과 절차를 유지할 수 있음

WebSphere Developerfor System z

WebSphere Developerfor System z

Inbound XML converter

Inbound XML converter

CICS MetadataCICS Metadata

Outbound XML converter

Outbound XML converterWeb Services

Tools

Web Services Tools

COBOL Data Declaration or

Complete program

COBOL Data Declaration or

Complete program

XMLSchema(XSD)

XMLSchema(XSD)Web Services

Client

Web ServicesClient

External XSD or WSDL

External XSD or WSDL

XML Services for the Enterprise

XML Services for the Enterprise

WSDLWSDL엔터프라이즈 자산

서비스로의 손쉬운 통합

32 IBM Systems

SOA의 중추로서 ESB: 가장 높은 수준의 가용성, 확장성, 보안 및 성능 요구

ESB는 SOA 아키텍처의 핵심적인 인프라 구성요소이며, 모든 서비스 통신이 실행되는 매개체입니다. 따라서 가장 높은 수준의 가용성, 확장성, 보안 및 성능이 요구되며, System z기반의 ESB는 서비스 사이의 커뮤니케이션 조정이라는 SOA의 기능 요건을 제공함과 동시에 이 기능요소에 요구되는 비기능적 요소를 만족 시킬 수 있습니다.

ESB는 SOA 아키텍처에서 가장 중요한 인프라스트럭처컴포넌트

모든 서비스 커뮤니케이션 플로우가 ESB에서 운용

최대한 가용성, 확장성, 보안성, 성능을 요구함

z/OS 운영 시스템과 연계한 핵심 ESB 컴포넌트를z/OS가 제공하는 서비스 품질(Quality of Service)를승계함

서비스와 데이터에 대한 접근성도 중요한 요소

ESB의 Java 워크로드는 zAAP(System z Application Assist Processor)에 의해 처리될 수 있음

HiperSockets Technology: System z 내부 LPAR 간에 Memory to Memory communication 방식의TCP/IP Network을 구성하여 Services 간에 이루어지는 Network Overhead를 최소화

z/OS

z/OS 기반의 ESB• 가용성, 확장성, 보안성• z/OS가 제공하는 QoS• HiperSocket에 의한 성능의 향상• 서비스와 데이터에 대한 근접성

33 IBM Systems

핵심 비즈니스 프로세스를 위한 프로세스 엔진의 위치

핵심적인 비즈니스 응용프로그램이 z/OS 플랫폼에서 수행되고, 서비스화 되어 제공되고 있다면, SOA의 ESB와 비즈니스 프로세스 엔진 구성요소를 그것이 의존하는 서비스가 배치되어 있는 것과 동일한 플랫폼에서 실행하는 것이 효율적입니다.

상당수의 핵심 비즈니스 어플리케이션이 이미 z/OS기반에서운용

비즈니스 프로세스 엔진이 기존의 데이터와 트랜잭션과동일하게 위치하는 것이 유리

WebSphere Application Server와 ESB기반의 Process Server를 z/OS에 위치하게 하여 z/OS가 제공하는 서비스품질(Quality of Service)를 승계할 수 있음

AccessServices

PartnerServices

Business AppServices

InformationServices

ProcessServices

InteractionServices

ProcessServices

AccessServices


PartnerServices

AccessServices

PartnerServices


zSeries Infrastructure ServiceszSeries Infrastructure ServicespSeries Infrastructure ServicespSeries Infrastructure Services

xSeries Infrastructure ServicesxSeries Infrastructure Services

InformationServices

ProcessServices

DB DB

DB

Business Innovation & Optimization Services Business Innovation & Optimization Services

Business Innovation & Optimization Services

IMSAdapter

CICSAdapter

SAPAdapter

SiebelAdapter

InteractionServices

InformationServices

InteractionServices

Portal

WebServices

WebServices

WebServices

FederatedQueries

CommunityManager

AccessServices

PartnerServices


InformationServices

ProcessServices

InteractionServices

ProcessServices

AccessServices


PartnerServices

AccessServices

PartnerServices


zSeries Infrastructure ServiceszSeries Infrastructure ServicespSeries Infrastructure ServicespSeries Infrastructure Services

xSeries Infrastructure ServicesxSeries Infrastructure Services

InformationServices

ProcessServices

DB DB

DB

Business Innovation & Optimization ServicesBusiness Innovation & Optimization Services Business Innovation & Optimization ServicesBusiness Innovation & Optimization Services

Business Innovation & Optimization ServicesBusiness Innovation & Optimization Services

IMSAdapter

CICSAdapter

SAPAdapter

SiebelAdapter

InteractionServices

InformationServices

InteractionServices

Portal

WebServices

WebServices

WebServices

FederatedQueries

CommunityManager

34 IBM Systems

핵심 어플리케이션 서비스를 위한 플랫폼System z는 핵심 응용프로그램 서비스를 위한 플랫폼의 역할을 수행합니다. 전통적인 트랜잭션 관리자인 IMS와 CICS도 그 기능을웹 서비스로서 공개함으로써 SOA에 완전히 참여할 수 있으며, CICS는 웹 서비스의 소비자 역할도 할 수 있습니다. 이는 메인프레임응용프로그램에 많은 투자를 하였고, 일괄 처리와 같은 메인프레임의 특징과 기능을 필요로 하고, 이러한 자산을 재사용하기를 원하는다수의 고객에게 매우 효율적인 선택이 될 수 있습니다.

메인프레임의 서비스 품질을 요구하는 자바어플리케이션은 별다른 수정없이 WebSphereApplication Server for z/OS에서 운영될 수 있음

자바 워크로드의 대부분이 z/OS에서 zAAP에의해 처리될 수 있음

COBOL, PL/1, ASM등의 전통적인 메인프레임개발

기존의 CICS, IMS와 같은 트랜잭션 매니저와DB2 Stored Procedure의 활용

CICS, IMS, DB2의 SOA 트랜잭션과웹서비스 지원

Eclipse 기반의 WebSphere Developer for System z와 같은 메인프레임 개발 툴의 활용

WAS z/OS

Partners (Java/.NET)

ESB

Web Services Clients

Front office(Java/.NET) Browser

Web services Servlets

EJB ServicesCICSApplications

ServicesRepository

Web services

35 IBM Systems

WPS와 Webservice provider 간의 보안z/OS의 경우 local connection에 의하여 외부에 공개되지 않아 보안 필요 없음.UNIX에 WPS를 위치할 경우 SOAP message가 그대로 plain text로 내부 N/W을

흐르게 되며 이에 대한 암호화를 하지 않을 경우 내부 사용자에 의한 security hole이 발생합니다.

방화벽을 포함한 Network과의 보안 구성 차이

Network 및 SOAP (XML) message에 대한 보안에 대하여, a. 방화벽에 의한 N/W traffic filtering을 포함한 모든 사항은 Process Server의 플랫폼과 관계 없이 동일합니다.b. 플랫폼에 의한 차이는 내부 방화벽 안쪽에서 WPS와 CICS간의 SOAP (XML) message에 대한 content security 입니다.

DMZInternet

Intranet

Internal Firewall

HTTPServer

Plug-in

HTTPServer

Plug-in

Network Dispatcher(Load Balancer)

Router

SSL SSLSSL

DB2

CICS

ProcessEngine/ESB

TCPIP

z/OS

UNIXProcess

Engine/ESB

External Firewall

LANSegment

방화벽 외부의 보안모든 SOAP message는 SSL 또는 IPsec에 의하여 플랫폼에 관계없이 모두 암호화

되어야 합니다.외부/내부 방화벽을 거치면서 필요한 N/W filtering은 모두 이루어 지며, http

server를 DMZ 구간에 위치 시키는 것 역시 Process Server와는 무관합니다.내부 사용자

WebService

pipeline

프로세스 엔진과 ESB를 메인프레임에 두었을 경우 SSL과 같은 내부 트래픽에 대한 암호화가 필요 없게 되어 성능면에서 암복호화에 대한부담이 줄어들게 됩니다.

36 IBM Systems

SOA 운영 플랫폼으로서의 System z

장기적인 SOA전략을 고려할 때, 플랫폼이 제공하는 Quality of Service (QoS) 및 TCO는 SOA를 위한 기능적인 요인 만큼이나 중요한요소이기 때문에 메인프레임은 UNIX 및 기타 분산 환경보다 향상된 SOA/BPM 운영 환경과 저비용 고효율 인프라를 제공합니다.

Workload Managementz/OS의 WLM에 의하여 다양한

워크로드를 단일 시스템에서 운영

Proximity to Service코어 비즈니스 자산 (Assets)과 Process Server가 동일 시스템에 존재

Special Engine (zAAP 및 zIIP)XML 처리 및 Java 워크로드의 상당

부분을 Special Engine에서 처리 가능

TCO 절감zAAP 및 zIIP은 H/W 측면에서 저렴할 뿐 아리라, S/W의

과금 대상이 아님

플랫폼의 고 가용성과 확장성은 장애 비용을 최소화 함

다양한 워크로드를 한 시스템에서 운영하므로 독립된 기능서버로 분리할 필요가 없음 센터 비용 절감

플랫폼 QualityParallel Sysplex 클러스터링

기법의 검증된 가용성 (99.999%) 및 확장성

Local ConnectionService간의 인터페이스가 z/OS내에서 Local Connection이 가능하므로

N/W의 연동 없이 Memory 통신 가능 확장성 및 성능

메인프레임 기반의 SOA가용성 : 메인프레임의 가용성(시스템 무 중단 서비스) 지표인 99.999%의 운영환경

확장성 : Local Connection에 의하여 물리적 서버간의 통신이 제거됨으로써 확장성이 보장됨

보안성 : 서비스 요청/제공이 시스템 내에서 구현됨으로써 XML 암호화 필요 없음 (단 Front-end는 암호화가 필요함)성능 : Local Connection에 의하여 Memory speed 수준의 메시지 처리가 가능

비용 : SOA/BPM의 워크로드의 상당 부분 (XML Overhead)을 Special Engine에서 수용함으로써 TCO의 절감

zAAP : System z Application Assist ProcessorzIIP : System z Integrated Information ProcessorBPM : Business Process Management

37 IBM Systems

IBM System z는 SOA 구현을 위한 기능적, 비기능적 필수 요건을 충실하게 지원하며 Open Server로서의 특징과 System z고유의Enterprise computing, Virtualization, Mixed workload, Quality of Service 등의 가용 특성을 SOA의 실제적인 구현을 위해 제공할 수 있는 최적의 플랫폼입니다.

비즈니스 유연성

집중과 선택

저비용 고효율

변화에 신속한 대응기업 경쟁력 강화

경제성

연계성

신뢰성

통합의 용이성

전사적인 IT 통제

재사용성

로깅/감사 보안저비용플랫폼

정합성성능및

가용성

유틸리티컴퓨팅

표준기반통합

중앙집중형관리

IT자산의재사용

신뢰성

비즈니스 IT

필수요건

Enterprise Computing Mixed Workload Quality of ServiceVirtualization

메인프레임 고유의 가치


system z soa와esb참고. eai vs. esb? eai란(광의의eai)? "eai encompasses approaches,...

Documents