1장 서비스 지향 개념의 이해 - contents.kocw.netcontents.kocw.net/KOCW/document/2015/chungnam/leekyuchul1/13.pdf · 기존의통합논의가주로it 리소스를통합하는it

Chungnam National University

Computer Science and Engineering

Database System Laboratory

SOA 아키텍처




SOA 아키텍처의 필요성

사일로 (Silo)

■ 기업 내의 각 부서들이 서로 단절된 상태로 자신의 부서에 필요한 독자적인

애플리케이션을 개발한 것

■ 다른 부서의 애플리케이션에서도 유사한 데이터 구조와 기능이 있음에도 불

구하고 정보 관리의 유사성은 배제된 채로 각 부서는 서로 다른 독자적인

애플리케이션을 개발

2

생명보험사의 영업채널시스템의 아키텍처




영업채널시스템의 장단점

장점

■ 각 채널 시스템마다 특화되고 최적화된 기능을 제공

단점

■ 정책 변경에 대한 민첩한 대응을 하지 못함

– 생명보험사 전체에 걸쳐 정책이 변경된다면 각 채널 시스템을 모두 변경해야 함

■ 하나의 채널 시스템에 구현된 기능을 다른 채널 시스템에서 재사용하지 못

함으로써 중복하여 투자를 하게 되는 셈

■ 영업 정책의 변화로 인한 또 다른 영업 채널의 추가

– 하나의 영업 채널 시스템을 구축하는데 다시 많은 시간과 돈이 투자

3




SOA의 적용

SOA의 목표는 기업 내 여러 시스템에 분산되어 있는 비즈니스 서비스

를 해체하여, 여러 시스템에서 공유할 수 있는 공유 비즈니스 서비스

(shared business service)로 통합하는 것

4

SOA를 적용한 영업채널시스템의 아키텍처




SOA 적용의 효과

각 채널 시스템에 분산되어 있는 고객관리, 상품관리, 청약관리, 언더라

이팅 등의 비즈니스 서비스를 해체

모든 채널 시스템에서 공유할 수 있는 고객서비스, 상품서비스, 청약서비

스, 언더라이팅서비스 등의 공유 비즈니스 서비스로 통합

생명보험사 전체에 걸쳐 정책이 변경될 때 통합된 공유 비즈니스 서비스

를 변경

■ 모든 영업 채널 시스템에 신속하여 변경된 정책을 반영

■ 또한 새로운 영업 채널이 추가되는 경우에도 이미 구현되어 있는 공유 비즈

니스 서비스를 재사용함으로써 중복된 투자 없이 신속하게 새로운 영업 채

널 시스템을 구축

5




SOA 레퍼런스 아키텍처

6




SOA 레퍼런스 아키텍처의 레이어

서비스 소비자 레이어(service consumer layer)

■ 하나 이상의 여러 서비스 공급자(service provider)가 제공하는 서비스를

사용하여 비즈니스가 직면해 있는 문제에 대하여 솔루션을 구성

서비스 공급자 레이어(service provider layer)

■ 비즈니스의 핵심 기능을 표현하는 비즈니스 서비스 집합의 논리적인 관점을

제공하며, 서비스 구현과 소비자 애플리케이션 사이를 연결하는 역할

컴포넌트 레이어(component layer)

■ 구현된 애플리케이션, 비즈니스 객체 및 구현 등을 지원하는 다양한 환경을

표현

7




레이어 아키텍처 스타일

SOA 기반의 레퍼런스 아키텍처

■ 기본적으로 레이어 아키텍처 스타일(layered architectural style)을 사용


■ 소프트웨어를 레이어(layer)라고 하는 단위로 분할

레이어

■ 응집력이 강한 서비스의 집합을 제공하는 모듈의 컬렉션

■ 인터페이스를 통해 다른 모듈에 서비스를 제공

■ 다른 레이어에서는 해당 레이어가 제공하는 서비스가 어떻게 구현되었는지

알지 못하고도 제공되는 인터페이스를 통해 서비스를 사용

8




레이어의 상호작용

각 레이어는 엄격한 순서(ordering) 관계에 따라 상호작용을 함

■ 가령 레이어 B 는 레이어 A 아래에 놓이게 되며, 이것은 레이어 A 는 레

이어 B 가 제공하는 인터페이스를 통해 기능을 사용할 수 있도록 허용된

(allowed to use) 상태라는 것을 의미

■ 따라서 레이어 스타일에서 레이어 사이에는 allowed to use 관계가 형성

