IBM®
메인 컨텐츠로 가기
    Korea [국가변경]    이용약관
 
 
   
        제품    서비스 & 솔루션    고객지원 & 다운로드    회원 서비스    
메인 컨텐츠로 가기

한국 developerWorks  >  Architecture | SOA와 웹서비스  >

UML 서비스 컴포넌트를 사용하여 SOA 아키텍처 패턴 나타내기 (한글)

SOA를 구성하는 서비스 컴포넌트를 더욱 잘 이해할 수 있도록...

developerWorks
문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

토론

영어원문

영어원문


제안 및 의견
피드백

난이도 : 초급

Prithvi Rao, Certified IT Architect, IBM 

2007 년 9 월 11 일

여러분은 아키텍트로서, 클라이언트 엔터프라이즈 아키텍트와 IT 스테이크홀더들로부터 서비스 지향 아키텍처(SOA) 패턴과 서비스 컴포넌트들을 중립적인 방식으로 묘사해 줄 것에 대해 요청을 받습니다. 이 글에서는, Unified Modeling Language (UML) 모델을 사용하여 SOA 아키텍처 패턴과 이것과 제휴된 서비스 컴포넌트를 묘사할 것입니다. 또한, 스테이크홀더들이 더욱 잘 이해할 수 있도록, 산업 표준의 UML 포맷의 정황 속에서 SOA 패턴의 서비스 컴포넌트를 표현하는 방법을 배워봅시다.

머리말

소셜 북마크

mar.gar.in mar.gar.in
digg Digg
del.icio.us del.icio.us
Slashdot Slashdot

스테이크홀더가 자신들의 아키텍처와 디자인에 SOA Unified Modeling Language (UML) 컴포넌트를 활용할 수 있도록 논리적 포맷으로 서비스 지향 아키텍처(SOA)를 제공하고자 한다면 이 글이 도움이 될 것이다. UML 노드의 형태로 SOA 아키텍처 패턴의 서비스 컴포넌트를 활용하는 방법을 배워서 SOA 시나리오를 생성한다. UML을 사용하여 제품 불가지론적(product-agnostic)인 방식으로 SOA 패턴과 이것의 제휴 서비스들에 대해 배워서 SOA 컴포넌트, 연결, SOA 아키텍처 패턴의 인터랙션을 나타내 보자.

*제품 불가지론(Product-agnostic): 이 용어는 UML을 사용하여 SOA 솔루션을 제공하는 것에 대한 논의가, 특정 제품 스팩을 피해서 고급의, 추상적인 용어로 다루어지는 방식을 의미한다.

이 글에 소개된 SOA 패턴과 제휴 서비스들은 비 상용의, 벤더 중립적인 방식으로 SOA 패턴을 스테이크홀더들이 이해하기 쉽게 제공하는 방법에 관한 것이다.

논리적인 SOA 레퍼런스 아키텍처

SOA 패턴은 UML 제품 불가지론적인 방식으로 표현된다. (그림 1) 이 간단한 형식 속에, SOA 패턴은 요청자와 공급자들간 서비스를 연결 및 제공하는 분리된 Enterprise Service Bus (ESB)들로 구성된다.




그림 1. 논리적인 SOA 레퍼런스 아키텍처
논리적인 SOA 레퍼런스 아키텍처

SOA 패턴은 ESB 인프라스트럭처와 서비스 인터랙션 포인트(SIP), 또는 엔드 포인트들로 구성된다. (표 1)


표 1. 서비스 인터랙션 포인트
서비스서비스가 제공하는 것
인터랙션 서비스 포털 또는 기타 관련 웹 기술을 사용하여 콘텐트와 데이터를 고객 또는 사용자에게 제공하는 기능.
프로세스 서비스 비즈니스 프로세스와 흐름에 따라서 다중의 서비스들 간 메시지 흐름과 인터랙션을 관리하는 컨트롤 기능.
정보 서비스 분산된 데이터 소스들을 연합, 복제, 변형하는 기능
파트너 서비스 파트너 전자 데이터 교환(EDI)과 레거시 시스템을 엔터프라이즈 아키텍처로 통합하는 기능.
비즈니스 애플리케이션 서비스 서비스 소비자들이 비즈니스 애플리케이션 서비스에 의해 호출될 수 있도록 하는 기능.
애플리케이션과 데이터 액세스 서비스 핵심 애플리케이션들을 외부 데이터 저장소와 패키지 애플리케이션들과 통합하는 기능.

