기업 정보 통합 기술 리뷰

데이터 홍수
“이제는 두렵지 않다”

비용·복잡성 각오해야 … 데이터 통합 능력 ‘CIS’가 탁월

기업정보통합(EII)이 명성을 얻게 된 것은 데이터를 연합시킬 수 있는 능력 때문이다. 이것은 서로 다른 정보 소스로의 단일 액세스 지점을 제공한다. 이는 다양한 데이트 소스로 합류하려 하는 클라이언트 애플리케이션에 있기 마련인 복잡성을 줄여주며, 동시에 그 정보로 액세스할 수 있는 또 다른 길을 제공한다. 좋게 들리는가? 그렇다면 본지 독자설문조사 응답자의 57%가 EII를 통해 조직에서 혜택을 볼 수 있을 것이라고 말했음에도 불구하고 56% 이상이 EII를 배치할 계획이 없다고 답한 이유는 무엇일까? 7개의 EII 스위트 테스트를 통해 여기에 대한 해답을 찾아 보았다.

EII를 통해 조직에서 혜택을 볼 수 있는데도, 배치할 계획이 적은 것에는 몇 가지 이유가 있다. 복잡성을 큰 장벽이라고 언급한 25%의 응답자와 같은 생각이라면, 틀린 생각은 아니다. 이런 제품들은 테스트하기도 만만치가 않았다. 비용이 문제라고 말한 25%의 생각도 또한 옳다. EII는 전혀 저렴하지 않다. 하지만 이런 것들을 감내할 수 있다면 EII는 이기종 데이터 소스들로의 표준화된 액세스를 가져다줄 수 있다. 이것은 아마 액세스 표준화가 이런 괴물을 이행하는 이유라고 답한 30%의 응답자들에게는 기쁜 소식이 될 것이다.
이런 결정을 내리는 데 있어서 느끼게 될 고통을 알기 때문에 우리는 7가지 EII 제품을 테스트했다. 우리가 생각하기에 테스트에서 설정한 목표는 대단한 것이 아니었는데, 서로 다른 데이터 소스(마이크로소프트 SQL 서버, 오라클9i, SOAP 및 XML)로의 액세스를 표준화하면서 동시에 맞춤 애플리케이션 배치의 복잡성을 줄이고, 우리의 보고 툴(엑셀 2003과 크리스탈 리포츠 9)을 위한 신뢰성 있는 액세스를 유지한다는 것이었다.
초대된 업체는 우리의 필요를 충족시켜줄 제품을 보유하고 있는 액추에이트(Actuate, 2003년 EII 업체인 님블 테크놀로지 인수), 아배키(Avaki), BEA시스템즈(BEA Systems), 써티브(Certive), 신콤(Cincom), 컴포지트 소프트웨어(Composite Software), 디노두 테크놀로지스(Denodo Technologies), IBM, 아이피두(Ipedo), 메타매트릭스(MetaMatrix), 스냅브리지 소프트웨어(Snapbridge Software) 및 엑서웨어(XAware) 등이었다. 총 12곳 중 7개 업체, 즉 신콤, 컴포지트, IBM, 아이피두, 메타매트릭스, 스냅브리지 및 엑서웨어 등이 참가를 승낙했다.
아배키는 잘 맞지가 않는다며 정중히 거절했고, 디노두는 4/4분기에 플랫폼 업그레이드가 예정돼 있다며 지금 제품의 테스트를 거절했다. 써티브는 참가에 동의했지만 그런 다음 소식이 없었다. BEA는 거절한 다음 재고해 보겠다고 했지만 결국은 특별한 이유없이 거절했다. 액추에이트도 또한 참가를 거부했다. 우리는 위스콘신주 그린베이에 있는 NWC 비즈니스 애플리케이션 랩에서 통합의 도전에 응한 용감한 도전자들의 제품을 테스트했다.

