‘ESB·거버넌스·관리 시스템·보안 게이트웨이’로 분류 …

SOA 인식 네트워크 인프라

“IT를 민첩하게”… 아직은 유년기
ADC로 하드웨어 가속화

SOA, 즉 서비스 지향형 아키텍처(Service Oriented Architecture)에 있어서 ESB 관리, 거버넌스, 그리고 전문화된 보안 등이 정말 필요할까? 그리고 파트너 업체를 현명하게 선택할 수 있는 방법은 무엇일까? 반드시 있어야 할 컴포넌트는 어떤 것들이고, 관리하기 힘들어질 것들은 무엇일까? 우리는 SOA 인프라를 파고 들어가 효과적인 배치에 필요한 컴포넌트와 제품, 그리고 기능들을 알아봤다.

IT에서 알아야 할 사실이 있다. 서비스 지향형 아키텍처는 원래 다중업체 매시업(Multivender Mashup)과 개방형 표준에 대한 모든 것이 되어, 새로운 방식으로 다시 쉽게 조합될 수 있는 서비스로 애플리케이션들을 분해하기 위해 만들어졌다. 그러나 SOA 업체들은 여전히 애플리케이션용의 그러한 경로를 선전하고 있긴 하지만 최근에는 그러한 선전을 실행에 옮기지 않고 있다. 이들은 한 번에 모든 SOA 니즈를 충족시킨다고 약속하는 스위트 안으로 자사 제품들을 집어넣으려 하고 있기 때문에, 마치 모두가 경쟁 업체를 사들이거나 인수를 당하고 있는 것처럼 보일 지경이다.

ADC 통해 SOA로 이동
이것은 놀랄 만한 비전이긴 하지만, 기업들로 하여금 서로 다른 경쟁 미들웨어 제품들간을 중개하기 위해 더 많은 미들웨어를 사도록 강요할 수 있는 것이기도 하다. 나아가 사용자들의 탄원에도 불구하고 웹 서비스 표준은 안정될 만한 기미가 전혀 보이지 않고 있다.
현재 SOA 중개 소프트웨어 시장은 네 가지 주요 제품 범주로 나뉘어져 있다. 그 가운데 가장 성숙한 부문은 ESB
(Enterprise Service Bus)로, 이것은 서비스들간에 데이터를 운반해 준다. 이와 대조적으로 거버넌스(governance)는 카탈로그와 소스 코드 관리의 조합으로, 아직 완전히 성숙하지 못한 상태다. 이 둘은 모두 언제나 소프트웨어 형태로 제공된다.
SOA 관리 시스템과 보안 게이트웨이는 각각 네트워크 관리 프레임워크와 방화벽과 같은 역할을 하며, 하드웨어나 소프트웨어로 제공될 수 있는데 심지어 같은 업체에서 두 가지를 모두 내놓는 경우도 있다.

네트워크 인프라 업체들은 또한 제5의 범주인 ADC
(Application Delivery Controller)를 통해 SOA로 이동하고 있는데, 이것은 다른 네 가지에서 중요한 기능들을 위한 하드웨어 가속화를 제공한다.
이러한 범주들은 기능적으로 중복이 되기 때문에 많은 IT 전문가들이 한 가지 이상을 피해가려 하기도 한다. 거버넌스와 하드웨어 오프로드는 실제로 비교적 큰 인프라에서만 필요하기 때문에 이것은 현명한 전략이 될 수 있다. 사실 어떤 조직에서는 이런 툴이 전혀 없이 버텨나가기도 한다. 예를 들어 오래된 COBOL 메인프레임 애플리케이션에 단순히 빛나는 새 웹 2.0 사용자 인터페이스를 주고 싶은 의도라면 SOA가 필요치 않다. 순수주의자들은 이 아키텍처를 ‘JABOWS’, 즉 ‘Just A Bunch of Web Service(웹 서비스 떼거지)’라며 조롱하고 있지만 실제로 이것은 많은 조직에서 잘 쓰이고 있다(적어도 한 동안은).
중복되는 것이 너무 많기 때문에 정리 통합은 불가피하다. 그리고 사실 SOA 업체들은 경쟁 업체 사양까지 넘보고 있으며, 아니면 그냥 그 업체를 사버림으로써 통합을 자기 회사만의 문제로 만들기도 한다. 그리고 이러한 통합은 단순히 SOA 제품 범주에서만 있는 게 아니다. 애플리케이션 업체들도 ESB와 거버넌스 기능성을 통합시키고 있으며, 네트워크 인프라 사업자들은 관리와 보안 영역으로 조금씩 손을 뻗쳐가고 있다. 아마도 이들을 다 지켜보려면 스코어카드가 필요할 것이다.
애플리케이션을 네트워크 인프라에 통합시키는 일은 분명 위험스런 일이다. 이것은 두 가지 모두를 흔들어 놓을 수 있으며, 계속 변화하는 웹 서비스 표준을 모양을 다듬어 표준으로 구워낸다는 것은 IT의 민첩성과는 완전히 거리가 멀어 보인다. 물론 펌웨어 업데이트와 FPGA(Field Programmable Gate Array)가 변화를 놓치지 않도록 하드웨어를 도울 수 있지만, 이들은 SOA로 가능하게 될 간편하고 시각적인 배치 환경을 따라갈 수 없다.
스위치나 라우터에 XML 프로세싱을 임베딩하는 기술인 시스코의 AON(Application Oriented Networking)을 보라. 시스코는 지난 2년간 AON의 이점을 선전해 왔지만 지금까지도 성공을 거두지 못하고 있다. IT에서 거부감을 갖는 큰 이유는 아직도 애플리케이션을 하나로 된 소프트웨어 코드 덩어리로 생각하는 데서 비롯된다.
SOA는 애플리케이션을 더 작은 서비스로 나누는 데 대한 것이며, 이 가운데 일부는 스위치나 네트워크 어플라이언스용으로 적합할 수도 있다. 하지만 어떤 것들은 메인프레임이나 서버에서 없는 게 나을 수도 있으며, 외부 ASP, 심지어 공중 웹 사이트에 의해 제공될 수 있는 것들도 있다.

