Workshop - 비즈니스 애플리케이션
상태바
Workshop - 비즈니스 애플리케이션
  • 승인 2005.10.14 00:00
  • 댓글 0
이 기사를 공유합니다

효과적인 SOA로 가는 길

비즈니스 펑션이 곧 서비스 … 트레이드오프는 신뢰성

SOA(Service Oriented Architecture)는 본질적으로 웹 서비스와 HTTP에 연결되기 마련이지만, 사실 이것은 원래 의도와는 반대되는 것이다. SOA는 언어, 플랫폼 및 프로토콜에 구속되지 않는 개념으로, 서비스가 어디서 어떻게 이행되는지를 규정하지 않는다. 우리는 NWC 비즈니스 애플리케이션 랩에 우리가 만든 가상의 부품 제조업체를 위한 서비스 SOA를 구축했으며, 이를 통해 배운 바를 소개한다.

효과적인 SOA는 서비스 뿐만 아니라, 기반 인프라에 독립적이면서 이런 서비스가 검색되고 이용될 수 있는 수단도 또한 필요로 한다. 이것은 제품이나 사양이 아니기 때문에 무턱대고 밖에 나가서 턴키 SOA를 구입할 수는 없다. 대신 애플리케이션 서버, 미들웨어, 저장소, 그리고 심지어 중앙식 SOA 관리 패키지 등과 같은 많은 컴포넌트들을 이용해 이 아키텍처를 전략적으로 구축해야만 한다.
이것은 어머니 세대의 CORBA 이행이 아니며, 리패키징된 RMI(Remote Method Invocation) 기반 아키텍처도 아니다. SOA의 핵심 컴포넌트는 서비스다.
업체들은 종종 서비스란 말을 서비스가 제공하는 오퍼레이션(opertaion)을 설명하거나, 혹은 많은 비즈니스 오퍼레이션들을 제공하는 서비스 종단지점으로 사용하고 있지만, SOA에서의 서비스는 구매 주문을 확인하거나 은행 계좌들간 자금 운용 등과 같이, 보다 규모가 크고 복합적인 애플리케이션을 조화롭게 하기 위한 비즈니스 펑션(business function)을 말한다.
이들은 애플리케이션을 만드는 데 사용되는 비즈니스 로직의 초석을 이룬다. 그리고 종단지점은 SOA 서비스가 상주하는 애플리케이션 서버(BEA 시스템즈 웹로직, IBM 웹스피어, 오라클 AS, 썬 자바 AS)가 된다.
우리는 IBM 웹스피어 6.0 애플리케이션 서버(WAS)와 마이크로소프트 닷넷(.Net) 서버를 이용해 우리가 만든 가상 부품 제조업체인 NWC용의 SOA를 구축했다. WAS는 우리의 고객 데이터와 부품 주문을 관리하는 서비스를 하우징하며, 닷넷 서버는 부품 재고를 관리하는 서비스를 하우징한다. 두 종단지점은 모두 고객 접촉 복합 애플리케이션(customer-facing composite application)을 구축하는 데 필요하다.

펑션은 직관적으로
서비스의 펑션, 즉 SOAP(Simple Object Access Protocol) 식으로 말하자면 오퍼레이션은 직관적이어야 하며, submitPurchaseOrder이나 validateCustomer Accounts와 같이 이들의 이름을 기반으로 해야 한다.
SOA에서는 전형적인 애플리케이션 인프라와 달리 단 하나의 서비스만이 주어진 비즈니스 펑션에 대해 권한을 가져야 한다. 엔터프라이즈 애플리케이션에는 언제나 같은 비즈니스 로직의 단편이 포함돼 있거나, 혹은 심지어 고객 주문과 같은 특정 객체를 재활용하기도 하지만, SOA에서는 사용 가능한 단 하나의 비즈니스 펑션 인스턴스를 만들게 된다. 이렇게 하면 다중 애플리케이션에서 기능성을 재활용하고, 변화하는 시장의 상황에 맞도록 비즈니스 로직을 신속하게 변경할 수 있으며, 이것이 바로 SOA의 큰 이점이기도 하다.
보다 큰 SOA 내에서 하나의 비즈니스 펑션 인스턴스를 표시할 때는, 비즈니스 규정이나 스토리지 메커니즘에 생기는 어떠한 변화든 이 기능에 의존하는 모든 애플리케이션에서 자동으로 업데이트된다. 따라서 예를 들어 가격 변동이나 할인율 변경 등과 같은 것들이 모든 애플리케이션으로 적용된다. 때문에 변경을 이행하는 데 걸리는 시간이 줄어들며, 변화하는 시장 상황에 신속하게 대응할 수 있게 해준다.
마찬가지로, 서비스 뒤에 있는 인프라에 생기는 변화도 서비스를 이용하는 애플리케이션에게 투명한 상태로 유지된다. 예를 들어 데이터베이스 버전을 마이그레이팅할 경우 이 변화로 인해 영향을 받는 서비스만이 변경될 것이다. 그리고 SOA에 있는 애플리케이션은 서비스만을 레퍼런싱하기 때문에 이들은 인프라에 생기는 어떠한 변화도 심지어 눈치도 채지 못한다. 과거에는 미들웨어나 데이터베이스에 생기는 변화는 곧 이 소프트웨어에 액세스하는 데이터베이스 애플리케이션을 포함한 엔터프라이즈 전체의 중단을 의미했다.
하지만 SOA의 트레이드 오프로 신뢰성이 있다는 사실을 명심해야 한다. 이는 특히 HTTP를 통해 가장 자주 전송되는 웹 서비스/SOAP에서 더욱 두드러진다. HTTP는 안정적이지 못하며 본질적으로 신뢰성이 없기 때문에, HTTP를 통해 전달되는 기간 트랜잭션은 보장을 받지 못한다. 비교적 최근에 두 가지 경쟁적인 표준들, 즉 WS-RM(Web Service Reliable Messaging)과 WS-R(Web Services Reliability)이 이런 문제를 해결하기 위해 만들어졌지만, 오늘날의 SOA 이행에서는 ESB(Enterprise Service Bus)와 같은 보다 전통적인 방안을 이용해 신뢰성을 보장하고 있다.