설정 목표
테스트의 목표는 EII 제품들이 데이터 소스를 얼마나 잘 통합하고, 시스템을 얼마나 잘 관리하며, 클라이언트 액세스를 얼마나 잘 구성하는지에 대한 평가였다. 우리는 오라클 9i(주문 명세), SQL 서버 2000(배송 명세) 및 XML 파일(인벤토리 명세)에 저장된 NWC 데이터를 위한 단일 액세스 포인트를 원했다. 이런 소스에 대해 아웃 오브 더 박스로 지원한다는 것은 곧 배치시 장애가 줄어든다는 얘기다. 모든 게 성공적이었지만 거의 대부분이 EII 서버에서 RDBMS 클라이언트를 필요로 했다.
이상적인 EII 플랫폼은 ODBC 액세스의 형태로 레거시 애플리케이션을 지원해야 한다. 게다가 EII 플랫폼은 유형 전환과 같은 최소한의 데이터 변형을 수행해야 하며, 일종의 캐싱을 제공해야 한다. 이 플랫폼은 또한 양방향이어야 한다. 이것은 데이터 소스를 업데이트하고 여기서 읽기를 하며, 기본적인 비용 기반 질의 최적화를 수행해야 한다.
우리는 제품들을 두 가지 범주로 금방 나눌 수 있었는데, 하나는 RDBMS 백그라운드에서 성장한 것들(신콤, 컴포지트, IBM 및 메타매트릭스의 소프트웨어)과 XML 세계에서 나온 것들(아이피두, 스냅브리지 및 엑서웨어)이다. 이 차이는 근본적으로 캐싱, 데이터 관리, 메타데이터 및 모델링, 질의 최저고하 등의 제품의 서버측 역량과, ODBC/JDBC 접속성 면에서 서버 측에서의 역량에 영향을 미친다.
대부분의 제품들(신콤은 예외)은 J2EE 애플리케이션이며, 마이크로소프트가 업체들에게 이들의 제품에 SQL 서버 JDBC 클라이언트를 배포할 수 있게 하지 않는다는 유감스러운 사실을 발견했다. 이것을 마이크로소프트에서 무료로 다운로드 받을 수는 있지만(마이크로소프트닷컴으로 가서 JDBC를 검색하면 된다), J2EE 애플리케이션에는 포함시킬 수가 없다. 신콤은 SQL 서버 어댑터를 제공했지만, 이 회사의 타이거(Tiger)는 SQL 서버 2000을 처리하는 데 처참하게 실패했다. 그 어댑터는 파손된 것 같으며, 마이크로소프트 RDBMS를 시스템에 통합시키기 위해 신콤에서 제공한 처방책이 필요했다. 이러한 핵심 기능의 부재나 처방책 모두 마음에 들지 않는 부분이었으며, 그 처방책이라는 것도 시스템에 접속성을 추가하기 위해서만 SQL 질의를 만들어야 했다.

아키텍처 다양
메타데이터의 지원 수준은 다양하며, 전적으로 RDMBS로 액세스하는 플랫폼에 의해 사용되는 JDBC 드라이버에 따라 달라진다. 스냅브리지의 JDBC 드라이버는 진정한 JDBC 이행이라 할 수 없다. 이것은 CSV 기반 인터페이스인데, 이는 곧 어떠한 메타데이터(행, 데이터 유형, 키, 및 제약조건 등에 대한 정보)도 RDMBS 데이터 소스로부터 검색이 불가능하다는 것을 의미한다.
CSV 포맷은 필드 이름과 값만을 주며, 필드 A가 스트링이라든가 필드 B가 십진수라는 얘기는 하지 않는다. 이 정보는 테이블에 합류할 때나 데이터를 다른 포맷으로 변형시킬 때 중요하다. 또 다른 완전한 JDBC 드라이버로 교체를 하는 경우도 있을 것이다.
테스트한 거의 모든 제품은(아이피두의 인포메이션 허브를 제외하고) XML 인터페이스로 표준화를 하면서 동시에 레거시 보고 애플리케이션인 엑셀 2003과 크리스탈 리포츠 9를 지원할 수 있게 해줬다. 아이피두는 ODBC 접속성을 제공하지 않으며, 여기에 대해 업체측과 토론한 결과 XML 중심의 방안을 만들어내 문제를 해결할 수 있었다. 크리스탈 리포츠 10과 엑셀 2003은 데이터 소스로 XML을 지원하며, 아이피두는 회사들이 두 제품 모두 최신 버전으로 옮기고 있는 추세기 때문에 ODBC 지원 부족은 큰 문제가 되지 않을 것이라고 말했다.
다른 모든 참가 제품들은 ODBC를 지원하지만, 이행의 편이 면에서는 다양한 수준 차를 보였으며, 아키텍처도 다양했다. 컴포지트, IBM 및 신콤은 간편하게 배치할 수 있게 해주는 클라이언트 소프트웨어를 제공했다. ODBC 클라이언트 드라이버 설치와 DSN(Data Source Names) 구성에 익숙한 관리자들은 이 프로세스를 익숙하고 간편하게 통과할 수 있을 것이다.
메타매트릭스와 엑서웨어는 써드파티 오픈RDA ODBC 드라이버를 사용하며, 엑서웨어의 경우 별도로 JDBC 서버를 구매해야 클라이언트 접속성을 얻을 수 있어 일은 더욱 복잡하고 비용이 들어가게 된다. 구성은 추가 비용은 논외로 하더라도 클라이언트측 ODBC 액세스를 제공하기 위해서는 별도의 추가 작업이 필요하기 때문에 둘다 가끔씩 까다로웠다. 스냅브리지는 ODBC 대 JDBC 브리지를 필요로 하며, 이지링크(EasyLink) 제품을 사용할 것을 제안했다.
XML과 SOAP 지원도 또한 매우 다양한 모습이었으며, XML 중심의 제품이 가장 유연한 사양들을 제공했다. 컴포지트는 세 가지 RDBMS 기반 제품들 가운데 가장 포괄적인 XML 및 SOAP 사양을 제공하며, 우리가 갈망하던 포인트 앤 클릭 SQL 투 XML/SOAP 능력까지 제공했다. 하지만 컴포지트의 모델링 툴인 컴포지트 스투디오(Composite Studio)를 이용한 데이터 변형은 유연성이 떨어졌으며, 두려운 프로세스인 수동 XSL 생성 작업을 필요로 했다.
스냅브리지의 XML 스투디오는 멋지고 사용이 간편한 툴로, 드래그 앤 드롭 XSL 기능성을 확보하는 데 필요한 모든 것을 제공하는 한편, 아이피두의 X쿼리 빌더(XQuery Builder)는 XML로의 행 생성 및 매핑을 간편하게 해줬다. XML 및 SOAP 문제에 대한 신콤의 솔루션은 자사의 토털XML(TotalXML) 제품과 함께 넷빈즈(NetBeans)의 IDE를 사용하는 것이다. 지나치게 개발자 지향적이긴 하지만 효과적인 솔루션이다.