엔터프라이즈 서비스 버스 따라잡기
과대 광고를 하고 있는 몇몇 업체를 제외하고, SOA에 참여하고 있는 업체들은 언제나 이것이 하나의 제품이나 기술이 아니라, 하나의 프레임워크, 혹은 개념임을 강조해왔다. 하지만 SOA의 초창기 시절에 ESB는 이미 유비쿼터스가 되고 있었다.
개별적인 SOA 이행은 각자 상호 접속돼 있는 시스템, 사용하는 메시징 프로토콜, 그리고 사용 가능하게 만든 서비스 종류에서 차이가 날 수 있겠지만, 모두가 ESB를 포함하고 있다. 다른 범주에서 기능이 중첩된다는 것은 곧 이것이 더 이상은 언제나 그런 건 아니라는 뜻이기도 하지만, ESB는 여전히 SOA의 기반으로 건재하고 있다.
ESB에는 두 가지 주요 기능이 있는데, 이들은 모두 애플리케이션 통합에서 없어서는 안될 것들이다. 낮은 레벨의 기능은 메인프레임, ERP 시스템, CRM 서버 및 기타 장비나 애플리케이션의 서로 다른 API를 하나의 공통된 언어로 번역함으로써 이들이 서로간에 소통할 수 있게 해주는 서비스 실현용 인터페이스들을 단순히 모으는 것이다. 그리고 높은 레벨에서 ESB는 새로 노출된 서비스를 합성 애플리케이션, 즉 매시업으로 통합 조정(orchestration)할 수 있다.
그리고 그 사이에는 콘텐츠 기반 라우팅, 아이덴티티 맵핑 및 감사 등과 같이 크고 분산된 ESB에서 메시지를 서로 다른 서비스로 오가며 라우팅하는 데 필요한 기능들이 있다. SOA에서 사용되는 프로토콜 수와 데이터 포맷이 늘어나면서 ESB에서는 이들간을 변환시켜 줄 XML 변형 및 프로토콜 중개(mediation) 기능이 필수 사양이 되었다.
SOA는 종종 웹 서비스를 연결하는 하나의 수단으로 묘사되지만, 많은 기업들은 비교적 오버헤드가 적다는 이유로 내부에서 JMS(Java Messaging Service)를 선호한다. 인터넷 중개는 여전히 진정한 웹 서비스를 선호하는 애플리케이션에서 사용되는 용도로 뿐만 아니라 인터넷을 가로지르기 위해 이것을 HTTP로 변환시키는 데 필요하다. 일부 ESB들은 또한 이메일이나 FTP 같은 다른 프로토콜도 지원한다. SOA 스택에서는 이들 모두, 그리고 어떠한 기반 네트워크든 전송 레이어로 간주된다.
XML 변형은 메시징 레이어와 그 이상에서 보다 높은 레벨의 데이터 포맷을 다룬다. 최대 상호운용성을 낼 수 있게 만들어진 애플리케이션은 메시지를 SOAP(Simple Object Access Protocol)로 감싸는 경향이 있는 한편, 인터넷 상의 웹 서비스는 일반적으로 다른 XML 포맷들, 즉 뭉뚱그려 REST(Representational State Transfer)라고 하는 포맷을 사용한다. 대부분의 ESB는 이들을 둘 다 지원하지만 RIA(Rich Internet Application)에서 널리 인기를 얻어가고 있는 간단한 비 XML 포맷인 JSON(JavaScript Object Notation)은 지원하지 않는다.

