회사의 SOA(서비스 지향형 아키텍처)는 변화하는 비즈니스 전략을 지원할 수 있을 만큼 충분히 유연해야 하며, 정책을 시행할 뿐만 아니라 서비스 재활용을 극대화하기 충분할 만큼 규율이 잡혀 있어야 한다. 우리는 SOA 거버넌스 시장을 점검하고 레지스트리/리포지토리를 어떻게 평가해야 하는지 살펴봤다.

SOA 거버넌스(governance)는 궁극적으로 제어에 대한 것이다. 즉 프로세스와 정책에 법칙을 부여한 다음 이것을 조직 내에서 시행함으로써 IT가 비즈니스 니즈에 맞는 양질의 애플리케이션과 서비스를 전달할 수 있게 보장하는 것이다.
SOA 거버넌스 제품은 정확히 이행될 경우 이러한 시행을 촉진시키고 자동화할 수 있으며, 동시에 SOA 이니셔티브용의 아키텍처 표준을 지킬 수 있게 해주기 때문에 메타데이터 관리를 이용해 프로젝트에서 서비스 재활용을 지원하며, 테스트와 문서 정책을 시행함으로써 배치된 서비스에서의 결함 수를 줄일 수 있다.

과도한 사용· 과대 선전
모두가 가치 있는 목표긴 하지만, ‘전문가’와 업체에서는 거버넌스라는 용어에 마치 올림픽 판정단에서 부정 판정을 내리는 것처럼 모두 10점 만점을 주고 있다. 이 말을 듣는 데 진력이 났다고 해도 뭐라고 할 말은 없다. 과도하게 사용되고, 과대선전되고 있으며, 제대로 설명이 되지 않고 있는 게 분명하기 때문이다. 여러 가지 면에서 이것은 당연한 일이기도 하다. 거버넌스는 프로세스와 정책에 관한 것이며, 이것은 각 조직마다 다르다. 하지만 여기에도 몇 가지 변치 않는 것이 있다.
우선 SOA 거버넌스는 일찍 시작해야 한다. 즉 비즈니스 목표와 부합되는지를 확인하기 위해 리포지토리에 아티팩트로 보관된 문서를 이용해 필요조건을 수집 단계에서 시작해야 한다. 거버넌스는 모든 것의 실행 시간 정책과 SDLC(Software Development Lifecycle)룰 다루며, 여기에는 SOA를 구성하는 서비스의 배치와 이 곳으로의 액세스가 포함된다.
당신이 이제 새로운 SOA 프로젝트를 시작하는 개발자라고 하자. 당신에게는 아마 네트워크 공유, 스프레드시트, 그리고 문서 관리 시스템 등에 프로젝트 차터와 처음 필요조건 문서를 저장하고 있는 디렉토리가 있을 것이다. SOA 거버넌스는 이런 문서에서 시작되며, 당신은 프로젝트를 만들어 향후 레퍼런스용으로 이들을 SOA 리포지토리에 저장하고 싶을 것이다.
SOA 레지스트리/리포지토리(registry/repository) 제품은 메타데이터 관리에 초점을 두고 있다. 중요한 문서에 대해 수집된 메타데이터는 개발자, 관리자 및 비즈니스 애널리스트들이 프로젝트의 개발 및 배치 단계에서 이들을 검색하고 로케이팅할 수 있게 해준다.
또 한 가지 일관된 것이 있다. 개발자의 눈으로 볼 때 거버넌스는 방해물로 널리 인식되고 있다는 사실이다. 문서화와 메타데이터 수집은 잘해야 지루한 일이며 ‘바쁘기만 하고 성과는 없는 일(busy work)’인 경우가 많다. 프로세스를 간단하게 하는 것만이 유일한 도움의 길이다.

