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

한국 developerWorks  >  웹서비스 | 오픈소스 프로젝트 | WebSphere  >

IBM WebSphere Developer Technical Journal: WebSphere Integration Reference Architecture 소개

기업단위 비즈니스 통합에 관한 서비스 기반 파운데이션

developerWorks
문서 옵션

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

토론


난이도 : 초급

Scott Simmons, Executive IT Architect, IBM

2005 년 8 월 17 일

The IBM® WebSphere® 통합 레퍼런스 아키텍쳐로 기업 내의 조직은 서비스 지향 기업통합방식을 취하게 되며 기존 기업통합 방식과 관련된 단점을 없앤다. 이 글에서, IBM® WebSphere® 통합 레퍼런스 아키텍쳐로 기업 내의 여러 가지 통합 요구들을 다루는 과정에 대해 설명한다.

IBM WebSphere Developer Technical Journal에서 발췌.

Introduction

지난 20여년 동안 소프트웨어 개발 및 구현작업이 진행되면서 서비스 지향 구조가 나오게 되었다. 우리 산업은 통합식 애플리케이션에서 진화되었지만 클라이언트-서버 솔루션을 관리하는 데 어려움을 겪었다. 하지만 SOA(서비스 지향 아키텍쳐)를 통해 서비스 구성요소를 점진적으로 개발하면서 애플리케이션 질이 향상되고 새로운 솔루션 개발 속도가 배가되었다. 따라서 더 나은 솔루션을 가지고 비즈니스 투자자의 요구조건을 다룬다.

SOA에서 구현한 개념으로 기업은 자체 비즈니스 라인 전반의 비즈니스 프로세스 및 라인 지원 정보 체계를 통합하게 된다. 기업 단위 통합이라는 요구를 수행하려면 정보, 애플리케이션 및 사람에 이르는 서비스 모델링 및 관리가 용이한 아키텍쳐가 있어야 한다. 구성요소 기반 방식을 통해 기업 내의 조직은 일반적 핵심 기반구조 서비스 구성에 영향을 줄 솔루션을 좀 더 탄력적으로 구축한다. 이와 같은 솔루션 프레임웍을 통해 소결합 방식을 단순화시켜 IT 솔루션의 신속성 및 적응성을 향상시킨다. SOA-기반 통합 파운데이션은 표준 기반 디자인 지원, 개발, 구현을 통한 기술 공존 지원기능을 제공한다. 이런 파운데이션 방식으로 최근의 기술 및 미래 기술 자산 전반에 걸친 기반구조를 제공해 기업 통합 아키텍쳐에 관한 견고한 기반을 제공하게 된다.

이와 같은 아키텍쳐 방식 지원 기능을 요구하는 통합 상품들이 많지만 상품들은 대개 기업 통합 요건을 제공하는 기능이 부족하다. 따라서 이 글에서는 기업 단위의 통합방식에 필요한 수많은 통합체제를 지원할 여러 가지 기능에 대해 중점적으로 알아보고 개방형 개발에 근거한 광범위한 SOA(서비스 지향 아키텍쳐)의 필요성 및 통합의 중요요소로 작용하는 실행 시간 표준들에 대해 논했다. SOA 파운데이션을 통해 기업은 기존 구성요소와 새 구성요소를 통합하고 기업 통합 조건이 나오면 복합 애플리케이션을 구현해 기업 자체의 솔루션을 확장한다.




위로


기업 통합 전략

기업 통합 전략에서는 사람, 애플리케이션/프로세스 및 정보를 통합하려면 최소한 솔루션 아키텍쳐 파운데이션으로서의 정보 상호교환이 요구된다. 이런 방식을 통해 부서별 단위로 통합 솔루션을 구현하고 이 솔루션을 기업 영역 전반에 걸쳐 확장한다. 이와 같은 기업 통합 전략을 통해 유동성 및 기업의 장점을 홍보할 시간이 제공된다. 기업 통합전략은 오늘날 복잡하고도 경쟁적인 비즈니스 환경에서 성공하기 위한 중요 요소가 되고 있다.

현재, 기업 통합 전략에 변화가 일고 있다. 이와 관련된 전략적 계획들이 계속 전개되면서 기업 내 부서별 요구조건을 해결하고 있긴 하지만 기업 내 조직에선 SOA방식에 근거한 기업통합 아키텍쳐 계획을 정의하고 있다. 이런 방식을 통해 조직은 기업 내 핵심 통합 자산/구성요소를 반드시 확인하며 통합 프로젝트 시 핵심 통합 자산들을 재활용하고 구체화시키는 방식을 지원한다. 이런 식으로 부서별 통합방식을 기업단위 계획으로 접근한다. 기업단위 계획을 통해 SOA방식의 정의, 발견, 호출에 따른 표준 접근 방식을 통한 자원 재활용을 촉진한다.

기업 통합 방식은 비즈니스 통합 솔루션의 부서별/라인별 개발에 관해 이전보다 더 전략적인 방식과 양립한다. 사실 전략적 솔루션은 전체 기업 통합을 위한 자산이 되고 있다. 한편 정책모델을 제공해 기업 통합 아키텍쳐 컨텍스트 및 법칙 내에서 전략적 솔루션을 개발하는 것이 중요하다. 이와 같은 계획이 없다면 기업들은 계속 부서별 통합 솔루션을 각기 독자적으로 구축하게 되며 결국엔 기업 통합으로 인한 장기적인 이득을 거두지 못하게 된다. 비즈니스 및 기술의 변화가 있는 한 기업 통합 방식에 있어 정책결여가 생기게 되면 기업 전반에 걸친 통합목표를 효과적으로, 적극적으로 지원하는 기능이 떨어지게 된다.




위로


서비스-지향 통합 아키텍쳐

기업 통합에 관한 구체적인 방식이 나와야 한다는 필요성이 제기되고 있다. 이에 따라 기업 통합 아키텍쳐의 경우 반드시 서비스 지향 아키텍쳐에서 나오는 장점들을 부각시켜야 한다. 서비스 지향 아키텍쳐는 새로운 기능 및 기존기능을 자유롭게 이용할 수 있는 표준을 사용한 재사용 서비스 구성요소로 통합하면서 모듈식의 복합 애플리케이션을 창출하게 된다. 서비스 지향 아키텍쳐에서는 여러 가지 비즈니스 목표를 수행하도록 구성된 비즈니스 맞춤 서비스 구성을 제공하게 된다. 한편 아키텍쳐 구현 메커니즘 또는 구현위치와 상관없이 인터페이스 구성으로 비즈니스 맞춤 세트를 나타낸다 (Endrie, 2003). 소결합 구성요소 아키텍쳐는 분산 토폴로지 전반에 걸친 표준포맷 내의 인터페이스를 나타냄으로써 구성요소가 서비스 소비업체 및/또는 공급업체로 작용하는 기능을 제공하기 때문에 그만큼 강력한 아키텍쳐가 되고 있다. 또한 복합 애플리케이션은 기능 분리를 통해 IT 시스템 유동성을 향상시키고, 다중 컨텍스트에서의 구성요소를 재활용하는 기능을 증가시키며 통합 모델을 단순화시키고 아울러 통합 프로세스 구축에 관한 탄력성을 제공한다.