표준 발전 주시해야
SOAP에서 돌아가는 많은 WS-* 표준들 가운데, 가장 중요한 것은 WS-시큐리티, WS-어드레싱 및 WS-인터오퍼러빌러티(WS-Security/Addressing/Interoperability)다. WS-시큐리티는 웹 서비스에 암호화된 데이터나 전자 서명이 포함될 수 있게 해준다. WS-어드레싱은 라우팅 정보를 다루며, WS-인터오퍼러빌러티는 WS-* 표준이 함께 사용될 수 있는 방법을 설명하는 프로파일 세트다. 이들은 모두 XML 기반이며, 따라서 ESB가 이들 중 어떤 것이든, 나아가 서비스에 의해 사용되는 어떠한 맞춤 데이터 포맷이든 지원하기가 비교적 쉽게 지원할 수 있다.
SOA를 번들링하는 것은 매우 큰 일이기 때문에 초기 ESB들은 규모가 매우 큰 기업에서만 사용되었다. 가트너 데이터퀘스트에 따르면 2006년 전체 설치 기반 수는 600개가 채 되지 못했는데, 이들 중 상당수는 초대형 데이터 센터에서였다.
현재 프로그레스 소프트웨어(Progress Software) 소유이며 ESB의 선구자인 소닉 소프트웨어(Sonic Software)는 자사 고객사 가운데 최소 20곳은 100개 이상의 CPU에서 프로그레스 소닉 ESB를 돌리고 있다고 한다. 하지만 점점 더 많은 업체들이 이 시장에 들어오고 있으며, SOA 채택이 일반화됨에 따라 가격은 계속 떨어지고 있다. 이러한 현상은 특히 아이오나(Iona)나 레드햇의 J보스의 오픈 소스 ESB에 의해 더욱 가속화되고 있는데, 지난해 5월 이들 회사는 각기 로직블레이즈(LogicBlaze)와 메타매트릭스(MetaMatrix)에 의해 인수되어 서비스 실행 능력이 더욱 향상될 전망이다.
ESB는 모든 애플리케이션 플랫폼에서 빠른 속도로 표준 영역이 돼 가고 있다. 최초의 ESB를 내놓았던 EAI(Enterprise Application Integration) 사업자들에다 BEA시스템, IBM, 오라클, SAP 및 썬마이크로시스템즈 등이 목록에 추가됐으며, 이들은 모두 서비스 구축 및 오케스트레이팅을 위한 간편한 방법을 약속하고 있다. 마이크로소프트조차 이제 자사의 비즈토크 서버(BizTalk Server)를 하나의 ESB라고 설명하고 있는데, 예전에는 그 제품들을 ‘보다 나은 것’이라고 선전한 바 있다. 한편 어바이어는 전화 애플리케이션에 초점을 둔 ESB를 갖고 있다고 밝혔다.

ESB와 애플리케이션 플랫폼간 통합 ‘효과’
ESB와 애플리케이션 플랫폼간 통합은 서비스 실행 관점에서 볼 때 효과가 있다. 대부분의 애플리케이션이 BEA의 아쿠아로직(AquaLogic)이나 IBM의 웹스피어(WebSphere)를 기반으로 구축돼 있다면, ESB에도 같은 제품을 사용하지 않을 이유가 없다. 서로 다른 플랫폼에서 돌아가는 레거시 애플리케이션을 매시업할 필요가 있는 사람이라면 케이프클리어소프트웨어(Cape Clear Software), 피오라노소프트웨어(Fiorano Software), 혹은 프로그레스소프트웨어(progress Software)의 소닉 같은 전문 제품이 보다 나을 것이다.
또 한 가지 옵션으로 다른 레이어, 보통 BPM(Business Progress Management)으로의 통합을 추진하며 다중 ESB를 돌리는 게 있는데, 이것은 자동화된 서비스만이 아니라 사람을 포함하고 있는 작업을 관리하려 한다는 점에서 서비스 오케스트레이션과는 다르다. 팁코소프트웨어(TIBCO Software)와 비트리아테크놀로지(Vitria Technology)는 자사 것뿐만 아니라 타 업체의 ESB와도 작동한다고 주장하면서 이 모델을 선전하고 있다. 하지만 ESB의 가치 가운데 상당 부분은 ‘컴포넌트화된(componetized)’ 서비스를 재활용하는 데 있으며, 이는 서비스가 합성 애플리케이션으로 쉽게 오케스트레이팅되지 못할 경우 발휘되지 못하는 이점이다.
오케스트레이션에는 원래 전용 언어가 필요하지만, 대부분의 업체들은 WS-BPEL(Business Process Execution Language)을 중심으로 통합을 시켰다. 버전 1.1은 널리 채택되긴 했지만 너무 많은 옵션들을 포함하고 있어 합성 애플리케이션이 ESB들간에 쉽게 이식이 가능하지 못했다. BPEL 2.0에는 해석의 여지가 더 적지만, 그리고 따라서 언제나 후방호환이 가능한건 아니지만, 여전히 익스텐션(exxtension)이 허용이 된다. 이것은 어떠한 ESB를 통해서 어떠한 서비스든 모든 기능을 지원할 수 있게 해주지만, 한 ESB에서 다른 것으로 옮겨갈 경우 새로 쓰여져야 할 합성 애플리케이션이 많을 것이다.
모든 BPEL 익스텐션이 전용은 아니라는 사실에 주목하라. 예를 들어 IBM과 SAP는 BPEL4People을 준비 중인데, 이것은 인간의 상호작동에까지 범위를 넓힘으로써 서비스 오케스트레이션을 BPM과 본질적으로 통합해 주는 표준 제안이다.
애플리케이션 플랫폼은 또한 내부적으로 ESB 개념을 사용하기 시작하고 있다. 마이크로소프트의 WCF(Windows Communications Framework)와 자바 커뮤니티의 SCA(Service Component Architecture)는 표준화된 인터페이스를 통해 상호작동하는 재활용 컴포넌트로 구축된 서비스로 구축된 서비스를 이용해 개발 플랫폼을 작은 SOA로 재설계하는 작업을 시도하고 있다. 이들은 BPEL을 단순히 다른 하나의 프로그래밍 언어로 취급하며, 애플리케이션이 서비스 실행이 되도록 보장함으로써 ESB가 반드시 필요하지 않아도 되게 해준다.