디렉토리 포함한 중앙 저장소
ESB 미들웨어는 SOA의 백본 역할을 하면서 메시지 신뢰성, 예외상황 처리 및 퍼블리케이션-서브스크립션 모델(publication-subscription model) 능력을 제공할 수 있다. 이것은 IBM의 MQ 시리즈, 팁코(Tibco)의 EMS, 그리고 개방형 표준인 JMS(Java Message Service) 사양과 같은 기존의 저장 후 전송(store-and-forward) 미들웨어 메시징 기술과 유사하다. 종단지점에서 하우징되는 서비스는 ESB로 향하는 관문의 역할을 하며 비동기 서비스 메커니즘을 지원하고 메시지 전달을 보증한다. ESB는 또한 통합 지점으로서의 역할을 하면서 엔터프라이즈에서 같은 트랜잭션으로의 다중 애플리케이션 액세스를 제공할 수도 있다.
잘 계획된 SOA의 두 번째 요소는 엔터프라이즈에서 사용 가능한 모든 서비스의 디렉토리를 포함하고 있는 중앙 저장소로, 이들은 각자의 조직에 가장 잘 맞게 어떤 식으로든 분류돼 있다. 여기에는 비즈니스 펑션, 비즈니스 유니트, 데이터 소스, 혹은 심지어 소스 코드 버전에 따른 그루핑(grouping)도 포함될 수 있다. 개발자들이 새로운 애플리케이션으로 통합시키는 데 필요한 서비스를 쉽게 찾을 수 있도록 해줄 분류법을 이용하도록 하라.
SOA에서 이런 기능성을 제공하는 메커니즘은 레지스트리다. 레지스트리는 UDDI(Universal Description, Discovery and Integration) 표준을 기반으로 하는데, 이것은 웹 서비스의 옐로우 페이지(yellow page)라 할 수 있다. 여기에는 회사와 거기에 연관된 서비스(UDDI, WSDL 및 SOAP는 모두 OASIS에 의해 관리된다) 목록이 있다. 이 레지스트리는 비즈니스 파트너들이 액세스할 수 있게 할 수 있으며, 궁극적으로는 이들의 애플리케이션과 신속한 통합을 가능하게 해준다.
이것은 꿈처럼 달콤하게 들리겠지만, 신뢰성은 그 파트너나 소비자 접촉 서비스가 종종 ‘복합 웹 서비스’ 형태의 다중 서비스들로 구성되고 그 개발을 위한 핵심 컴포넌트가 UDDI일 때의 얘기다. UDDI는 거래 파트너와 공급망들간에 서비스를 통합할 수 있는 수단을 제공한다.
인프라비오(Infravio)의 레지스트리(Registry), SOA 소프트웨어의 서비스 매니저(Service Manager), 그리고 시스티넷(Systinet)의 비즈니스 서비스 레지스트리(Business Service Registry) 등과 같은 UDDI 레지스트리 소프트웨어는 SOA 서비스가 분류되고, 액세스되고, 어떤 경우 관리되는 중앙 지능성 허브로서의 역할을 한다.