기업 통합에 관한 서비스 지향 방식 애플리케이션에서 다음과 같은 장점이 나온다.

  • 이 애플리케이션을 통해 기업 통합 자산을 여러 서비스로 표현하는 개방형 표준에 작용하고 기존 자산의 재사용을 촉진하고 특정 벤더에 고착되는 현상을 막는다.
  • 이 애플리케이션으로 맵, 프로세스, 이산적 거래/서비스 또는 인터페이스와 같은 기업통합 구성성분을 나타내면서 상호 작용하는 표준방식 및 다중 비즈니스 프로세스 솔루션 전반에 걸친 자산을 탄력성 있게 재사용하는 기능을 제공한다.
  • 애플리케이션 구현사항이 아닌 애플리케이션 어셈블리에 기업통합에 관한 초점이 맞춰지고 새롭게 수정된 비즈니스 솔루션을 효율적으로 구현하게 된다.

한편 기업 통합자산을 고차원 서비스 구성요소로 구성되는 서비스로 나타내면서 서비스-지향 아키텍쳐를 통해 조직자원 및 애플리케이션의 연결을 규정한다. 기술적인 관점에서 보면 기업 통합을 위한 서비스 지향 프레임웍을 통해 조직 자원에서 표준 상호교환 구성을 통해 정보(메시지, 문서, 비즈니스 객체 등)를 교환하게 된다. 새로운 애플리케이션 및 기존 애플리케이션을 여러 서비스로 나타내면서 기업통합 요구조건을 다루도록 여러 서비스들을 구성하게 된다.

SOA 방식으로 우리에게 친숙한 publish/bind/find 서비스 구성을 통해 나열된 서비스 공급업체, 서비스 요청업체 및 서비스 설명으로 이루어진 아키텍쳐 체계와 요약화, 서비스 결합, 느슨한 연결 및 재사용을 포함하는 디자인 원칙, 패턴이 이루어지게 된다.

서비스 통합 프레임웍을 통합 솔루션 전반에 걸쳐 확산시킬 필요가 있다. SOAP 래퍼를 통해 통합 구성요소를 정의 또는 실행하는 기능을 지원하는 현 미들웨어 방식이 있다. 하지만 통합 아키텍트는 SOA 에 근거한 통합방식이 SOAP-기반 통합방식보다 훨씬 더 낫다는 것을 인식해야 한다. OASIS 및 OAG와 같은 표준 본체에서 인터페이스에 관한 정의가 나왔으므로 이 정의(사용자 정의 및 산업 기반 정의)가 계속적으로 나오는 것을 지원하는 기업 통합 솔루션이 필요하다. 서비스 지향 통합 아키텍쳐 내에 있는 기본 통합 자산은 밑에 나와 있으며 SOA기반 통합방식을 반드시 따라야 한다.

  • 표준 인터페이스를 통한 서비스 설명 및 정의, 예: WSDL
  • 표준 기반 전송/중재 계층 전반에 걸친 서비스 호출/상호작용
  • 서비스 상호작용을 강화하는 서비스 구성, 예: BPEL4WS
  • 통합 레지스트리/디렉토리 서비스를 통한 서비스 발견, 예: UUDI

복합 애플리케이션으로 플로우 로직이 포함된 복잡한 서비스를 생성하게 되며 이로 인해 서비스 실행순서가 정해진다. 이와 같은 복합 애플리케이션은 IT영역에서 비즈니스 영역에서의 비즈니스 프로세스와 유사하다. SOA 디자인으로 미들웨어 및 운용환경기능에 작용하게 되면 플로우 로직 및 기본 비즈니스 로직이 분리되며 개별 서비스로 이 디자인을 구현하게 된다. 기존 구성요소(예를 들면 메인프레임 CICS 애플리케이션)로부터 개별 서비스를 구현할 수도 있고 완전 새로운 기능을 가진 서비스를 구현할 수도 있다.

서비스-지향 통합 방식에 있어선 적절한 추상화 레벨 상에서 여러 서비스를 정의, 구현하는 것이 주요 과제로 남아 있다. 기업 통합방식을 개발시키는 데 있어 합리적인 아키텍쳐 디자인을 적용시키는 것은 최근 나온 모델 중심 디자인 및 아키텍쳐에서의 개념 뿐만 아니라 인식의 분리에서 나온 개념과 밀접한 연관이 있다.




위로


인식의 분리를 통해서 통합 아키텍쳐 구축이 단순화된다.

기업 단위 통합전략 내에서 조정해야 할 여러 다중분야를 통해 정보기술의 발전 및 구현이 이루어지고 있다. 비즈니스 애플리케이션 및 기본 비즈니스 운영환경 사이의 영역을 정의, 관리하는 데 있어 IT의 역할은 비즈니스 솔루션 구현에 관한 주요 요소로 부각되고 있다. 운영환경을 통해 비즈니스 애플리케이션을 위한 기반구조 서비스가 제공된다. 운영환경은 통합 솔루션을 지원하는 일반적 서비스를 나타낸다.

기업 통합 아키텍쳐를 정의할 때 여러 가지 기업통합 요건을 고려하는 것이 중요하다. 이와 같은 통합요건은 인적 태스크 상호작용에 근거한 기존 작업 흐름 관리, 다른 체계 사이의 활동 구성, 구조화, 비구조화 데이터를 포함한 분산 데이터 관리 및 사용자 상호작용 기능 등을 포함한다. 한편 특수 통합 문제를 해결하는 데 필요한 특수 통합체제에 적절한 서비스 객체를 분화시키고 디자인하는 기능이 기업에 필요하다. 그로 인해 인식의 분리라는 개념이 생겼고 이 개념은 기업 통합 서비스 정의에 있어 기본이다.

인식의 분리는 비즈니스 요구를 각각의 서비스로 분해하는 것으로써 비즈니스 프로세스 과정을 나타내는 기존 서비스 및 새로운 서비스의 조합들로 구성된 것을 나타낸다. 인식의 분리를 통해 통합 요구조건들은 더 작은 서비스로 나누어진다. 그림 1에 나타난 바와 같이 비즈니스 요구조건을 지원하는 데 정의해야 하는 특수기능을 알아내는 것을 통해 각각의 서비스로 분해하는 작업이 이루어진다.


그림 1. 인식의 분리
Figure 1. Separation of concerns