디자인 시간 거버넌스
원칙적으로 볼 때, SOA 거버넌스는 곧 서비스가 계획되는 순간부터 합성 애플리케이션에 의해 액세스되는 매 순간까지, 비즈니스 프로세스와 나란히 진행될 수 있게 보장한다는 것을 의미한다. 하지만 현실적으로 이것은 SOA에서 가장 성숙하지 못한 범주의 제품들로, 대부분의 업체는 이행보다도 개발에 더 집중하고 있다. 서비스 범주 구분(cataloging)과 검증(validation)은 거버넌스 제품이 스스로 할 수 있는 기능들인 반면 실행시간에서 정책을 이행하려면 ESB나 서비스 자체와의 통합이 필요하다는 점에서 당연한 현상일 수도 있다.
거버넌스 플랫폼의 핵심은 리포지토리로, 이것은 SOA 안에 있는 모든 서비스뿐만 아니라, 정책에 대한 정보나 연관된 메타데이터를 계속 추적하는 데이터베이스를 말한다. 신규 서비스가 추가될 때마다 리포지토리는 이것이 정책에 맞고, 적합한 표준을 준수하는지 확인하는 책임이 있다. ESB와 달리 리포지토리에서 관할하는 기능들은 언제나 완전히 자동화되지 않는다. 여기에는 코드 리뷰나 버전 제어 같은 단계들이 포함돼 있기 때문이다. 이러한 단계들이 수행되도록 하는 비즈니스 규정이 만들어질 수도 있겠지만, 개발자나 테스터의 개입이 아직은 필수다.
리포지토리에는 또한 UDDI(Uniform Description Discovery and Integration) 레지스트리가 포함되는데, 이것은 리포지토리의 서비스 범주를 애플리케이션이나 개발자에게 노출시켜 주는 SOAP 웹 서비스다. 사용 가능한 서비스가 조직의 비즈니스 프로세스에서 널리 적용될 수 있는 재활용 가능한 컴포넌트로 만들어졌다면, 이것은 결과적으로 SOA의 가장 큰 혜택 중 하나가 될 수 있다. 즉 개발자가 애플리케이션을 처음부터 만들 필요없이 기존의 서비스 레지스트리에서 애플리케이션을 가져다 둘 수 있기 때문에 보다 민첩한 프로그래밍이 가능하다.
리포지토리는 개발 라이프사이클과 너무도 밀접히 관련돼 있기 때문에, 많은 개발 플랫폼 업체들이 SOA 거버넌스 제품을 공급하고 있다. IBM, 마이크로소프트, 오라클 및 썬 등은 모두 자사 SOA 스위트 내에서 UDDI 기능성을 제공하며, 그 주된 의도는 주로 자사 제품이나 ESB와 사용할 수 있게 하기 위해서다. BEA는 지난 해 리포지토리 전문 업체인 플래시라인(Flashline)을 인수했으며, IBM과 썬은 자체 레지스트리를 개발했다.
ESB에서와 마찬가지로, 단일 업체 아키텍처는 하나의 플랫폼에서 모든 서비스를 돌리는 조직들에게 적합하다. 또한 통합 셋업(unified setup)은 곧 거버넌스 플랫폼이 ESB와 보다 잘 통합될 수 있다는 의미며, 이는 실행시간에서 정책을 시행할 때 중요한 고려요소다. 하지만 다중 애플리케이션 플랫폼이 있는 기업에서는 로직라이브러리(LogicLibrary)나 시스티네트(Systinet, 현재 HP 머큐리 소속) 같은 전문 리포지토리 업체와 함께 하는 편이 나을 것이다. 서비스가 15개 미만 정도가 되는 SOA는 아마 리포지토리 없이도 그럭저럭 꾸려갈 수 있는데(특히 개발자에게 확실한 소스 코드 버저닝 시스템이 있을 경우), 이는 리포지토리가 그 기능성의 상당 부분을 모방하고 있기 때문이다.
ESB도 또한 포함하고 있는 SOA 스위트의 일부가 아니라면, 대부분의 SOA 거버넌스 플랫폼은 이미 배치된 서비스를 제어할 수 없다. 실행시간에서의 이들의 역할은 언제나 레지스트리로 한정돼 있으며, 애플리케이션은 레지스트리를 질의하고, 자신이 의존하는 서비스나 다른 서비스들을 로케이팅하는 데 사용하는 메타데이터를 검색한다. 서비스가 일단 인보킹이 되면 정책을 실행하기 위해 거버넌스에는 실행시간 관리가 통합돼야 한다.