표준 지원 부족 ‘실망’
SOAP를 통한 클라이언트 액세스는 WSSE(Web Services Security Extensions) 1.0을 통해서가 아니라 HTTP 베이식 오쏘리제이션(HTTP Basic Authorization)이나 전용 XML 엘러먼트를 통해 제공되는 보안과 함께 골고루 갖추고 있었다. IBM은 여기서 표준 기반의 두드러진 모습을 보였다. 단 웹 서비스의 SOAP 프로듀서 지원은 웹스피어 애플리케이션 서버(WebSphere Application Server)를 통해 별도로 제공되며, 개발자는 IBM의 WSSE 1.0 지원의 혜택을 받아야 한다.
다른 업체의 표준 지원 부족은 실망스러웠지만, 대부분이 향후 버전에서는 보다 나은 모습일 것이라고 말했다. 우리는 메타매트릭스, 엑서웨어 및 아이피두에 의해 제공되는 유연한 SOAP API를 즐겼는데, 이것은 우리가 질의당 기반에서 특정 SOAP 작동을 만들고 표준 SOAP 작동을 이용해 애드혹 질의를 수행할 수 있게 해줬다. 아이피두는 엑스패쓰 2.0(XPath 2.0)에서 유출된 XML 기반의 인간이 읽을 수 있는 형태의 질의 신택스인 엑스쿼리(XQuery)를 포함시킬 것을 요구했는데, 이에 반해 다른 제품들은 직접적인 SQL 92 준수 질의를 제출할 수 있게 해줬다. SOAP의 유연성은 마음에 들었으며, 보다 빠른 시일 내에 다른 제품에서도 이 지원을 볼 수 있기를 바란다.
캐싱 능력 또한 제품들을 차별화하는 요소가 된다. 이 부문에서는 컴포지트의 모델이 가장 좋았는데, 여기에는 사용자 구성이 가능한 기반으로 자동 무료(automated invalidation) 기능이 포함돼 있으며, IBM의 MQT(materialized query tables)는 간편하고 효과적으로 이용할 수 있었다. MQT는 데이터 소스의 스트럭처를 미러링하지만 EII 서버측에 거주하는 RDBMS 테이블들로 그 테이블로의 질의와 전반적 액세스를 보다 빠르게 만들어준다. 캐싱 지원과 성숙도는 제품이 RDBMS을 원천으로 하느냐 XML을 원천으로 하느냐에 따라 달라지는 것 같았다. RDBMS 제품은 XML쪽보다 캐싱을 훨씬 더 잘 지원한다. 엑서웨어는 유료로 캐싱을 지원하지만, 구성은 구성 파일에서 수동으로 정의된 다음, 관리 콘솔에 솜씨 좋게 숨겨진 다이얼로그 내의 비밀스런 세팅을 이용해 연관이 된다.
아이피두의 캐싱 능력은 엑서웨이와 유사하며, IBM이나 컴포지트에서 RDBMS 테이블을 사용하는 것과 상당히 유사한 방식으로 XML 집합이나 문서를 사용한다. 엑서웨이는 XML 캐싱만을 제공하며, SQL 결과 세트의 직접적인 캐싱을 허용하지 않는다. 이러한 기능은 SQL 결과 세트를 XML 문서로 밀어넣고 XML을 캐싱함으로써 제공될 수 있다. 엑서웨어는 다음 릴리즈에서 SQL 결과 세트 캐싱을 완전히 지원하게 될 것이라고 밝혔다. 메타매트릭스의 캐싱은 소형 룩업 테이블에 한정돼 있어, 큰 테이블을 캐싱하려면 질의 안에 전용 SQL 익스텐션을 포함시켜야 하는 힘든 과정을 통과해야 한다. 신콤은 어떠한 캐싱도 제공하지 않으며, 단 전문가 서비스에서는 (유료로!) 이런 기능을 제공할 수 있을 것이라고 밝혔다.
일부 제품들, 특히 그 가운데서도 컴포지트와 스냅브리지 제품들의 캐싱은 관리가 간편했으며, 원래 소스로부터 데이터의 리프레싱을 강행함으로써 캐시 무효를 자동화할 수 있게 해주었다. 다른 제품들도 이런 기능을 제공하긴 하지만 크론이나 윈도 스케줄러를 이용한 작업 스케줄의 수동 생성을 필요로 한다. 스냅브리지는 특정 질의 결과가 어떤 캐시(1분, 2분, 5분, 한 시간)에 저장돼야 하는지를 지시해주는 전용 XML 기반 XRAP 언어를 요구하는, 흥미로운 트위스트를 캐싱에서 제공한다. 컴포지트와 IBM은 단순히 결과를 캐싱하고 개별적인 캐시 콘덴츠가 무효화될 수 있게 해준다.