여러 서비스를 정의하는 인식의 분리 방식으로 인해 각각 독립적으로 구현되는 여러 기능들과 서비스를 특징짓고 분리하는 디자인이 나온다. 이와 같은 방식으로 통합 솔루션을 구축하는 것은 반복적 프로세스로 되어 가고 있으며 이와 관련된 각 구성 성분은 연속적인 통합 프로젝트에 걸쳐 구체화된다. 기업은 개발 팀에 디자인 정책 및 통합 멘토십을 제공해 최상의 전략 및 서비스와 각 구성요소의 재사용을 도모하게 된다.

SOA-기반 솔루션 프레임웍에 있어 서비스 구성요소를 분리하고 정의한다. 상기 솔루션 구성방식은 탑 다운 모델 중심 방식을 지원할 뿐만 아니라 새로운 서비스의 개발과 관련해 상향식 방식을 이용한다. 결국 최종적으로 나오는 복합 애플리케이션은 각각의 서비스에 관한 실행순서를 관리하는 플로우 로직으로 된 서비스 호출 기능들로 이루어져 있다. 이 애플리케이션은 기타 서비스에 활용하며 그 자체를 이용해 복합 애플리케이션을 부가적으로 개발한다.

한편 모델 중심 아키텍쳐(MDA)를 통해 구성성분 기반 아키텍쳐를 구축하는 방식이 널리 퍼져 있다. MDA 방식은 SOA 방식 개발에 관한 기초를 제공한다. MDA Manifesto(MDA 저널, 2004년 5월) 라는 기사를 보면 Grady Booch는 MDA를 "시스템 독립 모델을 구축해 이를 효율적으로 구현하는 자동화 툴을 사용에 기초한 기업 애플리케이션 개발 및 통합 체제"라고 평했다. MDA 방식은 비즈니스 투자자가 비즈니스 프로세스 개발에 참여할 뿐만 아니라 객체의 툴 기반 발생을 통해 IT 개발 프로세스의 효율성을 높인다. 서비스 지향 애플리케이션 개발에 있어 MDA 방식은 SOMA(서비스 지향 모델링 및 아키텍쳐) 및 SODA(서비스 지향 애플리케이션 개발) 방식으로 통합되고 있다.

또한 기업 IT 아키텍쳐 지침(C Perks/T Beveridge)이라는 글에서 Perks 씨는 "IT 아키텍쳐의 경우 기술적 기능을 계속 재고안한다. 현 팩션으로 IT 기존기능을 구축하지 않았기 때문이다. 때로는 이와 같은 방식이 완전히 합리적인 경우도 있다. 하지만 대개 이 방식은 프로젝트 팀에 의해 일시적으로 사용된다. 애플리케이션 개발은 비즈니스 기능에 관한 것일 뿐, 비즈니스 기반구조를 구축하는 것은 아니다."라고 말했다. 이 말은 인식의 분리 관점을 기업 단위 통합 전략에 응용하는 것과 아울러 기업통합전략을 개발하는 데 있어 기업 주도전략에 관한 필요성을 암시하고 있다.




위로


WebSphere 통합 레퍼런스 아키텍쳐

인식의 분리 과정을 시행하면서 비즈니스 통합 전략의 이점이 생기고 이를 통해 데이터 및 애플리케이션을 비즈니스 요구에 맞게 통합시킨다. 비즈니스 통합전략의 경우 프로세스 솔루션 및 애플리케이션 서버 파운데이션만 가지고서는 충분치 않고 일반 구성요소 및 서비스를 이용한 다중 통합체제가 모여야 한다. 상기 구성요소 및 서비스는 장기간 지속성을 제공하고 이를 통해 현존 IT 자산에 대한 투자가 계속 이루어지게 되며 "수정된" 통합 방식과 상호작용하는 것을 피한다. 비즈니스 통합을 효율적으로 하려면 서비스 지향 솔루션 구현을 지원하고 즉석 모듈러 형태로 구축되며 기업 단위 통합구축에 필요한 모든 기능을 지원하는 운영환경이 필요하다.

여기서 WebSphere 통합 레퍼런스 아키텍쳐는 광범위한 서비스 구성을 제공해 비즈니스 통합이 이루어지게 된다. 상기 서비스는 비즈니스 통합 요구조건을 해결하기 위해 필요한 여러 가지 기능을 제공한다. 한편 기업 통합 솔루션 아키텍쳐를 수행하는 동안 프로젝트마다 단계별로 구성요소 서비스를 구현한다는 점이 더 중요하다. 특수 아키텍쳐 상품은 이런 서비스가 다 필요하지 않지만 기업 단위 통합의 경우 서비스에 나온 모든 기능들을 통합 아키텍쳐에 포함시키는 기능이 필요하다. 결국 비즈니스 로직, 제어 로직, 라우팅 및 변환 로직을 약결합시키면 최종 아키텍쳐는 인식의 분리 기능을 규정하며 그 결과 외부 변화에 탄력적으로 더 잘 대처하게 된다. 조직 단위의 경우에는 이와 같은 접근방식으로 통합 솔루션 개발이 더 단순화되고 솔루션 유지성 및 작동성이 향상된다.

WebSphere 통합 레퍼런스 아키텍쳐(그림 2)는 광범위한 기업 단위의 솔루션에 요구되는 주요 통합 기능을 보여준다. 그림 2에서 나타난 서비스 구성에서는 인식의 분리가 기업 통합 요구조건에 적용되어 나타난 기능을 보여주며 결국엔 서비스-지향 아키텍쳐 원칙으로 통합되게 된다.


그림 2. WebSphere 통합 레퍼런스 아키텍쳐
Figure 2. WebSphere Integration Reference Architecture

그림 2와 같은 고차원 아키텍쳐에서는 광범위한 통합방식을 수행하는 데 필요한 통합기능/서비스에 대해 나와 있다. 이와 같은 서비스를 자체 구현기능이 아닌 자체 인터페이스로 설명하기 때문에 주어진 솔루션은 메인프레임 애플리케이션, 로컬 또는 원격 애플리케이션, BPEL(비즈니스 프로세스 설명에 관한 기준)로 묘사된 구성 프로세스 또는 J2EE로 구축된 구성요소 등으로 설명한 구성 프로세스 등으로 이루어진다. 위의 아키텍쳐 통합 구성요소를 구현하면 운영환경단위 및 구성요소/서비스 단위에서의 신뢰도, 안정성, 유용성 및 관리를 포함한 비기능 요구조건에 관한 지원기능을 제공한다.

연결 서비스(Connectivity services)