ESB

ESB는 SOA의 연결 엔트리 포인트로서 작동하고 다음과 같은 서비스를 제공한다.

  • 요청 및 응답 서비스
  • 변형
  • 콘텐트 기반 라우팅
  • 개인화 된 로깅
  • 최적화
  • 모니터링
ESB는 또한 서비스의 일반적인 연결과 가상화를 제공한다. 최신의 비즈니스 애플리케이션 수요를 다루기 위해, ESB는 Service Component Architecture (SCA) 프로그래밍 모델을 활용한다.

그림 2에서, 최신의 SCA 모델을 지원하는 ESB를 볼 수 있다. Java™ Message Service (JMS) 스팩을 기반으로 구현된 기본 메시징 엔진도 함께 있다. ESB는 SCA 모듈에 기반한 중재 컴포넌트(모듈)을 사용하여 서비스 요청자와 서비스 공급자 간 메시지를 중재한다. ESB의 중재 서비스는 위치와 구분이 확실하게 가상화를 구현하는 복잡한 중재 패턴을 구성하도록 만들어 진다. 또한, 성능, 메시지의 암호화/암호 해독, 신뢰성 있고 안전한 콘텐트 전달 및 트랜잭션 같은 서비스 품질(QoS) 요구 사항으로 강화된다.


그림 2. Enterprise Service Bus
Enterprise Service Bus

중재 컴포넌트는 세 개의 컴포넌트들로 구성된다.

메시지 모델
고려 중인 메시지의 메타-모델에 기반하고 있다. (ESB는 서비스 공급자와 서비스 요청자 간 흐르는 메시지 모델들의 다양한 유형을 지원해야 하고, 메시지-모델 불가지론적인 교환 방식을 생성해야 한다.)
중재 흐름
중재 흐름을 호출하여 서비스 요청자와 서비스 공급자간 중재를 수행하고, 외부 서비스에 대한 레퍼런스를 제공하는 인터페이스를 포함하고 있다. (중재 흐름은 여러 중재 패턴들을 지원한다. 모니터, 수정자, 밸리데이터, 캐시, 라우터, 디스커버리 클론 등)
통신 프로토콜
같은 다양한 통신 프로토콜을 지원하여 서비스 공급자들을 서비스 소비자와 연결한다. (통신 프로토콜은 요청/응답, 퍼블리시/등록, 동기식/비동기식 같은 여러 인터랙션 패턴들을 지원한다.)

ESB는 서비스 레지스트리와 저장소 컴포넌트를 동적인 검색 장치로서 사용하여 서비스 엔드포인트에 대한 정보를 제공한다. 레지스트리와 저장소 서비스를 통해 서비스 메타데이터와 서비스 인터랙션 및 정책의 관리에 최적으로 액세스 할 수 있다. 또한, 기타 표준 레지스트리 및 저장소의 통합을 지원한다. 기본적으로는 XML Schema Definition Language (XSD) 또는 Web Services Description Language (WSDL) 같은 서비스 메타데이터 문서들로 구성된다.

인터랙션 서비스

ESB와의 서비스 통합 포인트를 갖고 있는 인터랙션 서비스들은 그림 3에 나타나 있다. 인터랙션 서비스 노드는 SOA 엔트리 포인트로서의 역할을 한다. 인터랙션 서비스는 인터페이스를 추상화 하고 엔드 유저와 SOA 애플리케이션들 간 정보 소스를 모으는 SOA용 표현 레이어를 제공한다.

