[펌: developerWorks ] SOA 솔루션에 레거시 시스템 전략 적용하기 (한글)

2007 년 8 월 21 일

서비스 지향 아키텍처(SOA)는 많은 비즈니스 변형 노력의 중심에 있습니다. 많은 기업들은 점증적으로 SOA로의 변형을 시도하고 있고, 귀중한 레거시 IT 시스템들을 서비스 공급자로서 참여시키고 있습니다. 솔루션 아키텍트는 변형을 도모하는 수단으로서 SOA 인프라스트럭처를 제공해야 할 뿐만 아니라, 기업 중심의 비즈니스 연산들을 강력하고 순응적인 것으로 유지해야 하는 도전에 직면해 있습니다. 여러분의 기업은 SOA의 일부가 될 수 있는 엔터프라이즈 정보 관리 전략을 개발하고 모든 비즈니스 연산에서 전체적인 데이터 및 콘텐트 일관성을 관리해야 합니다. 이와 같은 변화 과정에 대해 알아보고 디자인 전략을 공부해 봅시다.

머리말

여러분의 비즈니스가 거의 비슷하다면, 비즈니스 전략과 핵심 경쟁력 분석은 비즈니스 리엔지니어링과 IT 현대화에 초점을 맞춰야 한다. 일반적인 산물이(엔터프라이즈의 핵심 측면에서 볼 때) 서비스 지향 비즈니스로의 변형 및 SOA에 대한 의존성이다. 비즈니스 연산은 현재 IT 시스템이 재 엔지니어링 되고 서비스 공급자로서 통합되어야 하는 서비스 세트를 중심으로 설계된다. 변형 역시 새로운 서비스 공급자를 도입한다. 목표는 내부 워크플레이스 포털 애플리케이션 또는 인터넷 커머스 애플리케이션 같은 새로운 복합 애플리케이션들을 구현하여 특수한 비즈니스 필요를 채우는 것이다.

이렇게 도전이 되는 변형의 일부로서, 엔터프라이즈는 많은 중요한 비즈니스와 IT 프로그램에 개입되어 있다. 주요한 변형에는 다음이 포함된다.

• 비즈니스 서비스 모델 중심의 엔터프라이즈 아키텍처 정렬.
• 비즈니스 서비스 모델의 관련 부분들을 실현할 수 있는 서비스 기반 IT 인프라스트럭처의 도입.
• 레거시 IT 시스템이 변형, 확장, 래퍼 적용을 통해 서비스 기반 IT 인프라스트럭처로 통합될 수 있도록 함.
• IT 애플리케이션들을 지원하는 효율적이고 유연한 구현을 가능케 하는 강력한 디자인 및 개발 환경 및 딜리버리 프로세스.

이러한 변형의 산물들은 구현상의 문제를 만들어 낸다. 엔터프라이즈는 변형의 의도를 전달하고 변화를 적용하여 유연성을 실현할 수 있는지를 확인해야 한다. 이러한 변형 노력은 다음의 원리를 따른다.

• 엔터프라이즈는 강력하고 순응적인 비즈니스 연산을 제공해야 한다.
• 전체 비즈니스 서비스 모델과 IT 시스템 구현이 변형 원리에 순응할 수 있도록 하는 거버넌스 프로세스와 디자인 권한이 필요하다.
• 엔터프라이즈는 비즈니스와 IT 서비스 관리의 통합적인 뷰를 통해 측정과 응답성 변화가 이루어 질 수 있도록 해야 한다.

일부 엔터프라이즈는 전체 조직에 걸쳐 SOA로 비즈니스 변형을 할 수 있다. 이러한 방식은 기본적인 변형 인도물에 대한 더 큰 도전을 시사하고 있지만, 결과적으로, 부차적인 변형 인도물을 성장시키고 개발하기에는 더 쉽다. 이러한 유형의 시나리오는 엔터프라이즈에 비즈니스 및 IT 변화를 이룩하고자 하는 최고위 간부들이 전략적인 문제를 지원하기로 결정할 때 발생한다.