WebSphere 통합 레퍼런스 아키텍쳐의 중심에는 연결 서비스가 있다. 이 서비스는 ESB(기업 서비스 버스) 아키텍쳐 패턴을 지원하고 실증하는 기반구조를 제공한다. ESB는 분산 구성요소 토폴로지 전반에 걸친 상호 연결 서비스를 전달한다. 전송 서비스, 이벤트 서비스 및 중재 서비스가 ESB에서 제공된다. 전송 서비스는 기본 연결층을 제공한다. 이벤트 서비스로 통합 레퍼런스 아키텍쳐에서 비즈니스 프로세스의 일부형태로 발생한 특수 이벤트에 반응하게 되며 중재 서비스로 아키텍쳐에 있는 상호작용 서비스들 간에 약결합이 이루어지게 된다. ESB는 근본적으로 확장된 기업의 동맥 시스템과도 같고 주로 기업의 다양한 운영환경 전반에 걸친 메시징, 공지 및 호출기능을 제공하며 앞으로만이 아니라 오늘날 서비스 지향 솔루션을 구현할 시 WebSphere 통합 레퍼런스 아키텍쳐의 서비스 방향성을 작용시키는 중요한 인자가 되기도 한다.

ESB는 다중 연결 토폴로지 대안을 규정하며 SOAP/HTTP, RMI/IIP 및 기타와 같은 실행도구와 함께 다중 메시지 교환 토폴로지 및 패턴을 지원한다. 대부분의 경우 서비스 간의 상호작용을 원활하게 하기 위해선 약결합이 요구된다. 반면 본질상 대연결을 요구하는 중요 비즈니스 기능 및 거래 등도 있다. 이런 연결 형태들은 WebSphere ESB 아키텍쳐 내에서 지원된다. 이종 기술이 지원되려면 메시지 흐름 인스턴스 내의 다중 프로토콜, 미들웨어 상호 운용성, 서비스의 다른 기능들(지속성, 신뢰성, 거래운영, 유용성 등)에 관한 사양, 다양한 메시지 분산 기능지원 및 라우팅(발행/구독, 질의 기반 및 방송 기반 라우팅을 포함함)을 지원하는 기능이 있어야 한다. 게다가 연결 서비스 및 ESB 아키텍쳐는 Point-of-Sales, SCADA 및 기타 보급 장치 솔루션과 같은 특수 메시지/정보 전달기능을 지원한다. 오늘날 WebSphere MQ 가 있는 현 솔루션을 이용하는 고객은 ESB 패턴을 구현하고 새로운 프로토콜 기능도 지원하게 된다.

ESB 내에서 연결 서비스 구성의 일부로 제공되는 세 가지 서비스가 있다.

  • 이벤트 서비스(Event services) 는 조직 자원 뿐만 아니라 아키텍쳐 구성요소로 비즈니스 이벤트와 같은 자극에 반응하는 이벤트 중심 서비스를 제공한다.
  • 전송 서비스(Transport services) 는 메시지 전달 보증 레벨이 다양한 동기화, 비동기화 메시지 전달에 관한 유무선 네트워크 전반에 걸친 통신 서비스를 제공해 위치 및 프로토콜 독립성을 규정한다.
  • 중재 서비스(Mediation services) 로 동적 공중 메시지 변환, 동적 라우팅 및 서비스 결합 확인 서비스가 이루어진다.

연결, 라우팅 및 변환과 같은 기능이 없이는 SOA 통합 방식이 진행되지 않는다. 위의 기능들은 WebSphere 통합 레퍼런스 아키텍쳐 내의 ESB를 통해 이루어지고 솔루션 아키텍쳐의 근간을 형성한다. ESB는 많은 경우 통합 구성요소에 관한 접근기능을 제공하는 기존 미들웨어 및 최근 나온 미들웨어를 이용해 실행된다.

비즈니스 로직 서비스(Business logic services)

비즈니스 로직 서비스는 서비스 종점의 형태로 비즈니스 로직을 구현하는 데 필요한 기능들을 제공한다. 서비스 종점 구현은 광범위한 통합 아키텍쳐에 있어 중요한 부분이다. 기존 애플리케이션의 조합, 새로 구현된 구성요소 및 제 3자 체계에 외부 연결 등을 통해 여러 서비스를 제공하기도 한다.

  • 파트너 서비스(Partner services) 는 여러 다른 수송업체에 있는 파트너들과 거래하고 문서 포맷을 사용하면서 제공되는 서비스 종점 통합기능을 제공한다. 이 서비스 층은 외부 파트너 및 공급업체와의 기존 B2B 파트너 통합 솔루션 지원기능을 제공하며 크로스 엔터프라이즈 상호작용 인식이 분리된 아키텍쳐 구성요소다. 이와 같은 서비스는 문서, 프로토콜 및 비즈니스 간 프로세스 및 상호작용을 효율적으로 수행하는 데 필요한 파트너 관리 서비스를 제공한다.
    • 커뮤니티 서비스(Community services) 로 파트너 자체 관리 및 거래 중심 커뮤니티 관리기능이 이루어진다.
    • 문서 서비스(Document services) 를 통해 문서 서비스 관련 상태 관리 기능 뿐만 아니라 RosettaNet, EDI 및 AS1/AS2와 같은 비즈니스 프로토콜을 지원함으로써 대화 프로세스를 지원한다.
    • 프로토콜 서비스(Protocol services) 는 인증, 문서 라우팅 및 자동 문서 상호교환을 위한 에지 서비스 기능을 포함한 전송 단위 서비스를 제공한다.
  • 비즈니스 애플리케이션 서비스(Business application services) 는 Java로 코드화 되고 애플리케이션 서버 환경에서 작동하는 사용자 애플리케이션 구성요소로서 개발된 통합 구성요소에 관한 J2EE 실행 시간 환경을 제공한다. 이 서비스 층은 J2EE, XML 및 웹 서비스 프로그래밍 모델로 개발된 사용자 애플리케이션 구성요소 관리를 위한 프레임웍 및 실행시간 작동 환경을 제공한다. 비즈니스 애플리케이션 서비스는 또한 오늘날 비즈니스 환경의 요구조건을 충족시키는 최신식 비즈니스 프로세스를 수행하는 데 필요한 새 기능을 제공한다. 상기 서비스를 WebSphere 통합 레퍼런스 아키텍쳐 내의 서비스로 수행하면 신 통합 솔루션 전체를 직접 재사용하게 된다. 이 서비스에는 고차원 자율 운영 및 관리기능이 이루어지는 실행시간 통합기능 뿐만 아니라 지속적이고 탄력적이고 재사용 가능한 비즈니스 로직 구성요소를 구축하는 데 있어 기존 프로그래머에게 중요한 기능 등을 포함한다. 비즈니스 애플리케이션 서비스 층의 서비스 기능은 다음과 같은 것을 포함한다.
    • 구성요소 서비스(Component services) 객체 영속성, 관계성 네비게이션 및 J2EE 구성 내의 객체 질의 및 거래 관리와 같은 문제를 자동적으로 다루는 실행시간 컨테이너 관리 서비스를 제공한다.
    • 코어 서비스(Core services) 는 메모리 관리, 객체 인스턴트화 및 풀링, 성능관리 및 로드 밸런싱, 이벤트 공지, 유용성, 디렉토리 및 안정성과 같은 실행시간 서비스를 J2EE, XML, 메시징 및 웹 서비스 프로그래밍 모델의 일부기능으로 제공한다.
    • 인터페이스 서비스(Interface services) 는 데이터베이스, 메시징 시스템 및 관리 구성 및 기업 애플리케이션과의 쌍방향 통합 서비스를 제공한다.
  • 애플리케이션 및 정보 액세스 서비스(Application and information access) 는 이종 데이터 소스(RDBMS, XML, 비-RDBMS 데이터 소스와 유사함, 예, IMS, 텍스트 파일 및 컨텐츠 관리 시스템)뿐만 아니라 제3자 애플리케이션(예, ERP, CRM), 메인프레임 인터페이스 (예, CICS, iSeries), 사용자 애플리케이션(메시징, 애플리케이션 프로그래밍 인터페이스, 데이터 핸들러와 같은 기술 브리지를 통한 애플리케이션)과 상호 작용하는 기능을 제공한다. 이 서비스 기능 층은 거래 서비스 및 데이터베이스, 메시징 시스템 및 기타 데이터 소스에 대한 연결서비스를 지원하는 기존 애플리케이션 및 데이터에 액세스 인터페이스를 규정한다. 기존 호스트 기반 애플리케이션 및 기업 데이터는 액세스 서비스 구성을 통해 ESB에서 처리된다. 이와 같은 액세스 서비스는 레거시 애플리케이션, 사전 패키지화 된 애플리케이션, 기업 데이터 저장창고(XML, 텍스트 및 컨텐츠 관리 시스템과 같은 관계적, 계층적, 특수적, 비구조화 소스)및 ESB간의 브릿징 특성을 제공한다. 애플리케이션 및 정보 액세스서비스 층으로 웹 페이싱, 커뮤니케이션 단위 통합, 메시징 및 웹 서비스 작동과 같은 다중 실행시간 솔루션 패턴을 통해 메인프레임 통합을 규정한다. 애플리케이션 및 데이터 구현작업이 비즈니스 프로세스에 있어 점점 더 복잡한 인자로 자리잡음에 따라 이 작업의 중요 운영환경 기능이 향상되면서 계속 유용도가 증가하고 있다. 애플리케이션 및 정보 액세스서비스 층에서 다음과 같은 서비스가 분리되어 작동된다.
    • 이벤트 감지 서비스(Event detect services) 는 특수 애플리케이션/데이터 소스 인터페이스를 통해 구현되는 이벤트 프레임웍에 근거한 이벤트 공지 서비스를 제공한다. 예를 들어, CRM 시스템에서 새로운 고객의 창출로 인해 ESB에서 가입자에게 공급한 이벤트를 이벤트 감지 서비스에 발생시킨다.
    • 온-램프 서비스(On-ramp services) 에서는 편도 인바운드, 질의-응답을 포함한 애플리케이션 통합패턴을 이룩하고 응답 메시지 패턴을 통해 질의수행계획 및 데이터 검색을 포함한 애플리케이션 및 데이터 래퍼 기능을 지원해 결국엔 데이터 통합기능을 지원한다. 예를 들어 비즈니스 프로세스에서 한 스텝에 순서를 업데이트해야 할 경우 순서 데이터가 있는 메시지는 ESB를 통해 긍정응답 회신이 되는 메인프레임 CICS 애플리케이션에 전송된다.