9





레이어의 방식

엄격한 레이어 방식(strict layered)

■ 상위 레이어는 같은 레이어 또는 바로 하위의 레이어만 사용

유연한 레이어 방식(flexible layered)

■ 엄격한 레이어 방식에 유연성을 부여하여 어떤 하위 레이어라도 사용

주의해야 할 점

■ 두 방식 모두 상위 레이어로의 직접 접근은 허용되지 않는다는 것

■ 상위 레이어로의 접근은 엄격하게 제한되며, 다만 하위 레이어가 이벤트를

발생시켜 상위 레이어로 메시지를 전달하는 것은 부분적으로 허용

– 그러나 이러한 방법도 자주 사용되지는 않음

10




레이어 스타일의 이점

레이어는 시스템을 구축할 때 청사진 역할

■ 개발자들은 자신의 소프트웨어가 어느 레이어에 놓이게 되는가를 알면 코드 작

업 환경에서 어떤 서비스를 사용할 수 있는지를 알게 됨

■ 레이어는 개발 팀에게 작업을 할당하는 기준을 제공

대형 시스템에서는 서비스의 개수가 급격히 증가하고, 따라서 이들 사이의

종속성도 확장됨

■ 서비스를 인터페이스를 갖는 레이어로 구성할 때, 레이어는 이러한 복잡성을 관

리하는 중요한 도구가 됨

레이어는 분석 도구로도 활용

■ 시스템을 변경할 필요가 있을 때 변경할 영역을 결정하게 함으로써 변경 영향도

를 분석하여 설계에 넘겨줄 수 있음

11




레이어와 티어

레이어는 클라이언트/서버 아키텍처 등에서의 티어(tier)와 자주 혼동됨

■ 레이어와 마찬가지로 티어도 시스템을 분할하는 메커니즘이기 때문

■ 특히 각 레이어를 티어로 실현할 때 레이어 다이어그램은 티어 다이어그램

과 유사하게 되므로 혼동하기 쉬움

레이어

■ 논리적 시스템 분할

■ 레이어 사이의 관계는 allowed to use

■ 양방향 커뮤니케이션이 허용되지 않음

■ 모듈 분할 기준은 변경의 용이성

12

티어

■ 물리적 시스템 분할

■ 티어 사이의 관계는 요청-응답

(request-reply) 커넥터로 표현

■ 양방향 커뮤니케이션의 허용

■ 모듈 분할 기준은 런타임 효율성




IBM의 SOA 레퍼런스 아키텍처

13




Microsoft의 SOA 레퍼런스 아키텍처

14




오케스트레이션과 코리오그라피

15




오케스트레이션

기존의 비즈니스 서비스를 재사용하는 컴포지트 서비스(composite

service) 또는 프로세스 서비스(process service)를 정의하기 위해 사

용

비즈니스 프로세스를 주도하는 하나의 참여자 관점에서 여러 비즈니스

서비스를 통합하는 계층적인 요청자/공급자(hierarchical

requester/provider) 모델을 사용

16




코리오그라피

여러 참여자가 보다 큰 비즈니스 트랜잭션(business transaction)의 일

부로서 거래 파트너끼리 메시지를 교환함으로써 피어-투-피어(peer-to-

peer) 방식으로 협업하는 방식을 정의하기 위해 사용

비즈니스 프로세스 안에서 다수의 참여자가 피어-투-피어(peer-to-peer)

방식으로 협업하는 모델을 사용

17




Enterprise Service Bus

SOA의 궁극적인 목적도 ‘통합’

기존의 통합 논의가 주로 IT 리소스를 통합하는 IT 통합에 집중

반면에, SOA에 있어서 통합은 IT 통합 뿐만 아니라, 비즈니스와 비즈니

스의 통합, 더 나아가 비즈니스와 IT 사이의 통합을 강조

BPM이 비즈니스와 비즈니스 사이의 통합을 이야기한다면, IT 사이의 통

합을 이야기하는 것은 SOA 아키텍처

서비스 지향 개념은 이 둘을 포괄하는 비즈니스와 IT 사이의 통합

18




통합과 기존의 노력들

소프트웨어 버스의 전형적인 예로는 CORBA와 DCOM, Java RMI 등

의 분산 객체 기술

이들 분산 객체 기술은 버스 위에 있는 다른 객체의 위치를 찾아내고

해당 객체의 오퍼레이션을 호출

