Copyright © 2004 Samsung SDS Co.,Ltd. All rights reserved

SOA( 서비스 지향 아키텍처 )

이현우hyun1822@paran.com

Servic

e Broker

Service

Consum

er

Servic

e

Provid

er

Bind

RegisterFind

Service Contract

Client Service

2

SOA 필요성SOA 동인SOA 개념 SOA 목적 Service 정의SOA 정의서비스 지향과 아키텍처기본요건 및 특징 Service Principles

Service 입자성 및 추상성Service Agility

Service Adaptability

Service Legacy 연계SOA Constitute

< 目 次 >< 目 次 >

3

SOA 필요성

■ SOA 필요성 증대 – 통신 회사 (KT,SKT 등 ) 및 금융권 ( 하나은행 등 ) 의 차세대 시스템의 SOA 아키텍처 도입 증대

– SOA 투자로 인한 직간접적인 프로젝트 증대로 매출 순위의 뒤바뀜 ( 세계 SI 시장 1 위 탈환 )

■ 차세대 시스템의 아키텍처의 요구사항– IT 시스템의 유연성 및 신속한 비즈니스 대응력이 비즈니스 경쟁력이 되고 있음

SOA 동인

• 변화하는 비즈니스 환경에 신속하게 대응

• 비즈니스 효율성과 성능을

향상

• 기업 내 각 부서 , 비즈니스 단위 ,

비즈니스 파트너와의 통합운영

• 변화하는 비즈니스의 우선 순위를 신속히

적용할 수 있는 정보기술 체계 필요

• IT 를 비즈니스 전략에 보다 밀접하게 연관시킴

• 비용 효율적 구조

• 안전하고 관리 가능한 환경을 제공

비즈니스 요구사항 아키텍처 요구사항

비즈니스 서비스

비즈니스 전략

(PI, BPR)

Business

목표IT 아키텍처

서비스 지향 IT 아키텍처 비즈니스 변화에

대응하는 서비스 중심으로 IT 응답성

제고

SOA

경영 환경 변화 요인 ( 동인 )

4

5

SOA 동인 (Gartner Hype Cycle)

■ SOA Position

– Gartner 곡선에 의하면 SOA 는 안정화 단계 및 실현 단계로 5-10 년 사이 main stream 이 될 것으로 , SOA 는 피할 수 없는 현실이며 , 기업의 SOA Transformation 이 중요해질 것으로 예상하고 있음 .

6

SOA 개념

■ SOA(Service Oriented Architecture) 개념– IT 시스템의 유연한 아키텍처를 서비스로 재구성함

– Service 는 비즈니스 서비스와 함께 IT 서비스로 분리 가능하며

– 이를 총괄적으로 구성 Enterprise Service 관리 방안이 있어야 함

Service 정의

Service Oriented

Architecture

비즈니스 관점

IT 관점

Alignment

7

SOA 목적

■ SOA 목적– 기업의 비즈니스 변화에 IT 가 빠르게 대응할 수 있도록 고객의 비즈니스와 이를 뒷받침하는

Enterprise IT 아키텍처를 밀접하게 Align 시키도록 Principle, Framework, Methodology

를 제공함

SOA Goal

비즈니스 IT

Business And IT

Framework Methodolog

y

Concept

and

Principle

8

Service 정의

– 비즈니스 수행 단위 (Task) 를 표현하는 재사용 가능한 컴포넌트

고객 찾기

계좌 찾기

신용 카드 유효 가능 검사

신용 조사

호텔 예약

이자율 계산

– 서비스는 조직 단위를 넘어 Global 하게 배포 가능함

– 새로운 비즈니스 프로세스 단위로 재구성이 가능함