제어 서비스(Control services)

제어 서비스는 WebSphere 통합 레퍼런스 아키텍쳐 내에 있는 사람, 프로세스, 정보를 효과적으로 통합하는 기능을 제공하며 사람들간의 상호작용 및 데이터, 프로세스, 그리고 비즈니스 프로세스의 개발 및 실행시간 구현에 적합한 정보 서비스 간의 흐름을 제공한다.

  • 상호작용 서비스(Interaction services) 는 여러 기능 및 데이터를 최종 사용자에게 전달하는 데 필요한 기능을 제공함으로써 최종 사용자의 특수 사용 선호도를 만족시킨다. 이 서비스는 또한 여러 가지 보급장치(예: 센서, 작동기)와 통합 시스템의 기타 구성요소를 통합시키는 데 필요한 기능도 제공한다. 상호작용 서비스 층은 브라우저 및 음성 상호작용을 포함한 사용용도 및 보급장치통합에 관한 외부 상호작용서비스를 제공한다. 상호작용 서비스의 일부로 다음과 같은 서비스가 제공된다.
    • 전달 서비스(Delivery services) 로 사용자가 포틀릿, 음성 및 퍼베이시브 메시징을 통해 통합 구성요소와 상호작용하는 실시간 상호작용 프레임웍이 이루어진다. 이런 기능 구성은 모바일/원격 사용자/장치 상호작용을 지원하는 무선 기술로의 통합기능 뿐만 아니라 다중-장치 지원, 페이지 수집, 마크업 전이 부호, 언어 번역 및 국제화 등을 포함한다.
    • 익스피리언스 서비스(Experience services) 는 개인화, 공동작업, 인증, 인가, 자체-서비스 기능(주문생산 및 등록) 및 싱글사인온 기능을 포함한 강력한 사용자 익스피리언스 전달에 해당되는 사용자 중심 서비스를 제공한다.
    • 자원 서비스(Resource services) 는 상호작용 구성성분 지원기능으로 인한 실행시간관리기능(예를 들면 페이지, 테마/스킨, 원칙 및 포틀릿과 같은 구성요소를 통한 안전성 및 자격)을 규정한다.

  • 프로세스 서비스(Process services) 는 비즈니스 프로세스를 수행하는 서비스들 간의 흐름 및 상호작용을 관리하는 데 필요한 제어서비스를 제공한다. 프로세스 서비스 층은 통합 구성요소의 수집을 통해 프로세스 수행을 중개하는 기능을 제공해 복잡한 비즈니스 기능을 지원한다. WebSphere 통합 레퍼런스 아키텍쳐 내에서 여러 서비스의 통합을 설명하기 위해 BPEL4WS표준을 활용한다. 프로세스 서비스 내에서 다음과 같은 서비스를 제공한다.
    • 구성 서비스(Choreography services) 는 기타 여러 서비스로 이루어져 있다. 따라서 구성 서비스는 정의된 순서에 따른 기타 서비스 수행 및 에러 복구 기능을 제공한다.
    • 트랜잭션 서비스(Transaction services) 는 단기 운영 프로세스 및 장기 운영 프로세스에 대한 에러 복구기능을 제공한다. 전 과정이 트랜잭션(단기운영 프로세스)과 연관될 수 있다. 장기 운영 프로세스의 경우 각 서비스는 데이터가 변하는 경우 트랜잭션으로 취급된다.
    • 스태프 서비스(Staff services) 로 사람을 프로세스로 통합하게 되고 스태핑 디렉토리에 있는 규칙 및 정보에 근거한 업무 항목을 창출한다. 이 서비스는 상호작용 서비스와 함께 태스크 할당, 델리게이션 및 관리기능을 지원한다.

  • 정보 서비스(Information services) 는 구조화된 데이터 소스(RDMBS 또는 IDMS 또는 VSAM과 같은 기타 데이터 소스) 또는 비구조화 데이터 소스(스프레드시트, 텍스트 파일, 문서 포맷, 유사 Adobe PDF와 같은 데이터 소스)를 통합, 복제, 분석, 변환하는 기능을 제공한다. 정보 서비스 층은 이종 데이터 소스에 관한 데이터 통합 및 수집기능을 제공한다. 따라서 분산 최적화 선진기술을 사용해 다중 데이터 컨텍스트에 접근하게 된다. 정보 서비스 층 내에서 다음과 같은 서비스가 제공된다.
    • 협업 서비스(Federation services) 는 데이터 저장 장소를 제어하는 가운데 데이터를 남기는 동안 기존 데이터 소스(RDBMS와 같은 데이터 소스) 및 새 데이터 소스(XML, 데이터 저장소, 텍스트 데이터 및 컨텐츠 저장소)로부터 데이터를 수집하는 기능을 제공한다.
    • 복제 서비스(Replication services) 는 자동 실행시간 데이터 동기화 및 구조 데이터 소스의 소스/타깃 변환기능을 지원하며 이에 따라 소스 구현과 관련 없이 데이터 처리를 위한 액세스 지역성을 이룩한다.
    • 변환 서비스(Transformation services) 는 배치 및 기록 지향 액세스/변환 시 데이터를 소스 포맷으로부터 타깃 포맷으로 변환하는 기능을 가진다.
    • 탐색 서비스(Search services) 로 통상적 데이터 소스(데이터베이스 및 구조화 데이터 소스) 및 특수 데이터 소스(PDF, 스프레드시트, 워드 프로세싱 문서 등과 같은 데이터 소스)를 통해 질의 및 탐색 통합을 완전히 이루게 된다.