아주 성숙된 기술이지만 작은 입자성(fine-grained)을 갖는 커뮤니케이션

인프라이기 때문에 유지보수 및 성능 문제를 종종 야기

소프트웨어 버스 개념을 기반으로 하는 다양한 통합 접근 방법

■ EAI(enterprise application integration)

■ 애플리케이션 서버(application server)

■ MOM(message oriented middleware) 등

19




통합 접근 방법

20

전통적인EAI

ESB

커스텀 코드/MOM

애플리케이션서버

애플리케이션과통합 로직이 분리됨

애플리케이션과통합 로직이 혼합됨

Hub-and-Spoke 통합 분산 통합




ESB 통합

Enterprise Service Bus(ESB)의 개념은 hub-and-spoke EAI 브로커

의 한계를 넘어서 확장될 수 있는, 느슨한 결합도의 고도로 분산된 통합

네트워크를 위한 토대를 제공할 수 있는 새로운 통합 접근 방법

표준 기반의 통합 플랫폼으로서 메시징과 웹 서비스, 데이터 변형, 그리

고 인텔리전트 라우팅을 결합하여 확장 기업(extedned enterprise)에

전개되어 있는 수많은 다양한 애플리케이션 사이의 상호작용을 트랜잭션

무결성으로 연결하고 조절

21

Enterprise Service Bus




ESB = SOA의 백본

앞에서 살펴 본 SOA를 적용한 생명보험사의 아키텍처 예와 같이 ESB

가 없더라도 서비스 소비자와 공급자가 복잡한 연결 관계에 있는다는 것

을 의미

22

ESB 적용 이전 아키텍처




아키텍처 변경

각 채널 시스템이 청약 서비스를 사용하려면 관련된 모든 코드를 변경

채널 시스템에서 각 서비스의 정보를 정의한 구성(configuration) 정보

를 관리하고 있다가 이 구성 정보를 변경

가장 바람직한 해결 방법은 SOA 아키텍처의 하나의 구성요소인 서비스

레파지토리를 활용하는 것

23

아키텍처 변경




아키텍처 변경의 문제점

서비스를 QoS 관리 의무라는 제약 사항으로부터 자유롭게 해야 할 필요가

있으며, QoS 관리를 전담할 수 있는 별도의 메커니즘이 필요

■ 각 서비스가 채널 시스템들이 요구하는 보안, 신뢰성, 트랜잭션 등의

QoS(quality of service)를 구현해야 한다는 것

■ 각 서비스들이 QoS 관리를 위한 코드를 일일이 구현해야 한다는 부담을 안는

다는 것은 결국 서비스의 개발을 지연시키며 코드의 중복이라는 비효율성

■ QoS가 변경될 때 모든 서비스의 QoS 관리 코드를 변경시켜야 하므로 민첩하

게 대응할 수 없다는 문제점

서비스에게 데이터를 라우팅하고 변형시킬 수 있는 별도의 메커니즘이 필요

■ 각 채널 시스템이 유사하지만 서로 다른 형식의 데이터 구조를 사용하고 있을

때 서비스 인터페이스를 정의하기 어렵다는 문제점

■ 만약 새로운 채널 시스템이 또 다른 형식의 데이터 구조를 요구하거나, 기존 채

널 시스템이 데이터 구조를 변경하는 경우에 민첩하게 대응하기 어려움

24




ESB 적용 이후 아키텍처

만약 여러분이 아키텍트라면 façade 패턴을 머리 속에 떠올릴 것

ESB를 façade 패턴에 적용

채널 시스템과 서비스의 중간에서 위의 문제점들을 해결하는 소프트웨어

버스로서의 역할을 수행

25

ESB 적용 이후 아키텍처




ESB 아키텍처

ESB는 분산 통합 미들웨어 인프라스트럭처(distributed integration

middleware infrastructure)로서 XML과 웹 서비스 지원, 그리고 컨텐트

나 프로토콜의 변환, 인텔리전트 라우팅 기능을 제공

MOM(message-oriented middleware)를 포함하거나 다른 MOM 트랜스

포트 메커니즘을 지원

ESB는 SOA를 효과적으로 구현하는데 필요한 중요한 상위 레벨의 서비스를

제공

서비스 관리와 모니터링, 보안 등의 QoS 관리, 서비스 오케스트레이션, 비

동기 메시징과 요청-응답의 지원, 그리고 다양한 패키지 애플리케이션과 기

술 플랫폼을 연결해주는 어댑터 등이 포함

26