■ Service 란 ?- 논리적으로 하나의 단위를 이루는 업무를 자체적으로 처리할 수 있는 소프트웨어 구성요소 - 비즈니스 업무의 논리 단위를 구현한 것으로서 , 개방형 인터페이스로 설계되어 다른 프로그램에서 접근이 가능한 소프트웨어 컴포넌트를 「서비스」라고 지칭함- 다른 어플리케이션의 요청 (Request) 을 받아들이고 결과를 전달하는 인터페이스 부분과 요청된 서비스를 실제로 처리하는 구현 (Implementation) 부분으로 이루어짐

9

SOA 정의

☞ 웹서비스 : 표준화된 XML 기반의 인터페이스를 통하여 플랫폼과 독립적이고 프로그램 언어에 중립적인 방법으로 네트워크 상에서 응용프로그램들을 접속하는 활동

☞ 웹서비스 : 표준화된 XML 기반의 인터페이스를 통하여 플랫폼과 독립적이고 프로그램 언어에 중립적인 방법으로 네트워크 상에서 응용프로그램들을 접속하는 활동

■ Service Oriented Architecture( 서비스 지향 아키텍처 ) 란 ? - 서비스 요청자 (Client) 와 제공자 (Server) 로 이루어진 어플리케이션 소프트웨어 설계방식 - 표준기반의 공통사용 ( 재사용 ) 이 가능한 서비스들의 관계를 느슨한 관계로 모델링하여 소프트웨어의 서비스화를 지향하는 아키텍처

☞ 웹 서비스 (Web Service) 는 SOA 의 구현을 위한 현존하는 최적의 기술 대안

+Business Focus (Service Oriented)

…whereby business activity components are packaged as well-

defined services, accessible electronically by partners, suppliers

and others

…whereby business activity components are packaged as well-

defined services, accessible electronically by partners, suppliers

and others

Technology Focus (Architecture)

…which is implemented within an architectural technology

framework optimized for this purpose

…which is implemented within an architectural technology

framework optimized for this purpose

SOA 의 비즈니스 관점 및 서비스 관점

서비스 지향과 아키텍처

■ Service Orientation

– “open” 된 상호 호환성 있는 프로토콜을 사용하여 어플리케이션간 서비스 description 과 이를 지원하는 dynamic discovery 시스템을 통해 조합되는 것을 지원하는 환경

■ Architecture

– 일정한 총체적인 목표를 달성하기 위해 컴포넌트를 서로 조합하는 프로세스

– Layer 에 의해 구성되는 컴포넌트들을 통해 이루어지는 blueprint 로 , 컴포넌트간의 특성 및 관계 및 상호 작용 , 제약사항들을 포함

10

기본요건 및 특징

■ 기본요건– SOA 는 표준화에 따른 서비스 구성을 통해 Layered 구조를 이루게 하며 , 재사용 가능한

서비스 모듈의 사용 방안을 제공하여 서비스간 Loosely-coupled 되어 통신하도록 하여 유연한 비즈니스 대응을 가능하게 함

11

기본요건 및 특징

■서비스 지향 아키텍처의 특징

– 느슨한 연결 (Loosely Coupling) : 기민하게 각 서비스의 내부 구조 및 구현의 변화에 대응

– 굵은 입도 (Coarse Granularity) : IT 환경의 기술적인 복잡성을 덮어줌

– 재사용 (Reuse) : 개발기간 단축 , 비용 절감

– 민첩성 (Agility) 향상 : 서로 다른 환경에서 개발된 시스템의 통합이 쉬우며 , 변경 요청 발생時

신속 대응이 가능해짐

– 개발 생산성 행상 : 개발자는 자신이 개발하는 시스템에서 어떤 서비스를 요청할 것인가만

신경을 쓰면 되고 , 요청한 서비스가 어떻게 처리되는지는 몰라도 됨

주문 처리 업무 서비스

SOA

SOA 구축 이전 SOA 구축 이후

고객관리

재고관리

배송관리

송장관리

실적관리

사용자

고객모듈

재고모듈

배송모듈

송장모듈

실적모듈

주문 처리 업무

사용자

13

SOA Principles (1/4)

■ 1) 상호 운용성 (Interoperable)