개발 서비스(Development services)

WebSphere 통합 레퍼런스 아키텍쳐의 경우 광범위한 소프트웨어 개발 플랫폼을 핵심기능으로 갖추어야 한다. 소프트웨어 개발 플랫폼이 요구조건 분석, 모델링 및 디자인, 구성요소 개발, 테스팅 및 코드 유지성을 포함한 소프트웨어 개발의 전 과정을 포함한다는 사실은 중요하다. 이에 따른 개발 툴링은 MDA(모델 중심 아키텍쳐)의 개념과 일치하고 SOMA(서비스 지향 모델링 아키텍쳐) 및 SODA(서비스 지향 애플리케이션 개발)을 통해 최근 나타난 최상의 서비스 사용기능을 지원해야 한다. IBM 소프트웨어 개발 플랫폼에서 이와 같은 특성은 늘 있다.

고급 레벨에서, WebSphere 통합 레퍼런스 아키텍쳐 내의 개발 서비스로 사람들은 특수 태스크를 완수하고 기업 내의 스킬, 전문적 지식 및 역할에 근거한 특수 출력자료를 창출한다고급 레벨에서, WebSphere 통합 레퍼런스 아키텍쳐 내의 개발 서비스로 사람들은 특수 태스크를 완수하고 기업 내의 스킬, 전문적 지식 및 역할에 근거한 특수 출력자료를 창출한다.

  • 비즈니스 프로세스 요구조건을 분석하는 비즈니스 분석가들은 비즈니스 프로세스를 설계하고 시뮬레이션 할 모델링 툴이 필요하다.
  • 소프트웨어 설계자는 데이터, 기능 흐름 및 시스템 상호작용을 모델화하고 시스템 토폴로지를 개발시킬 툴이 필요하다.
  • 통합 전문가들에게는 통합 솔루션 개발 시 구성요소를 구성, 통합하는 기능이 반드시 필요하다.
  • 프로그래머들에게는 J2EE 구성요소, 포틀릿 및 기타 사용자 서비스 구성요소와 같은 새로운 비즈니스 로직을 개발할 툴이 필요하다.

통합 툴링 환경으로 공동개발, 자산관리 기능 및 자산 처리 및 자산 공유를 통한 개발 역할들간의 공동 협업 기능이 도모된다는 점이 가장 중요하다. 조직의 툴 기술 및 역량은 다중 벤더에서 발생하며 이로 인해 개발과정 시 이종 역할에 관한 학습곡선을 줄이는 데 있어 Eclipse와 같은 멀티벤더 프레임웍이 필요하다는 것을 인식하는 것이 중요하다. 게다가 Eclipse와 같은 표준 툴 프레임웍은 모든 개발자 퍼스펙티브에 걸친 공통 리파지토리 및 공통 베이스 기능을 제공한다 (예를 들어 CVS 및 ClearCase와 같은 다양한 제어기능, edit, file 및 인쇄 서비스와 같은 유틸리티 기능). WebSphere 통합 레퍼런스 아키텍쳐를 통해 제공되는 개발 서비스는 서비스 수행 시 Eclipse 베이스에 작용하게 된다.

특수 개발 역할과 상관없이 각각의 역할이 생산적이고 효율적이기 위해선 소프트웨어 개발 시 높은 단위의 협업이 필요하다. 개발 툴 플랫폼은 역할기반 활동 및 멀티 벤더 툴 환경 전반을 통해 통합 개발영역을 다루는 통합 툴 구성을 제공한다. 인식의 분리를 개발 과정에 적용시키면 각각의 역할에서 개인 기술 및 임무에 특정한 객체를 설계, 개발, 전개하게 된다. 개발 서비스 구성의 일부로 수많은 서비스 기능들이 나오게 된다.

  • 모델 서비스(Model services) 는 분석가들이 비즈니스 프로세스를 대표하는 비주얼 모델을 구축하는 기능을 제공한다.
  • 디자인 서비스(Design services) 로 모델을 디자인하게 된다. 이 서비스는 디자인 프로세스를 서비스 구성요소로 귀착시키는 기능을 포함한다. 게다가 이런 기능 구성으로 새로운 통합 구성요소의 설계 및 개발이 이루어진다.
  • 실행 서비스(Implementation services) 로 개발 객체가 조직의 구성 관리 기준의 일부로 생성되는 기능이 이루어진다.
  • 테스트 서비스(Test services) 는 전체 개발과정의 일부로 통합 테스트 및 단위 테스트를 지원하는 기능을 제공한다.

비즈니스 개발 및 최적화 서비스

위에서 언급된 많은 서비스와 함께 비즈니스 개발 및 최적화 서비스는 계속적인 비즈니스 향상 및 개발을 위한 기반구조를 제공하고 이로 인해 비즈니스는 변화하는 시장동향 및 매일의 비즈니스 운용 변화에 적응하게 된다. 공학적으로 잘된 BPM 솔루션은 전체론적 비즈니스 경영방식을 지원하며 이에 따라 정렬 객체, 역할기반 가시성, 컨텍스트 통찰력 및 지정 시간 액션기능이 이루어진다. 여기서 BPM은 비즈니스 및 IT 프로페셔널의 요구사항을 지원하고 구체화시키는 차별화 된 기능 구성이 필요하다는 점을 알아두는 게 중요하다.