디자인 시간과 실행 시간
SOA 거버넌스에는 두 가지 부류가 있는데, 바로 디자인 시간과 실행 시간이다. 둘 다 필요하며, 둘 다 당신의 SOA 이니시어티브에 방해가 아닌 도움을 주기 위해 만들어진 전체 거버넌스 전략의 일부다. 디자인 시간 거버넌스는 개발 단계에 초점을 두며 주로 내부적인 것인 반면에, 실행 시간 거버넌스는 내외부 클라이언트에 의해 쓰일 액세스, 보안 및 서비스 성능을 규정하는 정책을 다룬다.
시중에 나와 있는 SOA 레지스트리/리포지토리 제품은 디자인 시간 거버넌스를 매우 잘 다루고 있지만, 실행 시간 쪽은 기업용으로 준비되기에는 아직 가야 할 길이 멀어 보인다.
SOA 인프라에 있는 나머지 부분(보안 정책과 액세스 제어를 시행하는 보안 장비, SLA를 시행하는 관리 지점 등)과의 상호운용성은 아직 수준 미달인데, 이제 레지스트리/리포지토리 업체들과 다른 SOA 인프라 업체들간의 파트너십이 민들레처럼 피어나고 있다. 이러한 파트너십은 궁극적으로 보다 나은 상호운용성을 가져다 줄 것이며, 보다 나은 실행 시간 거버넌스를 위해 제품들간 정책의 상호교환을 가능하게 해줄 것이다. 하지만 이렇게 되기까지에는 시간이 걸릴 것이며, 내년까지는 진정한 상호운용성 이행을 보기 힘들 것 같다.
지금 준비돼 있는 것에 초점을 맞추기로 하자. 디자인 시간 거버넌스는 SDLC에 역점을 둠으로써 서비스 개발자들이 협업 환경에서 서비스를 발견, 배치, 문서화 및 재활용할 수 있는 프레임워크를 제공한다. 검증(validation), 중복 제거(de-duplication), 버저닝(versioning), 그리고 비즈니스 및 기술 리뷰 같은 프로세스 시행 등이 디자인 시간 거버넌스 제품의 영역에 속하는 것들이다.
SOA 거버넌스 제품이 전통적인 버전 제어의 자리를 대신하는 것은 아니며 그래서는 안된다는 사실을 주목해야 한다. 이들은 버전 제어 시스템과 함께 작동해야 한다. 버전 시스템은 보통 아티팩트(artifact) 스토리지나 조직에서 고려하는 것으로, 메타데이터를 지원하지 않으며, 메타데이터를 기반으로 한 검색 기능도 제공하지 않는다. 그리고 그 자체로는 검증이나 프로세스 관리 능력도 없다. 버전 제어는 단순한 스토리지며, 버전 제어 시스템에 있는 것을 관리해야 하는 부담은 여전히 사람의 몫으로 남는다. 이와 대조적으로 레지스트리/리포지토리에 있는 아티팩트들 관리는 대폭 자동화가 될 수 있으며, 여기에는 다양한 기능성이 포함돼 있다.
실행 시간 거버넌스는 승인 프로세스를 통해 배치를 제어하고, 실행 시간 액세스 제어 정책을 서비스에 적용시키는 데 초점을 둔다. 개발자가 서비스의 개발과 테스트를 완료하고, 승인을 위해 서비스를 제출했다고 하자. 서비스가 조직의 정책에 부합하는지를 레지스트라(registrar: 레지스트리/리포지토리의 ‘수퍼 어드민’을 가리키는 말)가 버튼을 누르면 서비스는 이제 ‘퍼블리시드(published)’로 간주된다.
완전히 이행되는 거버넌스 시나리오에서, 서비스 WSDL과 그에 연관된 실행 시간 정책은 어떤 것이든(예를 들어 액세스 제어, 암호화나 디지털 서명 요건과 같은 보안 옵션, 그리고 SLA 정책 등과 같은 사양 규정) 실행 시간 시행을 위해 적절한 SOA 인프라 제품으로 푸싱될 것이다. 이러한 방법에 대한 대안으로 많은 업체들이 매우 선호하고 있는 것은 SOA 인프라 제품이 레지스트리/리포지토리에 질의를 하고, 자체적으로 적절한 실행 시간 정책을 검색하는 방법이 있다. 하지만 시중에서 이러한 기능성을 보기까지는 얼마간의 시간이 흘러야 할 것 같다.