ESB 아키텍처

27




ESB의 기능

중재(mediation) 서비스

■ 라우팅(routing) 서비스

– 서비스는 ESB를 통해서 서로 연결되어 있어야 하며 서비스 사이에 ESB를 통해

서 컨텐트를 기반으로 메시지를 라우팅

– 컨텐트 기반 라우팅(CBR, content-based routing)은 메시지에 포함된 정보를

기초로 호출할 서비스를 선택하는 기능

– 라우팅 서비스를 트랜스포트(transport) 서비스라고도 함

■ 변환(transformation) 서비스

– 프로토콜 변환(protocol transformation): 소비자와 서비스 사이의 전송 프로

토콜을 변환

– 컨텐트 변환(content transformation): 소비자와 서비스 사이의 메시지 형식을

변형

28




프로토콜 변환

하나의 프로토콜을 다른 프로토콜로 변환하여 서비스 사이를 중재

29




컨텐트 변환

메시지 컨텐트의 형식을 변형하는 것

서비스의 핵심은 비즈니스 통합에 있으므로 ESB가 서비스 사이의 메시

지 형식을 중재할 필요

컨텐트 변환 중재를 통해서 메시지에 정보를 추가하는 것이 가능

30




서비스 오케스트레이션(service orchestration)

BPEL 표준을 지원하는 비즈니스 프로세스와 서비스 통합을 위한 엔진을 제공

ESB가 제공하는 이벤트 서비스를 통해 이벤트 기반 SOA(event-driven SOA)를 실

현

■ ESB 이벤트(event) 서비스는 이벤트를 탐지하고 발생시키며 배포하는 기능을 제공

■ 이벤트가 발생하면 ESB가 이벤트를 탐지하여 서비스를 호출

ESB의 기능

■ QoS(quality of service) 관리 기능을 제공

■ 보안, 신뢰성, 트랜잭션 등의 QoS를 정책(policy)으로 관리하며 서비스의 실행을 통제

■ 서비스 레지스트리(registry)와 레파지토리(repository)를 통해 서비스를 관리하며, 서비스

거버넌스를 통해서 서비스를 통제

31




BizTalk Server의 ESB 아키텍처

32

Microsoft ESB 아키텍처




Microsoft ESB 솔루션 세부 아키텍처

33




ESB 활용 패턴

기업이 SOA 기반의 시스템을 구축하고자 할 때 가장 먼저 기업 내 기

존 자산을 재사용하기를 원함

■ 즉, 기업 내 모든 가치있는 자산을 연결시킬 수 있어야 하며, 가능하다면

기존 자산을 변경시키지 않고 연결하기를 원함

34




기존 자산 통합

지역화된 통합 프로젝트에도 적당하며, 어떤 유형의 통합 환경이든 받아

들일 수 있는 유연한 토대를 제공

애플리케이션은 필요할 때 버스에 플러그인 되어 다른 애플리케이션이나

서비스와 데이터를 공유

35




표준 기반 통합

표준 기반 통합(standards-based integration)은 ESB의 기본 개념

표준 기반의 인터페이스와 컴포넌트는 개방형 플러그인 아키텍처를 구성하는

방식으로 통합되며, ESB는 산업 표준 통합 컴포넌트를 지원하는 인프라를

제공

ESB는 J2EE, .NET, COM, C/C++ 등의 다양한 기술을 사용하여 구현된

애플리케이션과도 통합되며, SOAP과 웹서비스 API를 지원하는 어느 것과도

쉽게 통합

ESB는 XML 표준을 사용하여 데이터 변형과 인텔리전트 라우팅 기능을 제

공하며, 버스 위에 흐르고 있는 데이터를 질의

SOA와 비즈니스 프로세스 라우팅을 처리하기 위해 ESB는 WSDL(web

services description language)를 사용하여 추상적인 서비스 인터페이스

를 기술하며, BPEL4WS(business process execution language for

web services), WS-Choreography 등을 사용하여 추상적인 비즈니스 프

로세스를 기술

36




표준 기반 통합

37




프로세스 흐름

간단한 작업 순서로부터 복잡한 비즈니스 프로세스 오케스트레이션에 이

르까지의 모든 범위에 적용

간단한 메시지 메타데이터로도 통제할 수 있고, BPEL4WS와 같은 오케

스트레이션 언어를 사용해서 통제

개별 부서나 비즈니스 단위에 국한된 비즈니스 프로세스를 정의하는 것