인터랙션 서비스들은 세 개의 주요 서비스들로 나뉜다.

사용자 인터페이스 서비스
의사 결정과 실행의 가시성을 위해 대시보드를 사용하는 포털 애플리케이션으로 구성된다.
사용자 인터랙션 서비스
시각화, 협업, 복합 서비스, 경고 발생, 폼들로 구성된다.
전개 서비스
모바일, 브라우저, 리치 클라이언트로 구성된다.

인터랙션 서비스들은 지원 템플릿 컴포넌트를 사용하여 복합 애플리케이션들을 쉽게 생성한다. 복합 애플리케이션들은,

  • 아웃소싱 또는 인하우스(in-house) 애플리케이션들을 위한 토대를 제공한다.
  • 리치 클라이언트와 모바일 엔드 유저 클라이언트를 지원한다.
  • 매우 개인화 되고 동적인 데이터를 제공하는데, 이는 결과를 기반 비즈니스 프로세스 메트릭스로 연결하여 실시간으로 보여준다.
  • 대시보드의 역할을 하며, 사용자에게 프로젝트의 핵심 성능 인디케이터(KPI)의 실시간 뷰를 제공한다.


그림 3. 인터랙션 서비스
인터랙션 서비스

각각의 복합 애플리케이션들에는 특정 함수와 연결된 워크플로우를 갖고 있는 사전 구현된 포틀릿이 포함되어 있다. 인터랙션 서비스들에는 빌트인 필터링 기능, 브라우저 기반 설정 마법사, 대화형 웹 폼, 검색, Web 2.0 기술, 협업도 있다. 예를 들어, 협업 서비스 컴포넌트는 완벽히 통합된, 포털 기반의 협업 환경이다. 여기에는 이메일, 캘린더링 및 스케줄링, 인스턴트 메시징, 웹 컨퍼런싱, 문서, 웹 콘텐트 관리가 포함된다.

프로세스 서비스

그림 4는 프로세스 서비스들과, SOA 도메인 내에서 이것의 기능을 수행하기 위해 사용하는 컴포넌트들을 나타내고 있다. 프로세스 서비스들은 비즈니스 서비스와 중재 모듈을 사용하여 비즈니스 흐름 요구 사항을 달성한다. 프로세스 서비스는 SCA 프로그래밍 모델을 사용하여 비즈니스 데이터를 소비 및 생산하는 비즈니스 서비스를 모델링 한다.


그림 4. 프로세스 서비스
프로세스 서비스

비즈니스 프로세스는 Business Process Execution Language (BPEL)을 사용하여 정의된다. 비즈니스 서비스는 비즈니스 관련 액티비티, 규칙, 조건들이며, 사전 정의된 순서대로 호출되어 비즈니스 목표를 달성한다. 비즈니스 규칙들은 비즈니스 함수의 외부화를 통해서 비즈니스 정책을 구현 및 실행하는 수단이다. 외부화(Externalization)는 비즈니스 규칙들이 애플리케이션의 다른 측면들과는 독립적으로 관리되도록 한다. 이러한 독립성은 동적 비즈니스 규칙들이 기능을 업데이트 하면서, 비즈니스의 기민성(agile)에 기여한다.

SCA 컴포넌트는 인터페이스, 레퍼런스, 구현들로 구성된다. 서비스 컴포넌트는 자바 또는 WSDL 포트 유형으로 된 인터페이스를 가질 수 있다. 비즈니스 프로세스 유형 컴포넌트는 자바 또는 WSDL 포트 유형들로 한 개 이상의 SCA 인터페이스들을 구현할 수 있는 프로세스 구현 유형으로 구성된다. 이 프로세스는 장기 또는 단기 실행이 될 수 있다. 단기 실행 프로세스를 마이크로 플로우(micro flows)라고 한다. 장기 실행 비즈니스 프로세스는 다중 파트너들과 인터랙팅 하며, 인터랙션은 표준의, Stateless 웹 서비스 호출을 통해 수행된다.