레그레프
어떠한 거버넌스 이니시어티브든 그 심장은 레지스트리/리포지토리로 전문가들은 ‘레그레프(regrep)’라고 즐겨 부르기도 한다. UDDI(Universal Description, Discovery and Integration) 사양의 이행을 통해 서비스 카탈로그를 제공하기 위한 이니시어티브로 처음 시작된 것이 지금은 단순한 디지털 전화번호부의 개념 이상으로 성장했다.
메타데이터 관리를 중심으로 하는 리포지토리는 메타데이터 스토리지에 초점을 맞춘 리포지토리와 힘을 합쳐, SOA를 구성하는 서비스의 기록을 위한 하나의 단일 소스를 제공한다. 이 시장은 하지만 아직 성숙하지 않은 상태다. 이 기사를 작성하면서 몇 가지 초기 버전을 살펴봤는데, 그 후에는 우리 랩에 막무가내로 밀어닥쳐 작업에 방해를 받았다.
레지스트리/리포지토리가 마땅히 갖춰야 하는 핵심 사양에 대해서는 보편적인 의견 일치가 이뤄지지 않은 상태며, 거버넌스에서 UDDI가 하는 역할에 대해서도 마찬가지다. UDDI가 통합과 상호운용성용으로 사용돼야 한다는 데 대해서는 업체 커뮤니티에서 예외가 거의 없이 의견 일치가 늘어나고 있는 추세다. 레지스트리는 서비스 카탈로그, 자산, 혹은 아티팩트를 검색할 수 있는 액세스가 가능한 인터페이스를 제공하는 한편, 리포지토리는 자신들이 퍼블리싱될 때 서비스와 그에 연관된 아티팩트를 저장, 분류 및 검증하는 책임을 진다. 이들은 둘이서 함께 SDLC의 양단에서 정책과 프로세스를 강행할 수 있는 강력한 프레임워크를 제공한다.
이 시장을 한층 더 혼란스럽게 하는 것은 UDDI 기반 이행과 ebXML 기반 이행이 나눠져 있다는 사실이다. 둘 다 레지스트리 표준이며, 레지스트리의 주 용도인 검색과 퍼블리싱을 위한 인터페이스를 제공한다. 하지만 UDDI는 SOA 관련 아티팩트를 저장하는 데 초점을 두는, 훨씬 더 협의의 기반 스토리지 모델을 의미한다. 이 사양과 UDDI 기반 레지스트리와 상호작동을 하는 데 개발자가 사용하는 API는 ebXML 쪽보다 덜 포괄적이며 보다 엄격하다.
반면에 ebXML 사양은 ebXML을 기반으로 하는 레지스트리 안에서 관리돼야 할 것에 대해 고려하지 않고 만들어졌으며, 대신 이행자들에게 유연성과 확장성을 두는 데 역점을 뒀다. 그런 다음 이러한 특성은 사용자에게로 전달된다.
시간과 혁신적인 노력 덕분에 사용자가 고려되는 한 이러한 표준을 기반으로 하는 레지스트리/리포지토리의 이행간 차이는 대부분 없어졌지만, 표준 자체는 개정을 통해 그리 많이 바뀌지 않았다. 업체에서 하나가 있는 데다 다른 하나를 또 사용한다고 기능성이 방해를 받는 것은 아니지만, 두 가지는 종종 어떤 식으로든 서로 경쟁한다고 볼 수 있다.

UDDI 기반 제품 폭넓게 사랑
인프라비오(Infravio)와 썬마이크로시스템즈(Sun Microsystems)는 ebXML을 사용한다. 사실 썬의 이행은 오픈 소스 ebXML 레지스트리인 freebXML과 협력해 실행이 되고 있다.
한편 UDDI 기반 제품들은 후지츠-소프트웨어 AG 센트라사이트(Fujitsu-Software AG CentraSite)와 시스티네트(Systinet: 최근 머큐리 인터랙티브서 인수)의 시스티네트 2에서 공동으로 개발했다. 시스티네트의 포괄적인 파트너십과 OEM 계약 덕분에 이것은 ISV SOA 커뮤니티에서 보다 폭넓게 사랑받고 있다.
그리고 그 중간 쯤에 플래시라인(Flashline)과 로직라이브러리(LogicLibrary)가 있다. 시스티네트, 인프라비오 및 썬이 레지스트리를 중심으로 레지스트리/리포지토리를 구축한 반면, 플래시라인과 로직라이브러리은 완전히 다른 방식을 택했다. 두 제품은 인터페이스로서 UDDI를 한정적으로 지원하지만, 둘 다 디자인 시간에 초점을 맞추고 있으며 개발자 지향적이다.
플래시라인과 로직라이브러리는 첫째가 리포지토리고 레지스트리가 둘째로, 레지스트리가 첫째, 리포지토리가 둘째인 타 제품들과 크게 구분이 된다. 분명 플래시라인과 로직라이브러리는 리포지토리/거버넌스 기능을 레지스트리 부분보다 더 중요하게 생각하고 있다. 두 제품 모두가 레지스트리 유형의 기능성을 제공하지만, 이들은 UDDI 이행을 중지하고 파트너십을 통한 전용 통합과 표준 기반의 통합에서의 코드를 선호하고 있다. 이것은 대부분의 SOA 커뮤니티가 지향하는 것이기도 하다.
예를 들어 로직라이브러리는 자산 퍼블리싱용으로 UDDI 준수 레지스터만 통합이 가능하며, 그 리포지토리에는 어떠한 직접적인 UDDI 인터페이스도 없다. 플래시라인은 자사 제품에 질의를 허용하고, 다른 SOA 인프라 제품 통합을 수월하게 해주는 UDDI 인터페이스를 제공하지만, 다른 제품이 UDDI의 퍼블리싱 인터페이스를 이용해 새 자산을 제출하도록 해주지 않는다. 그러나 둘 다 너무 리포지토리 중심적이기 때문에, IDE 통합, 승인 프로세스, 액세서 제어 및 재활용 메트릭스 수집 등에 있어서 디자인 시간 프로세스를 거버닝하는 데는 훨씬 더 뛰어난 역량을 발휘한다.
마지막으로 순수한 UDDI 레지스트리와 SOA 제품에 번들된 것(SOA 소프트웨어의 레지스트리 매니저 등)은 단순히 레지스트리라는 사실을 명심해야 한다. 이런 제품들은 카탈로그와 거의 다를 바가 없으며, 거버넌스 기능이나 질의, 퍼블리싱 및 가입(subscription) 옵션에 대한 실질적인 제어 능력이 없다. 레지스트리는 거버넌스 파이 중 한 조각에 불과하며, 그것도 작은 조각에 속한다.