아쉬운 부분들
컴포지트와 아이비엠의 제품처럼 모범적이고 자동화된 질의 최적화 지원을 제공하는 제품들도 있었지만, 아이피두와 스냅브리지 및 엑서웨이 제품들처럼 질의를 전혀 최적화하지 않는 것도 있으며, 메타매트릭스의 아키텍처는 시스템의 최고 성능을 유지하는 데 질의의 수동 복제를 필요로 한다.
컴포지트와 아이비엠은 상세 질의 계획을 제공하며, 아이비엠은 기분 좋게도 참여 알고리즘에 대한 설명도 제공했다. XML 기반 제품들은 서로 다른 소스에 합류하기 위해 네이티브 데이터베이스 능력을 이용하는 게 거의 불가능하며, 단 엑서에이는 질의 합류 차단이나 푸시 다운과 같은 기본적인 최적화는 제공한다. 스냅브리지와 아이피두 제품에서는 결과 세트를 축약시켜 데이터베이스 부하를 줄이는 메커니즘이 다소 수고스러워서, 컴포지트와 IBM에서 쉽게 할 수 있는 일을 엑스쿼리 코드의 생성(아이피두)과 XML(스냅브리지)가 있어야 할 수가 있었다.
예상하는 바와 같이 CIS(Composite Information Server)가 에디터즈 초이스를 수상하고 IBM의 DB2II(DB2 Information Integrator)가 2위를 차지했으며, 메타매트릭스도 눈에 띄는 모습을 보였다. 테스트용 구성의 정가는 가격표를 참조하기 바란다.

컴포지트
CIS 2.5
CIS는 테스트한 제품들 가운데 최고였으며, 하나의 잣대가 된 제품이기도 하다. SQL 서버 JDBC 커넥터에서처럼 가끔씩 문제에 부딪치기도 했지만, 이들은 금방 해결됐으며 CIS에만 있었던 문제도 아니었다.
CIS는 아웃오브더박스로 모든 제품용의 JDBC 커넥터를 제공하며(물론 마이크로소프트 제품은 예외), 다른 드라이버를 통한 부가 기능 추가도 간단해서 테스트를 하는 동안 CSV를 추가할 수 있었다. 구성도 또한 간단하다. 프로젝트의 조직과 연합 데이터에 대해 우리의 가장 큰 불만은 고작 공유 폴더에 연합 데이터 소스를 만드는 일을 잊기가 쉽다는 것이었다. CIS의 보안 모델은 역할 기반이며 유연하지만, 메타매트릭스의 극도로 정말한 보안 모델에는 다른 제품들과 마찬가지로 따르지를 못했다.
CIS는 클라이언트 접속용으로 ODBC를 제공하며, 연합 소스를 엑셀과 크리스탈을 통해 연결시키는 데 아무런 문제가 없었다. 캐싱 구성도 마찬가지로 간편해서 간단한 포인트 앤 클릭 작동만 하면 되었다. CIS와 스냅브리지는 둘 다 구성을 기반으로 캐싱된 결과 세트를 무효화하지만, 스냅 브리지 제품에서 지원하는 옵션을 기반으로 간격을 선택해야 하는 것보다는 캐싱한 각각의 데이터에서 간격을 지정할 수 있는 CIS 방안이 더 마음에 들었다.
ODBC에서의 캐싱 성능은 인상적이었다. CIS는 캐싱이 구성되기 전 3.3TPS(transactions per second)를 지원했으며, 클라이언트가 캐싱된 결과 세트를 질의했을 때는 놀랍게도 63TPS에 달했다.
연합 데이터로 SOAP 기반 인터페이스를 제공하도록 CIS를 구성하는 일도 또한 전혀 문제가 되지 않았으며, 몇 번의 마우스 클릭만으로 금방 사용할 수 있었다. 웹 서비스를 만들기 위해 옵션을 선택한 후 우리는 어떤 데이터 소스를 퍼블리싱할 것인지를 지정해야 했다. CIS SOAP 서비스의 유일한 약점은 WSSE 1.0을 지원하는 게 아니라 HTTP 베이식 AUTH를 사용하도록 한 것이다. 컴포지트는 이런 표준들을 준수하기 위해 작업 중이라고 말했다.
연합 부분에 있어, CIS는 DOC/LIT 인코딩된 웹 서비스만을 집합할 것인데, 이로 인해 WS-1 베이식 프로파일은 준수하지만 많은 기업용 서비스가 CIS로 연합될 수 없게 내버려둔다. 웹 서비스 기반 질의의 ‘페러미터라이제이션(parameterization)’은 우리로 하여금 SQL 스크립팅을 사용할 것을 요구했는데, 이보다는 메타매트릭스의 간편한 GUI 방안이 훨씬 마음에 들었다.
CIS는 질의 플랜 분석과 질의 최적화 면에서 DB2II와 동등한 수준이었다. 원자 질의(atomic queries)의 시각적인 분류와 CIS가 서브질의에 대한 성능 정보를 보여줄 수 있는 능력이 돋보였는데, 이는 테스트한 다른 제품들은 제공하지 않는 능력이었다. CIS는 주문 및 배송 데이터의 합류에 있어 가장 효율적인 방안을 자동으로 결정해주며, 오라클을 먼저 질의한 다음 Order_ID 값을 술어의 일부로 이용해 SQL 서버에 있는 배송 테이블로부터 적절한 데이터 세트를 검색해 낸다.