뿐만 아니라, 더 큰 규모의 통합 네트워크 안에서 공존할 수 있는 비즈

니스 프로세스를 정의

내용에 기초한 메시지의 인텔리전트 라우팅을 수행하는 특수한 통합 서

비스를 포함

분산 SOA 위에 구축되므로, 물리적인 네트워크 영역이나 다양한 프로토

콜을 고려하지 않고도 고도로 분산된 전개 토폴로지로 확장

38




프로세스 흐름

39




운영 인식(operational awareness)

비즈니스 분석가가 비즈니스 운영의 상태와 건강 상태에 대한 통찰력을

얻는 능력

비즈니스 프로세스 안에서 비즈니스 메시지의 형식으로 조직 사이를 이

동하는 데이터의 시기적절한 관리와 보고 기능을 제공하는 인프라는 운

영 인식을 얻는데 있어서 아주 귀중한 자료

운영 인식의 문제점을 해결하기 위해 BAM(business activity

monitoring)을 ESB에 통합

40




자치적인 연합 환경

지역적인 비즈니스 단위 또는 부서는 자신의 IT 리소스를 제어할 필요가

있으며, 동시에 지역적인 통합 도메인을 하나의 커다란 연합 통합 네트

워크 안에 끼워 넣을 수 있게 하는 것이 바람직함

ESB는 자치적이지만 연합할 수 있는 환경(autonomous but

federated environment)을 제공

41




점진적 채택

ESB의 구별되는 특징 중 하나는 점진적 채택을 허용한다는 것

42




QoS 관리

서비스들은 비즈니스 요구를 충족시킬 수 있는 서로 다른 QoS를 필요로

하며, 비즈니스 상황을 분석하여 동적으로 QoS를 변경시켜 적용할 수

있어야 함

ESB는 상황 분석에 따른 유연하고 즉각적인 QoS를 전달해주며, 각 서

비스가 QoS를 구현하지 않아도 되도록 통합 관리

43




서비스 관리

기업 내 서비스를 관리하고 질의할 수 있어야 함

ESB는 서비스의 헬스(health), 성능 모니터링 및 장애 관리 등의 서비

스 관리를 기능을 제공하며, 서비스 등록과 질의를 위한 UDDI를 지원하

며, 디자인 타임과 런 타임 시 서비스를 질의할 수 있는 기능을 제공

44




SOA 2.0 = SOA + EDA

이벤트 주도적 비즈니스 프로세스(event-driven business process)를

필요

전통적인 애플리케이션 아키텍처는 너무 정적이고 유연성이 부족하여 이

벤트 주도적 프로세스가 필요로 하는 감지-반응(sense-and-respond)

행위를 구현하기 어려움

애플리케이션을 이벤트 주도적(event-driven)으로 설계할 필요가 있으며,

이벤트 주도적 아키텍처(EDA, event-driven architecture)를 도입할 때

비즈니스 프로세스의 시간을 줄여주며, 비즈니스의 민첩성을 증가시킬 수

있음

45




비즈니스 이벤트

비즈니스에 영향을 미치는 주목할 만한 비즈니스 활동

비즈니스는 많은 시간을 이벤트 주도적 프로세스(event-driven process)

를 처리하는데 소비

비즈니스의 크기에 따라 수 백, 수 천, 수 만의 이벤트가 하루에 발생된

다. 고객이 주문을 하는 행위도 이벤트이고, 고객이 주문을 취소하는 행

위도 이벤트다. RFID 리더기를 상품이 통과하는 것도 이벤트

46

단순 이벤트 처리




Event-Driven Architecture

분리된(decoupled) 소프트웨어 컴포넌트와 서비스들 사이에 이벤트

(event)를 전송(transmit)하는 애플리케이션과 시스템을 설계하고 구현하

기 위한 방법론을 정의

47

EDA 아키텍처 개념도




EDA 아키텍처의 레이어

이벤트 발생기(event generator)

■ 이벤트가 발생하는 소스(source)

이벤트 채널(event channel)

■ 이벤트 처리 엔진에게 표준 형식으로 이벤트를 전송

이벤트 처리 엔진(event processing engine)

■ 전달된 이벤트를 이벤트 처리 규칙(event processing rule)에 따라 평가

한 후에 규칙에 따라 행위를 수행

이벤트 활동(event-driven activity)

■ 이들 행위에는 서비스를 호출한다든지, 비즈니스 프로세스를 시작하는 일,