비즈니스 리엔지니어링은 하나의 재앙
궁극적으로 레지스트리/리포지토리는 특정 조직의 스트럭처 안에서 거버넌스를 강요하는 게 아니라 지원하고 장려한다. 이것이 많은 IT 조직은 업체들이 자사 제품에서 무엇을 하는지에 대해 상세히 밝히려 하지 않는 상황에 접하기도 한다.
각 제품은 특정 조직과 그 프로세스에 맞을 수가 있으며, 또 반드시 그렇게 돼야만 한다. 조직의 모든 거버넌스 필요를 해결해 줄 수 있는 하나의 ‘아웃 오브 더 박스(out of the box)’ 레지스트리/리포지토리는 없다. 레지스트리/리포지토리 제품은 맞춤화가 되도록 만들어진 서비스 세트를 제공하는 프레임워크에 접근할 수 있는 인터페이스를 제공하는 정도다. 이것은 어떤 이들에게는 도피처의 역할을 하기도 하지만, ERP/CRM 업체들에게 무슨 일이 일어나는지를 보라. 이들은 고객에게 프로세스를 강요함으로써 큰 것을 잃어버렸다. 비즈니스 리엔지니어링은 하나의 재앙이며, 레그/레프 업체들은 이것을 잘 알고 있다.
레지스트리/리포지토리는 분명 개발자, 설계자, 비즈니스 프로세스 및 서비스 소유자가 조직의 정책을 따르기 위해 협업을 할 수 있는 하나의 프레임워크를 제공하며, 이러한 정책이 지켜지고 이행되는지 여부는 매일같이 시스템과 상호작동을 하는 개인에 따라 달라진다. 말을 물가로 끌고 갈 수는 있지만 억지로 물을 먹일 수는 없는 일이기 때문이다.

네 가지 기능
SOA 거버넌스용으로 필요한 네 가지 주요 기능은 레지스트리/리포지토리에 의해 제공이 되는데, 이들은 각각 검증, 카탈로깅, 관계 관리 및 협업 프로세스/정책 시행이다. 이 모든 기능들은 표준을 시행하고, 재활용을 지원하고, 서비스 품질을 향상시키는 데 있어 결정적인 역할을 한다. 버저닝과 연합 질의(federated query) 능력과 같은 다른 기능들도 있으면 좋긴 하지만, 이런 주 기능이 없으면 거버넌스 이니시어티브를 이행하는 것 자체가 힘들어진다.