각 파트너와의 인터랙션은 웹 서비스 인터페이스를 통해 발생한다. BPEL은 WSDL과 XML 스키마를 기반으로 구현된다. 이러한 프로세스 모델은 확장된 XML 스키마를 사용하여, BPEL 스팩에 정의된 대로, 신택스와 의미론적 제약 조건에 적용된 규칙 세트를 검사한다.

정보 서비스

ESB용 정보 서비스 스택은 그림 5와 같다.


그림 5. 정보 서비스
정보 서비스

다음과 같은 컴포넌트들을 갖고 있다.

메타데이터 관리
데이터에 대한 정보를 제공한다. (메타데이터는 데이터 구조와 의미에 대한 정보이다. 메타데이터 관리 컴포넌트는 메타데이터와 메타모델, 메타-메타모델(meta-metamodels)을 관리할 수 있다.)

메타모델(메타-메타데이터)는 메타데이터의 구조와 의미를 정의한다. 표준화된 메타모델의 예제에는 UML과 Common Warehouse Metamodel (CWM)이 포함된다. 메타-메타모델 레이어는 구조의 디스크립션과 메타-메타데이터의 의미로 구성된다. 다른 모든 정보의 모델을 기술하는 공통의 언어를 제공한다. MetaObject Facility (MOF)는 메타-메타모델에 사용되는 표준이다. (참고자료)

추출, 변형, 로드(ETL)
한 개 이상의 데이터 소스에서 한 개 이상의 대상으로 데이터를 추출, 변형, 로딩한다. (ETL은 데이터 통합, 마이그레이션, 전파를 실행하고, 데이터 웨어하우징과 비즈니스 정보 기능과 제휴된다.)
연합
데이터와 콘텐트 클래스를 사용하여 이종의 콘텐트 소스들 간 데이터를 연합한다. (이러한 분산된 방식은 데이터와 콘텐트 과잉, 대역폭, 스토리지, 동기화, 추가 관리 비용을 줄인다. 분산 정보 소스로의 실시간 액세스는 비즈니스 정보에 새로운 기능을 가져온다.)

연합은 다양한 데이터 소스용 커스텀 애플리케이션 프로그램 인터페이스(API)를 개발 및 관리하는 필요를 줄인다. 연합은 또한 자주 사용되는 데이터를 캐싱하고 구체화 된 쿼리 테이블(MQT)과 분산된 쿼리 최적화와 실행을 사용함으로써 성능을 향상시킨다. 성능을 높이기 위해서는, 연합 서버는 목표로 한 연합 데이터 소스에서 행의 하위 세트가 될 수 있는 MQT를 저장 및 생성하여 성능을 높인다.

데이터 배치 (복사와 캐싱)
하나의 위치에서 또 다른 위치로 데이터를 복사한다. (대상 위치는 데이터 웨어하우스 같은 중앙화 된 위치 또는 네트워크에 분산된 장소가 될 수 있다. 그리드 환경에서, 복제와 캐시 서비스들은 QoS 목표에 맞는 배치 관리 서비스를 생성하는데 사용된다. 액세스 패턴과 소비 애플리케이션의 위치에 따라서, 배치 관리 서비스는 캐시나 복제를 생성함으로써 응답 시간과 정보 가용성을 향상시킨다. 단계화 된 데이터 거버넌스는 정보 흐름의 라이프 사이클에 대한 더 많은 제어권을 제공한다.)
데이터 모델링
엔터프라이즈의 모델을 저장하는 논리적, 물리적, 메타데이터 모델의 결합을 갖고 있이다. (이러한 데이터 모델은 데이터 구조와 데이터 사용의 형태로 비즈니스와 비즈니스 애플리케이션에 직접적인 영향을 미친다.)

데이터 모델의 신중한 플래닝은 전체적인 트랜잭션 성능을 향상시킨다. 트랜잭션 유형에 의존한다. 온라인 트랜잭션 프로세싱(OLTP) 트랜잭션은 E/R 모델을 사용한다. 데이터 웨어하우징 트랜잭션은 다각적인 모델링 기술을 사용한다.