IBM
DB2II 8.1
DB2II는 구성이 간편했다. 이것은 DB2 데이터베이스의 꼭대기에 설치돼 클라이언트 접속성 및 캐싱 기능 등과 같이 DB2 안에서 사용 가능한 많은 기능들을 이용한다. IBM은 JDBC 드라이버를 통해 뽑아내는 메타데이터로부터 실질적인 뷰를 자동으로 만들어냄으로써, 래퍼(Wrapper)를 이용해 오라클9i와 SQL 서버 2000의 데이터를 연합시키는 과정을 매우 쉽게 만들었다. 우리의 XML 기반 인벤토리 목록과 같은 계층적인 데이터를 포함시키는 것도 같은 프로세스를 따랐으며, 설치 후 금방 데이터 소스로 질의할 수 있었다.
DB2는 모든 연합 데이터를 시각적인 테이블로 나타내 주어, 엑스패쓰가 아니라 SQL을 이용해 XML 문서에 질의할 수 있게 해줬다. 데이터베이스 관리자들은 엑스패쓰 신택스에 익숙치 않은 경우가 많기 때문에 이것은 확실한 이점이다. 우리는 오라클의 주문 데이터와 SQL 서버의 배송 데이터에 대한 실제 뷰를 시각적인 디자인 모드로 신속하게 만들어냈으며, 여기에는 사용 가능한 합류 알고리즘 종류들에 대한 상세한 설명이 포함됐다.
일단 적합한 뷰를 셋업하자 클라이언트 기계에서 ODBC 데이터 소스를 쉽게 구성했으며, 엑셀 2003과 크리스탈 리포츠 9 모두에서 데이터를 검색했다. 클라이언트 소프트웨어를 7.2에서 8.1로 업그레이드하자 데이터 액세스에서 현저한 성능 향상을 볼 수 있어 시간을 투자한 가치를 충분히 느낄 수 있었다.
ODBC 기반 성능 테스트의 첫 번째 세트를 돌리자 20명 동시 사용자 부하 아래서 1.8TPS가 나왔으며, 그런 다음 우리는 두 가지 질의 모두에서 결과 세트를 캐싱하도록 DB2II를 구성했다. DB2II는 캐싱용으로 MQT를 사용하며, DB2II를 지원하는 필요한 DB2 인스턴스 안에 로컬 테이블을 만든 다음 질의로부터 이 테이블을 파퓰레이팅시킨다.
테이블을 만들 때는 ‘Data initially deferred refresh deferred’를 지정함으로써, 적절한 명령어를 내보내어 언제든지 소스로부터 데이터를 갱신할 수 있다. 이로 인해 어떤 간격으로든 캐시로의 업데이트를 스케줄링할 수 있다. 일단 캐시 테이블을 파퓰레이팅한 다음 우리는 성능 테스트를 다시 실시했으며, 캐싱된 테이블을 이용해 2.7TPS를 얻었다. 그리 성능이 많이 좋아진 것처럼 보이지 않을지 몰라도 RDBMS 데이터 소스에 대한 어떠한 캐싱도 지원하지 않는 제품들을 생각한다면 이 정도면 만족할 만한 수준이다.
IBM은 DB2II의 다음 버전인 8.2에서는 막대한 캐싱 기능 향상과, 특히 웹 서비스를 데이터의 연합 소스로서 포함시키기 위해 특별히 만들어진 래퍼가 포함될 것이라고 말했다. 버전 8.1은 웹 서비스 연합을 위한 메커니즘을 제공하긴 하지만 다음 버전에서 가능할 만큼 깨끗하게 통합되지 못한 상태다.