– Universal Interface 인 Web Services 기술을 이용하여 ,

– 기존의 독점적인 “ Lock and Key” 디자인이 아니라 ,

– 어디에서든 통하는 전기 socket 과 같은 Interface 를 통해 다수의 응용 어플리케이션과 쉽게

결합할 수 있는 기반을 제공함

– 예 ) 전자 제품 과 Wall-Sockets / USB 와 USB Device

14

SOA Principles (2/4)

■ 2) 조합 가능성 (Composable)

– Web Services 기술은 WSDL 을 이용하여 자신의 묘사가 가능하며 이런 “ Self-Describing”

특성과 SOAP 을 통한 상호 운용성은 Software 솔루션을 서비스 조합으로 가능하게 함

– 서비스의 Building Block 화

ServicesServices

ApplicationsApplications

composed ofcomposed of

15

SOA Principles (3/4)

■ 3) 재사용성 (Reusable)

– 서비스는 자신을 설명하는 WSDL (Web Services Description Language) 를 갖고 있는 단위

소프트웨어로 SOAP 메시지 통신을 통해 언제 어디서든 호출 가능함

– 이런 특징을 갖는 서비스는 재사용이 가능하며 , 따라서 Repository 에서 관리되어 짐

<description><types>

</types>

</description>

<interface name = “..”>

</interface>

<binding name = “..”>

</binding>

<service name= “..” interface = “..”>

</service>

Service

Request

Response

WSDL is a Key

Repository

/ UDDI*) UDDI = Universal Description,

Discovery and Integration

16

SOA Principles (4/4)

■ 4) 느슨한 결합 (Loosely-coupled)

– 서비스 간 연동은 웹 서비스를 Wrapper 로 사용하여 Loosely 하게 연동하도록 함

– 중요 비즈니스 서비스의 인터페이스를 웹 서비스로 노출하고 , 호출 시 또한 웹 서비스를 활용 ,

플랫폼 및 기술에 독립적인 Coupling 을 이루게 함

I_SalesOrder_CreateOrder Web Service

Sales OrderApplication

Platform X

ProcurementApplication

Platform Z

InterfaceWeb Service

Order Service

X

17

Service 입자성 및 추상성

■ 서비스 Granularity( 입자성 ) 및 Abstraction( 추상성 )

– 입자가 굵은 (Coarse Grained) Business Service 와 입자가 작은 (Fine Grained) Impl. Service

의 적절한 조합 (Aggregation) 및 추상성을 통해 서비스 기반의 비즈니스 환경 구축 가능

고려 요소

• 굵은 입자성

• 외부에서 사용의 적절성 )

• 느슨한 연결 / 디자인

• Low level 서비스와 Business 서비스의 조합

Coarse Grained Business Services(Business Services Bus)

Fine Grained Implementation-Based Services

Aggregation

ExistingApplication

ExternalServices

ServiceWrapper

ExistingApplication

ServiceWrapper

InfrastructureServices

Abstraction

18

Service Agility

■ 서비스 통한 신속한 개발 가능– 새로운 비즈니스인 교육 사업을 위한 Course Management Application 프로그램 개발 시

이미 개발되어 사용되어지는 서비스를 호출하여 구성 가능하며 , 새롭게 개발되는 Room

Availability 서비스는 또 다른 비즈니스 or 어플리케이션에서 호출하여 사용 가능함

주문 처리 어플리케이션(Order Processing

Application)

고객 찾기 Service

신용 체크 Service

물품 처리 Service

재고 체크 Service

과정 관리 어플리케이션(Course Management

Application)

Room Availability

Service

새로운 어플리케이션은 쉽게 사용 가능한

서비스를 찾을 수 있음

새로운 서비스는 또한 다른 Application

에서 사용 가능함

19

Service Adaptability

■ 서비스 Communication

– SOA Infrastructure 에 의해 서비스의 프로토콜과 data 변환이 가능하여 확장성을 보장 가능

Order Processing Application