■ 검증
검증은 서비스와 그에 연관된 아티팩트, 즉 WSDL, XSD(XML Schema Definition), XSLT(Extensible Stylesheet Language Transformation)가 조직의 표준을 따르는지 확인해 주는 자동 메커니즘을 제공한다. 레지스트리/리포지토리로의 아티팩트 제출에 따라, 예를 들어 이름공간(namespace)이 일관성이 있는지, 그리고 아티팩트가 제대로 모양을 갖추고 알려진 표준을 고수하는지를 검증하기 위해 자동 검증 프로세스가 시작된다. 이 프로세스는 심지어 WSDL에 대조해 WS-I 베이식 프로파일(Basic Profile) 점검을 실시하도록 구성될 수도 있다.
아티팩트 제출은 승인 프로세스를 시작하는 워크플로우를 트리거링할 수 있는데, 여기에는 코드, 문서 및 회사 표준 준수에 대한 리뷰뿐만 아니라 서비스가 지정된 기업 필요조건을 얼마나 잘 충족시키고 있는지에 대한 평가도 포함이 된다. 대부분의 레지스트리/리포지토리는 그 조직 전용의 검증 항목을 포함시키도록 기존의 점검을 확장할 수 있게 해주는, 검증 서비스용 플러그인 기능성을 제공한다. 검증 서비스를 코딩할 수 있다면, 이것은 보통 레지스트리/리포지토리에 통합될 수 있다. SOA 거버넌스 내에서 검증의 역할은 잘못 만들어진 아티팩트가 회사용으로 사용되지 못하게 함으로써 전체적인 서비스 품질을 향상시키고, 회사 표준을 지키게 보장하는 것이다.
조직 전용의 검증 서비스를 코딩할 수 없다 하더라도 레지스트리/리포지토리는 주어진 비즈니스 기능을 이행하는 재활용 서비스가 존재하는지 여부를 수동으로 확인하는 데 걸리는 시간을 줄여 준다. 설계자는 신규 서비스 리뷰를 수행함으로써 이들이 기존의 기능성과 중복이 되는지(분명 그럴 것이다)를 파악해야 하는데, 레지스트리/리포지토리는 자산이나 아티팩트에 첨부된 정책 데이터를 내보임으로써 이런 프로세스를 수월하게 해준다. 특정 정책이 첨부돼 있으면 설계자는 IT 표준에 부합하는 것뿐만 아니라 조직의 정책과 목표까지 염두에 두고 새로운 자산을 리뷰할 수 있다.
이러한 작업은 시간 소모적이긴 하지만 정확한 메타데이터가 수집되는 레지스트리/리포지토리를 이용함으로써 합리화될 수 있다. SOA 설계자는 문제의 서비스를 설명하는 비즈니스 용어나 기술 용어를 이용해 레지스트리/리포지토리에 질의를 할 수 있으며, 파라미터에 부합되는 모든 서비스를 볼 수 있다. 개발자는 개발에 뛰어들기 이전에 이 작업을 정기적으로 수행하는 법을 익혀야 한다. 그러면 개발 사이클이 결과적으로 IT의, 따라서 비즈니스의 기민성(agility)이 향상될 수 있다.

■ 카탈로깅 서비스
카탈로깅 서비스는 서비스에 관한 메타데이터를 수집하는 메커니즘을 제공한다. 이 메타데이터는 레지스트리/리포지토리 사용자가 프로젝트를 시작할 때 재활용이 가능한 서비스가 존재하는지 아닌지를 검색하는 데 사용할 수 있다. 카탈로깅은 메타데이터 관리의 심장이다. 자동 카탈로깅 서비스는 WSDL이나 XML 스키마 같은 문서로부터 데이터를 풀링할 수 있으며, 이것을 저장할 리포지토리를 사용하기로 선택할 경우 심지어 코드까지 가능하다.
메타데이터를 자동으로 수집함으로써 개발자들이 이런 데이터를 수동으로 입력해야 할 필요가 사라지는데, 이것은 종종 최종 순간까지 미루거나 피할 수 있다면 피하게 되는 번거로운 작업이다. 더 큰 비율의 메타데이터를 자동으로 수집함으로써, 카탈로깅 서비스는 보다 덜 수고스럽게 만드는 방법으로 이 필요조건을 지키는 것을 장려한다. 하지만 대부분의 레지스트리/리포지토리 제품은 필요한 필드의 구성을 허용함으로써 제출자로부터 최소한의 데이터가 수집되도록 보장하고, 이를 통해 자산이 분류되고 이후 검색되는 데 필요한 정보를 제공한다.
그렇다면 이러한 자동 메타데이터 수집이 특정 작업을 수행하면서 아티팩트를 만드는 개발자에게 의존을 할까? 아마 그럴 것이다. WSDL이나 정의된 XML 표준과 같은 일부 유형의 아티팩트들로서는 프로세스를 자동화하기가 충분히 쉬운데, 그 이유는 포맷이 잘 정의돼 있고 알려져 있기 때문이다. 다른 자동화된 분류/검증 프로세스의 경우는 카탈로깅/검증이 자동화될 수 있도록 문서 내에 특정 데이터가 있어야 한다고 요구를 해야 할 것이다. 따라서 카탈로깅 자체는 마법의 총알이 아니지만, 잘 정의된 유형의 경우 개발자가 자동 카탈로깅을 위해 문서를 만져야 하는 부담을 없애 준다.

■ 관계관리
관계 관리는 영향 분석(impact analysis) 등과 같은 기능을 지원하기 때문에 중요하다. 영향 분석은 특히 SOA에서 실행 시간 부문을 다스리는 데 유용한데, 그 이유는 이것이 인프라에 있는 하나의 서비스나 아티팩트에 생긴 변화의 영향을 볼 수 있게 해주기 때문이다. 즉 수동, 혹은 자동 카탈로깅 프로세스를 통한 관계 관리는 아티팩트와 서비스들 사이의 관계를 결정해 준다.
XSD 파일은 WSDL 문서에 의해 임포팅되는 경우가 많은데, 이 문서는 서비스에 연결이 된다. XML 스키마의 재활용은 서비스간에 일관성을 제공하며, 베스트 프랙티스다. 하지만 XML 스키마가 바뀐다면 어떤 서비스가 영향을 받는지 파악하는 일은 악몽이 될 수 있다. 영향 분석은 아티팩트들간의 관계를 이용해 어떤 서비스가 아티팩트가 영향을 받게 될지를 파악하며, 이것은 프로젝트 관리자에게 이러한 변화를 일으키는 데 필요한 시간과 노력을 보다 잘 파악할 수 있게 해준다.