메타매트릭스
서버
메타매트릭스 서버는 어떠한 추가 비용없이 디폴트로 BEA 애플리케이션 서버에 배치가 된다. 포함돼 있는 데이터다이렉트(DataDirect)의 JDBC 드라이버를 이용해 NWC의 관계형 데이터베이스로 접속하기는 어렵지 않았다. 메타매트릭스 서버는 가상 데이터베이스 모델을 이용해 데이터 소스를 연합시켰으며, 우리는 아무런 문제 없이 특화된 타깃을 포함한 가상 데이터베이스를 만들 수 있었다.
메타매트릭스 서버는 병렬적으로 질의를 처리하지만, 컴포지트나 DB2II와 마찬가지로 원자 질의를 적정 RDBMS로 푸시 다운할 수 있다. 질의 플랜 분석은 관리자에게는 보이지 않지만 최적화를 위해 데이터베이스 관리자에 의해 로깅 및 검토되거나, 혹은 서비스 계약의 일부로 메타매트릭스로 보내 평가받을 수 있다.
메타매트릭스 서버는 XML 파일이나 웹 서비스 연합을 지원하지 않지만, CSV 파일을 지원한다. 우리는 적합한 서술자 파일을 수동으로 만들어, 어떤 분리 특성이 사용됐는지와 같은 세부 사항들을 지적한 다음 우리 데이터를 연합시켰다. XML 파일에 대한 지원은 다음 버전에서 가능해질 계획이다.
IBM과 컴포지트 시스템에서의 한 가지 문제는 SQL 질의 안에 있는 버거운 레퍼런스들을 피할 수 있다는 희망이라도 품기 위해서는 소스가 어떻게 연합되는지에 대해 알아야 한다는 것이다. 가상 데이터베이스의 초기 구성 동안 매우 신중한 대신 메타매트릭스 서버에 의해 노출되는 질의로 인해 우리는 테이블을 레퍼런싱하는 데 단순히 문자가 아니라 카탈로그와 스키마 둘 다 필요하다는 것과 같은 질의를 만들어내야 했다.
ODBC 클라이언트의 구성도 또한 직관적이었으며, 단 스냅브리지나 엑서웨어 제품과 마찬가지로 써드파티 오픈RDA 클라이언트가 필요했다. 성능 테스트에서는 처음에는 문제에 부딪쳤지만 로그 파일을 메타매트릭스 엔지니어에게 보내고 난 후 메타매트릭스 서버에 있는 스레드 풀과 최대 스레드를 늘렸다. 이렇게 하고 나자 20명 동시 사용자 로드를 지원할 수 있었다.

스냅브리지 소프트웨어
FDX 인포메이션 서버 3.5
FDX는 유연성과 혼돈이 흥미롭게 조화를 이루고 있다. 아이비엠 DB2, SQL 서버, 마이SQL, 오라클 및 사이베이스 등과 같은 주요 RDBMS에 대한 기성품 지원이 포함돼 있으며, 보너스로 이 패키지는 포함된 톰캣 애플리케이션 서버 안에 데이터 소스 접속을 구성할 수 있게 해줬다. 혼란은 두 가지 서로 다른 데이터 연합 방안이 제시될 때 발생했으며, 구성 과정에서의 난관을 경험한 후 이들 중 하나가 후 ‘진정한’ 연합을 할 수 있게 만들어진 게 아니라는 사실을 알게 됐다.
FDX는 연합된 데이터 소스를 XML, HTML, CSV, 그리고 JDBC나 SOAP 프로토콜을 통한 고정 칼럼 출력 등으로 퍼블리싱하기가 간편했다. 연합된 데이터로의 HTML 퍼블리싱된 액세스에는 중복 포매팅이 포함됐으며, 열/행 데이터에서 HTML로의 포인트 앤 클릭 변형 방안은 DB2II의 수동 변형 방안보다도 수월했다.
간단한 데이터 소스들의 연합은 FDX 빌더에 의해 다소 단순화되었지만, 이러한 능력은 제한적이라는 사실을 금방 알 수 있었다. 샘플 질의가 데이터를 돌려주지 않았을 경우 연합 소스는 소용이 없다. 마찬가지로 두 데이터 세트의 핵심 행이 거기에 맞는 결과를 만들어내지 않았을 경우에도 합류는 실패했다. FDX의 디자인 툴은 데이터 소스를 훨씬 더 쉽게 연합시킬 수 있게 해주었지만, 엑스패쓰와 XSL, 그리고 스냅브리지의 전용 XRAP 언어에 대한 작업 지식이 필요했다. XRAP는 프리젠테이션에 있어 뛰어난 유연성을 제공하지만, 소스 연합에 필요한 코딩은 컴포지트나 IBM, 메타매트릭스에서 제공하는 방안들에 비해 다루기가 힘들었다.
모든 FDX 관리는 이 회사의 웹 콘솔을 이용해 수행했는데, 이것은 테스트한 제품들에서 독특한 부분이었다. 다른 모든 제품들은 서버를 완전하게 관리 및 구성하는 데 팻 클라이언트(자바) 애플리케이션을 필요로 했기 때문이다. 모든 관리 및 퍼블리싱 기능을 하나의 웹 환경에 완전히 통합시키는 편이 우리는 더 좋았다.