실행시간 관리
SOA 관리는 하나의 웹 서비스 관리로 출발했으며, 그런 만큼 같은 제품들의 상당 수가 JABOWS 아키텍처로 사용될 수 있다. 그 이론은 웹 서비스 수가 많은 엔터프라이즈에서는 관리 제품을 이용해서 이들을 제어할 수 있고, 궁극적으로 처음부터 SOA를 구축할 수 있다는 것이다.
많은 웹 서비스 관리 사용자들이 ESB를 갖고 있지 않기 때문에, SOA 관리 시스템은 ESB에서 발견되는 콘텐츠 라우팅 기능이나 XML 프로세싱의 상당 부분을 복제했다. 정의상으로 볼 때는 SOA 관리 시스템이 다루는 모든 것은 이미 웹 서비스이며, 서비스가 합성 애플리케이션에 구축돼 있지 않을 경우 오케스트레이션할 것은 거의 없다.
하지만 SOA 관리 스위트는 단순한 하나의 ESB 라이트 이상이다. 그 핵심 기능은 실행시간을 모니터링하고 웹 서비스가 SLA나 기타 성능 기준에 부합하는지를 확인하는 것으로, 이는 ESB에는 없는 기능들이다. 성능이 좋지 못할 경우 SOA 관리는 오류를 고립시키고 애플리케이션들간의 의존성을 추적함으로써 개발자나 IT 관리자를 도울 수 있다.
인터넷에 노출된 웹 서비스는 데이터 센터 중심의 ESB에는 없는 보안 기능을 필요로 하며, 따라서 SOA 관리 제품들은 언제나 XML 서명과 XML 암호화 엘리먼트를 처리할 수 있다. 이들은 또한 ‘불량 서비스(rogue service)’, 즉 인터넷에 지나치게 노출된 웹 서비스를 식별할 수 있으며, 이는 그 결과가 멀웨어든, 패치되지 않은 취약성이든, 혹은 열정이 지나친 사용자든 마찬가지다.
모두 소프트웨어로만 제공이 되는 ESB나 레지스트리와 달리, SOA 관리는 하드웨어와 소프트웨어로 둘 다 사용이 가능하며, 이들은 각자 작동하는 방식에서 차이가 난다.
액셔널(Actional), 앰버포인트(AmberPoint) 및 SOA 소프트웨어의 소프트웨어 제품들은 모두 네트워크 관리 프레임워크와 상당 부분 같은 방식으로 작동하며, 애플리케이션 플랫폼에 탑재돼 나란히 서비스를 실행하는 에이전트를 사용한다. 덕분에 관리 시스템은 애플리케이션 내부에 대한 좋은 가시성을 갖지만 각 플랫폼이나 ESB용으로 별개의 에이전트가 만들어져야 한다. 플랫폼이 직접 지원이 되지 않을 때는 모든 트래픽이 통과해 라우팅되는 프록시 서버에서 에이전트가 돌아갈 수 있다. 프록시는 확장이 보다 용이하지만 막대한 성능 저하를 가져올 수 있다. 특히 SSL을 이용할 때 더욱 그러한데 여기서는 트래픽이 분석용으로 암호해독이 된 다음 다시 암호화가 돼야 하기 때문이다.