■ 프로세스 및 정책 제어
아마도 레지스트리/리포지토리의 네 가지 기능 중에 이행하기가 가장 힘들 것인데, 그 주된 이유는 프로세스와 정책이 둘 다 조직마다 고유한 것이기 때문이다. 회사 A와 회사 B가 모두 애자일(agile) 프로그래밍 방법론에 가입을 했다 하더라도 각각이 필요로 하는 실질적인 프로세스는 매우 다를 것이다. 누가 코드를 리뷰하는가? 언제? 얼마나 자주? 개발자에 의해 수행되는 유닛 테스트가 또한 QA 엔지니어에 의해서도 수행이 돼야만 서비스가 완벽하다고 간주되는가?
앞서 언급한 것처럼 SOA 거버넌스 업체들은 주로 프로세스를 다뤄 온 다른 기술 분야에서 했던 실수로부터 교훈을 얻었다. 즉 초창기 ERP와 CRM 이행에서는 ‘비즈니스 프로세스 리엔지니어링’ 도그마에 많이들 경도돼 조직들로 하여금 개별적 기업의 필요조건에 맞게 프로세스를 적용시키는 게 아니라 제품에 맞게 프로세스를 바꾸도록 강요했다.
레지스트리/리포지토리 제품은 보통 일종의 SDLC 승인 프로세스 이행을 지원하며, 그 제어 및 맞춤화의 수준은 다양하다. 최고의 솔루션은 어떤 회사 표준이든 이것을 지키는 다른 개발자가 이용할 수 있도록 레지스트리/리포지토리로 아티팩트와 서비스가 퍼블리싱되도록 보장해 주는 조직의 리뷰 프로세스를 코딩할 수 있도록 맞춤 메커니즘을 제공하는 것이다. 분명 개발자가 서비스와 아티팩트를 보다 폭넓은 기업 환경에서 사용하기 적합한지 여부에 대한 어떠한 제어도 없이 레지스트리/리포지토리로 아무렇게나 퍼블리싱하기를 원하지는 않을 것이다. 레지스트리/리포지토리는 퍼블리케이션 프로세스에 대한 제어 수단을 제시함으로써 이러한 일이 일어나지 못하게 막을 수 있게 만들어졌다.
프로세스 제어와 이행은 협업적이고 자동화돼야 하며, 개발자와 임원은 너나 할 것 없이 서비스와 아티팩트의 상태가 언제 바뀌는지를 알아서 시기 적절하게 그러한 변화에 대응할 수 있어야 한다. 여기서는 가입 기반 모델이 필수다. 이것은 아티팩트가 퍼블리싱되거나 변경될 때 가입자에게 즉시 통보할 수 있기 때문이다. 비즈니스 애널리스트를 그들의 프로젝트에 관련된 서비스나 아티팩트에 가입할 수 있게 하는 것 또한 중요하다. 이로 인해 그들은 필요를 충족시키는 과정에서 IT의 효율성을 측정하는 데 필요한 정보를 얻을 수 있게 되며, 동시에 개발자가 불려와서 프로그레서 업데이트를 제시해야 하는 상황설명 미팅 수도 줄어든다.
레지스트리/리포지토리는 IT 프로젝트나 포트폴리오 관리 제품에 대한 세부적인 상태 보고서를 제공하지는 않지만, 아티팩트가 제출되고 리뷰되고 퍼블리싱될 때 프로젝트에서 어떤 프로그레스가 일어나고 있는지에 대한 뷰를 제공할 수 있다. 이러한 정보로 인해 개발자가 미팅에 쓰는 시간이 줄어든다면, 이들은 더 많은 시간을 서비스 개발에 보낼 수 있게 될 것이다.