고객 찾기 Service

신용 체크 Service

물품 처리 Service

재고 체크 Service

SOA Infrastructure

SOA Infrastructure 는 어플리케이션과 서비스 사이의 통신 메커니즘을

제공함

서비스의 변경 사항은 기존 서비스를 사용하는 Application 에 영향을

미치지 않음

20

Service Legacy 연계

■ Service Legacy 연계– 서비스 기반의 infrastructure 를 통해 Legacy 시스템과의 연결을 표준화함 . 어플리케이션은

SOA Infrastructure 를 통해 Legacy 의 서비스를 연동함으로 , 신뢰성 있는 환경을 제공할 수 있음 Order

Processing Application

고객 찾기 Service

신용 체크 Service

물품 찾기 Service

재고 체크 Service

SOA Infrastructure

Customer Management

System

어플리케이션은 서비스를 표준화된

방식으로 access 함 .

레가시 시스템을 호출하는 것이

서비스의 역할임

레가시 시스템의 복잡함과 다양함을 단순하고 명쾌하게

함

Manufacturing System

21

SOA Constitute

■ SOA 구성– SOA 아키텍처는 기본적으로 Service Provider, Service Consumer, Service Broker 로

이루어진 구조

– 자기 설명적인 (Self describing) 인터페이스를 (WSDL) 를 가진 서비스는 플랫폼 독립적인 XML 형식으로 Formally 하게 정의되어 , Service Broker 를 통해 서비스로 등록하고 관리되어 애플리케이션 수가 증가해도 서비스를 찾을 수 있는 방안이 제공됨 (UDDI)

Service

Broker

Service

ConsumerService

ProviderBind

RegisterFind

Service Contract

Client Service

※ UDDI(Universal Description, Discovery, and Integration) - 인터넷에서 전 세계의 비즈니스 업체 목록에 자신의 목록을 등록하기 위한 , XML 기반의 규격

22

SOA 로의 변화 – IT 시스템SOA 로의 변화 – 개발 방식SOA Layer

SOA Case Study

1) 여행사 비즈니스 2) 의료 비즈니스SOA Benefits

Summary

< 目 次 >< 目 次 >

23

SOA 로의 변화 – IT 시스템

■ 기업의 IT 시스템의 SOA 로의 변화– 서비스 아키텍처 Layer 로 잘 정의된 구성을 갖고 보다 신속히 비즈니스 변경 사항에 대응 가능

데이터 중복

프로세스

어플리케이션 /

데이터

기술 요소

기능 중복단편화된 어플리케이션

기술의 정체

기술의 비효율성

비즈니스 프로세스와의 Gap 발생

부서 A부서 B

부서 C

각각의 부서 및 agency 에 따라 수직적인 방향으로 통합을 하는 Silo 형태를 가짐또한 서로 다른 기능의 Application 과 Database 가 cross 교차되어 사용되는 비효율성 발행

SOA 도입 이전의 기업 환경 SOA 도입 이후의 기업 환경

.NET

J2EE Unix

OS/390MQ

DB2

Finance

PeopleSoft

SAP

SeibelDir

Outlook

CustomerEmployee

ProductSales

SOA 는 Application Layer 뿐만 아니라 , 구조화된 Service Layer 와 Business Process Layer 등 체계화된 Layer 로 관리함으로 기업의 비즈니스 환경에 rapidly 하게 대응 가능함

24

SOA 로의 변화 – 개발 방식

■ 소프트웨어 개발 방식의 세련화– 각기 다른 시기의 프로그램 개발 및 DB 구축은 서로 다른 시스템의 영향에 민감하게 반응 할 수 밖에 없도록 구성되어 비효율성을 남발하였으나

– 계획성 및 표준화 방안을 갖은 개발 방식으로 인해 기업의 IT 시스템이 세련되어 짐

InventoryInventory

ApplicatioApplicatio

nn

InventoryInventory

DatabaseDatabase

Financial Application

Financial Database