검색
고유의 검색 메커니즘을 사용한다. (가장 일반적인 검색 기능은 SQL과 XQuery 같은 검색 언어를 사용한다. 데이터베이스 검색은 구조화 된, 정확히 매칭된 데이터를 검색하는데 탁월하지만, 이에 따라 쿼리를 구현하는 데이터 모델 구조에 익숙해야 한다.)

데이터베이스 검색은 범위로 제한된다. 관련성 랭킹, 명확하지 않은 검색, 다중 키워드에는 맞지 않다. 검색 엔진이 고성능, 유연성, 관련 랭킹을 달성하려면, 엔진은 데이터베이스로 직접 연결하여 데이터를 추출하고 데이터베이스에서 인덱스를 생성해야 한다.

분석
더 나은 의사 결정, 데이터 마이닝, 부분적 리포팅을 보조한다. (전통적인 분석에는 리포팅, 데이터 마이닝, 대시보드, 스코어보드, 비즈니스 성능 관리를 포함하고 있다. 조직들은 실시간으로 이종의 데이터 소스에 액세스 하여 규제 순응성을 확인하고, 고객에게 더욱 잘 응대하며, 시장 트랜드를 예견하고, 운영 효율성을 높인다.)

분석 컴포넌트는 인터랙션 서비스의 복합 애플리케이션의 기능과 밀접하게 연결되어 있고 비즈니스 애플리케이션에 대한 실시간 KPI를 제공한다. 향후, 분석들은 늘어난 정보를 구현하여 이종의 정보 소스에서 온 정보를 연결시켜 보다 나은 비즈니스 결정을 내릴 수 있도록 새로운 인사이트를 제시한다.

파트너 서비스

SOA용 재사용 엔트리 포인트로서 작동하는 파트너 서비스는 그림 6에 나타나 있다. 레거시 시스템과 전자 데이터 교환(EDI) 시스템들이 커스텀 어댑터를 사용하여 SOA 엔터프라이즈 아키텍처와 ESB로 연결되고, 운영 효율성과 QoS를 높인다. 어댑터는 EIS와 통합 브로커 간 통신을 제공한다. 백엔드 시스템이나 비즈니스 애플리케이션은 지정된 어댑터가 필요하다.

비즈니스 통합 어댑터들은 소프트웨어 API들의 컬렉션으로 구성되며, 네이티브 통신에 백엔드 엔터프라이즈 정보 시스템(EIS)와 비즈니스 객체와 어댑터를 설정할 수 있도록 해주는 툴을 제공한다. 커스텀 어댑터를 사용하는 파트너 서비스들은 SAP, Siebel, IBM® WebSphere® (WebSphere Adapter Toolkit을 비롯하여 수십 개의 어댑터를 제공하고, WebSphere Adapter for SAP Software와 WebSphere Adapter for Siebel Business Applications가 포함된다.)를 포함한 다양한 소프트웨어 벤더들에 의존한다.


그림 6. 파트너 서비스
파트너 서비스

그림 7은 다양한 백엔드 비즈니스 애플리케이션 시스템들간 비슷한 데이터를 의미적으로 동기화 하는 것을 포함하여, 비즈니스 통합에 사용되는 공통 패턴을 보여주고 있다. 이 시나리오는 두 개의 다른 백엔드 시스템들을 보여주고 있고, 비즈니스 통합 어댑터를 사용하여 각 프로세스 서버에서 실행되는 비즈니스 통합된다. 이 어댑터의 통합은 통합 애플리케이션들에 의해 사용되는 같은 SCA 프로그래밍 모델과 컴포넌트를 활용함으로써 이루어진다.


그림 7. 비즈니스 통합 어댑터 서비스
비즈니스 통합 어댑터 서비스