실행 시간 이야기
거버넌스는 SOA 이행에서 디자인 시간 쪽에 초점을 많이 두고 있지만, 이번에는 실행 시간 쪽을 이야기하기로 하자. 이 부문의 모든 제품은 UDDI 준수 인터페이스를 제공하는데, 덕분에 이들은 SOA 인프라의 나머지 부분과 통합이 가능하다.
SOA 관리 스위트, SOA 보안 게이트웨이, 심지어 엔터프라이즈 서비스 버스 등이 모두 UDDI를 통해 레지스트리/리포지토리와 통합이 가능하며, 레지스트리/리포지토리는 이런 제품에 필요한 WSDL 문서를 풀링함으로써 이들이 기능을 수행할 수 있게 해준다. 이런 문서에 대한 정식 소스로 레지스트리/리포지토리를 이용함으로써 SOA 인프라의 나머지 부분들이 동기적으로 최신 모습을 유지할 수 있다.
사실 레지스트리/리포지토리의 가입 및 통보 기능은 SOA 인프라의 각기 다른 조각을 관리하는 사람들이 기존의 서비스에 일어나는 변화에 대해, 혹은 새로운 서비스의 탑재에 대해 통보 받을 수 있게 해주는 좋은 방법이 된다. 인터페이스에 생긴 변화로 인해 발생할 수 있는 문제들도 관리자가 통보를 받을 경우에는 쉽게 확인될 수 있다. 이것은 변하기 쉬운 환경에서 발생하는 문제를 추적하고 해결하는 시간을 줄여주며, 따라서 서비스 가용성을 향상시킨다.
궁극적으로 레지스트리/리포지토리는 보안 및 액세스 권한을 설명하는 SOA 인프라 제품에 의해 사용되는 실행 시간 정책을 관리하는 책임도 또한 맡고 있지만, 이러한 통합은 지금 제품에서는 이제 막 등장하기 시작했다. WS-폴리시(Policy)와 그 프로파일은 이런 정책이 상호운용이 가능한 방식으로 교환되게 해줄 프로토콜인 것 같지만, WS-폴리시는 아직 표준 상태에 이르지 못했다. 이는 곧 이 지원이 아직 레지스트리/리포지토리(나 다른 어떤 SOA 인프라 제품)용으로 확인창(checkbox) 사양이 아니며, 업체들은 자신들의 장비를 이용해 정책 교환을 지원해야 한다는 것을 의미한다.
이러한 지원은 한정적이긴 하지만 표준화 기구들과 업체 커뮤니티로부터 얼마간의 장래가 유망한 움직임(파트너십과 통합)이 눈에 띄고 있다. 아마도 2년 이내에 레지스트리/리포지토리는 다른 SOA 인프라 엘러먼트와 정책을 상호교환하고, 그 궁극의 역할, 즉 중앙 정책 관리 리포지토리로서의 역할을 할 수 있게 될 것 같다.

파트너와 좋은 관계 유지 기본
우리의 조언은, 과거에 표준을 잘 채택해 온 업체를 선택하라는 것이다. 그리고 한편으로는 이러한 기능성을 보장받을 수 있도록 다른 SOA 인프라 업체와 좋은 파트너십을 유지하는 업체를 찾아야 한다.
우리는 레지스트리/리포지토리의 이러한 면을 ‘실행 시간’이라고 부르지만, 그렇다고 레지스트리/리포지토리를 실행 시간 서비스 검색 엔진으로 사용하라는 얘기는 아니며, 특히 용량이 많은 상황이라면 말할 것도 없다.
WSDL 문서의 형태로 된 정책 및 서비스 설명은 레지스트리/리포지토리에서 관리돼야 하지만, SOA 인프라와 레지스트리/리포지토리간 양쪽의 상호교환은 생산 환경으로의 애플리케이션 배치와 같은 시각에서 생각해야 한다. 상호교환은 정기적인 스케줄 기반으로 이뤄질 수 있지만, 서비스에 이뤄지는 모든 클라이언트 요청에 레지스트리/리포지토리가 포함돼서는 안된다. 마찬가지로 SOA 인프라 제품이 레지스트리/리포지토리에 서비스 재활용을 계산할 때 도움이 되는 서비스 메트릭스를 공급할 수 있게 해주는 피드백 메커니즘이 반드시 실시간 프로세스가 돼야 되는 것은 아니다.

결정의 시점 : 레지스트리/리포지토리 평가
1. 레지스트리/리포지토리가 나의 분류법에 맞게 맞춤화가 가능한가?

2. 레지스트리/리포지토리가 프로세스를 시행할 능력이 되는가?

3. 레지스트리/리포지토리가 UDDI 준수 인터페이스를 제공하는가?

4. 레지스트리/리포지토리가 내 소프트웨어 개발 수명에 어떻게 부합되는가?
a. 이것이 소프트웨어 개발 툴에 직접 통합되는가?
b. 원격으로 쉽게 액세스가 가능한가?

5. 레지스트리/리포지토리가 기존의 인프라에 어떻게 통합이 되는가?
a. 기존의 아이덴티티 저장소를 활용할 수 있는가?
b. 기존의 RDBMS를 활용할 수 있는가?
c. 기존의 애플리케이션 서버를 활용할 수 있는가?
d. 이것이 다른 SOA 인프라와 단순히 상호운용될 뿐만 아니라 통합이 되는가? SOA 인프라 제품이 레지스트리/리포지토리로 퍼블리싱을 할 수 있는가? 이것이 SOA 인프라 제품으로 퍼블리싱할 수 있는가?