그러나, 대부분의 엔터프라이즈 변형은 점증적이고 거대하며 전략적이다. 레거시 IT 시스템들은 리엔지니어링 되어, 다른 IT 시스템들을 결합하여 고객 주문 프로세싱을 단순화 하는 등, 새로운 비즈니스 연산 지원에 참여할 수 있어야 한다. 이러한 IT 시스템들은 현재 갖고 있는 모든 또는 대부분의 기능을 계속해서 수행한다. SOA 변형의 범위 밖에서의 비즈니스 연산들도 여전히 지속된다.

변형 시나리오에서, SOA IT 인프라스트럭처에 대해 신중한 구현 디자인을 모색해야 한다. 이러한 IT 시스템 내에서의 데이터 프로세싱은 이 범위 밖에서의 데이터 프로세싱에 영향을 주고, 이 프로세싱에 의해 영향을 받는다. 전체적인 데이터 프로세싱 환경은 전체 비즈니스 연산에 대하 강력함과 순응성을 유지해야 한다.

그림 1의 예제는 세 개의 레거시 시스템들이 서비스 프로바이더가 되도록 엔지니어링 되는 모습을 보여준다

그림 1. 새로운 SOA 환경에서의 레거시 IT
 

그림 1에서, 비즈니스 변형 프로그램이 SOA 인프라스트럭처를 구현했고, 비즈니스 서비스들은 여기에서 퍼블리시 되고 새로운 애플리케이션에 의해 소비될 수 있다. 이러한 인프라스트럭처에는 일반적으로, 소프트웨어 간 다중 프로토콜 연결, 비동기식 및 동기식 메시지 플로우 관리, 메시지 트랜슬레이션, 규칙 실행, 프로세스 구성법을 실행하는 미들웨어가 포함된다. 이러한 서비스들을 사용하는 복합 애플리케이션들이 구현되었고, 레거시 시스템들은 새로운 서비스들을 호출함으로써 강화되었다.

SOA에서의 프로세스와 정보 아키텍처

SOA 인프라스트럭처를 구현하기 위해, 비즈니스 서비스 모델(business service model)이 생성, 관리, 향상된다. IBM® Service Oriented Modeling and Architecture (참고자료) 같은 기술들은 이러한 모델을 개발하는데 사용된다. 전형적인 엔터프라이즈에서, top-down 분석, bottom-up 분석, 목표 서비스 모델링이 포함된다. 변형의 목표는 새로운 비즈니스 연산과 지원하는 IT 애플리케이션들의 구현을 실행하는데 사용되는 프로세스 및 정보 아키텍처로 귀결된다.

• 프로세스 아키텍처는 엔터프라이즈 연산을 받치고 있는 비즈니스 프로세스를 형성하기 위해 결합될 수 있는 액션의 기능적 계층이다. 인간 대 시스템, 시스템 대 시스템의 플로우 컨트롤을 책임진다. 예를 들어, 고객이 제품 주문을 하고 그 제품의 전달을 기다리는 상태가 되는 동안 필요한 액션들이 포함된다.
• 정보 아키텍처는 엔터프라이즈 연산에 상태와 의미를 제공하기 위해 액세스, 조작, 저장되는 관련 데이터 및 콘텐트 세트이다. 데이터 및 콘텐트의 정보 관리를 수행한다. 단순한 액세스 이벤트나 프로세스 플로우 정황이든 상관이 없다. 제품 개발 라이프 사이클 동안 소비 및 생성되는 데이터와 콘텐트가 하나의 예이다.