이 이벤트에 관심있는 구독자(subscriber)에게 이벤트를 출판(publish)하는

것, 그리고 사람이나 시스템에게 직접 통보하는 일 등이 포함

48




이벤트 처리 유형

단순 이벤트 처리(simple event processing)

■ 발생한 이벤트들은 모두 의미 있는 이벤트로 간주하고 각각의 이벤트 내용에 따라 대응되는 활동을 수행

■ 출판/구독(publish/subscribe) 방식이나 중재(meditation) 방식에 의해 이벤트가 처리

스트림 이벤트 처리(stream event processing)

■ 의미 있는 이벤트와 무의미한 이벤트가 같이 발생하는 대량의 이벤트 스트림을대상

■ 이벤트가 발생하면 필터링 등을 수행하여 의미 있는 이벤트 정보만 뽑아서 애플리케이션에 전달하거나 서비스에 연동

■ 주로 기업 내 실시간 정보 흐름을 주도함으로써 실시간 의사 결정을 가능하게하는데 사용

복합 이벤트 처리(complex event processing)

■ 여러 이벤트 소스로부터 발생한 이벤트를 대상으로 이벤트들의 영향을 분석하여대응되는 액션을 수행

49




스트림 이벤트 처리

50




복합 이벤트 처리(CEP)

51




EDA 플랫폼

52




EDA 플랫폼

이벤트 메타데이터(event metadata)

■ 이벤트 메시지를 형식을 정의한 이벤트 사양(event specification)과 이벤트를 처리하기 위한 이벤트 처리 규칙

(event processing rule) 등 이벤트 관련 메타 데이터로 이벤트 소스 및 수신자, 이벤트 처리자 등이 공유할

수 있어야 함

이벤트 처리 엔진(event processing engine)

■ 이벤트 사양을 준수하는 이벤트 메시지를 대상으로 이벤트 처리 규칙에 따라 서비스를 호출하거나 이벤트를 전송

하고 이벤트 메시지를 캐싱

이벤트 개발 도구(event development tool)

■ 이벤트 사양과, 이벤트 처리 규칙 등을 정의할 수 있도록 하는 지원 도구

이벤트 관리 도구(event management tool)

■ 이벤트 처리 상태 모니터링, 이벤트 흐름에 대한 모니터링 등 전체 시스템을 관리하는데 사용되는 도구

엔터프라이즈 통합 백본(enterprise integration backbone)

■ 이벤트 입,출력시 또는 이벤트 처리시 외부 자원과의 연동을 담당하는 기존 엔터프라이즈 환경에서 사용되고 있는

엔터프라이즈 통합 시스템

통합 자원(integrated resource)

■ 다양한 이벤트를 발생하는 소스와 이벤트 기반의 활동으로서 구동되어야 할 외부 서비스 등을 의미하며, 엔터프라

이즈 통합 백본에 의해 EDA 플랫폼에 통합

53




SOA와 EDA

SOA는 요청/응답(request/response) 방식에 적합하며, EDA는 감지-반

응(sense-and-respond) 방식으로 장기간 실행되는 비동기적인 프로세

스 능력을 제공

54




SOA와 EDA의 차이점

55




이벤트 주도적 SOA

이벤트가 발생할 때 서비스를 호출하는 것

서비스는 이벤트 소스 또는 대상으로서의 역할을 수행할 수 있음

이벤트가 발생할 때 이벤트의 대상으로 서비스를 호출

이벤트 대상으로서의 서비스는 간단한 기능일 수도 있고, 완전한 비즈니

스 프로세스가 될 수도 있음

56




이벤트 소스로서의 서비스

이벤트는 가능한 모든 행위를 수행하도록 즉시 확산되어, 다른 서비스를

호출한다든가, 비즈니스 프로세스를 실행하거나 포탈에 정보를 게시

서비스는 많은 이벤트 소스와 대상 중 하나일 뿐이며, 서비스 지향을 사

용하여 EDA를 구현할 수도 있음

EDA는 이벤트 주도적 SOA를 넘어서 확장되어, 실시간 정보 흐름과 분

석, 그리고 복잡한 이벤트 처리(CEP)까지 포함할 수 있음

SOA와 EDA가 결합된 것을 SOA 2.0 또는 Advanced SOA라고 함

57

Documents

1장 서비스 지향 개념의 이해 - contents.kocw.netcontents.kocw.net/KOCW/document/2015/chungnam/leekyuchul1/13.pdf · 기존의통합논의가주로it 리소스를통합하는it