엑서웨어
XA-i서버 3.52
엑서웨어는 재미있는 EII 용어인 펑토이즈(functoids)란 말을 만들어 냈다. 이것은 자바나 자바스크립트를 통해 자사의 XA-i서버의 기능성을 확장시키는 간단한 메커니즘을 제공한다는 강력한 개념을 익살스럽게 표현한 말이다.
XA-i서버는 J보스(JBoss)에 디폴트로 설치돼 있지만, BEA, 아이비엠 및 오라클 애플리케이션 서버로 배치될 수 있다. 애플리케이션 서버에 배치되는 데 따르는 한 가지 이점은 XA-i서버가 JDBC 접속 풀링의 혜택을 받을 수 있다는 것이며, 이것은 표면적으로 성능 향상과 서버가 받는 압박의 감소를 의미한다. 하지만 20명 동시 사용자의 부하 아래서 테스트한 어떤 제품도 CPU 활용도를 100% 아래로 유지할 수 없었기 때문에, JDBC 접속 풀링을 사용하면 XA-i서버의 성능이 높아질 것으로 우리는 기대했다.
이 서버는 ODBC를 통해 3.3TPS를, SOAP 요청을 통해서는 2TPS를 처리했다. 캐싱은 ODBC 기반 접속용으로는 사용이 불가능했지만, SOAP 요청용 캐싱은 같은 부하 아래서 성능을 5TPS까지 향상시켰다.
XA-i서버는 연합 데이터 소스를 구축하는 데 있어 독특한 재활용 모델을 제공하는데, 여기에는 비즈도큐먼트(BiZDocuments: 엔드유저가 볼 수 있는 것), 비즈컴포넌트(BizComponents: 데이터 비트), 그리고 비즈드라이버(BizDriver: 데이터 소스로의 접속) 등이 포함된다. 이 모델은 비구조적 프리젠테이션만을 지원하며, SQL 기반 인터페이스는 계층적 데이터 소스 뷰와는 별도인 가상 데이터베이스를 필요로 하는데, 이는 곧 SQL 결과 세트와, 동일한 연합 데이터의 XML 프리젠테이션을 둘 다 지원하고 싶을 경우에는 이것을 두 번 만들어야 한다는 것을 의미한다.

아이피두
XIP 3.5
XIP(XML Intelligence Platform)는 엑스쿼리 표준을 수용한 유일한 제품이다. 엑스쿼리는 못생긴 야수와 같아서 표준을 좋아하는 우리로서도 이 표준은 예외다. 하지만 아이피두의 엑스쿼리 빌더(XQuery Builder) 비주얼 툴로 인해 엑스쿼리 질의를 만들기가 그리 지루하지 않았다는 점은 인정하지 않을 수 없다.
아이피두는 XML 세계를 수용했는데, 이 회사의 그 XML 데이터베이스 사업자로서의 출발을 감안할 때 이것은 일리가 있다. XIP는 오라클의 씬 JDBC 클라이언트를 이용해 데이터를 연합시키며, 이는 곧 어떠한 메타데이터도 돌아올 수 없다는 것을 의미한다. 따라서 연합 문서를 만드는 일은 우리의 몫이었다. 아이피두는 톰캣/아파치에 디폴트로 배치를 하지만, 주요 J2EE 컨테이너(IBM과 BEA) 안에서의 이행을 지원한다.
하지만, ODBC 지원은 존재하지 않기 때문에 XIP 안에 연합된 데이터로 액세스하기 위해 우리는 크리스탈의 ODBC XML 드라이버와 XIP의 웹대브 인터페이스를 이용해야 했다. 유효한 방법이긴 했지만, 정상적인 것과는 거리가 먼 방법이기도 했다.
XIP에서 마음에 들었던 한 가지는 질의를 패러미터라이징하는 간편한 메커니즘이었다(엔드유저가 값을 전달할 수 있게 해준다). 이것은 스냅브리지가 효과적으로 할 수 없었던 부분이며, 테스트한 다른 대부분의 제품들에서 매우 어려운 작업이었다.