프로세스와 정보 아키텍처 뷰포인트는 프로세스-데이터(CRUD) 매트릭스 같은 것을 통해서 개발 및 제시된다. 이들은 서비스 아키텍처를 구성하는 많은 서비스들을 정의한다. 서비스는 메시지 데이터가 전달된 곳에서 호출되는 연산 세트이다. 서비스 구현은 영속 스토리지나 액세스를 사용하여 데이터나 콘텐트를 조작하는 프로세싱을 수행하고 결과를 리턴한다. 서비스는 동기식 및 비동기식으로 사용될 수 있고, 호출은 통합 인프라스트럭처에 의해 일반적으로 중재된다. 완전히 분리된 시스템에서, 일부 서비스들은 변경 사항들이 상태를 처리하도록 한다. (예를 들어, 요청된 정보가 제공될 때, 고객 X에 대한 새로운 주소의 유효성 검사가 수행된다.) 다른 서비스들은 정보 상태가 바뀌도록 하면서, 데이터와 콘텐트가 향후 서비스 이벤트가 의존할 수 있는 원하는 상태가 되도록 조작한다. (예를 들어, 새로운 선적 주소가 고객 X에 적용된다.)

레거시 데이터 프로세싱 문제

레거시 IT 시스템들은 의심할 여지 없이 엔터프라이즈의 서비스 공급자 구현의 일부이고 SOA 인프라스트럭처로 통합된다. 레거시에는 전통적인 메인프레임 프로세싱 뿐만 아니라, 엔터프라이즈 리소스 플래닝(ERP) 애플리케이션, 내/외부 웹 애플리케이션, 워크플로우 애플리케이션, 스캐닝 및 프린팅 시스템 등이 포함된다. 이러한 레거시 시스템들이 사용되고 서비스-공급자 구현으로 결합되기 위해서는 많은 일들이 발생할 수 있다.

• 프로세싱 함수는 노출되고 액세스 되어 서비스 공급자 구현에 결합된다. 이는 CICS® 트랜잭션의 SOAP 래퍼처럼, 새로운 프로토콜과 호출 메커니즘을 통해 트랜잭션을 노출하는 것을 의미한다.
• 함수들은 트랜잭션을 노출할 때 프로세싱 무결성을 관리하도록 리엔지니어링 되어야 한다. 트랜잭션은 기존에 존재했던 것 또는 한 개 이상의 기존 트랜잭션을 호출하기 위해 생성되어야 한다. 서비스 세분성 전략은 그러한 서비스의 호출 디자인에 영향을 미친다.
• 특정 프로세싱 함수는 데이터 프로세싱이 서비스 공급자 구현을 통해 호출되는 새로운 함수에 의해 수행되기 때문에 스위치를 꺼야 한다.
• 기존 액세스 권한과 보안 및 감사 요구 사항들은 새로운 액세스 메커니즘을 위해 실행되어야 한다.
• 기존 시스템의 서비스 품질(Quality of Service (QoS)) 기준은 확장 또는 보충되어야 한다. 예를 들어, 오프라인 일괄 프로세싱 윈도우는 대리 프로세싱 솔루션에 의해 다루어져야 한다.
• SOA는 기존 시스템에 새롭고 예측할 수 없는 부하를 가져오는데, 이는 기존 프로세스에 부정적인 영향을 미친다.

레거시 IT 시스템들이 SOA에 참여하고자 하는 노력으로 노출될 때, 변형의 범위 밖에서 비즈니스 연산을 지원하는 특정 함수들이 데이터 프로세싱을 지속한다. 여기에는 일반적으로 데이터 동시성과 동기화 문제를 이해하고 다룰 수 있어야 한다.

사용자는 계속해서 원래의 애플리케이션 수단을 사용하여 레거시 IT 시스템을 호출한다. 주로 사용자 인터페이스(메인프레임 터미널 또는 애플리케이션의 UI)를 통해서 호출한다. SOA는 SOA 생태계 주위로 흐르는 메시지를 기술하기 위해 사용되는 데이터 스키마에 의존한다. 이러한 데이터 스키마들은 서비스 연산의 협업 세트 내에서 통합되는 물리적인 데이터 메시지로서 실현된다. 여기에는 런타임 데이터 트랜슬레이션, 의미 매핑, 또는 메시지 데이터의 추가 등이 포함된다. 데이터는 기반 레거시 IT 시스템에 의해 사용 및 처리된다.

SOA에서 실행될 수 있는 프로세스 세트는 특정 상태로 되어 있어야 하는 데이터와 콘텐트에 의존한다. SOA 함수와 레거시 IT 시스템들을 통한 병렬 프로세싱은 상태 모델에 불안정하게 만들 뿐이다.