공통 베이스 이벤트(CBE) 사양은 WebSphere 통합 레퍼런스 아키텍쳐에 관한 공통 베이스 이벤트 모델을 제공한다. 파트너 서비스와 함께 IBM 자율 팀에 의해 개발된 공동 베이스 이벤트는 이벤트에 관한 공통 XML 스키마 기반 표현을 정의한 최근의 OASIS 표준으로 로깅, 추적, 관리 및 비즈니스 이벤트의 코드화를 지원한다.

WebSphere 통합 레퍼런스 아키텍쳐 내에서 BPM 서비스는 세 가지 주요 서비스로 이루어져 있으며 각각의 서비스는 IT 및 비즈니스 이벤트를 지원한다.

  • 공통 이벤트 기반구조(CEI) 서비스(Common event infrastructure services) 는 원시 이벤트를 CBE 형태로 필터링하고 변환하는 방사 서비스, 이벤트를 저장, 질의, 관리하는 이벤트 저장 서비스 및 이벤트 방식을 저장, 질의, 관리하는 이벤트 카탈로그 서비스 등을 제공한다.
  • 상관관계 서비스(Correlation services) 는 정책중심 필터링 기능 및 이벤트의 상관관계를 제공해 관심상황을 탐지한다.
  • 모니터링 서비스(Monitoring services) 는 관찰 모델을 사용해 적절한 모니터링 컨텍스트, 컨텍스트에 대한 맵을 정의하고 이와 관련된 성능 측정값 및 주요 성능 지표(KPI)를 계산하고 관리한다.

상호작용 서비스를 이용해 메트릭 및 KPI계 표현이 이루어지게 된다. 이와 비슷하게 정보 서비스를 이용해 BPM 솔루션을 지원하는 데 필요한 분석 데이터 기법을 제공하게 된다.

개발 플랫폼 및 비즈니스 개발 및 최적화 서비스 간의 연관이 WebSphere 통합 레퍼런스 아키텍쳐에 있어 주요 특징이 된다. 모델링 환경의 일부로 주요 성능 지표의 특성을 나타내고 프로세스 모델의 일부로 특수 이벤트 플래그를 발생시키는 경우 비즈니스 분석가들은 관리기능성을 자신들만의 비즈니스 프로세스에 구축한다. 통합 구성요소를 구현한 다음 BPM 층은 이벤트 데이터 및 통계를 기록, 전달하는 기능을 제공하며 이 기능은 다시 모델링 환경으로 들어가게 된다. 이와 같은 접근 방식으로 기업 내 조직들은 연속 비즈니스 프로세스 향상 사이클을 통해 반복적 과정 재공학화 기능을 지원하게 된다.

IT 서비스 관리(IT services management)

WebSphere 통합 레퍼런스 아키텍쳐의 모든 기능에서 제일 밑을 보면 안전성, 디렉토리, 시스템 관리 및 자원의 가상화에 관한 관리 서비스가 있다. 안전 디렉토리 서비스는 예를 들면 분산 이종 시스템 전반에 걸친 단일 사인 온 기능과 같이 서비스 수행 시 필요한 인증 및 인가 기능 등을 포함한다. 시스템 관리 및 가상 서비스는 서버, 기억장치, 네트워크 및 기타 자원 관리 시 운영환경 전반에 걸친 기능을 포함한다. 예를 들면 클러스터링 가상화 서비스로 로드 패턴 및 다른 인자에 근거한 계산 자원의 효율적인 활용이 이루어지게 된다. 그리드 컴퓨팅 플랫폼의 일부로 그리드에 작용하는 기능은 IT 서비스 관리 기능의 통합 기능이다. 한편 수많은 관리 서비스는 하드웨어 및 소프트웨어 구현과 직접적으로 연관된 기능을 수행하는 반면 기타 관리 서비스는 ESB를 통해 아키텍쳐의 다른 요소에 제공되는 통합 서비스와 직접 상호작용하는 기능을 제공한다. 이와 같은 상호작용은 대개 지원 운영환경의 일부로 안전성, 디렉토리 및 IT 운영체계관리와 연관된 서비스를 포함한다.

하드웨어 및 소프트웨어 관리 서비스는 기업 시스템을 효과적으로 작동, 운영하는 데 필요한 기능을 제공한다. 하드웨어 및 소프트웨어 관리 서비스들은 대개 기타 통합서비스와는 독립적이며 나머지 경우엔 기타 통합 서비스에 여러 기능 및 데이터를 제공해 비즈니스 성과 관리 및 시스템 운영을 효율적으로 이룬다.




위로


실행 중의 WebSphere 통합 레퍼런스 아키텍쳐

그림 3에서 구매 순서 프로세싱은 단 대 단 복합 통합 프로세스다. 이에 해당되는 솔루션은 WebSphere 통합 레퍼런스 아키텍쳐의 구성 서비스를 통해 통합될 서비스 순서를 나타낸다.


그림 3. WebSphere 통합 레퍼런스 아키텍쳐에서의 서비스 호출과정
Figure 3.  Service invocation in the WebSphere Integration Reference Architecture

개발 툴 및 IT 서비스 관리는 그림에 나타나지 않았다. 개발 툴 및 관리 서비스는 통합 구성요소 개발에 관한 지원기능 및 중요 운영 실행시간 프레임웍 관리기능을 각각 제공한다. SOA-기반 비즈니스 통합 방식 및 개별 통합 객체를 독립적으로 개발하고 통합해 전체 솔루션을 제공한다. 이렇게 하면 대결합 애플리케이션으로 통합 솔루션을 구식으로 개발하는 데 있어 탈피하는 주요 인자를 제공하게 된다. 또한 개발 구성요소(어댑터 서비스 또는 파트너 프로파일 서비스와 같은 구성요소)중 어떤 것도 구매 주문 프로세스 운영과정에 작용하지 않고 다시 재사용될 수 있다. WebSphere 통합 레퍼런스 아키텍쳐로 기업 내의 조직들은 주문형 컴퓨팅으로 인한 과제를 해결하기 위한 통합 기술 애플리케이션에서 더 전략적으로 변해간다.

패턴: 서비스-지향 아키텍쳐 및 웹 서비스 (M.Endrei 및 그 외, 2004)라는 기사에서도 논의 논의되었듯이 "주문형 운영 환경은 공통 표준 및 개방형 기술을 이용해 애플리케이션을 통합시키는 데 필요한 기반구조를 제공한다." 이는 통합 프레임웍의 주요 원칙이다. 통합 프레임웍은 WebSphere 통합 레퍼런스 아키텍쳐를 통해 작동된다. 공통 표준 및 개방형 기술을 고수하는 것이야말로 IBM 통합방식의 근간이 되고 있다. 밑의 표에선 WebSphere 레퍼런스 아키텍쳐에 존재하는 일부 주요 표준 및 기술에 대해 나와 있다.


