|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
|
 |
|
Bobby Woolf, IBM Sofware Services for WebSphere, IBM 2006 년 8 월 07 일 아이비엠이 서비스 지향 아키텍처 관리를 정의한 방식에 대해 알아보고 서비스 지향 아키텍처 관리란 무엇인지, 관리가 서비스 지향 아키텍처 프로젝트 성공에 중요한 이유를 배워봅시다. 서비스 지향 아키텍처(SOA)는 비즈니스 모델과 최적으로 잘 맞는 소프트웨어 애플리케이션을 개발하는 데 있어 매력적인 기술이다. 하지만 SOA는 IT 부서 및 팀원 가운데만이 아니라, 비즈니스 및 정보기술(IT) 간에 요구되는 협력 및 조정 수준을 증가시켰다. SOA 관리는 이런 협력 및 조정수준을 제공하고 주로 서비스 및 SOA 애플리케이션을 지원하는 방식을 지정하고 관리하는 태스크 및 과정을 다룬다. 이 글에서, 관리 및 관리가 무엇인지, 관리 및 관리가 중요한 이유 등에 대해 알아본다. 우리는 다음과 같은 SOA 관리의 중요한 특징에 대해 검토할 것이다. 아울러 SOA 애플리케이션에서 SOA 관리가 필요한 이유에 대해 확실히 알아야 한다. 또한 여러분의 조직이 자체적으로 SOA 관리 방식을 구축하는 방식에 대해서도 어느 정도 알게 될 것이다. 관리에 대해서 얘기하기 전에, 회사 IT 부서에서 일반적으로 벌어지는 상황에 대해 생각해 보자. 즉 관리가 없을 때 벌어지는 상황에 대해 생각해 보자. 당신이 통화량을 다른 나라 통화로 바꾸는 멋진 서비스를 개발했다고 해보자. 당신은 작업하고 있는 순서-처리 프로그램에서의 다른 위치에 서비스가 필요해 프로그램의 임의의 위치에서부터 호출하는 재사용 함수로 코드를 작성한다. 또 다른 프로그램에서도 서비스가 필요해, Java . jar에 코드를 넣어 서비스를 필요로 하는 임의의 프로그램의 클래스경로에 추가한다. 하지만 서비스를 기동하는 데 오랜 시간이 걸린다는 점이 서비스에서 나타나는 문제다.Yahoo 통화 변환기 웹 사이트상에 개제된 서비스와 같이 통화-환율로 서비스를 초기화해야 하기 때문이다. 통화량을 변환해야 될 때마다, 이 단계는 서비스를 초기화하는 데 시간이 너무 오래 걸린다. 따라서 당신은 자체적인 작은 프로그램에 변환기를 호스트한다. 이 작은 프로그램은 작동을 시작하고 초기화하고, 항상 실행하고 원격 API를 통해 프로그램의 일부에서 호출된다. 아마도 API는 HTTP 웹 서비스에 대한 SOAP로 구현되거나 단지 IIOP에 대한 RMI를 지원하는 원격 Enterprise JavaBeans(EJB) 인터페이스에 불과할 것이다. 지금 가지고 있는 건 통화량 변환기 서비스다. 당신의 몇 가지 프로그램에서 사용하고 있을 뿐만 아니라, 부서 내의 동업자들도 통화량 변환기 서비스를 선호해 자신들의 프로그램에서 그 서비스를 호출하기 시작한다. 머지 않아 들어본 적이 없어 잘 알지 못하는 당신 회사의 다른 부서에 있는 프로그램도 그 서비스를 사용하고 있다. 변환기가 많이 실행되고 있어, 응답시간이 느려진다. 따라서, 당신의 매니저에게 서비스를 호스트할 더 강력한 머신을 구매하라고 설득한다. 매니저는 자신의 예산에서 돈을 쓰는 것에 대해서 좋아하지 않는다. 매니저가 들은 또 다른 머신은 그저 단순한 기능만 하기 때문이다. 하지만 그를 설득한다. 어느 주말, 전혀 들어보지 못한 회사의 누군가에게서 집에 전화가 왔기 때문에 당신은 머신이 충돌했다는 사실을 알게 된다. 그 사람은 회사로 와서 변환기를 다시 작동시킬 것을 요구한다. 나중에 매니저가 적절한 방식으로 현재 환율이 업데이트되지 않아 또 다른 부서에서 변환기에 대한 불만들을 접수했다고 말한다. 그는 당신이 변환기를 고치길 원하지만 또한 실제 업무 시간을 낭비하지 않길 원한다. 이 경우 당신은 어떻게 책임을 지게 될까? 어느날 당신이 "이거 어쩌란 말이야."라고 말했다 치자. 그래서, 변환기에 대해 더 이상 책임을 지지 않고 변환기를 셧다운시켰다고 해보자. 변환기 고장에 대한 책임자를 찾으려고 하는 사람들로부터 불만사항이 있는 수많은 이메일이 회사전체에 유포되기 시작한다. 상당히 가치있는 프로그램들이 컨버터 없이는 작동되지 않는다고 항의하는 이메일이 수두룩하다. 고객은 화가 났고 회사는 돈을 잃고 있다. 재수 없게도, 모든 사람이 그 책임자가 당신이었다는 것을 알게 될 때 당신은 해고될지도 모른다. 이런 일이 어떻게 해서 발생된 걸까? 이제 플립쪽을 고려해 보자. 당신은 이 회사에서 다른 직원으로, 상품 카탈로그 애플리케이션을 연구한다. 다른 나라에 있는 사용자들이 자기 나라의 통화로 상품의 비용을 보길 원한다. 동업자들은 당신에게 각 상품의 가격을 사용자 국가의 통화로 바꾸는 호출 서비스에 대해 얘기한다. 당신은 그 서비스를 시험한 다음, 작동된다는 것을 충분히 확신하게 된다. 그래서 호출 서비스를 사용해 당신의 애플리케이션을 구현한다. 당신의 매니저는 기록시간에 작동되는 호출 서비스 기능 때문에 만족해 한다. 고객들은 그 기능을 좋아하고 당신의 웹 사이트 상의 판매 실적은 현저하게 증가한다. 그리고 난 뒤 어느 주말, 당신의 웹 사이트 가동이 중단됐다. 웹 사이트에서 다른 나라 통화로 표시가 안 되는 바람에, 매니저는 당신에게 전화를 걸어 프로그램을 수리하라고 말한다. 당신은 호출서비스에 대해 말한 동업자에게 집에서 전화를 건다. 반면, 판매 부사장 대리는 당신에게 소비자들이 불만을 가지고 있다고 통지한다. 당신은 호출서비스를 분명히 작성한 친구에게 이 사실을 말한다. 대리는 그 친구에게 전화를 절어 회사로 와서 당장 호출서비스를 작동시키라고 요구한다. 반면에 당신은 애플리케이션에 아무런 문제가 없었는데도, 단순히 호출서비스 때문에 카탈로그 애플리케이션 작동이 중지되어 곤란한 지경에 빠진다. 어떻게 해서 이런 일로 당신이 잘못하게 되었는가? 그래서 SOA 관리가 필요한 것이다. 이 경우 효과적인 관리가 부족해서 생기는 문제들이다. 서비스 제공 사업자와 서비스 소비자 둘 다 흥정한 것보다 훨씬 더 많은 책임이 있다. 이와 같은 곤란한 상황이 발생되지 않고도 서비스들을 어떻게 이용할까?
관리가 비효율적일 때 일어나는 현상들을 봤다. IT 관리가 더 나은 경우 IT 관리가 IT가 어떻게 전보다 더 낫게 작동될까? 먼저 우리는 관리가 무엇인지, 그리고 관리가 IT 및 서비스에 영향을 주는 방식에 대해 이해해야 한다. 일반적으로, 관리는 그룹이 함께 작업하기로 동의한 방식을 수립하고 시행하는 것을 의미한다. 특히 두 가지 관리 측면이 있다.
관리는 다음과 같은 방식으로 관리와 구분된다.
따라서 관리란 할 임무를 말하고, 관리는 임무가 수행되고 있는지 확인하는 작업이다. 관리의 특수한 형태는 IT관리로 다음과 같은 역할을 수행한다.
즉, IT 관리는 IT 부서에서의 책임자 및 부서에서 그와 같은 책임을 수행하는 사실을 아는 방식에 관한 것이다. SOA는 관리에 다음과 같은 고유의 측면`을 추가한다.
관리는 일반 IT에서보다 SOA에서 더 중요한 문제가 되고 있다. SOA에서, 서비스 소비자와 서비스 제공 사업자는 다른 과정에서 실행하고 다른 부서들에 의해 개발되고 관리된다. 뿐만 아니라 이들이 서로 함께 일하기 위해선 많은 협력이 필요하다. SOA가 성공하려면, 다중 애플리케이션은 공통 서비스를 공유해야 한다. 이는 이와 같은 서비스를 일반이 이용할 수 있고 재사용되는 데 있어 서비스 소비자 및 제공 사업자가 서로 협력해야 한다는 것을 의미한다. 이와 같은 것들이 관리에 관한 문제들이고 단일 애플리케이션 시대, 심지어는 재사용 코드 및 구성요소 시대 때보다 훨씬 복잡하다. 회사에서 비즈니스와 IT를 더 잘 맞추기 위해 SOA를 사용하고 있을 때 전체적인 IT 관리를 향상시키기 위해, SOA 관리를 사용하는 것이 이상적이다. 회사가 SOA의 장점을 실현하고자 한다면, SOA 관리를 사용하는 것이 중요하다. SOA가 성공하려면, SOA 비즈니스 및 기술 관리는 선택이 아니라 필수가 되어야 한다. 실제로, SOA 관리로 재사용 서비스가 개발되고 서비스의 설계 및 개발 방식 및 아울러 시간에 따른 서비스의 변화 방식까지 수립한다. SOA 관리로 서비스 공급업체와 서비스 소비자 간의 계약을 수립하고 소비자에게 기대하는 것, 이 계약을 통해 서비스 소비자들에게 기대하는 것, 서비스 제공 사업자들이 해야 될 임무들에 대해 명시한다. SOA 관리에서는 서비스를 설계하지 않고 서비스를 설계할 방식을 안내할 뿐이다. 이 관리로 SOA와 관련된 까다로운 수많은 질문을 해결하는 데 도움이 된다. 질문들은 다음과 같다. 어떤 서비스가 유용한가? 서비스의 신뢰도는? 서비스 지원기간은? 변하지 않는 서비스를 신뢰할 수 있는가? 서비스가 변하길 원할 경우엔 어떻게 할까? 아니면 새로운 기능을 추가하는가? 서비스 노출을 결정한 이유만으로, 서비스를 영원히 지원할 의무가 있다는 것을 의미하는가? 서비스 소비를 결정한 경우, 서비스가 내일도 셧다운되지 않을 거라고 자신하는가? SOA 관리는 기존 IT 관리 기술 및 실례에 근거해 구축된다. 자바2 플랫폼인 엔터프라이즈 에디션(J2EE)와 같은 객체-지향 기술을 사용할 경우, IT 관리의 가장 중요한 측면은 코드 재사용이다. 코드 재사용은 또한 IT 관리의 어려움을 잘 설명한다. 모든 사람들은 재사용 자산이 좋다고 생각한다. 하지만 재사용 자산을 실제로 쓸모있게 하는 게 어렵다. 재사용 자산을 개발하기 위해 누가 지불하겠는가? 개발 팀은 자산을 다시 재사용하기 위해 실지로 노력할 것인가? 모든 사람이 정말로 재사용 재산에 관한 단일기능에 동의할 수 있을까? 또는 모든 사람이 결국 실지로 재사용되지 않는 자신만의 맞춤형 버전을 소유할 것인가? SOA 및 서비스는 이와 같은 관리 문제를 더욱 중요하게 부각시켜 문제의 결과를 더욱 의미심장하게 만든다. 관리는 기술적, 비즈니스 문제보다는 정치적 문제에 가깝다. 기술은 인터페이스 및 호출 인터페이스를 맞추는 것에, 비즈니스는 고객에게 제공할 기능에 초점을 두고 있다. 기술과 비즈니스는 요구조건에 중점을 두고 있다. 관리는 그와 같은 측면에 관여하기도 하지만, 모든 사람들이 같이 협력하면서 개별적인 작업이 서로 어긋나지 않는다는 점을 확고히 하는 데 더 중점을 두고 있다. 관리로 결정의 결과가 아닌 내린 결정 및 결정을 내릴 주체를 결정한다. 두 당사자인 소비자와 공급업테는 같이 협력하는 방식에 합의해야 한다. 이와 같은 합의는 서비스 레벨 계약서(SLA), 서비스 제공 사업자가 달성하고 서비스 소비자가 따르기로 합의한 측정 가능한 목표에 표현된다. 이 계약서는 당사자들간의 계약서와 비슷하고 사실 법적인 계약서일 수 있다. 적어도, SLA에는 서비스 제공 사업자의 의무 및 소비자의 기대에 대해 명확히 나타나 있다. SOA로 기업의 성공을 보장하는 정책을 수립, 감독하는 우수연구센터(center of excellence, COE) 및 전문가 이사회에서 SOA 관리를 규정한다. COE는 서비스의 식별 및 개발, SLA의 수립, 레지스트리 관리 및 효과적인 관리를 제공하는 기타 대책들에 관한 정책을 수립한다. COE 임원들은 이런 정책들을 실행에 옮기고, 팀에게 서비스 및 복합 애플리케이션 개발에 대해 조언하고 지원한다. 일단 관리 COE가 정책을 수행하고 나면, 이러한 정책을 관리하는 데 기술을 사용한다. 기술은 SLA를 정의하지 않지만, 신뢰성을 시행, 평가하는 데 사용된다. 예를 들어, 기술을 통해 서비스를 호출할 고객 및 고객의 서비스 호출 시기에 대해 제한할 수 있다. 또한 기술을 통해 서비스 가치가 하락되었다고 소비자에게 경고를 주며, 서비스의 가용성 및 응답 시간을 측정한다. 엔터프라이즈 서비스 버스(ESB) 및 서비스 레지스트리를 조합시키는 것을 통해서야말로 기술로 관리 정책을 시행하는 좋은 상황이 된다. 서비스를 노출해 일정 ESB만 서비스를 호출할 수 있다. ESB/레지스트리 조합은 소비자의 접근기능을 제어하고 사용률을 모니터, 측정하고 SLA 신뢰성을 측정한다. 이런 식으로 서비스는 비즈니스 기능의 제공에, ESB/레지스트리 조합은 관리 측면에 중점을 두고 있다. 관리는 SOA의 단점에 있어 희생양이 될 수 있다. 성능면에서 보면 관리는 발생하는 모든 문제에 관한 압도적인 관심사일 뿐만 아니라 변명거리로 등장하고 의문이 되는 모든 솔루션에 대한 정당화 구실을 할 수 있다. SOA 토론(말싸움장으로 변함)장으로 일방적인 의견만 제시할 뿐이고 당신은 유익한 모든 대화가 중단되는 것을 보게 된다. 관리를 지혜롭게 사용해 관리에 관한 문제로 다른 사항들이 발목잡히지 않는 상태에서 SOA를 잘 작동시키도록 하는 것이 SOA에서 주어진 과제다.
SOA 관리는 단지 관리의 단일 집합일 뿐만 아니라, 함께 조합되는 많은 실례들의 집합이다. 각각의 SOA 관리 측면은 다음 글에서 더 자세하게 토론할 만한 가치가 있다. 지금 하는 이와 같은 토론은 단지 간단한 개요에 불과하다. 몇 가지 관리에 관한 측면에 대한 더 자세한 사항은 참고자료를 참조하라. SOA 관리의 가장 기본적인 측면은 서비스 생성과정을 감독하는 것이다. 서비스를 반드시 식별하고 서비스 기능을 설명하고, 서비스 기능을 조사하며 서비스 인터페이스를 설계해야 한다. 관리 COE는 이와 같은 작업을 수행하지 않을 수도 있지만 이런 작업이 수행 중인지는 확인한다. COE는 서비스를 생성하고 서비스를 필요로 하는 팀을 구성해 이들의 필요를 충족시키고 이중 노력을 피하도록 한다. 서비스여야 하지만 그렇지 않을 수도 있는 불분명한 것이 종종 있다. 함수는 일련의 반복 비즈니스 태스크를 일치시켜야 한다. 서비스 경계에선 재사용 가능하고 컨텍스트가 없는 기능을 소중히 보호해야 한다. 인터페이스는 서비스의 기능을 노출하지만 서비스의 구현 방식은 숨기고 구현 방식이 변경되거나 대체 구현방식을 허용하도록 해야 한다. 서비스를 처음서부터 설계할 때 비즈니스를 모방하기 위해 설계한다. 서비스가 기존 기능을 포함할 경우 좋은 비즈니스 인터페이스를 생성하고 구현하는 게 더 어려울 수도 있다. 서비스 경계를 정의하는 잠재적인 어려움 가운데서 흥미로운 예는 트랜잭션 경계를 설정하는 곳이다. 서비스는 보통 자체 트랜잭션에서 실행되고 기능이 완전히 작동되든지, 완전히 원래대로 되돌아가던지 여부를 확고히 한다. 하지만 서비스 조정자(조정자 또는 구성자)는 단일 트랜잭션(이상적으로 WS-AtomicTransactions와 같은 특정 상호작용을 통해)에서 다중 서비스의 호출을 원할 수도 있다. 이런 작업은 호출자의 트랜잭션에 관여할 수 있도록 트랜잭션 지원기능을 노출하는 서비스 인터페이스가 필요하다. 하지만 그와 같은 노출과정은 호출자에 대한 신뢰가 필요하며, 서비스 제공 사업자에는 위험할 수도 있는 것이다. 예를 들어, 서비스 제공 사업자는 서비스를 제공할 리소스를 잠글 수도 있다. 하지만 호출자가 트랜잭션을 전혀 끝내지 않을 경우 (트랜잭션 커미트 실패 또는 되돌아가기), 서비스 공급업체는 리소스 잠금기능을 확실히 푸는 데 어려움을 겪게 된다. 이 상황에서 보듯, 서비스 및 지배자 영역을 결정하는 것은 때로는 쉬운 일이 아니다. 서비스는 순간적으로 생성돼 영원히 존재하는 건 아니다. 임의의 소프트웨어와 마찬가지로, 서비스를 계획하고, 설계하고, 구현하고, 전개하고, 유지보수하고, 궁극적으로 폐기처분해야 한다. 애플리케이션 생명주기는 공개되어 있고 조직의 많은 부분에 영향을 미친다. 하지만 다중 애플리케이션은 단일 서비스에 따라 다르기 때문에 서비스의 생명주기 영향은 더 크다. 레지스트리의 사용을 고려해 볼 때 서비스의 생명주기는 더욱 분명해진다. 새로운 서비스를 레지스트리에 추가할 때는 언제인가? 레지스트리에 있는 모든 서비스가 필연적으로 유용하고 서비스를 사용 준비가 되었는가? 폐기처분된 서비스는 레지스트리에서 제거되어야 하는가? 모든 서비스 및 조직에 적절하게 다 맞는 생명주기는 하나도 없는 반면, 일반적인 서비스 개발 생명주기에는 5가지 주요단계가 있다.
서비스 폐지로, 효과적으로 서비스 버전 설정이 해제된다. 서비스 폐지일을 미리 계획, 공표해야 한다. 서비스를 폐지하기 오래 전 서비스의 사용을 중지해 프로그램면에서 소비자들에게 다음 프로그램을 계획할 수 있도록 경고를 주어야 한다. SLA에서 서비스 사용중지 및 폐지에 대한 스케줄을 지정해야 한다. 여기서 한 가지 빠진 것으로 보이는 단계가 바로 "유지보수" 단계다. 유지보수 단계는 서비스가 사용단계일 때 발생한다. 이 단계에서 서비스는 도로 테스트 단계로 넘어와 적절한 기능 여부를 재확인한다. 하지만 이런 단계는 능동 서비스 제공 사업자에 의존하는 기존 사용자들에게는 문제가 될 수 있다. 유지보수 단계는 기대한 것보다 덜한 서비스에서 발생한다. 서비스 유지보수는 종종 기존 서비스 변경이 아닌 새로운 서비스 버전 생성 등을 포함한다. 서비스가 이용가능하면 곧바로 서비스 사용자들은 서비스 변화를 필요로 한다. 버그를 수정해야 하고 새로운 기능을 추가해야 하고 인터페이스를 재설계하고 필요없는 기능을 제거해야 한다. 서비스는 비즈니스를 반영한다. 따라서 비즈니스가 변하면 서비스도 변해야 한다. 하지만 기존 서비스 사용자들과 함께 서비스를 잘 변화시켜서 서비스의 성공적인 운영에 걸림돌이 되지 않도록 해야 한다. 동시에 서비스의 안정성을 추구하는 기존 사용자들의 필요로 인해 부가적인 기능추가를 바라는 사용자들의 필요를 막아선 안 된다. 서비스 비저닝은 이런 상충되는 목표를 충족시킨다. 서비스 비저닝으로 기존 서비스에 만족하는 사용자들은 서비스를 변화시키지 않은 상태에서 계속 사용하게 되면서도 서비스가 진화해 새로운 요구조건에 있는 사용자들의 필요를 충족시킨다. 현 서비스 인터페이스 및 기능은 한 버전으로 보존되지만 새로운 서비스는 다른 버전으로 소개된다. 버전 호환성으로 한 버전을 예상하는 소비자는 다르지만 호환성이 있는 버전을 호출하게 된다. 버져닝은 이와 같은 문제를 해결하는 데 도움이 되지만, 새로운 문제인 서비스 이전에 관한 필요성을 야기시킨다. 소비자는 서비스 비저닝으로도 서비스에 의존할 수 없다. 특히 서비스에서 원하는 버전을 영원히 이용하면서 지원할 수는 없다. 결국 서비스 제공 사업자는 서비스 제공을 중단시켜야 한다. 버전 호환성으로 이와 같은 서비스 사용중단일을 연기하는 데 도움이 되지만 그래도 서비스 사용중단을 취소할 수는 없다. 비저닝으로 서비스 개발 생명주기가 줄어드는 것은 아니지만 다음 세대에 걸쳐 그 생명주기는 끝나게 된다. 소비자가 서비스 사용을 개시할 경우, 비저닝으로 서비스 종속성을 생성하며 그 종속성은 관리되어야 한다. 새로운 서비스 버전으로의 계획적, 주기적 이전을 위해 종속성 관리 기술을 이용한다. 이와 같은 방식으로, 소비자는 서비스에 추가된 부가적 기능을 이용하게 된다. 하지만 가장 좋은 관리를 가진 기업의 경우에서도, 서비스 제공 사업자는 소비자 서비스 이전에만 의존할 수 없다. 레거시 코드, 인력, 예산, 우선권 등 여러 가지 이유로, 서비스를 제때 이전하지 않는 소비자들이 있다. 결국 서비스 제공 사업자가 서비스 버전을 영원히 지원해야 하는가? 모든 사람들이 이미 서비스를 이전한 뒤 그 다음 날, 서비스 사업자가 단순히 서비스 버전 설정을 해제할 수 있을까? 두 경우 다 바람직하지 못하다. 서비스 전개 생명주기에서도 설명했듯이, 모든 서비스 버전에 대한 계획된 사용정지 및 폐지 스케줄만이 제일 좋은 방안이다. 서비스 제공 사업자가 자신의 서비스를 어떻게 알리고 이용하게 할 수 있을까? 서비스 소비자는 호출하고 싶은 서비스를 어떻게 찾을 수 있을까? 이러한 것들은 서비스 레지스트리에 관한 영역이다. 서비스 레지스트리는 이용가능한 서비스 및 서비스를 호출하기 위한 주소에 대한 목록을 보여준다. 서비스 레지스트리는 또한 서비스의 여러 버전을 조정한다. 서비스 소비자와 서비스 제공 사업자는 소유하고 있거나 필요한 버전을 지정하면 서비스 레지스트리는 소비자가 희망한 버전의 제공 사업자를 나열한다. 서비스 레지스트리는 버전 호환성을 관리하고, 버전 간의 호환성을 추적하고, 소비자의 희망 버전 또는 호환 버전에 관한 제공 사업자를 나열한다. 뿐만 아니라, 테스트(이전에 설명함) 및 사용중지 단계와 같은 서비스 상태를 지원하며, 서비스를 훤하는 소비자에게 유용한 서비스 상태로 서비스를 생성한다. 소비자가 서비스 사용을 개시할 때, 서비스에 대한 종속성이 생성된다. 각 소비자가 전체적으로 기업을 통해 의존해야 할 서비스를 분명히 알고 있을 경우, 이와 같은 의존성은 탐지되기 힘들고 더군다나 관리하는 건 더 어렵다. 서비스 레지스트리는 서비스 및 서비스 제공 사업자에 대한 목록을 만들 뿐만 아니라, 소비자와 서비스 간의 종속성을 추적한다. 이와 같은 추적 기능으로 다음과 같은 질문 (이 서비스를 사용하는 사람은?) 을 해결한다. 종속성에 대해 인지하는 레지스트리는 서비스를 사용정지해야 될 때와 같이 서비스 제공 사업자 변경에 관해 소비자에게 공지한다. 서비스 호출에 있어 서비스 소비자 및 제공 사업자는 메시지 포맷에 있어 일치를 봐야 한다. 개발 팀들이 각기 소비자 및 제공 사업자 메시지 포맷을 설계할 때, 이들은 공통 메시지 포맷에 대한 일치를 보는데 쉽게 어려움을 느낀다. 전형적인 서비스를 이용한 여러 가지 애플리케이션 및 여러 가지 서비스를 이용한 전형적인 애플리케이션으로, 메시지 포맷 수를 나열하면 메시지 포맷에 대해 단순한 일치를 보는 게 얼마나 노력을 요하는 일인지 알게 된다. 여기서 메시지 포맷에 대한 혼란을 없애는 공통적인 방식은 표준 데이터 모델을 이용하는 것이다. 표준 데이터 모델은 임의의 한 애플리케이션과는 무관하고, 모든 애플리케이션에서 공유하는 데이터 포맷의 공통집합이다. 이런 식으로는, 애플리케이션으로 메시지 포맷에 대해 일치를 보지 않아도 된다. 다만 애플리케이션은 공통적으로 기존 표준 데이터 모델을 사용한다. 표준 데이터 모델은 메시지에 있는 데이터 포맷을 나타낸다. 따라서, 헤더 필드, 메시지 유료 부하가 포함된 데이터의 종류, 그 데이터가 나열되는 방식 등의 메시지 포맷의 나머지 부분에 대한 일치가 필요하다. 하지만 표준 데이터 모델로 이와 같은 부분에 대한 일치를 보기엔 아직 멀었다. 중앙 관리 이사회는 표준 데이터 모델을 개발시키는 중립 당사자로서의 역할을 한다. 애플리케이션을 조사하고 서비스를 설계하는 일환으로, 이 이사회는 또한 서비스 호출 시 사용되는 공통 데이터 포맷을 설계한다. 서비스 제공 사업자가 작업을 중단할 경우, 이를 어떻게 알겠는가? 서비스 제공업자가 사용하는 서비스를 사용하는 애플리케이션의 작동이 중단되고, 서비스를 사용하는 사람들의 불만이 나오기 시작할 때까지 기다리겠는가? 다중 서비스를 결합한 애플리케이션인 복합 애플리케이션은 서비스 제공 사업자가 믿는 서비스만큼 믿을만하다. 다중 복합 애플리케이션은 한 서비스를 공유하기 때문에, 단 하나의 서비스 오류도 많은 애플리케이션에 영향을 줄 수 있다. 소비자가 의존하는 신뢰성 및 성능을 설명하기 위해 SLA를 정의해야 한다. 소비자가 정의된 SLA를 충족시키는 것을 확고히 하려면 서비스 제공 사업자를 감시해야 한다. 이와 관련된 문제는 문제 해결에 관한 것이다. 복합 애플리케이션 작동이 정지된 경우 그 이유는 무엇인가? 아마도 사용자가 연결하는 애플리케이션 헤드 및 UI의 작동이 정지되었기 때문일 수도 있다. 하지만 헤드는 잘 작동되어도, 헤드에서 사용하는 서비스 일부 또는 그 서비스에서 사용하는 서비스의 일부가 제대로 작동이 안 되어서 그럴 수도 있다. 이와 같이 각 애플리케이션의 작동 방식 뿐만 아니라, 각 서비스(사업자 집합으로서의)의 작동 방식 및 개별 사업자 운영방식 등에 대해 감시하는 게 중요하다. 단일 비즈니스 거래에 있어 서비스 간의 이벤트 상관성은 상당히 중요하다. 이와 같은 모니터링은 문제가 발생되기 전 문제를 탐지하고 예방하는 데 도움이 된다. 이를통해 부하 불균형 및 정전 등을 탐지할 뿐만 아니라 이런 현상들이 심각할 경우, 경고 기능도 제공하고 자동적으로 문제를 해결하려는 시도도 생기게 된다. 모너터링으로 시간 당 서비스 사용률을 측정해, 요즘 인기를 얻고 있는 서비스를 예측하는 데 도움이 되고, 이를 통해 용량을 증가시켜 서비스를 작동할 수 있게 한다. 다중 복합 애플리케이션에서 한 서비스를 사용하는 경우, 그 서비스에 대해 누가 책임지는가? 그 사람 또는 그 사람이 소속된 조직에서 모든 복합 애플리케이션에 관한 책임을 지는가? 애플리케이션 중 한 애플리케이션이라면 어떤 것인가? 다른 사람들은 그 조직이 서비스를 소유해야 한다고 생각하는가? 서비스 소유권의 모호한 세계로 당신을 환영한다. 임의의 공유 리소스는 서비스 소유권이 neighborhood park, 재사용 자바 프레임워크 또는 서비스 제공 사업자 중 어떤 것인지 정보를 얻고 나타내는 게 쉽지 않다. 하지만 필요한 공동 리소스는 임의의 참여자가 지불한 비용 외의 값을 제공한다. 공용 도로 시스템을 생각해 보면 된다. 종종 기업은 자체적으로 비즈니스 운영에 있어 사원 보고구조 및 재정 등을 조직한다. SOA에서 그와 같은 동일운영을 하는 기업의 IT를 조직하는 경우에, 일정한 분야의 운영을 책임지는 부서는 비즈니스 운영에 있어 IT 개발 및 런타임에 대해서도 책임진다. 그 부서는 그와 같은 서비스를 소유한다. 하지만 SOA및 복합 애플리케이션은 기업의 엄격한 계층적 보고 및 재정 구조를 따르지 않고 IT 책무에 있어 갭 및 중복영역을 생성한다. 이와 관련된 문제는 사용자 역할이다. SOA는 IT 및 비스니스를 일치시키는 데 주로 중점을 두고 있고 기업 재활용에도 중점을 두고 있다. 조직에 있는 수많은 사람들은 서비스의 미래, 차후 서비스의 작동방식, 차후 서비스의 활용방식 등에 대해 얘기한다. 비즈니스 분석가, 기업 설계자, 소프트웨어 설계자, 소프트웨어 설계가 및 IT 관리자 등이 이와 같은 역할들을 맡는다. 모든 이런 역할들은 서비스가 기업의 필요를 충족시키고, 서비스가 제대로 작동되는지에 관한 여부에 대해 관련이 있다. SOA로 기업의 비즈니스를 반영한다. 일반적으로, 이는 SOA를 기업에 맞게 변형시킨다는 것을 의미한다. 하지만 이와 같은 경우에서도, SOA에 맞는 비즈니스를 변화시키는 게 필요할 수도 있다. 이런 상황이 가능하지 않은 경우에는, 여러 부서간의 협력이 증대되어 공통 서비스 개발에 관한 짐을 함께 공유하는 것이 필요하다. 실지로, 서비스를 소유하고 이를 관리하는 조직간 상임위원회에서 이와 같은 협력을 이뤄낼 수 있다. 서비스 전개 생명주기는 팀이 서비스를 사용하기 전 서비스가 제대로 작동하고 있다고 확인하는 기간인 테스트 단계를 포함한다. 서비스 제공 사업자가 서비스를 테스트해 제대로 작동하고 있다는 것을 입증하면, 소비자 또한 서비스를 테스트해야 할까? 모든 서비스 제공 사업자들이 동일하게 조건의 엄격한 적용을 통해 서비스를 테스트할까? 서비스가 변하면 서비스를 다시 재테스트할까? SOA는 개개의 서비스 기능을 테스트할 기회 및 의도대로 서비스가 작동되는 것에 대한 가능성을 증가시킨다. 하지만 SOA는 또한 SOA에서 사용하는 서비스가 일관적으로 적절히 작동된다는 것을 그다지 믿지 않는 각각의 새로운 소비자들이 동일한 기능을 계속 테스트할 수 있는 기회를 제공한다. 반면, 복합 애플리케이션은 여러 서비스를 공유하기 때문에 단일 버그 서비스는 별로 관련이 없어 보이는 일정한 범위의 애플리케이션에 악영향을 줄 수도 있어, 프로그래밍 오류로 인한 결과가 확대될 수도 있다. SOA에 관한 재사용 장점들을 더 살리기 위해서는 서비스 소비자 및 제공 사업자가 적절한 레벨의 서비스 제공 사업자 테스팅에 합의하고 합의한 대로 테스팅 수행을 확고히 해야 한다. 그런 다음, 서비스 소비자는 서비스 자체의 기능 및 서비스에 대한 연결만을 테스트하면 되고 아울러 광고에 나온 대로 서비스가 작동된다고 가정할 수 있다. 아무라도 임의의 서비스를 호출할 수 있는가? 일정 사용자가 쓰는 서비스를 통해 모든 사용자가 모든 데이터를 접속하도록 해야 하나? 서비스 소비자 및 제공 사업자 간에 교환되는 데이터를 보호해야 할까? 서비스는 가장 의심이 많은 사용자나 가장 멍청한 사용자의 필요를 충족시킬 만큼 안전해야 할까? 보안이란 문제는 사실 어렵지만 임의의 애플리케이션에서의 필요충분조건이다. 인가된 사용자에게만 기능을 제한하고 정보 가로채기를 하지 못하도록 데이터를 보호해야 한다. SOA는 기능(즉, 서비스)에 대해 더 많은 액세스 포인트를 제공함으로써, 복합 애플리케이션에서의 취약성을 크게 증가시킬 가능성이 있기 때문이다. SOA를 통해 심지어는 서비스를 재사용할 필요가 없는 소비자에 의해서도 쉽게 재사용 가능한 서비스를 생성한다. 인가된 사용자들 중에서조차도, 서비스를 통해 접속되는 모든 데이터에 대해 모든 사용자가 접속하는 것은 아니다. 예를 들어, 은행계좌를 처리하는 서비스의 경우, 코드를 통해 다른 사용자의 계좌로 접속된다 할지라도 특수 사용자 계좌만 이용가능하다. 데이터 기밀성, 무결성, 부인방지를 위해 동일한 서비스를 사용하는 다른 소비자에 비해 보안에 대한 필요가 훨씬 큰 소비자도 있다. 서비스 호출기술은 이러한 모든 보안기능을 제공할 수 있어야 한다. 허가된 소비자들에게만 서비스 접속을 허용해야 한다. 사용자 신원을 여러 서비스에 전달하고 사용해 데이터 접속을 허가한다. 데이터 보호에 대한 질을 범위 내의 정책으로 나타내야 한다. 이렇게 하면 소비자들은 최소한의 보호레벨 및 최대한의 기능을 표현하게 되고, 부가적인 지원기능을 포함하는 적절한 서비스 제공 사업자와 일치해 짝을 이루게 된다.
이 글에서는 SOA 관리가 SOA를 사용하는 기업의 성공에 중요한 이유를 언급했다. 관리는 책무 수립 및 해당 당사자 권한 부여하기 등을 포함하는 반면 관리는 관리 정책이 실제로 일어나는지 여부를 확인하는 것을 포함한다. 관리 설정이 아닌 관리 수행을 위해 기술을 활용한다. 서비스를 호출하는 동안 관리되는 관리는 ESB에 의해 효과적으로 관리되어, 서비스 제공 사업자 및 소비자의 책무를 단순화한다. SOA 관리는 다음을 포함해 많은 기능이 있다.
이와 같은 각각의 기능에 관한 적절한 대처법에 대한 내용은 그 자체로 하나의 글이 될 수 있다. 감사의 글: 필자는 이 글에 정보를 제공해 준 IBM 동료인 Steve Graham, Arnauld Desprets, Randy Langel, Kerry Holley, All Arsanjani, Emily Plachy, Bob Vanorsdale, Jon Richter, Mandy Chessell, Mark Cocker, Mark Ernest, Steven Adler 및 Fill Bowen에게 감사의 말을 전하고 싶다.
다음은 유용한 참고자료 목록이다.
| ||||||||||||||||||||||||||||||
| [펌: developerWorks ] SOA 솔루션에 레거시 시스템 전략 적용하기 (한글) (0) | 2007.08.28 |
|---|---|
| [펌] SOA 성숙도 모델 (0) | 2007.04.07 |
| [3편] ESB를 이용하여 Service Enabling 하기 (2) | 2007.03.20 |
| [2편] BPM을 통한 서비스 분류하기 (0) | 2007.03.15 |
| [SOA] SOA, 어떻게 접근해야 하는가?[1편] (0) | 2007.03.14 |
archidream's Blog is powered by Daum