그림 1의 예제에서, 변형은 고객의 보험 정책을 설정하고 관리하는 단순한 프로세싱 기능을 갖고 있는 새로운 인터넷 애플리케이션을 실행했다. 이 새로운 애플리케이션들은 고객과의 연락을 실행하고 보험 정책이 갱신될 때 갱신 처리를 제공한다. 하지만, SOA 범위 밖에 있는 기존 비즈니스 연산들은 문제를 일으킬 수 있다. 고객들은 거주지를 옮겼던 경로에 따라 회사에 공지할 수 있는 수단이 있다. 새로운 인터넷 애플리케이션을 통해 정책이 처음 구매되었더라도, 고객은 SOA 애플리케이션을 사용하여 회사에 주소 변경을 알리지 않고, 대신 편지를 보낼 수 있다. 백 오피스(back- office) 프로세스는 고객의 새로운 주소가 고객 관리(CRM) 시스템에만 적용되도록 한다. 기존의 CRM 시스템의 일괄 프로세싱이 Insurance Contract Administration 시스템을 고객 데이터로 업데이트 한다. 새로운 SOA 기반 시스템은 거의 실시간 트랜잭션으로 설계되므로, 데이터 동기화 타이밍 문제가 발생한다. 새로운 애플리케이션은 오래된 주소의 갱신에 대해 고객과 연락을 시도할 수 있고, 응답 및 콘텍스트 인식 SOA 애플리케이션이 새로운 주소에 있는 사람에게 연락하여 오래된 정책을 취소하고 새로운 정책을 설정한다

서비스 공급자

SOA 아키텍트의 역할은 서비스 실행 인프라스트럭처의 디자인과 구현과 관련되어 있다. SOA 모델링 기술은 프로세스와 정보 아키텍처가 소비할 서비스를 결정하고, 서비스 공급자와 연락하고, 프로세싱 실행과 데이터 프로세싱의 일부로서 서비스 연산을 호출하는 애플리케이션을 구현할 수 있게 도와준다. 서비스 소비자는 동의된 계약에 따라 데이터를 처리하고 관리하는 한 서비스 공급자가 서비스를 구현하는 방식은 신경 쓰지 않는다.

특정 시나리오에서, 모델이 작동한다. 특히, 여러분이 서비스 공급자 구현을 기업 외부에서 아웃소싱 했을 경우에 그렇다. 이 글에서는 오늘날 많은 기업들이 SOA를 채택하면서 겪게 되는 특수하지만 공통적인 시나리오에 초점을 맞춘다.

현실은, SOA 변형에서 전체적인 솔루션 아키텍트는 많은 책임을 갖고 있고, 특히 점증적인 변형을 해야 하는 기업의 경우 특히 그렇다. 이러한 책임은 기업 거버넌스 프로세스의 영역 안에서 수행된다. ("SOA 거버넌스" [developerWorks, 2005년 8월]).

우선, 솔루션 아키텍트는 SOA 인프라스트럭처의 디자인과 구현에 관련되어 있다. 여기에는 서비스 공급자 구현의 일부를 형성하는 소프트웨어 시스템으로서 작동할 레거시 IT 시스템을 구분하는 것이 포함된다. 두 번째, 솔루션 아키텍트는 서비스 소비 애플리케이션을 조합할 수 있는 개발 프로세스와 환경을 제공한다. 여기에는 디자인 패턴과 표준, 툴링 환경이 포함된다. 셋째, 솔루션 아키텍트는 비즈니스와 IT 아키텍처를 구성할 수 있어야 한다. 비즈니스 아키텍트는 기능과 콘트랙트와 관련하여 비즈니스 전략을 짜야 한다. IT 아키텍처는 전체적인 비즈니스 연산을 지원하는데 필요한 IT 시스템을 제공할 것이다. 대형 엔터프라이즈 내에서, 이는 전략적 애플리케이션의 대형 포트폴리오가 된다

디자인 전략

