SQL Server Service Broker | ||||||||||||||||||||||||||||||||||||||||||||||||
| 서비스지향기술구조(SOA)는 대규모 분산 어플리케이션을 설계하기 위해 중요한 개념으로 자리를 확고하고 있습니다. SOA의 중심부에는 서비스간에 통신을 위한 신뢰할 수 있는 메시지 기반 매커니즘이 위치하고 있습니다. SQL Server 2005에서 서비스 지향 데이터베이 스 솔루션을 개발하기 위한 메시지 기반 플랫폼의 역할을 하는 Service Broker에 대해서 소개합니다. 데이터베이스 어플리케이션 간의 메시지교환을 위한 Service Broker의 기능을 살펴보기에 앞서, SOA의 전체적인 개념에 대해서 먼저 알아두어야 합니다. | ||||||||||||||||||||||||||||||||||||||||||||||||
SOA 란? | ||||||||||||||||||||||||||||||||||||||||||||||||
| 최종 사용자에 대한 지연현상을 감소시키거나 확장성을 증대하기 위해서, 대부분의 대용량 시스템은 전통적인 통신 접근방법과 다른 방식의 통신 접근방법을 필요로 하고 있습니다. SOA는 대용량 시스템의 이러한 요구사항을 충족시켜 줄 수 있는 통신 접근방법의 역할을 합니다. ■ 정의 SOA는 소프트웨어 서비스간에 느슨하게 연결된 통신을 보장하는 기술구조의 유형입니다. 서비스는 비즈니스 업무에 대한 소프트웨어적인 구현으로, 통신을 위한 인터페이스와 계약을 제공합니다. 느슨하게 연결된 통신이란 클라이언트와 서비스가 서로에게 비교적 낮은 수준의 의존성을 갖는다는 의미입니다. 예를 들어, 서비스내부에 존재하는 로직은 클라이언트에 영향을 주지 않고 수정이 가능하며, 클라이언트도 서비스내부에 존재하는 로직과 상관없이 수정될 수 있습니다. ■ 웹 서비스 사례 소프트웨어는 웹 서비스를 사용하여 인터넷을 통해 통신이 가능합니다. 웹 서비스는 클라이언트가 서비스 공급자가 노출시킨 인터페이스를 통해 서비스를 호출하기 때문에, SOA의 한 사례가 될 수 있습니다. 클라이언트에게 노출된 인터페이스가 웹 서비스 내부의 로직을 호출하며, 서비스 공급자는 클라이언트에 영향을 주지 않고, 내부 로직을 수정할 수 있습니다. 웹 서비스는 XML과 SOAP을 사용하여 서로간에 통신을 수행합니다. ■ 메시징 사례 서비스는 Windows NT 4.0 이후에서 제공되는 기능인, 메시지 큐와 같은, 메시징 기술을 사용하여 통신하게 됩니다. 메시징 기술은 서비스 소비자와 서비스 공급자간의 비동기 통신을 가능하게 합니다.  | ||||||||||||||||||||||||||||||||||||||||||||||||
| SOA 용어 | ||||||||||||||||||||||||||||||||||||||||||||||||
다음 표에는 SOA 관련 용어에 대한 설명이 나타나 있습니다.
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker의 기능 | ||||||||||||||||||||||||||||||||||||||||||||||||
SQL Server 2005 Service Broker는 데이터베이스 어플리케이션에 메시징 기능을 제공하는 SOA의 구현의 역할을 수행합니다. Service Broker를 통해, SOA 기반 솔루션에서 제공하는, 다음과 같은, 강력한 기능을 사용할 수 있습니다.
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker의 시스템 기술구조 | ||||||||||||||||||||||||||||||||||||||||||||||||
Service Broker 어플리케이션을 개발하기 전에, 먼저 Service Broker 기술구조에 포함된 다섯 가지 SQL Server 개체에 대해서 알아두어야 합니다.
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker 대화 기술구조 | ||||||||||||||||||||||||||||||||||||||||||||||||
Service Broker 통신은 메시지를 교환하기 위해 대화를 사용합니다. 대화는 신뢰할 수 있는 메시지를 순서에 따라 보내기 위한 구조로 되어 있습니다. Service Broker 기반 어플리케이션을 개발하기 위해서는, Service Broker의 대화 기술구조에 대해서 알고 있어야 합니다. ■ Service Broker의 대화처리절차 Service Broker 어플리케이션에서는 단순하게 서비스 공급자에게 개별 메시지를 보내는 기능만 있는 것이 아니라, 부가적인 기능이 좀 더 포함되어 있습니다. 서비스 소비자는 작업이 완료되었을 때, 응답 메시지를 받기를 희망합니다. 하나의 작업을 완료하기 위해 여러 번의 대화가 이루어 질 수 있고, 수 시간에서 수일까지 시간이 소요될 수 있습니다.  | ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker 보안 기술구조 | ||||||||||||||||||||||||||||||||||||||||||||||||
| 웹 서비스에서 네트워크 연결을 통해 대화를 수행하는 경우, 교환되는 메시지에 대한 보안이 보장되어야 합니다. Service Broker에서는 전송 보안과 대화 보안을 모두 지원합니다. ■ 전송보안 Service Broker는 대화를 하기 위해 계약된 두 개의 서비스 간에 보안이 보장되고, 인증된 연결을 설정하기 위해 전송 보안을 사용합니다. 서비스는 원격서버의 HTTP 엔드포인트에 메시지를 송신하기 위해 다음과 같은 인증 옵션을 사용할 수 있습니다. ㆍ None - 서비스에 익명 접근을 허용합니다. ㆍ Enabled - 서비스에 익명 접근을 허용하며, 호출하는 서비스에서 제공하거나, 호출하는 서비스 가 요청하는 경우에만 인증을 사용합니다. ㆍ Required - 인증을 필수로 사용합니다. ■ 인증 사용되는 인증의 유형은 호출자 어플리케이션의 master 데이터베이스에 존재하는 dbo 사용자가 디지털 인증서를 보유하고 있는지 여부에 따라 결정됩니다. 디지털 인증서가 존재하는 경우, 인증서 기반 인증이 사용됩니다. 디지털 인증서가 없는 경우, Windows 인증이 사용됩니다. 인증서 기반 인증을 사용하기 위해서는, 각 서비스의 관리자별로 master 데이터베이스내에 dbo 사용자에 대한 디지털 인증서를 생성한 다음, 해당 인증서에 대한 공개키를 내보내기하고, 원격 서비스 관리자에게 해당 공개키를 전달합니다. 각 관리자는 원격 서비스내에 dbo 사용자를 대표하기 위해서, master 데이터베이스에 사용자를 생성한 다음, 새로 생성한 사용자에 원격 관리자에 의해 제공된 공개키를 연결해야 합니다. Windows 인증을 사용하기 위해서는, 각 서비스의 관리자는 원격 서비스의 서비스 계정으로 사용할 Windows 로그온을 위한 사용자를 master 데이터베이스에 생성해야 합니다. ■ 대화(Dialog) 보안 Service Broker 는 원격 서비스간의 메시지를 암호화하고, 원격 사용자에 대한 인증절차를 처리하기 위해 대화 보안을 사용합니다. 대화 보안은 높은수준의(full) 대화 보안과 익명 대화 보안으로 구현될 수 있습니다. 높은 수준의 대화 보안의 경우, 대화를 시작하는 서비스를 호스팅하는 데이터베이스와 호출된 서비스를 호스팅하고 있는 데이터베이스 양쪽 모두에 두 가지 사용자를 포함하고 있어야 합니다. 하나는 원격 서비스에 메시지를 보내는 로컬 사용자이고, 또 하나는 원격 서비스를 호스팅하고 있는 원격 데이터베이스내의 사용자입니다. 대화에 포함되는 각 서비스에는 원격 서비스와 원격 데이터베이스 사용자에 대한 로컬 사용자 계정을 매핑하는 원격 서비스 바인딩 정보가 포함되어야 합니다. 디지털 인증서는 메시지를 수신자의 공개키로 암호화한 다음, 그에 상응하는 개인키로 복호화할 수 있도록, 반드시 각 사용자와 연결되어 있어야 합니다. 익명 대화 보안은 대부분 전체 대화 보안과 동일한 방식으로 동작하지만, 대상 서비스에서 원격 사용자에 대한 접근을 명시적으로 허용할 필요가 없다는 차이가 있습니다. 익명 대화 보안을 사용하면, 대상 서비스는 guest 계정으로 접근을 허용하며, 세션키를 생성하여, 서비스간에 교환되는 메시지를 암호화하기 위해 사용합니다. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 데이터베이스에서 Service Broker 활성화 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker 서비스는 데이터베이스가 생성될 때, 기본값으로 활성화되지 않습니다. TSQL 문장을 사용하여, Service Broker 서비스가 활성화되어 있는지 여부를 확인하고, 활성화/비활성화 시킬 수 있습니다. Service Broker가 비활성화되어 있는 경우, 다시 활성화될 때까지 모든 메시지는 전송 큐에 저장되게 됩니다. ■ Service Broker 상태 체크 데이터베이스의 Service Broker의 상태를 확인하기 위해서는, 다음 예제와 같이, sys.databases 카탈로그 뷰에서 is_broker_enabled 컬럼을 조회하면 됩니다. ■ Service Broker 활성화 데이터베이스의 Service Broker를 활성화/비활성화 시키기 위해서는, 다음 예제와 같이, ALTER DATABASE T-SQL 명령을 사용합니다. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Service Broker 구현 | ||||||||||||||||||||||||||||||||||||||||||||||||
| ■ 계약 생성 Service Broker 어플리케이션을 개발하기 위해서 데이터베이스에 생성해야 하는 개체는 계약과 메시지 유형이 있습니다. 계약은 서비스 간에 교환되는 메시지 유형의 목록을 정의합니다. 계약을 생성하기 위해서는, 다음과 같은 단계의 작업을 수행해야 합니다. 1 단계. 메시지 유형 생성 메시지 유형은 서비스간에 전송되는 데이터의 유형을 정의합니다. VALIDATION 절에는 메시지에 포함될 데이터의 유형을 지정합니다. 메시지에 포함된 데이터의 유형에는 다음과 같은 항목 중 하나를 선택하여 지정합니다. ㆍ NONE - 메시지에 대한 유효성검사를 수행하지 않습니다. ㆍ EMPTY - 메시지에 데이터를 포함하지 않습니다. ㆍ WELL_FORMED_XML - 메시지에 잘 구성된 XML 문자열만 포함되도록 설정합니다. XML이 잘 구성된상태가 아니라면, Service Broker에서 오류를 발생시킵니다. ㆍ VALID_XML - 지정된 XML 스키마 컬렉션에 포함된 스키마를 기준으로 검증된 XML 데이터만 메시지에 포함됩니다. AUTHORIZATION 절에 메시지 유형의 소유자로 사용할, 특정 데이터베이스 사용자나 역할을 설정할 수 있습니다. 알림 [따라하기] 메시지 유형 만들기 CREATE MESSAGE TYPE 2. 계약 생성 계약에는 대화에서 사용하게 될 메시지 유형을 정의해야 하고, 메시지 유형이 전송되는 방향(direction)을 정의해야 합니다. 사용할 메시지 유형을 생성한 다음, 다음과 같은 구문으로, 계약을 생성할 수 있습니다. CREATE CONTRACT contract_name 위의 구문에서 message_type_name 는 사전에 정의된 메시지 유형 이름을 지정합니다. SENT BY는 대화에서 메시지 유형을 전달할 수 있는 방향을 지정합니다. owner_name 에는 계약의 소유자로 설정할 데이터베이스 사용자나 역할을 지정합니다. [따라하기] 계약 생성 CREATE CONTRACT앞의 예제에서는, 시작자(intiator) 서비스에서만 ExpenseClaim 메시지를 보낼 수 있으며, 대상 서비스에서만 ClaimResponse 메시지를 보낼 수 있습니다. ■ 큐 생성 큐는 서비스 프로그램이 메시지를 처리할 수 있는 상태까지, Service Broker가 메시지를 저장할 장소를 정의합니다. 큐를 생성하기 위해서는 다음과 같은 작업절차를 수행해야 합니다. 1. 큐의 이름을 생성합니다. 2. 큐의 가용량을 정의합니다. 3. 활성화 조건 매개변수를 지정합니다. 큐를 생성하기 위한 구문은 다음과 같습니다. CREATE QUEUE queue_name ■ 서비스 생성 서비스는 서비스 소비자와 서비스 공급자를 연결하는 역할을 합니다. 서비스에는 대화가 시작된 다음, 대화가 종료될 때까지의 범위가 포함됩니다. 서비스를 생성하기 위해서는 다음과 같은 작업을 수행해야 합니다. ㆍ 서비스명을 생성합니다. ㆍ 서비스 소비자가 보낸 메시지를 저장하기 위한 큐를 지정합니다. ㆍ 서비스 공급자의 계약 목록을 지정합니다. ㆍ 대화가 진행되는 동안 메시지를 계속해서 유지할 것인지 여부를 지정합니다. 다음 표에는 CREATE SERVICE 문장에 포함되는 각 구문에 대한 설명이 나타나 있습니다.
[따라하기] 서비스 생성하기-서로 다른 큐를 사용하는 두 개의 서비스 CREATE SERVICE [//Adventure-Works.com/SubmitExpense] ON QUEUE ExpensesInitiator ( [//Adventure-Works.com/Expenses/ProcessExpense] ) CREATE SERVICE [//Adventure-Works.com/ProcessExpense] ON QUEUE ExpensesTarget ( [//Adventure-Works.com/Expenses/ProcessExpense] ) ■ 메시지 송신 Service Broker 어플리케이션에서 수행해야 하는 가장 기본적인 작업 중 하나는 서비스 소비자로부터 서비스 공급자에게로 메시지를 보내는 것입니다. 메시지를 보내기 위해서는, 먼저 계약, 큐, 서비스와 같은, 관련 Service Broker 개체가 먼저 생성되어 있어야 합니다. 메시지를 보내기 위해서는, 다음과 같은 작업절차를 수행해야 합니다. 1. 대화를 관리하기 위한 식별자 변수 선언 메시지를 보내기 전에, 대화를 관리하기 위한 식별자 변수를 선언해야 합니다. 대화를 관리하기 위한 변수는, 다음 예제와 같이, 반드시 uniqueidentifier 데이터형을 사용해서 선언해야 합니다. DECLARE @dialog_handle uniqueidentifier 2. 대화 시작 BEGIN DIALOG CONVERSATION 명령을 사용하여 대화를 시작할 수 있습니다. BEGIN DIALOG CONVERSATION 명령에 대한 구문은 다음과 같습니다. 다음 표에는 BEGIN DIALOG 구문에서 사용하는 매개변수 목록이 나타나 있습니다.
[따라하기] 대화시작 대화 핸들 식별자가 설정되면, SEND 명령을 사용하여 메시지를 송신하게 됩니다. SEND 명령에 대한 구문은 다음과 같습니다. SEND ON CONVERSATION conversation_handle 다음 표는 SEND 명령에서 사용하는 매개변수의 목록을 나타냅니다.
[따라하기] 메시지송신 DECLARE @msgString NVARCHAR(MAX) SET @msgString = NCHAR(0xFEFF) + N’ 앞의 예제는 메시지가 XML 본문으로 구성되었다고 가정합니다. XML 형식 문자열에 대해서 메시지 송신 작업을 하기 위해서는, XML 데이터 앞에 바이트 순서 표시를 포함한 문자열인 지를 확인해야 합니다. NCHAR(OxFEFF) 값이 바이트 순서 표시로 사용됩니다. 팁 ■ 메시지 수신 메시지가 보내지면, 서비스 프로그램은 큐로부터 보내진 메시지를 읽어 들여, 메시지 본문에 대한 처리를 수행합니다. 서비스 프로그램이 메시지를 읽는 방법은 큐를 설정할 때 선택한 방법에 따라 결정됩니다. 물론, 공통적인 메시지 수신 절차는 변경되지 않습니다. 메시지를 수신하기 위해서는 다음과 같은 작업절차가 수행됩니다. 1 단계. 메시지 상세정보를 저장하기 위한 변수선언 메시지의 개별 컬럼을 저장하기 위한 로컬 변수를 생성해야 합니다. 작업을 위해 공통적으로 필요한 컬럼에는 conversation_handle, message_type_name, message_body 등이 있습니다. 2 단계. RECEIVE 명령 호출 RECEIVE 명령은 큐에 저장된 메시지를 처리하여, 테이블 기반 결과값과 같은 결과를 만들어 내는 작업을 수행하기 위해, 지정된 큐로부터 하나 또는 그 이상의 메시지를 가져오는 역할을 합니다. RECEIVE 명령에 별도로 TOP 매개변수를 지정하지 않으면 동일한 서비스 인스턴스 식별자에 소속된 모든 메시지를 큐에서 제거하여 가져옵니다. RECEVIE 명령이 큐에서 메시지를 제거하는 동안에는, 다른 서비스 프로그램 인스턴스가 RECEIVE 명령의 대상이 되는 메시지에 대한 작업을 수행할 수 없으며, 동일한 서비스 인스턴스 식별자가 소유한 메시지에 대한 다른 작업도 수행할 수 없습니다. RECEIVE 명령은 대화에 포함된 각 메시지의 message_sequence_order 값의 순서에 따라 메시지를 큐에서 제거합니다. RECEIVE 명령에 대한 구문은 다음과 같습니다. [ WAITFOR ( ]
RECEIVE [ TOP (n) ]
<column_specifier > [ ,...n ]
FROM queue_name
[ INTO table_variable ]
[ WHERE { conversation_handle = conversation_handle
| conversation_group_id = conversation_group_id } ]
[ ) ] [ , TIMEOUT timeout ]다음 표는 RECEIVE 명령에서 사용할 수 매개변수 목록을 나타냅니다.
다음의 예제는 하나의 메시지를 수신하여, 해당 메시지에 포함된 세 개의 컬럼의 정보를 로컬 변수에 저장하는 방법을 나타냅니다. [따라하기] 메시지 수신 ;RECEIVE TOP(1) @conversation = conversation_handle,
@msgType = message_type_name, @msg = message_body
FROM ExpenseQueue팁 적절한 메시지 유형을 처리하는 것인지 확인하기 위해, IF 문장을 조합하여, 메시지 결과집합에 포함된 message_type_name 컬럼의 값을 체크합니다. 체크한 결과에 포함될 수 있는 메시지 유형에는 사전에 정의된 메시지 유형, http://schemas.microsoft.com/SQL/ServiceBroker/Error 메시지 유형의 오류 메시지, http://schemas.Microsoft.com/SQL/ServiceBroker/DialogTimer 메시지 유형의 대화 타임아웃 메시지, http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog 메시지 유형의 대화종료 메시지가 있습니다. 4 단계. 대화를 종료하기 위해 END CONVERSATION 호출 서비스 공급자가 작업을 완료하면, END CONVERSATION 문장을 사용하여, 대화를 종료할 수 있습니다. END CONVERSATION 명령에 대한 구문은 다음과 같습니다. END CONVERSATION conversation_handle
[ [ WITH ERROR = failure_code DESCRIPTION = failure_text ]
| [ WITH CLEANUP ] ]conversation_handle 는 종료하고자 하는 대화에 대한 식별자를 지정합니다. WITH ERROR 절을 사용하여 오류 코드와 설명을 지정할 수 있습니다.WITH CLEANUP 절은 대화 상대자에게 통지 없이 대화에 포함된 모든 메시지와 메타데이터를 삭제하기 위해서 사용합니다. SQL Server 는 대화를 구성하고 있는 엔드포인트와, 전송 큐에 포함된 대화에 대한 모든 메시지, 서비스 큐에 포함된 대화에 대한 모든 메시지를 삭제합니다. | ||||||||||||||||||||||||||||||||||||||||||||||||
[출처] DBGuide.net