Shipping Application

Shipping Database

운송 시스템은 재고 시스템 DB의 재고량을 삭제 (via SQL call)

회계 시스템은 재고 시스템의 database 를 직접 access 함

회계 시스템은 주문 취소 건에 대해 운송 시스템의 DB 로 직접 삭제

Financial Financial

ApplicationApplicationFinancial Financial

DatabaseDatabase

Finance Web Service

InventoryInventory

ApplicationApplicationInventoryInventory

DatabaseDatabase

Inventory Web Service

Shipping Shipping

ApplicationApplicationShipping Shipping

DatabaseDatabase

Shipping Web Service

WSDL 통해서 서비스 연동 Application 에서 DB 직접 Access 금지

25

SOA Layer

Existing Systems

Service Enablement

Implementation-Based Services

Business Service Bus

Business Services

Composite Application UI

Composite Application Process

Other Services

Composite Application Portal Configuration

Composite Business Services

Composite Application

En

terprise S

ervice Bu

s

Po

licies and

Meta D

ata

Internal and External Resources

■ SOA 구성 : Layered Architecture

– SOA 는 계층화된 Layer 를 구분하여 관리함으로써 향후 확장 및 유지 보수에 이점 제공

– 각 계층 역할과 책임의 체계화에 따라 중복 개발 방지 및 아키텍처 일관성 유지

– SOA 로 구성된 시스템 간의 연계 통합의 편의성 확보 통한 Enterprise Architecture 완성 도모

26

SOA Case Study (1)

■ LibGo Travel 사의 SOA 도입 사례 ( 여행 비즈니스 )

– Next-Generation Travel System (NGTS) 구축에 있어 SOA 를 도입하고 비즈니스 서비스를 공유할 수 있는 기반을 마련한 사례임

– 대규모의 복합 어플리케이션으로 구성된 NGTS 는 하루 평균 100만 정도 Transaction 을 가짐

– 항공 및 숙박에 대한 가격 정보 및 이용 가능 정보는 다양한 Format 과 다양한 채널을 통해 들어오며 , 이를 위해 Service adapter layer 를 구성하여 파트너사의 시스템 간의 비즈니스 프로세스 구성을 XML 기반의 인터페이스로 정의되는 WSDL 을 사용 , ESB infrastructure 를 사용하여 구성하였음

27

SOA Case Study (2)

■ Health Institute’s CMS ( 의료 비즈니스 )

– 의료 서비스를 제공해야 하는 기관의 Care Management System 은 관리 대상의 개인 의료 정보를 입력 받아 관리하여야 함 . 이는 Individual Health Record 에서 입력 받는 체계를 따라 , System 간의 상호 호환 및 효율적인 일 처리가 필요함

Diabetes 40+ appsMaternityA&E

Referral PrescribingRequestingSchedulingDemographics

비 표준화 -> 복잡도 증가 -> 효율 감소

Events

Information

Care Management

Systems

Individual Health Record

Events

Information

Care Management

Systems

Individual Health Record

Diabetes 40+ appsMaternityA&E

Demographics

Messaging service

RequestingSchedulingReferral Prescribing

표준화 기반 -> Orchestration -> 효율성 증대

28

Standardized Service 예제

■ SOA Reference Model

– SOA 기반으로 Architecting 한 미 연방의 Health and Human Services System

End Users B

usin

ess T

ran

sform

atio

n T

oo

ls an

d M

eth

od

olo

gie

s

Pla

tform

, To

ols a

nd

Me

tho

do

lgo

ies

De

velo

pm

en

t Fra

me

wo

rkSe

rvic

e D

eliv

ery

Fra

me

wo

rk

Co

urt

s

Wo

rklo

ad

/Sta

ff

Ma

na

ge

me

nt

Scr

ee

nin

g a

nd

Inta

ke

Pa

rtic

ipa

nt

Ma

na

ge

me

nt

Pro

vid

er

Ma

na

ge

me

nt

Re