신콤
신콤 타이거
타이거(Tiger: Totally Integrated Enterprise)는 신기술과 예전 기술이 혼합돼 있어 데이터 연합 기술이 최근에 나온 기술이 아님을 입증해준다. 신콤은 데이터 소스로의 접속을 구성하기 위해 변경되는 데 있어 DOS 배치 파일과 본문 구성 파일에 많이 의존하고 있다. 이것은 또한 메타데이터 스토리지로 전용 데이터베이스를 사용하며, 프록시를 통해 연합에 대한 독특한 뷰를 제공한다.
우리가 연합시킨 각각의 데이터는 프록시 생성을 필요로 했다. 설명서를 샅샅이 훑어 필요한 구문을 찾은 후 우리는 프록시가 평가한 다른 대부분의 제품들이 버추얼 뷰란 용어로 나타내는 개념을 타이거식으로 표현한 용어라는 사실을 알게 됐다.
우리는 오라클9i의 프록시를 자동으로 만들었지만, SQL 서버에 대해서는 이렇게 할 수 없었다. 이에 대한 우리의 질문에 신콤은 즉시 자사의 SQL 서버 어댑터에 ‘문제’가 있는 것으로 알려졌다고 응답했다. 여기에 대한 처방은? 프록시를 수동으로 만드는 것이다. 사실 타이거에 있는 대부분의 기능은 수동으로 구성 및 관리되며, 기본적인 객체 지향 설계 개념에 대한 이해를 강조하고 있다. 이러한 복잡성을 관리자와 설계자들에게 숨기기 위해서 신콤은 더 많은 노력이 필요하며, 시스템의 완전한 재단장이 필요해 보였는데, 이에 더해 신콤은 현재 다양한 업데이트와 인핸스먼트들을 준비 중이라고 밝혔다.
우리는 또한 SQL 서버의 배송 테이블에 있는 Order-ID가 오라클9i의 주문 테이블에 있는 Order-ID와 같은 유형이 아니었기 때문에 데이터 유형 변형에도 고전했다. 최종적으로 우리는 클라이언트 소프트웨어를 설치하고, ODBC DSN을 구성하며, 엑셀 2003과 크리스탈 리포츠 9에서 연합 데이터 소스를 성공적으로 질의할 수 있었다. 하지만 성능 테스트 클라이언트는 그다지 믿을 만하게 돌아가게 할 수 없었다.

기업 정보 통합 기술 테스트 방법

EII 스위트들은 모두 데이터 연합에 대한 얘기다. 이런 제품의 능력을 테스트하기 위해 우리는 위스콘신주 그린베이에 있는 NWC 비즈니스 애플리케이션 랩에 이들을 모아 작동시켜 보았다.
NWC는 SQL 서버, 오라클9i, 플랫 파일, 문서 및 웹 서비스 등 다양한 데이터 소스로의 액세스를 통합시키는 데 관심을 두고 있다. 가장 중요한 목표는 기업 보고를 위한 교차 데이터베이스 질의(cross-database query)를 촉진시키는 한편(크리스탈 리포츠 9을 통해), NWC가 맞춤 개발용으로 XML 인터페이스로 표준화를 할 수 있게 하나는 것이다. NWC는 작은 기업이기 때문에 사베인-옥슬리(SOX) 법을 지켜야 할 필요가 보이기는 하지만 급박하지는 않다. 각각의 스위트가 SOX 준수 문제를 처리하는 데 있어 어떻게 도움을 줄 수 있는지도 살펴는 봤지만, 의사결정 과정에서 이를 주된 요소로 꼽지는 않았다.
각각의 제품은 듀얼 지온 프로세서와 1GB의 램으로 윈도 2000 SP3를 돌리는 델 2650에 배치했으며, 각 제품은 SQL 서버, 오라클9i, XML 및 플랫 파일뿐만 아니라 웹 서비스(SOAP)와 커뮤니케이션을 해야 했다. 우리는 통합 지점의 구성 및 관리뿐만 아니라 캐싱과 같은 관리 기능들도 또한 검토해 보았다.
각각의 제품은 우리의 오라클 9i 및 SQL 서버 데이터베이스로 접속을 하고 세 개 테이블(주문, 주문 항목 및 배송)의 단일 뷰와 CSV나 XML 파일(인벤토리)를 만들어야 했다. 이러한 데이터 연합 프로세스는 우리가 각 제품의 데이터 모델링 방안과 질의 최적화를 사용된 합류 알고리즘에 이르기까지 검토해볼 수 있도록 해줬다. 연합을 검증하기 위해 우리는 크리스탈 리포츠 9와 엑셀 2003을 이용해 데이터를 새로 생성된 데이터 소스로부터 끌어냈다.
그런 다음 제품들은 웹 서비스, CSV 및 XML 파일로부터 데이터를 통합 및 연합해야 했다. 플랫 파일을 포함시킴으로써 우리는 데이터 변형을 수행하는 데 사용 가능한 메커니즘을 시험해볼 수 있었다.
각 제품의 성능은 오라클과 SQL 서버로부터 두 개의 테이블의 간단한 연합에 대조시켜 테스트했다. 적용 가능한 곳에서는 연합된 데이터가 ODBC/JDBC, XML 및 SOAP 인터페이스로 퍼블리싱됐다. 벤치마크팩토리(BenchmarkFactory)와 5개의 에이전트를 이용해 우리는 퍼블리싱된 ODBC 데이터 소스에 대조해 읽기 전용 트랜잭션 속도를 테스트했다.
첫 테스트를 실시한 후 우리는 캐싱을 지원해서 테스트를 다시 실시했으며, 웹 서비스 기능도 같은 식으로 처음에는 캐싱 지원이 없이, 그 다음 번에는 캐싱 기능이 지원되도록 테스트를 실시했다.