6. 레지스트리/리포지토리가 검증 서비스를 제공하는가? 어떤 것이 아웃 오브 더 박스며, 어떤 것이 맞춤 플러그인을 필요로 하는가?

7. 레지스트리/리포지토리가 재활용에 대한 메트릭스를 제공하는가?
a. 디자인 시간으로 피드백되는 실행 시간 메트릭스는 어떤가?
b. 제품이 재활용을 어떻게 측정하는가?

UDDI와 ebXML 표준
UDDI와 ebXML 기술 위원회는 모두 OASIS의 후원을 받고 있지만, 이 두 표준은 메타데이터 관리에 접근하는 방식이 서로 다르다.
UDDI는 레지스트리/리포지토리가 발견되는 원칙이라기보다 레지스트리를 통합하는 메커니즘으로 보는 시각이 늘어나고 있다. 기존의 ebXML 레지스트리/리포지토리는 주로 질의용으로 SOAP를 사용해 UDDI 3.0 인터페이스를 지원하지만, 많은 경우 퍼블리싱용으로도 지원이 된다. UDDI에는 SOA 밖에 있는 객체와 아티팩트를 지원할 수 있는 능력 면에서 ebXML만큼 확장적이지 못하다. 하지만 이 사양의 유연성 없음을 UDDI 레지스트리/리포지토리에서 발견되는 능력과 혼동해서는 안 된다. 업체들은 전용 익스텐션을 통해 이 사양 고유의 한계를 극복하고 있으며, 그 레지스트리/리포지터리는 아티팩트와 메타데이터 관리 면에서 ebXML 기반 쪽보다 더 이상 유연성이 떨어지지도 않는다.
경로는 제품이 자신의 거버넌스 필요에 얼마나 잘 맞는지와, 조직의 프로세스와 정책에 필요한 시행 수준을 제공할 수 있는 능력, 두 가지 모두를 기준으로 해서 선택돼야 한다. UDDI나 ebXML을 기반으로 하는 레지스트리/리포지토리는 거버넌스 솔루션을 선택할 때는 유효한 기준이 되지 못하는데, 그 이유는 나와 있는 제품 세트들이 둘 다 UDDI 인터페이스를 지원하며, 이는 곧 이들이 나머지 SOA 중개자들과 상호운용이 가능하다는 것을 의미하기 때문이다. 그리고 두 사양 모두가 강력한 지원 커뮤니티가 있는 개방형 표준이다.

● UDDI 3.0
· 기술 위원회에 포함된 업체들 : 액센추어, 아리바, 커머스원, 후지츠, HP, i2 테크놀로지즈, IBM, 인텔, 마이크로소프트, 오라클, SAP, AG, 썬마이크로시스템즈, 베리사인
· UDDI를 기반으로 한 레지스트리/리포지토리 : SOA 소프트웨어 레지스트리 매니저, 후지쯔 소프트웨어 AG 센추라사이트, 시스티네트 레지스트리
· UDDI를 지원하는 레지스트리/리포지토리 : 플래시라인 레지스트리, 인프라비오 X-레지스트리, 로직라이브러리 로직덱스, SOA 소프트웨어 레지스트리 매니저, 후지츠-소프트웨어 AG 센추라사이트, 썬마이크로시스템즈 서비스 레지스트리, 시스티네트 레지스트리

●● ebXML 3
· 기술 위원회에 포함된 업체들 : 후지츠, 인텔, 아이오니아테크놀로지즈, 썬마이크로시스템즈, 비트리아테크놀로지, 웹메쏘드
· ebXML을 기반으로 한 레지스트리/리포지토리 : 인프라비오 X-레지스트리, 썬마이크로시스템즈 서비스 레지스트리, freeBXML
· ebXML을 지원하는 레지스트리/리포지토리 : 인프라비오 X-레지스트리, 썬마이크로시스템즈 서비스 레지스트리, freeBXML

레지스트리/리포지토리의 용례
● 비즈니스
· 성공과 진행 중 ROI 측정을 위한 재활용 추적
· 비즈니스 목표에 맞게 서비스 정렬
· 전사적 아키텍처 이행 작업에 대한 가시성 제공

●● IT
· 모든 서비스에 대한 하나의 단일 기록 소스 제공
· 서비스와 애플리케이션 품질 향상을 위해 소프트웨어 개발 수명에 대한 정책과 프로세스 시행
· 아티팩트나 서비스 변경을 요하는 비즈니스 변화의 영향 분석 수행
· 메타데이터 일관성 관리

데이터넷