그림 7의 중앙은 비즈니스 통합 애플리케이션을 가진 프로세스 서버를 보여주고 있다. 비즈니스 통합 애플리케이션은 SCA 모듈 밖에서 JMS 반출을 통해 다른 서비스를 호출하는데 사용된다. 비즈니스 통합 애플리케이션은 JMS 반입을 사용하여 SCA 모듈 밖에서 다른 서비스들을 호출할 수 있다. 이 어댑터는 애플리케이션 스팩의 데이터 구조나 비즈니스 객체를 사용하여 백엔드 시스템과 통신하고 커넥터 설정 파일을 사용하여 설정된다.

비즈니스 객체가 반출을 통해 프로세스 서버로 전달될 때, 반출의 일부인 데이터 바인딩에 의해서 프로세스 서버가 이해할 수 있는 포맷으로 변환된다. 비즈니스 객체가 어댑터로 전달될 때 반입의 일부인 데이터 바인딩에 의해서 어댑터가 이해할 수 있는 포맷으로 변환된다. 이러한 데이터 동기화 패턴은 애플리케이션 스팩의 포맷에서 제너릭 포맷으로 비즈니스 객체를 매핑할 수 있다.

애플리케이션 어댑터 컴포넌트들을 공급하는데 제휴한 벤더들에는 Ariba Buyer, Clarify, MatrixOne (eMatrix), JD Edwards, mySAP.com, Oracle applications, PeopleSoft Portal intranet, QAD MFG/PRO, Retek, SAP Exchange Infrastructure, Siebel, WebSphere Process Server, WebSphere Enterprise Service Bus (ESB)등이 있다.

일부 기술 어댑터 컴포넌트들은 다음과 같다: ACORD XML, Microsoft® COM, CORBA, e-mail, EJB, Microsoft Exchange, FIX Protocol, IBM iSeries®, WebSphere Business Integration iSoft Peer-to-Peer Agent, Java Database Connectivity (JDBC) (SQL and stored procedure access), JMS, JText, IBM Lotus® Domino®, Society for Worldwide Interbank Financial Telecommunication (SWIFT), WebSphere MQ, WebSphere Business Integration Message Broker, WebSphere MQ Workflow, Web services, and XML.

일부 기술 어댑터는 데이터 핸들러를 사용하는데, EDI, SOAP, XML, 기타 텍스트 포맷용 데이터 핸들러도 포함된다.

이 어댑터는 공통의 어댑터 프레임웍을 사용하여 구현되며,

  • 이벤트 프로세싱과 요청 프로세싱이 가능하다는 점에서 양방향이다.
  • 메타데이터를 통해 설정 가능하고 멀티쓰레디드 비즈니스 객체들을 처리할 수 있다.

비즈니스 통합 협업 컴포넌트는 고객 관리(CRM), Health Insurance Portability and Accountability Act (HIPAA), 보건, 주문 관리, procurement, 통신, 보험 같은 컴포넌트와 협업한다. 비즈니스 통합 협업은 각각의 컴포넌트와 관련된 정보와 데이터를 체계화 및 동기화 하는 사전 구현된 템플릿으로 수행된다.

예를 들어, HIPAA 트랜잭션을 위한 협업은 필요한 스팩과 표준과의 순응성을 실행하며, 모든 트랜잭션과 인터랙션이 다중의 애플리케이션들과 엔터프라이즈 영역들 간 상호 연결되도록 한다. 브로커 플러그인 컴포넌트는 사용자 플러그인 노드를 생성하는데 필요한 필수 클래스들을 제공한다. 마이크로브로커(microbroker) 플러그인 컴포넌트는 브로커 이름, 큐 이름, 데이터 소스 같은 필수 액세스 관련 정보를 제공한다.

비즈니스 애플리케이션 서비스

비즈니스 애플리케이션 서비스들은 SOA용 재사용 엔트리 포인트를 구성한다. 비즈니스 애플리케이션들은 약결합 되어 웹 서비스를 사용함으로써 기업에 비즈니스 가치를 가져온다.