에이전트에 대한 하나의 대안
IBM의 데이터파워(DataPower)와 시스코의 리액티비티(Reactivity) 어플라이언스는 성능 감소를 줄여주는 맞춤 XML과 SSL 하드웨어를 이용하는 순수 프록시 방안을 채택했다. 하지만 프록시는 임베디드 에이전트들처럼 애플리케이션 내부에 대한 통찰력이 뛰어나지 못하다. 이들은 플랫폼과 독립적으로 실행되기 때문에 예를 들어 새로운 서비스를 자동으로 발견하지 못할 것이다.
에이전트에 대한 하나의 대안으로, 관리 업체들은 ESB나 애플리케이션 플랫폼에 의해 퍼블리싱된 API에 액세스할 수 있다. 불행히도 SNMP와 동등한 웹 서비스는 존재하지 않는다. 모든 시스템은 전용이며, 업체들간의 긴밀한 협동을 필요로 한다. 예를 들어 BEA는 앰버포인트(AmberPoint)의 SOA 관리 제품을 재판매하는데, 이것은 에이전트리스 방식으로 BEA의 아쿠아로직(AquaLogic)을 제어할 수 있다. 액셔널(Actional)은 이와 유사하게 프로그레스 소닉 ESB와 통합이 되며, 2006년 프로그레스에게 인수됐다.
현재 파트너십이나 단일 업체 스위트는 또한 실행시간 관리가 디자인 시간 거버넌스에 통합이 되는 방식이다. 전문 업체들 가운데 가장 멀리까지 간 곳은 SOA소프트웨어로, 여기서는 지난 12월 자체의 거버넌스 제품을 발표했다. 마찬가지로 오라클과 IBM에는 SOA 스위트에 얼마간의 관리 기능이 포함돼 있으며, HP는 지난해 관리 업체인 머큐리 인터랙티브(Mercury Interactive)와 이 회사의 시스티네트 거버넌스 제품을 인수했다.
표준화에 대한 최고의 희망은 웹 서비스의 정책을 설명한 표준인 WS-폴리시인 듯하다. 하지만 이것으로는 충분치가 못하기 때문에 몇몇 업체들은 관리와 거버넌스를 하나로 통합하기 위한 상호운용성 링크 세트인 SOA 링크를 작업 중이다. 거버넌스 업체인 인프라비오(Infravio)에 의해 만들어진 이 이니셔티브에는 순수 SOA 업계에 종사하는 대부분의 업체들이 포함돼 있다. 하지만 인프라비오가 현재 경쟁자인 소프트웨어AG 소속이라는 이유로 정작 덩치가 큰 IBM, 마이크로소프트, 그리고 썬 등은 여기에 참여하지 않을 것 같다.

보안 게이트웨이
보안 게이트웨이는 XML 방화벽으로 출발을 하며, 이것은 여전히 이들의 핵심 기능으로 존재하고 있다. 웹 서비스는 포트 80을 통해 곧장 나가기 때문에 인터넷에 노출된 SOA에는 트래픽 콘텐츠를 점검할 수 있는 방화벽이 필요하며, 여기에는 SOA 관리 소프트웨어에서 발견되는 것과 같은 보안 기능성이 상당 부분 포함된다. 게이트웨이의 콘텐츠 인식 프로세싱은 또한 라우팅과 ID 관리에도 사용될 수 있으며, XML이 관리나 ESB 서버에 미치는 부하를 덜어준다. 이런 경우 같은, 혹은 유사한 어플라이언스는 에지가 아닌 SOA에 깊숙이 배치될 것이다.
네트워크 인프라와 소프트웨어 업체간 충돌은 보안 게이트웨이 영역에서 가장 확실하다. 언제나 하드웨어 박스로 판매되긴 하지만 어떤 것들은 근본적으로 블레이드 서버 플랫폼에서 돌아가는 소프트웨어라 할 수 있다. 그리고 이미 다른 SOA 기능성으로 확장이 된 전담 하드웨어를 사용하는 것들도 있다.
소프트웨어쪽에는 보델(Vordel)과 엑스트라다인테크놀로지스(Xtradyne Technologies)가 있다. 엑스트라다인은 소프트웨어만 판매하는데, 이 제품은 SSL 가속기 카드 옵션이 있는 고객 소유의 블레이드 서버에 배치되도록 만들어졌다. 보델은 고객에게 소프트웨어와 어플라이언스간에 선택을 할 수 있게 했다. 순수 소프트웨어 방식의 이점은 이것이 비 XML 서비스를 지원하도록 보다 쉽게 적응될 수 있으며, 규모가 작은 네트워크에서는 다른 SOA 컴포넌트와 물리적 하드웨어를 공유할 수 있다는 점이다.
보델은 또한 자사 제품을 VM웨어와 함께 사용할 수 있는 하나의 가상 어플라이언스로 제공하고 있다. 가상화의 오버헤드는 곧 이것이 아직 실제 배치보다는 개발과 테스팅에 더 많이 사용되고 있음을 의미하지만, 이러한 상황은 앞으로 바뀔 것이다. AMD와 인텔이 성능 감소를 줄이기 위해 노력하고 있음을 감안할 때, 가상화는 SOA 인프라 자체가 민첩해질 수 있게 해주고, 하드웨어는 필요할 때만 암호화 같은 기능에 전담될 수 있게 할 것이다.
하드웨어 쪽에는 데이터파워(DataPower), 레이어7테크놀로지스 및 리액티비티(Reactivity)가 있으며, 이들은 모두 XML 가속화 ASIC를 사용하고 있다. 데이터파워와 리액티비티는 이미 각각 시스코와 IBM에 인수됐을 때 SOA 관리 영역으로 확장이 돼 있었다. 레이어7은 SOA 관리의 전체 영역에서 활동적이지는 않지만, SOA 내에서 사용될 수 있는 다양한 어플라이언스에서 순수한 보안 이상을 제공하고 있다.
인텔은 ASIC가 소프트웨어에 비해 갖는 속도 이점을 줄이기 위해 작업 중이며, 그 일환으로 2005년 어플라이언스 업체인 사베가(Sarvega)와 함께 얻은 소프트웨어를 사용하고 있다. 그리고 엑스트라다인이나 보델의 PC 기반 어플라이언스는 또한 단순히 소프트웨어에게 전담 서버를 주는 덕분에 성능 향상을 제공한다.
시스코와 레이어 7은 둘 다 타라리(Tarari)의 ASIC를 사용하는 반면 데이터파워는 자체적으로 이것을 만들었는데, 덕분에 IBM은 XML 프로세싱에서 매우 유리한 입장에 서게 되었다. IBM은 또한 데이터파워 하드웨어에서 돌아갈 수 있는 전체 소프트웨어 스위트를 갖고 있기 때문에 웹스피어 어플라이언스들이 미래의 제품으로 쓰일 가능성이 매우 크다. 어플라이언스로서 발표될 가장 유력한 후보자는 애플리케이션 서버 자체며, 그 다음이 아마 ESB나 기타 SOA 인프라일 것이다.