전체적인 엔터프라이즈 순응성을 실행하는 강력한 정보 관리 아키텍처를 구현하기 위해서는 이 문제를 다룰 많은 디자인 전략과 원리를 생각해야 한다.

비즈니스 프로세스 분석에 있어서 범위 변경 계획

변형 프로그램 동안, 일반적으로 시스템 분석과 디자인이 바람직하지 못한 데이터 프로세싱 시나리오를 발견하게 된다. 이전에 범위에서 벗어났던 비즈니스 연산들은 다시 범위로 가져와서 새로운 시스템을 수용할 수 있도록 수정될 수 있다. 새로운 SOA 기반 시스템들은 고객 상세를 업데이트 하는 추가 프로세싱 단계 같은 변화된 비즈니스 연산을 위해 내부 애플리케이션을 제공해야 한다.

레거시 엔터티 변화를 퍼블리시 및 등록하기

동의된 엔터티와 애트리뷰트 데이터가 서비스 공급자로서 참여하는 레거시 IT 시스템에서 변화될 때, 추가 프로세싱은 SOA에 알리도록 개발되어야 한다. 이상적으로 이것은 실시간으로 되어야 하지만, 스케줄링이 된 일괄 액티비티가 된다. 데이터 기록이 바뀔 때 탐지하는 레거시 IT 시스템으로 계측 코드를 적용하는 데는 비용이 많이 들고, 오래되고 구조가 형편없는 애플리케이션 코드에서는 거의 불가능 하다.

엔터프라이즈가 수행해야 하는 한 가지는 레거시 시스템이 소유한 데이터와 관련 당사자에게 변화를 공지하는 시스템 기능을 평가하는 것이다. SOA에 중요한 데이터가 자주 변하고 이것이 레코드 레벨 이벤트 트리거를 생성하는 시스템의 무능력과 결합한다면 레거시 시스템의 리엔지니어링 또는 대체를 다시 고려해야 한다. 비즈니스 서비스의 QoS는 계획된 엔지니어링 노력으로 정렬되어야 한다 핵심 서비스 데이터의 일괄 프로세싱에서 실시간 메시지 중심 프로세싱으로 옮기는 것 같은, 엔지니어링 향상을 통해, QoS가 시간이 흐르면서 향상되고 있다는 것을 나타내야 한다.

정보 서비스 쿼리 facade

정보 관리 서비스는 데이터 또는 콘텐트에 적용될 수 있는 단순한 액션들을 나타내야 한다. 쿼리 facade는 정보가 액세스 되고 조작되는 방법을 숨기고, 물리적 IT 시스템들이 얼마나 많이 있는지도 숨긴다. 기본적으로, 쿼리 facade는 데이터 통합을 이룩하기 위해 두 개의 패턴을 구현할 수 있다. 엔터프라이즈 내에 다양한 시나리오와 레거시 시스템들 때문에 서비스를 구현하는데 이 두 가지가 사용될 것이다.

• 데이터를 쿼리로 가져오기. 천천히 변하는 정보를 데이터 스토어(웨어하우스)로 가져오고, 그곳에서 데이터에 대해 작동한다. Extract, Transform, Load (ETL) 기술들이 여기에서 사용될 수 있다.
• 쿼리를 데이터로 가져오기. 빠르게 변화하는 트랜잭션 데이터의 경우, 액션은 이를 조작할 수 있는 물리적 소스로 가야 한다. 커넥터와 어댑터 기술을 사용하여 액세스 할 수 있다. (읽기 및 업데이트)

SOA 내에서, 실제 쿼리 facade는 federation과 population (참고자료 섹션의 데이터 통합 애플리케이션 패턴 참조) 같은 다양한 패턴들을 사용하여 구현되고, Service Data Objects와 Data Access Services (참고자료) 같은 기술을 사용하여 구현된다. 다양한 서비스 구현을 위한 전체적인 디자인 패턴("서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1" [한국 developerWorks, 2005년 7월])은 이러한 결정에 영향을 미친다. 하지만, 이러한 문제 공간에서, 구현 디자인은 확장되어 서비스를 더욱 지능적인 것으로 만든다. 엔터티 데이터 변경 사항을 퍼블리시 하는 레거시 시스템을 위한 솔루션이 정비된 상황에서(QoS), 정보 시스템은 변경 사항을 등록하고 변경 사항들을 각각의 물리적 시스템에 적용해야 한다.