웹 서비스는 값비싼 비즈니스 애플리케이션들을 구현하는 비용을 줄이고, 새로운 비즈니스 모델을 엔터프라이즈 구조에 전개한다. 대부분의 기업에서, 전개의 가장 큰 문제는 보안이다. 비즈니스 애플리케이션 서비스들은 비즈니스 보안 기능들을 사용하여 비즈니스 트랜잭션 동안 보안을 확립한다.

그림 8은 비즈니스 프로세스와 정책 관리 컴포넌트를 사용하여 비즈니스 애플리케이션에 비즈니스 보안 서비스를 제공하는 비즈니스 애플리케이션을 묘사하고 있다.


그림 8. 비즈니스 애플리케이션 서비스
비즈니스 애플리케이션 서비스

비즈니스 프로세스와 정책 관리 컴포넌트는 다음과 같은 보안 컴포넌트를 사용하여 비즈니스 애플리케이션에 대한 보안 의무 사항을 수행한다.

보안 거버넌스 프레임웍
효과적인 거버넌스 구조의 필요성과 기업 내 의사 결정 권한을 다룬다. (이 프레임웍은 명령 체인, 책임, 권한을 확립하여 엔터프라이즈 비즈니스 애플리케이션들이 보안 관점에서 효과적으로 관리될 수 있도록 한다.)
신용 관리
두 개의 엔터프라이즈 또는 조직들간 신용을 확립하여 안전한 비즈니스 트랜잭션을 수행한다. (신용은 관계와 책임 관리 규칙을 지키는데 동의하는 두 개의 엔터티들간 성립된다.)

신용은 암호 키, 개인 또는 공개 키, 디지털 서명, 프로토콜을 포함하여 암호 방식을 사용하여 기술 관점에서도 확립된다.

ID 및 액세스 관리
필수 ID 관리와 액세스 권한을 제공한다. 이 컴포넌트는 다음과 같은 추가 컴포넌트를 사용하여 서비스를 수행한다.
  • HR 아이디 피드: 관리 기구에 ID 변경을 공지하고 적절한 워크플로우를 실행한다.
  • 승인 컴포넌트: ID 또는 정보 액세스에 대한 변경 또는 업데이트에 대한 필수 관리 승인을 얻는다.
  • 사용자 자가 보호 컴포넌트: 엔드 유저가 관리 감독 없이 특정 보안 관리 태스크를 수행할 수 있도록 한다. (예, 주기적으로 패스워드를 변경하기)
  • 위임 컴포넌트: IT 보안 관리 기능을 또 다른 개인에게 위임하는 기능을 제공한다.
  • 재확인 컴포넌트: 정기적으로 승인되어야 하는 시스템으로의 액세스를 제공한다.
보안 시스템과 네트워크
방화벽, 침입 탐지 시스템, 바이러스 탐지, 패치 관리, 운영 및 네트워크 보안 같은 보안 서비스를 제공한다. (비즈니스 애플리케이션 서비스 컴포넌트는 연합 컴포넌트를 사용하여 엔터프라이즈의 다양한 서비스 환경을 관리한다.)
데이터 보호
전송 과정에 비즈니스 정보 콘텐트의 보안을 관장한다. (데이터 보호 컴포넌트는 사생활 보호 정책을 관리하고, 민감한 정보에 대한 상세한 리포트를 획득하고, 사용자에 의한 리뷰용 정책을 공표하며, 사용자 선호도를 파악 및 실행함으로써 신뢰를 구축한다.)
위험 요소 관리
엔터프라이즈 시스템 내에 위험 요소 레벨을 결정하고 비용 효과 분석과 시스템에 미치는 영향에 기반하여 전체적인 보안 연산에 미치는 영향력을 평가한다.
순응성 관리
외부 연방 또는 주 규제 및 IT 기업 비즈니스 보안 정책에 순응하도록 한다.
감사 트레일 및 레코드
IT 시스템에 도입된 다양한 IT 보안 정책들이 매일 매일의 연산에 실제적으로 적용되어 내/외부 정책에 순응하는 방식을 조정 및 평가한다. (관리 및 기술 팀이 정책의 차이가 있을 때 적절한 액션을 빠르게 취할 수 있도록 한다.)