표1. WebSphere 통합 레퍼런스 아키텍쳐 표준 및 기술
서비스 기능 관련 표준
기업 서비스 버스JMS, J2EE, SOAP, XSLT, WSDL, UDDI
개발 툴Eclipse, J2EE, J2SE, J2ME, XML, UML, 자바 서버 페이스(Java Server Faces), SWT, XMI, WS BPEL, SQLJ, JDBC, XSLT, WSDL, UDDI
비즈니스 성능 관리 툴W3 공통 로그 포맷(W3 Common Log Format), WS DM initiatives, CEI/CBE
상호작용 서비스(Interaction services)WSRP, JSR 168, 자바 서버 페이스(Java Server Faces), VoiceXML, J2EE
프로세스 서비스(Process services)J2EE, BPEL4WS, WSDL, UDDI
정보 서비스(Information services)XQuery, SQL, JDBC/ODBC
파트너 서비스(Partner services)FTP, sFTP, HTTP, HTTP/S, RosettaNet, SMTP, JMS, SOAP/HTTP, WMQ, cXML, EDI (X12, EDIFACT를 포함한 기타)
비즈니스 애플리케이션 서비스J2EE (JNDI, EJB, JSP, JTA, JAAS, JAXP, JAXR, JMX 및 기타)
애플리케이션 및 정보 서비스J2C, JMS, IIOP, JDBC, CICS, IMS, 3270/5250

게다가 ACORD, SWIFT, HIPAA, UCCNET 및 기타 주요 종단 프레임웍 방식과 같은 솔루션 프레임웍 내에 비즈니스 산업 표준이 반영되어 있다. 여러 표준을 고수하는 것이야말로 IBM 통합방식을 탄력적이고 지속성 있는 기업 통합 아키텍쳐로 구축하는 주요 요인이 되고 있다.

IBM의 WebSphere 통합 레퍼런스 아키텍쳐는 비즈니스 산업에 있어 가장 광범위한 통합 프레임웍을 제공한다. 이 아키텍쳐는 기존 프로그래밍 개발 솔루션을 지원할 뿐만 아니라 서비스 지향 통합 솔루션을 개발하는 데 있어 광범위한 지원기능을 한다. 이와 같은 SOA에 대한 지원기능은 IBM 소프트웨어 개발 플랫폼에 있는 MDA에 관한 산업 선도 지원기능에서 시작되며 결국 IBM WebSphere 애플리케이션 서버 및 IMB WebSphere MQ내에 있는 WebSphere 파운데이션 기술에서 구현된다. 전체 WebSphere 통합 레퍼런스 아키텍쳐는 SOA 개발을 지원하는 기존 표준 및 최근 표준과 밀접하게 연관되어 있다. 그리고 WebSphere 통합 레퍼런스 아키텍쳐는 모든 주요통합체제를 지원하는 기능을 제공해 사람, 프로세스 및 표준 기반 파운데이션 상에 있는 정보를 연결함을 인식하는 게 가장 중요하다. 이밖에 WebSphere 통합 레퍼런스 아키텍쳐는 개발 및 구현을 통해, 완전한 개발 플랫폼의 일부로 비즈니스 및 IT 메트릭 모니터링을 하는 것을 통해 주기 모델링을 충분히 지원한다.




위로


결론

WebSphere 통합 레퍼런스 아키텍쳐로 기업은 서비스 지향 아키텍쳐 파운데이션을 통해 비즈니스 요구조건 및 기술 솔루션 간에 밀접한 연관관계를 형성시킨다. 이 아키텍쳐를 적용하고 "인식의 분리" 라는 개념을 사용하면 기존 통합방식에 대한 명쾌한 통합대안을 제공하게 된다.

세 가지 주요 개념인 MDA, SOA 및 BPM은 WebSphere 통합 레퍼런스 아키텍쳐의 기초를 제공한다. MDA를 구체화한 역할 기반 개발 툴링에 관한 공통 프레임웍으로 통합 객체 설계 및 개발이 이루어지게 된다. 이 객체를 테스트하고 이를 실행시간 환경으로 전개한다. 그리고 통신기반구조는 기업 서비스 아키텍쳐를 통해 제공된다. 이와 같은 통합 구성요소로 성능, 범위성, 안정성 등등에 관한 SOA 기반 공통 핵심 기반구조 서비스 구성에 작용하게 된다. 결국 이 같은 실행시간 구조를 겹치게 하면 BPM을 구체화한 광범위한 모니터링 및 관리 환경이 만들어진다.

간단히 말해서 WebSphere 통합 레퍼런스 아키텍쳐는 기업 내의 수많은 통합 요구를 다루는 완전하고 광범위한 아키텍쳐다. 통합 서비스를 분명히 정의하고 모듈러 식으로 전송해 조직 전반에 걸친 재사용 및 공유능력을 도모한다. 한편 새로운 프로젝트를 수행할 시 서비스들을 쉽게 부가하거나 확장해 기업 통합운동 영역 및 효율성을 높인다. WebSphere 통합 레퍼런스 아키텍쳐로 기업 내의 조직들은 서비스 지향 기업통합방식을 취하며 기존 기업통합방식과 관련된 단점들을 없앤다.




위로


감사의 글

저자는 WebSphere 통합 레퍼런스 아키텍쳐 창출 및 발전에 관한 Worldwide WebSphere Technical Sales Team의 연구에 관해 감사를 표하고 싶고 특히 Bill Hassell, Bob Liburdi 및 Bob Knaus씨의 수고에 고마움을 표한다. 아울러 본 논문을 쭉 교정해 준 IAM사의 비즈니스 통합 CTO인 Dan Wolfson 씨에게도 감사의 말을 전하고 싶다.




위로


참고자료

  • Participate in the discussion forum.

  • M Endrei (and others) Patterns: Service-oriented Architecture and Web Services (Redbook), IBM TSO, 2004.

  • C Perks and T Beveridge Guide to Enterprise IT Architecture Springer-Verlag, New York, 2003.

  • G Booch et al. An MDA Manifesto MDA Journal May 2004.

  • M Keen and others Patterns: Implementing an SOA using an Enterprise Service Bus IBM Redbook SG2463, July 2004.

  • IBM Service-Oriented Modeling and Architecture, IBM Business Consulting Services Overview, 2004.



위로


필자소개

Scott Simmons 는 Worldwide WebSphere Integration Technical Sales Support 팀의 IT 아키텍트이다.





위로


기사에 대한 평가

매우 불만족 (1)
불만족 (2)
보통 (3)
만족 (4)
매우 만족 (5)




위로



    IBM 소개개인정보 보호정책문의