이것은 엔터티 결정을 완성하는 아키텍처의 장소이다. 어떤 레거시 IT 시스템이 마스터로 간주되어야 할까? 여기에서 마스터 데이터 관리 기술은 구현을 도울 수 있고, 옵션과 결정들은 레거시 시스템의 통합 기능과 균형을 맞추어서 아키텍처 정의의 중요한 부분이 되어야 한다.

비즈니스 규칙 배치

SOA로의 변형에는 통합 미들웨어와 새로운 복합 애플리케이션들을 포함하고 있는 새로운 IT 인프라스트럭처가 도입된다. 비즈니스 규칙들은 하나의 애플리케이션 안에서만 더 이상 제한되지 않는다. 상태는 비즈니스 규칙의 실행을 통해 효과적으로 관리된다. 정보 관리 디자인을 개발하는 것의 일환으로 비즈니스 규칙 로직의 유형과 위치가 이해되어야 한다.

SOA 내에서 비즈니스 규칙의 유형에는 다음이 포함된다.

• 참조 무결성 규칙
• 애플리케이션 작동 규칙
• 크로스 애플리케이션 통합 규칙
• 트랜잭션 프로세싱 비즈니스 로직 규칙
• 저장 프로시저 같은 데이터 엔터티 프로세싱 규칙

전략은 비즈니스 규칙을 다시 만드는 것이 아닌 재사용이 되어야 한다. SOA의 도입으로 기존의 비즈니스 규칙과 새로운 비즈니스 규칙을 실행하는 것을 신중하게 생각해야 한다. 규칙 로직 그 자체는 특정 프로세싱 시나리오를 위해 무결성을 관리하기 위해 호출될 수 있는 서비스로서 노출되어야 한다.

잠재적인 디자인 전략 영향

이와 같은 디자인 결정에 다다르면 여러분이 고려해야 하는 솔루션에 미치는 영향은 다음과 같다.

• 더블-키 프로세싱. SOA의 도입으로 인해 하나의 비즈니스 영역에서 얻어진 효율성은 추가 데이터 엔트리 태스크(그리고 데이터 엔트리 에러의 위험)에 비례하여 균형이 맞춰져야 한다. 하지만, 이것은 데이터-동기화 타이밍 시나리오를 대처하기 위한 유일한 옵션이다. 이러한 시나리오는 보통 가볍게 취해진다. 엔터프라이즈는 밤마다 수행되는 일괄 업데이트의 시간 지연을 피하기 위해 이벤트 중심 더블 키(keying)를 수행하는 인원수를 확립해야 한다. 데이터 동기화를 보조할 시스템에서 자동화된 인터페이스를 개발하는 비용도 계산해야 한다. 자동화된 인터페이스를 구현하는데 필요한 시간이 전체적인 딜리버리 타임 스케일을 구성하는지 여부도 평가해야 한다.
• 불필요한 피드백 루프. CRM 시스템에서의 고객 기록 업데이트는 SOA로의 수동 또는 자동 호출로 이어져서 영역 KR의 고객 데이터 변경에 대해 다른 애플리케이션에 알려야 한다. 고객을 업데이트 하려면, SOA는 정보 서비스를 호출하고, 이는 그 자체로 원래의 CRM 시스템을 호출하고 고객 데이터를 업데이트 한다. 정보 서비스 아키텍처는 사용 모델에 기반하여 업데이트 고객의 다른 스타일을 구현해야 한다.
• 범위 이동. SOA 범위가 정의될 때, 레거시 IT 시스템에 대한 지식의 부족과 프로세스 및 정보 관리 기능도 변하게 된다. 서비스 모델의 파생은 레거시 분석을 이끌어 내고, 보다 미묘한 SOA 인프라스트럭처 구현이 필요하다는 것을 드러낸다. 전체적인 비즈니스 서비스와 엔지니어링 프로그램의 전체 범위를 정의하기 전에 단계를 플래닝 해야 한다.