애플리케이션 및 데이터 액세스 서비스

애플리케이션과 데이터 액세스 서비스 컴포넌트는 SOA의 정보 및 재사용 엔트리 포인트로서 작용한다. (그림 9) 이종의 기술들간 서비스 연결성은 SOA의 토대가 된다. 그림 9는 애플리케이션과 데이터 액세스 서비스 컴포넌트들을 사용하여 다양한 인터랙션 프로토콜과 QoS를 지원하는 엔터프라이즈 시나리오를 보여준다. 대부분의 기업들의 비즈니스 애플리케이션들은 SOA 환경에 서비스로서 애플리케이션들을 노출하기 시작할 때 다양한 데이터 표현을 다룰 수 있어야 한다.

데이터의 다양한 형태를 다루는 것은 도전이 된다. 다양한 데이터 소스를 다룰 수 있는 공통의 API가 필요하다. SCA 프로그래밍 모델은 기반 데이터 레이어와 인터랙팅 하는 서비스들을 노출할 수 있다. 관계형 데이터베이스 데이터 액세스 서비스 (RDB DAS)라고 하는 강력한 데이터 액세스 유틸리티가 Service Data Objects (SDO)와의 긴밀한 통합을 제공하여 SCA 기반 애플리케이션 내에 있는 데이터에 액세스 한다.


그림 9. 애플리케이션과 데이터 액세스 서비스
애플리케이션과 데이터 액세스 서비스

요약

아키텍트와 스테이크홀더들은 종종 SOA 아키텍처 패턴을 묘사하고 어떤 엔트리 포인트를 선택해야 하는지에 혼란을 겪는다. 결국, 엔터프라이즈가 직면한 가장 힘든 문제를 다룰 수 있는 여러 SOA 엔트리 포인트들을 선택해야만 한다. 이 글을 읽은 후에, 아키텍트와 관련자들은 각 엔트리 포인트에서 규명된 다양한 노드들을 파악함으로써 자신들의 기업이 이러한 요구 사항들을 더욱 잘 맞출 수 있도록 한다.

이 글에서, 논리적인 관점에서 본 SOA를 배웠으며, 비 영리, 제품 불가지론적 방식으로 SOA 레퍼런스 아키텍처를 나타내는 노드와 UML 컴포넌트들을 생성하는 방법을 배웠다.

감사의 말

IBM DoD CTO인 Pavlick 박사에게 감사의 말을 전하고 싶다. 판매 및 아키텍처 팀이 SOA 노드의 저장소를 사용하여 고객에 빠르게 대응할 수 있도록 하는데 도움이 되는 논리적 SOA 모델과 반복적인 프로세스를 제공해 주었다.



참고자료

교육

제품 및 기술 얻기

토론


필자소개

Author1 photo

Prithvi Rao는 IBM Software Services Federal의 소프트웨어 IT 아키텍트이다. IBM 인증의 IT 아키텍트이며, IBM Rational 툴링과 지원 분야에서 많은 경력을 쌓았다. 도메인 디컴포지션 분석과 디자인을 사용하여 소프트웨어 아키텍처 제공, UML 모델링과 DoDAF 뷰와 뷰포인트와 관련하여 컨설팅을 하고 있다.




기사에 대한 평가


보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오.



아니오잘 모르겠음
 


 


12345
 



위로


developerWorks 콘텐트를 다른 사이트에 전재하기:
developerWorks 콘텐트에 대한 저작권은 IBM에 있습니다. IBM의 서면 허가나 원본 저자의 허락이 없이는 전재를 금합니다. 저희 콘텐트를 전재하시려면 IBM developerWorks 담당자 에게 문의하십시오.
    IBM 소개 개인정보 보호정책 문의