애플리케이션 전달 제어기
애플리케이션의 기능성이 하드웨어로 옮겨감에 따라, 네트워크 인프라 업체들이 기회를 발견하고 있다. 그 중에서 시스코가 가장 돋보이는데, 이는 이 회사가 이미 전통적인 네트워크 분야에서는 너무 지배적인 입장이라, 성장할 수 있는 유일한 길은 애플리케이션쪽으로 이동하는 것뿐이라는 관점에서 보면 놀랄 일도 아니다. 하지만 다른 네트워킹 사업자들도 또한 SOA 제품을 보유하고 있으며 이들은 대부분 ADC를 기반으로 하고 있는데, 여기서 ADC는 부하조절 기능에 캐싱이나 다른 데이터센터 중심의 방안을 결합시켜 애플리케이션 성능을 향상시키는 어플라이언스를 말한다.
ADC는 물론 SOA나, 심지어 웹 서비스에게도 전용이 아니며, 수년간 데이터 센터의 대들보 역할을 해왔다. 또한 이들은 최신 SOA 외부에서 꼭 필요한 게 아니다. 캐싱을 제외한 이들의 모든 기능은 SOA 중개 소프트웨어에서 처리가 될 수 있다. 하지만 이들은 기업이 SOA에서 기존의 인프라를 재활용할 수 있는 수단이 되며, 하드웨어 업체가 소프트웨어로 이동하는 데 있어 중추적인 역할을 한다.
ADC 업체들에게는 XML 라우팅이 부하 조절의 자연스러운 확장판이다. 서비스가 보다 전문화됨에 따라, 부하조절기는 어떤 서버가 가장 적합한지를 판단하기 위해 각각의 패킷을 보다 깊이 들여다 볼 필요가 있다. 이것은 한 때는 레이어 3에서 세션을 추적하는 것을 의미했지만, 지금은 레이어 7까지 추적이 이뤄진다. 마찬가지로 ADC는 이미 SSL, TCP 및 HTTP 압축의 하드웨어 가속화를 통해 서버를 보조하고 있다. XML은 단지 거기에 컴퓨팅 집약적인 동작이 하나 더 추가되는 것뿐이다.
부하조절기는 언제나 방화벽 다음에 놓이며, 따라서 이 두 가지를 합하면 아키텍처적으로 효과가 있을 수 있다. 특히 이 둘은 XML과 작동하기 위해 유사한 패킷 점검 기능을 필요로 하기 때문에 더욱 그러하다. 이것은 점점 더 ADC를 보안 게이트웨이와 경쟁 구도에 놓이게 만들고 있다. 시트릭스 넷스케일러(Citrix NetScaler)와 F5 BIG-IP는 이미 위협 방지를 제공하고 있으며, 이것은 원칙적으로 게이트웨이를 불필요하게 만든다. 마찬가지로 레이어7은 부하 조절 기능까지 확장을 했다. 하지만 이 두 가지 범주는 그 외 이들이 가속화하는 것에서 여전히 차이가 나는데, 게이트웨이는 XML에서 최고며 ADC는 보다 낮은 레이어인 TCP/IP에서 뛰어나다.
나아가 ADC 업체들이 스택 위로 이동함에 따라 컨버전스와 경쟁이 예상된다. 하지만 시스코의 AON 경험담은 신중한 마음을 갖게 만든다. 2년 전 출시된 이것은 타라리 기반의 XML 가속기로, 시스코 카탈리스트 6500 코어 스위치나 ISR 지사 라우터용 블레이드나 어플라이언스로 사용 가능하다. 게이트웨이 업체들과의 경쟁을 시도한 지 20개월이 지난 후 시스코는 경로를 변경해 리액티비티를 인수했다. 현재 시스코의 계획은 리액티비티 기술을 시스코의 ADC 플랫폼인 ACE(Application Control Engine)로 통합한다는 것이다.
시스코는 AON이 아직 살아 있다고 주장하고 있다. 이것은 현재 코어 애플리케이션 기능성을 위한 하나의 플랫폼으로 선전되고 있는데, 사실 ADC와 게이트웨이는 네트워크 에지에 놓이는 경우가 많다. 특히 AON은 시스코가 SAP와 함께 개발 중인 새로운 합성 애플리케이션 스위트를 돌릴 것이다. 지난해 4월 발표되고 조만간 시장에 선보일 이들은 SAP와 ESB, 그리고 애플리케이션 서버로부터 일부 기능들에 대한 부담을 AON 하드웨어로 넘겨줄 것이다. 시스코는 아직 이런 기능들이 무엇인지를 정확히 밝히지 않았다.