관리와 보안
마지막이긴 하지만 결코 덜 중요하지는 않은 것은 사라지지 않을 SOA의 관리와 보안에 대한 필요다. 사용되기를 기다리는 수백 가지 서비스들이 있기 때문에 사용 가능한 모든 서비스들이 모니터링되고 나아가 보안될 수 있는 중앙 관리 시스템이 필요하다.
많은 에이전트 기반 제품과 비 에이전트 제품들이 SOA 관리를 지원하고 있다. 엔터프라이즈에서의 서비스 관리를 위한 가장 인기 있는 옵션들로는 액셔널(Actional)의 SOAP스테이션(SOAPStation), 앰버포인트(AmberPoint)의 매니지먼트 파운데이션(Management Foundation), 서비스 레벨 매니저(Service-Level Manager), 그리고 익셉션 매니저(Exception Manager), 리액티비티(Reactivity)의 게이트웨이(Gateway)와 SOA 소프트웨어의 서비스 매니저(Service Manager) 등이 있다. 그리고 컴퓨터어쏘시에이츠(유니센터)와 휴렛팩커드(오픈뷰)는 모두 SOA의 운영적 관리와 모니터링을 위한 제품을 제공하지만, 이들은 여기까지가 한계다.
SOA를 관리한다는 것은 곧 개별적인 서비스 건강을 모니터링하는 것뿐만 아니라 사베인 옥슬리(Sarbanes-Oxley), 캘리포니타의 SB 1386, GLBA(Gramm-Leach-Bliley Act), HIPAA(Health Insurance Protability and Accountability Act) 등과 같은 법규의 필요조건을 준수하는 데 필요한 로깅/감사 능력을 의미한다.
SOA 관리 소프트웨어는 또한 제대로 파악이 안 되는 접속과 상호운용성 문제를 그 메시지 캡처 도구를 통해 자동으로 추적함으로써 배치를 한결 수월하게 해준다. 이것은 전통적인 네트워크 프로토콜 캡처 툴을 훨씬 능가하는 부분이다.
일반적인 SOAP 관리 제품을 이용하거나, 혹은 독립적으로 조직의 특수한 필요에 맞게 SOA를 보안할 수 있다. 예를 들어 NWC에서는 재정적인 관점에서 보안과 관리 모두를 위한 하나의 솔루션을 선택하겠지만, 큰 조직에서는 보안과 관리를 별도로 생각할 수 있을 것이다. SOA용 보안 및 관리 기능을 제공하는 모든 제품은 현재 완전 프록시며, IP와 마찬가지로 요청이 건너가야 하는 연결이 많을 수록 성능은 고통을 받는다.
데이터파워(DataPower)의 XS40, 포럼시스템즈(ForumSystems)의 센트리(Sentry)와 X월(XWall), 리액티비티(Reactivity)의 게이트웨이(Gateway), 사비가(Sarvega)의 XML 가디언(Guardian) 등과 같은 보안 소프트웨어들은 모든 서비스 요청이 가로질러 가야 할 하나의 액세스 지점을 제공한다.
SOA의 기본 디자인에서는 인벤토리와 같은 비즈니스 객체 유형에 따라 서비스를 그루핑하는 경우가 많으며, 여기서는 데이터에 액세스하고 이것을 변경하는 용도의 인터페이스가 모두 제시된다. 종단지점으로의 액세스를 갖는다는 것이 곧 애플리케이션이나 특정 사용자가 모든 서비스로의 액세스를 가진다는 것을 보증하지는 않기 때문에, 각각의 개별적인 기반으로 서비스를 보안해야 한다.
서비스를 호스팅하는 애플리케이션 서버를 통해 보안을 제공할 수도 있지만, 비즈니스 파트너가 회사의 SOA와 상호작동할 경우 이것은 실현 불가능하다. 애플리케이션 개발자들이 무거운 리프팅을 할 필요 없이 파트너(나 심지어 소비자)에게 SOA로 액세스를 제공하는 데는 외부 웹서비스(WebServices)나 XML 보안 게이트웨이가 보다 유연하게 사용될 수 있다. 그리고 SOA가 느슨하게 결합된 시스템들이 전부라는 점을 감안할 때, 서비스들로부터 어떻게든 보안과 관리 기능을 분리해 두는 것이 보다 효과적이다.

Step by Step

SOA로 가는 길

1. 조직에서 SOA 서비스를 규정하라. 필요한 서비스와 특정 비즈니스 펑션을 결정하라(비즈니스 오너들과 협력하여). 서비스를 가능한 한 가장 폭넓은 비즈니스 이용에 적용시킴으로써 SOA로부터 최대한을 뽑아낼 수 있을 것이다.

2. 서비스를 구축하라. 시간 소모적인 일이겠지만 탐색 프로세스가 철저할 경우 값진 열매를 얻게 될 것이다.

3. 서비스를 분류하라(catalog). 2단계와 연계되어 수행될 경우, 많은 시간을 절약할 수 있다. 시스티네트의 비즈니스 서비스 레지스트리와 같은 레지스트리들은 애플리케이션 서버를 모니터링할 수 있으며, 서비스를 실행하고 이들을 자동으로 레지스트리에 추가시켜 준다. 때문에 남은 일은 어렵지 않은 메타데이터 태깅(metadata tagging)뿐이다.

4. 서비스를 관리 및 보안하라. SOA 서비스용으로 디폴트 보안 정책을 만들고, 비즈니스 파트너와 사용자들의 필요에 따라 이들을 변경하라. 서비스 성능을 모니터링하고 매일 액세스하라. 운영상의 통계는 조직 자원을 통한 ROI를 보여 줄 때 유용하게 사용할 수 있다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.