결론

이 글에서는 SOA로의 성공적인 비즈니스 변형 프로그램을 제공하는 것에 초점을 맞추었다. SOA로의 비즈니스 변형의 문제는 매우 많다. 대부분의 기업들은 새로운 복합 애플리케이션들이 구현될 수 있는 SOA 인프라스트럭처를 도입함으로써 점증적인 변형을 시도하고 있다. 이들은 레거시 IT 시스템들을 사용하여 서비스 공급자를 구현한다.

강력하고 순응적인 연산을 기업이 유지하려면, 변형 프로그램은 엔터프라이즈 정보 관리 솔루션을 개발해야 한다. 이 솔루션은 SOA에서의 레거시 IT 시스템들에서 데이터의 일관성과 동기화 문제를 다루어서 정보 서비스들이 안전하게 노출될 수 있도록 해야 한다.

SOA 변형을 제공하는 책임이 있는 솔루션 아키텍트는 전체적인 엔터프라이즈 아키텍처 및 예산의 정황 속에서 SOA의 필요와 레거시 IT 시스템의 기능에 균형을 맞춰야 한다. 데이터 통합을 위한 기술과 주 데이터 관리는 정보 관리 솔루션을 위한 구현 전략에 포함된다

감사의 말

이 글을 검토해 준 Rick Robinson, Patrick Dantressangle, Bob Lojek, Claudio Cozzi에 감사의 말을 전하고 싶다.

 

참고자료

교육

• Ali Arsanjani의 기술자료, "서비스 지향 모델링과 아키텍쳐 (한글)" (한국 developerWorks, 2004년 11월) : SOA 서비스의 정의, 특성화, 구현 방법.
• Tilak Mitra의 기술자료 "SOA 거버넌스" (developerWorks, 2005년 8월)
• 데이터 통합 애플리케이션 패턴: IBM Patterns for e-business 사이트.
• "Service Data Objects 소개" (developerWorks, 2004년 9월): Bertrand Portier와 Frank Budinsky의 Service Data Objects를 활용한 차세대 데이터 프로그래밍 소개.
• Service Data Objects 스팩.
• Ali Arsanjani의 기술자료 "서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1: 서비스 생태계 구현하기 (한글)" (한국 developerWorks, 2005년 7월) : 이 시리즈에서 이들의 사용법과 관련된 패턴과 경험들을 나눌 것이다. 또한 SOA와 SOI의 마이그레이션, 모델링, 디자인, 구현과 관련된 문제에 대한 솔루션도 모색해 볼 것이다.
• developerWorks 기술 이벤트와 웹캐스트.
• IBM SOA 웹사이트
• 한국 developerWorks의 SOA와 웹서비스 존
• Safari bookstore.

제품 및 기술 얻기

• IBM 시험판 소프트웨어를 다운로드하여 차기 개발 프로젝트에 활용해보라(다운로드 또는 DVD)

토론

• 포럼에 참여하기.
• developerWorks 블로그와 커뮤니티 참여하기.

 

필자소개

		Jeremy Caine은 IBM Global Business Services의 IT 아키텍트이자 기술 전략 컨설턴트이다. 대형 비즈니스 변형과 시스템 통합 프로그램과 관련한 일을 하고 있으며, 복잡한 IT 시스템, 웹 기술 솔루션, 엔터프라이즈 애플리케이션 통합 전략 분야를 담당하며, 주 고객 층은 금융 서비스와 정부이다. 월드와이드 IBM 기술 커뮤니티에서 활발하게 활동하고 있다. IBM 아키텍처 교육 팀의 리더이자 멤버이다.

 

		Joe Hardman은 IBM Global Business Services의 IT 아키텍트이다. SOA와 웹 애플리케이션 아키텍처와 보안 전문가이다. 최신 프로젝트로는 cahoot 인터넷 뱅킹과 Polaris imarket 등이 있다. 현재 글로벌 정유 회사에서 SOA 프로그램을 맡고 있다.