SOA 구축 체크리스트
1. 재활용 가능한 서비스로서 어떤 기능성을 노출시킬지 결정하라. 일반적으로 서비스가 실제로 다른 애플리케이션에서 유용하게 사용될 수 있으려면 가능한 간단하고 일반적이어야 한다. 기술 컨설팅 기관인 아큐멘솔루션즈(Acumen Solutions)에 따르면, SOA 배치에 있어 가장 큰 실수는 너무 전문적인 서비스를 노출시킴으로써 재활용의 가능성을 제한시키는 데 있다고 한다. 이것은 몇 개의 웹 서비스를 셋업하는 데도 적용이 되지만, SOA를 중심으로 모든 것을 재구성하는 기업의 경우 문제는 훨씬 심각해진다.

2. 비즈니스 프로세스를 자동화하려 하기 이전에 이것을 먼저 이해하라. SOA는 IT를 비즈니스에 맞출 수 있지만, 조직의 비즈니스 프로세스 자체가 관료적이고 비효율적이라면 이것은 단순히 문제를 증폭시킬 뿐이다.

3. SOA 관리나 ESB에 투자하라. 어떤 것에 할지는 SOA에 어떻게 접근하느냐에 따라 달라진다. ESB가 여전히 그린필드 SOA의 핵심 컴포넌트긴 하지만, SOA 관리는 JABOWS와 함께 하는 사람들에게 좋은 출발점이 될 수 있다. 어떤 것이든 레거시 통합용으로 사용될 수 있으며, 대형 SOA라면 결국 두 가지 모두 필요할 것이다.

4. 기반 애플리케이션 플랫폼을 계속 주시하라. 서비스가 돌아가는 서버가 늘어나는 부하를 처리할 수 없을 경우에는 서비스를 재활용할 수 있는 지점이 없다. 가상화, 클러스터링 및 오프로딩 서비스는 네트워크 인프라에 도움이 되긴 하겠지만 아직 유년기며, 현재로서는 직접적인 모니터링과 관리가 요구된다.

5. 레지스트리와 리포지토리를 계획하라. 일단 SOA가 약 15개 이상의 서비스로 성장을 하면 이것이 필요할 것이다. 이는 언제나 별도의 SOA 거버넌스 시스템을 의미하는데, 단 코드 관리 시스템이 있는 기업들에게는 ESB나 SOA 관리 제품에 번들링된 유사한 레지스트리로 충분할 수 있다.

6. 특히 SOA가 더 크게 성장할 때는 하드웨어 가속화 기술을 고려해 보라. 보안 게이트웨이에 있는 전담 XML 프로세싱이 WS-* 표준과 SOAP에서 사용되는 긴 XML 메시지에 가장 적합하다. ADC에 있는 TCP 오프로드와 부하조절 기능은 JSON이나 기타 에이잭스 포맷의 보다 짧은 다수의 메시지들에게서 도움이 된다.

7. 방화벽이 필요한지를 판단하라. XML 방화벽은 JMS 기반의 SOA에는 필수가 아니지만 인터넷에 노출된 HTTP 서비스용으로는 필수다. 이것은 언제나 보안 게이트웨이를 뜻하지만 ADC에서도 비슷한 기능을 발견할 수 있다.

데이터넷