sou

rce

Ma

na

ge

me

nt

Fin

an

cia

l M

an

ag

em

en

t

Ass

et

Ma

na

ge

me

nt

Elig

ibili

ty

Evi

de

nce

M

an

ag

em

en

t

ServiceDirectory

Common HHS Services

Co

mp

osi

te S

tate

-Wid

e A

pp

lica

tion

s

TA

NF

Ch

ild

Su

pp

ort

He

alth

an

d

Nu

triti

on

Ch

ild C

are

Juve

nile

Ju

stic

eM

MIS

Po

rta

l

Enterprise Management

Hardware and Software Platform

Enterprise Security

IVR

/PB

X/A

CD

/CT

I M

idd

lew

areGovernment

Users

Providers

Citizens

Ca

se

Ma

na

ge

me

nt

Re

v M

ax

Enterprise Service Integration (ESB)

Co

nte

nt

Ma

na

ge

me

nt

Ou

tput

Man

age

ment

Wo

rkflo

w

Bu

sin

ess

In

telli

ge

nce

Se

arc

h

Ru

les

En

gin

e

Au

dit

Ale

rts

ET

L

Le

ga

cy

Inte

gra

tion

CR

M

Ele

ctro

nic

P

aym

en

t

SA

CW

IS

Ch

ild

Su

pp

ort

Infrastructure Services

Create value-add composite services and/

or applications using common HHS services

Expose application business components as services

Leverage shared enterprise services

Externalize HHS business rules into a rules engine

Leverage common HHS services for developing

business processes using service orchestration

29

SOA Benefits (1/2)

플랫폼 및 기술 독립성 보장

실시간 비즈니스 가능

통합의 복잡도감소

현 프로세스에서 접근할 수 있는 정보 원천접근성 증대 통한 실시간 시행 가능성 증대

연결 비용감소

연결 비용감소로 인한 비즈니스 프로세스 효율 증대

비용절감

프로세스 효율 증대

■ 기술과 단말에 구속 없이 연결할 수 있는 메커니즘 통해 프로세스 효율 증대 및 비용 절감

① Ubiquitous Web Services 연결 메커니즘

표준화 통한 기술 비용감소

비즈니스 공급망의확대

독점적 기술에종속되지않는다는 이점

공개 표준은 IT 와 비즈니스 모두에게 이점 제공

② 국제 산업 표준 기반

③ 적은 Communication 비용

진입 장벽의

축소 글로벌화를 지향하며 , 지리적으로떨어진 조직체에 통합화 이점

소규모 파트너또는 공급사와낮은 비용으로 통합 가능함

다양한규모의 사업체와 조직에서 사용 가능함

30

SOA Benefits (2/2)

Facilitates reuse of existing assets

System change is not a constraint on business

change

Reduced impact of change

Facilitates M&A activity

Lower cost of maintenance

Makes it easier to change or add partners.

유지 보수 비용절감

민첩한 비즈니스

형성

■ 독립적으로 서비스하는 모듈을 구성 , 활용 방안 제공 통한 비즈니스 & IT 민첩성 제공

④ Loosely Coupled

⑤ Self Describing

Time To Market

Cost Savings Through Consolidation

Shortened Development Cycles

31

■ 서비스란 하나의 반복될 수 있는 비즈니스 단위– 고객 신용 정보 조회 , 계좌 개설 등

■ 서비스 지향이란 비즈니스를 서비스로 연결하여 통합하는 방안– SOA 를 위한 가이드 (Framework & Methodology) 와 뚜렷한 목표 (Goal) 가 필요

■ SOA 란 IT architectural style 로 다양한 시나리오에 적용 가능함 – 서비스는 프로세스 기반으로 디자인되어야 함

■ 일련의 연결성과 통합성을 가진 SOA Infrastructure 를 통해 신뢰성 있는 비즈니스 프로세스 환경 구성 가능

– 실 세계의 프로세스 패턴으로부터 배워야 함

Summary