Bora.Choi

 Serverice Borker 보안 ^#

•  Service Broker 보안은 인증서를 이용합니다
•  일반적으로 인증서를 사용하여 원격 데이터베이스의 자격 증명을 설정한 다음 원격 데이터베이스에서 로컬 사용자에게 작업을 매핑합니다.
•  로컬 사용자에 대한 사용 권한은 원격 서비스 대신 모든 작업에 적용됩니다
•  인증서는 데이터베이스 간에 공유됩니다
•  사용자에 대한 다른 정보는 공유되지 않습니다.

 대화 보안^#

 개별 대화 메시지를 암호화하고 대화 참가자의 ID를 확인합니다. 또한 원격 권한 부여와 메시지 무결성 검사를 제공합니다. 대화 보안은 두 서비스 간에 인증되고 암호화된 통신을 설정합니다.

기본사항^#

Service Broker 대화 보안을 사용하면 응용 프로그램이 개별 대화에 대한 인증, 권한 부여 또는 암호화를 사용할 수 있습니다.

 적으로 모든 대화에는 대화 보안이 사용됩니다. 대화를 시작할 때 BEGIN DIALOG CONVERSATION 문에 ENCRYPTION = OFF 절을 포함하여 대화 보안 없이도 대화가 진행될 수 있도록 명시적으로 허용할 수 있습니다. 그러나 대화의 대상이 되는 서비스에 원격 서비스 바인딩이 존재하면 ENCRYPTION = OFF인 경우에도 대화에 보안이 사용됩니다.

SQL Server는 대화 보안을 사용하는 대화에 대한 세션 키를 만듭니다.

션 키가 데이터베이스에 저장되는 동안 세션 키를 보호하기 위해 Service Broker는 데이터베이스의 마스터 키를 사용하여 세션 키를 암호화합니다

데이터베이스 마스터 키를 사용할 수 없으면 데이터베이스 마스터 키가 생성되거나 대화의 시간이 초과될 때까지 대화에 대한 메시지는 오류가 발생한 상태로 transmission_status에 남아 있습니다. 그러므로 대화에 참가하는 두 데이터베이스가 동일한 인스턴스에서 호스팅되는 경우라도 두 데이터베이스 모두에 마스터 키가 있어야 합니다.그러므로 대화에 참가하는 두 데이터베이스가 동일한 인스턴스에서 호스팅되는 경우라도 두 데이터베이스 모두에 마스터 키가 있어야 합니다.

•  시작 데이터베이스에 마스터 키가 없으면 대화가 실패합니다. 대상 데이터베이스에 마스터 키가 없으면 메시지는 시작 데이터베이스의 전송 큐에 그대로 남습니다.

• 이러한 메시지에 대한 마지막 전송 오류는 메시지를 배달하지 못한 원인을 보여 줍니다. ENCRYPTION = OFF 매개 변수를 사용하여 암호화되지 않은 대화를 만들거나 다음 명령을 사용하여 데이터베이스 마스터 키를 만드세요.

  1.  CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>' 

익명보안^#

• 익명 보안은 시작 서비스에서 트러스트되지 않은 데이터베이스로 메시지를 보내지 못하도록 합니다. Service Broker는 대화에서 익명 보안을 사용할 경우 네트워크에서 전송되는 메시지를 암호화합니다.

• 예를 들어 작업 주문을 전송하는 응용 프로그램은 작업 주문을 받는 사람이 원하는 대상이 확실함을 보장해야 하지만, 대상 데이터베이스는 작업 주문을 전송하는 서비스에 어떤 특별한 권한도 제공할 필요가 없습니다. 이 경우 시작 서비스가 포함된 데이터베이스에는 대상 서비스에 대한 원격 서비스 바인딩이 포함되어야 합니다.

  대상 서비스는 시작 서비스의 ID를 확인할 수 없으므로 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 고정 데이터베이스 역할 public의 멤버로 실행됩니다. 대상 데이터베이스는 대화를 시작한 사용자에 대한 정보를 받지 않습니다. 대상 데이터베이스에는 대화를 시작하는 사용자에 대한 인증서가 없어도 됩니다.

  익명 보안을 사용하는 대화의 경우 대화의 양측이 시작 데이터베이스가 생성한 세션 키를 사용합니다. 대상 데이터베이스는 시작 데이터베이스에 세션 키를 반환하지 않습니다.

대화 보안에 대한 보안 컨텍스트^#

• Service Broker는 전적으로 SQL Server 인스턴스 내에서 실행되지 않는 보안 대화에 대해 항상 원격 권한 부여를 사용합니다

보안 대화 만들기^#

SQL ServerBroker 는 두 데이터베이스 사이의 대화를 설정하는 경우 시작 서비스는대상 큐에 메시지를 추가할 수 있도록 대상 데이터베이스에 사용자 컨텍스트를 설정해야 합니다.

이러한 사용자 컨텍스트는 시작 서비스에 대상에 대한 대화를 열 권한이 있는지 여부를 확인합니다.

이러한 작업을 수행하는 가장 유연한 방법은 인증서 및 원격 서비스 바인딩을 만드는 것입니다. 인증서를 만드는 방법은 CREATE CERTIFICATE(Transact-SQL)를 참조하십시오. 원격 서비스 바인딩을 만드는 방법은 CREATE REMOTE SERVICE BINDING(Transact-SQL)을 참조하십시오.

인증서 및 원격 서비스 바인딩을 만드는 다른 방법은 SQL Server 보안을 사용하여 두 데이터베이스 사이에 트러스트 관계를 설정하는 것입니다. 그러면 시작 서비스의 소유자가 대상 서비스의 사용자를 가장합니다. 이를 위해 시작 데이터베이스의 TRUSTWORTHY 데이터베이스 속성을 ON으로 설정하고 대상 데이터베이스의 사용자에게 인증 권한을 부여해야 할 수 있습니다. 자세한 내용은 EXECUTE AS를 사용하여 데이터베이스 가장 확장을 참조하십시오.

대화보안 유형 결정^#

• 보안 유형은 BEGIN DIALOG CONVERSATION 문의 옵션, 서비스에 대한 원격 서비스 바인딩 설정, 시작 서비스의 소유자가 인증서를 소유하는지 여부 등에 따라 결정됩니다.
• sys.remote_service_bindings 카탈로그 뷰에서 대상 서비스 대한 원격 서비스 바인딩을 조회합니다.
• 원격 서비스 바인딩이 있으면 대화는 BEGIN DIALOG CONVERSATION 문의 설정에 관계없이 암호화를 사용합니다.

대화가 실패함

요청한 보안을 제공하는 데 필요한 정보가 SQL Server에 없습니다. Service Broker는 대화를 종료하고 시작 서비스에 대한 큐에 오류 메시지를 넣습니다.

대화 보안 없음

SQL Server가 대화에 대화 보안을 제공하지 않습니다. 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 public으로 실행됩니다. 이 대화에 대해서는 메시지가 암호화되지 않습니다. 그러나 전송 보안의 경우 네트워크의 메시지를 암호화할 수 있습니다.

익명 보안

SQL Server가 익명 보안을 사용합니다. 이 대화에 대한 인스턴스 외부의 메시지가 암호화됩니다. 대상 서비스는 시작 서비스의 ID를 확인할 수 없으므로 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 public으로 실행됩니다.

높은 수준의 보안

SQL Server는 높은 수준의 보안을 사용합니다. 이 대화에 대한 인스턴스 외부의 메시지가 암호화됩니다. 시작 서비스를 대신하여 수행되는 작업은 대상 데이터베이스에서 지정된 사용자로 실행됩니다.

전송보안^#

• 권한이 없는 데이터베이스에서 Service Broker 메시지를 로컬 인스턴스의 데이터베이스로 보낼 수 없게 합니다. 전송 보안은 두 데이터베이스 간에 인증된 네트워크 연결을 설정합니다.
• 데이터베이스 관리자가 데이터베이스에 대한 네트워크 연결을 제한할 수 있으며 네트워크의 메시지를 암호화할 수 있습니다. Service Broker 끝점은 인증서 기반 인증과 Windows 인증을 모두 지원합니다.
• 전송 보안은 두 인스턴스 간의 네트워크 연결에 적용됩니다. 전송 보안은 통신할 수 있는 인스턴스를 제어하며 두 인스턴스 간에 암호화를 제공합니다.
• 전송 보안은 인스턴스 전체에 적용됩니다. 전송 보안은 개별 메시지 내용을 보호하지 않으며 인스턴스 내의 개별 서비스에 대한 액세스도 제어하지 않습니다. 메시지가 대상 인스턴스에 도달할 때까지 Service Broker 대화 보안은 메시지가 보내는 인스턴스를 떠날 때 개별 메시지를 암호화합니다.
•  인스턴스에 사용되는 인증 유형은 각 인스턴스의 Service Broker 끝점의 AUTHENTICATION 옵션에 따라 결정됩니다
•  끝점에서 둘 이상의 인증 방법을 지정하면 연결을 시작하는 인스턴스에 인증 방법이 지정된 순서에 따라 사용되는 정확한 인증 방법이 달라집니다. 협상하는 동안 각 인스턴스에서 지원되는 인증 유형과 알고리즘을 모두 보고합니다. 시작자는 수락자가 지정한 순서에 따라 양 끝점에서 지원되는 인증 방법을 시도하므로 대화가 오래 실행되는 경우 둘 이상의 연결을 통해 메시지를 교환할 수 있으며 대화를 시작하는 인스턴스에 따라 연결의 인증이 다를 수 있습니다.
•  Service Broker 끝점은 두 종류의 암호화를 지원합니다. 인증과 마찬가지로 연결을 시작하는 인스턴스에 지정된 암호화 방법의 순서에 따라 연결에 사용되는 정확한 암호화 방법이 결정됩니다.

사용자 수준 권한^#

•   개 이상의 인스턴스를 포함하는 대부분의 Service Broker 응용 프로그램은 해당 응용 프로그램을 위해 특별히 생성된 데이터베이스 보안 주체의 보안 컨텍스트에서 실행됩니다. 이러한 데이터베이스 보안 주체는 응용 프로그램이 수행하는 작업을 완료하는 데 필요한 최소 권한을 가져야 합니다.
• 원격 권한 부여를 위해 지정된 데이터베이스 보안 주체는 시작 서비스를 호스팅하는 데이터베이스에 CONNECT 권한 필요
•  시작 서비스에는 SEND 권한 필요
• 데이터베이스 보안추제가 대화를 시작하려면 해당 보안 주체에 시작 서비스의 큐에 대한 RECEIVE 권한 필요
• 시작 서비스를 소유하는 데이터베이스 보안주체는 대상 서비스에 대한 SEND 권한 필요
•  데이터베이스 보안주체가 서비스에 메세지를 보내려면 해당 보안주체에 서비스에 대한 SEND 권한 있어야함
• 활성화 저장 프로시저에 대한 사용자로 지정된 사용자 프로시저를 실행할 수 있는 권한
•  SSPI가 사용되면 원격데이터베이스대한 서비스 게정은 master 에서 connect 권한, 로그인에도 해당되어야함, 따라서 원격 SQL Server 인스턴스가 실행되는 계정은 윈도우 인정을 사용하여 SQL Server에 로그인 할 수 있는 권한이 있어야 합니다. 로그인이 다른 권한을 갖거나 데이터베이스의 개체를 소유하기 위해 필요한 요구 사항은 없습니다.
  

• 인증서 보안요구사항^#

• 키 모듈러스는 2048 미만이어야 합니다.
• 전체 인증서 길이는 32KB 미만이어야 합니다.
• 주체 이름을 지정해야 합니다.
• 유효 날짜를 지정해야 합니다.

키 길이는 64비트의 배수여야 합니다.

인증서를 SQL Server에 저장할 경우 인증서가 데이터베이스에 대한 마스터 키로 암호화되어야 합니다. Service Broker는 암호만 사용하여 암호화된 인증서를 사용할 수 없습니다. 또한 데이터베이스에 대한 마스터 키는 인스턴스에 대한 서비스 키로 암호화되어야 합니다. 그렇지 않으면 Service Broker가 마스터 키를 열 수 없습니다.

• SQL Server가 인증서를 사용하여 대화를 시작하려면 인증서가 ACTIVE FOR BEGIN_DIALOG로 표시되어야 합니다. 대화 시작 시에는 인증서가 기본적으로 활성으로 표시됩니다. 

이 글은 스프링노트에서 작성되었습니다.

 장점

• 데이터베이스 통합

  • 데이터, 메시지 및 응용 프로그램 논리가 모두 데이터베이스에 있으면 응용 프로그램의 관리(재해 복구, 보안, 백업 등)가 일상적인 데이터베이스 관리의 일부가 되고 관리자는 3-4개에 이르는 별도의 구성 요소를 관리할 필요가 없으므로 관리가 더욱 쉬워진다.
  •  Service Broker에서는 같은 데이터베이스에 메시지와 데이터를 저장하므로 불일치는 문제가 되지 않는다.
  • Service Broker 서비스를 구현하는 저장 프로시저는 Transact-SQL 또는 CLR(공용 언어 런타임) 언어 중 하나로 작성할 수 있습니다. 데이터베이스 외부의 프로그램에서는 Transact-SQL 및 ADO.NET 같이 익숙한 데이터베이스 프로그래밍 인터페이스를 사용합니다.

• 메세지 순서 지정 및 조정

  • 기존은 응용프로그램이 잘못된 순서로 도착하는 메세지의 순서를 지정하고 조정하는 작업 담당
  • 기존 MSMQ 시스템에서는 메세지가 중복 배달되는 문제 발생
  • Severice Broker는 메세지의 순서, 고유한 배달 및 대화 식별을 자동으로 처리함으로 이런 문제 해결, 끝점 사이에 대화가 설저되고 나면 응용 프로그램은 각 메세지를 보낸 순서대로 한 번씩만 메세지를 받는다.

• 느슨한 연결 및 작업 유연성

  •   응용 프로그램에서는 큐에 메시지를 보낸 다음 계속하여 응용 프로그램 처리를 진행하되 Service Broker를 통해 메시지가 대상에 도착했는지 확인할 수 있다. 이처럼 연결이 느슨하면 유연한 일정 예약이 가능합니다.

• 관련 메세지 잠금

  •  대화의 그룹 잠금을 통해 여러 스레드가 같은 큐에서 읽는 경우 메세지를 잘 못된 순서로 처리되지 않게 한다.
  • 연관된 메세지의 경우 대화 그룹에서 관련된 대화를 연결하는 밥업을 사용하여 대화 그룹의 모든 메세지를 자동으로 잠그기 때문에 하나의 응용 프로그램 인스턴스에서만 수신하고 처리할 수 있다.

• 자동 활성화

  •  활성화를 사용하면 응용 프로그램이 큐에 도착하는 메시지 볼륨에 맞게 크기를 동적으로 조정할 수 있다.
  •  Service Broker는 데이터베이스 내부에서 실행되는 프로그램과 데이터베이스 외부에서 실행되는 프로그램 모두에서 활성화를 활용하는 기능을 제공한다. 그러나 응용 프로그램이 활성화를 사용할 필요가 없다.
  •  Service Broker는 큐의 작업을 모니터링하여 사용 가능한 메시지가 있는 모든 대화에 대해 응용 프로그램이 메시지를 받는지 여부를 확인. Service Broker 활성화는 큐 판독기가 수행할 작업이 있을 때 새 큐 판독기를 시작합니다. 큐 판독기가 수행할 작업이 있는 시기를 확인하기 위해 Service Broker에서는 큐의 작업을 모니터링합니다.
  • 큐 판독기의 수가 들어오는 트래픽에 일치할 경우 큐는 정기적으로 큐가 비어 있는 상태 또는 큐의 모든 메시지가 다른 큐 판독기에서 처리 중인 대화에 속하는 상태에 이르게 됩니다. 큐가 일정 기간 동안 이러한 상태에 이르지 않으면 Service Broker는 다른 응용 프로그램 인스턴스를 활성화합니다.
  • Service Broker는 활성화를 통해 시작된 프로그램을 중지하지 않습니다. 대신 활성화된 응용 프로그램은 메시지가 도착하지 않은 일정 기간 이후 자동으로 종료되도록 작성됩니다. 이러한 방법으로 설계된 응용 프로그램을 사용함으로써 서비스에 대한 트래픽 변경으로 인해 여러 응용 프로그램 인스턴스가 동적으로 증가하고 감소할 수 있습니다. 또한 시스템이 종료되거나 다시 부팅되면 시스템을 다시 시작할 때 응용 프로그램에서 자동으로 큐의 메시지를 읽기 시작합니다.

사용용도

• 비동기 트리거

  •  OLTP 시스템과 같이 트리거를 대신해서 메세지를 보내면 메세지를 받는 쪽에서는 해당 작업을 수행하며 된다.

• 안정적인 쿼리 처리

  • 정전, 오류등을 대비에서 서비스 브로커로 쿼리르 메세지로 보내서 처리할 수 있다. 컴퓨터가 복구되면 응용 프로그램이 다시 시작되고 메세지가 다시 처리된다.
• 클라이언트 응용 프로그램에 대한 서버쯕 분산 처리
• 클라이언트 응용 프로그램에 대한 데이터 통합

• 대량 일괄 처리

  • 대량 일괄 처리를 수행해야 하는 응용 프로그램은 Service Broker에 제공되는 큐 및 병렬 처리 기능을 통해 많은 작업을 신속하고 효율적으로 처리할 수 있다.

이 글은 스프링노트에서 작성되었습니다.

대화(conversaction) 아키텍처^#

 메세지^#

 메시지에는 메시지를 보내는 응용 프로그램에 따라 결정되는 특정 유형이 있습니다. 각 메시지에는 고유한 대화 ID와 함께 대화 내의 시퀀스 번호가 있습니다. 메시지를 받을 때 Service Broker는 메시지의 대화 ID와 시퀀스 번호를 사용하여 메시지를 순서대로 정렬합니다.

대화^#

Service Broker가 보낸 모든 메시지는 대화의 일부입니다. 대화는 두 서비스 간의 통신입니다. 대화는 두 서비스 간의 안정적이고 지속적인 양방향 메시지 스트림입니다.

대화는 EOIO(Exactly-Once-In-Order) 방식으로 메시지 배달을 제공합니다. 대화는 각 메시지에 포함된 대화 식별자와 시퀀스 번호를 사용하여 관련된 메시지를 식별하고 올바른 순서로 메시지를 배달합니다. 대화는 두 서비스 간의 안정적이고 지속적인 메시지 스트림입니다.

대화에는 두 참가자가 있습니다. 시작자는 대화를 시작하고 대상은 시작자가 시작한 대화를 수락합니다. 대화에 대한 계약에 지정된 바와 같이 참가자가 대화를 시작하는지 여부에 따라 참가자가 보낼 수 있는 메시지가 결정됩니다.

 응용 프로그램은 메시지를 대화의 일부로 주고받습니다. SQL Server가 대화에 대한 메시지를 받으면 SQL Server는 대화에 대한 큐에 메시지를 넣습니다. 응용 프로그램은 큐에서 메시지를 받고 필요에 따라 메시지를 처리합니다. 처리 과정 중에 응용 프로그램이 메시지를 대화의 다른 참가자에게 보낼 수도 있습니다.

• 대화수명
• 대화 타이머

대화그룹^#

대화 그룹이란 관련 대화의 그룹을 나타냅니다. 대화 그룹을 사용하면 응용 프로그램에서 특정 비즈니스 작업에 관련된 대화를 쉽게 조정할 수 있습니다.

모든 대화는 하나의 대화 그룹에 속합니다. 모든 대화 그룹은 특정 서비스와 관련되어 있으며 그룹의 모든 대화는 해당 서비스 간의 대화입니다. 대화 그룹에 포함할 수 있는 대화 수에는 제한이 없습니다.

 SQL Server에서는 대화 그룹을 사용하여 특정 비즈니스 작업에 관련된 메시지에 대해 EOIO(Exactly-Once-In-Order) 방식으로 액세스를 제공합니다

응용 프로그램이 메시지를 보내거나 받을 때 SQL Server에서 메시지가 속한 대화 그룹을 잠급니다. 그러면 한 번에 한 세션만 대화 그룹의 메시지를 받을 수 있습니다. 대화 그룹을 잠그면 응용 프로그램이 각 대화 그룹의 메시지가 EOIO 방식으로 처리됩니다. 대화 그룹에 둘 이상의 대화를 포함할 수 있으므로 응용 프로그램에서는 대화 그룹을 사용하여 같은 비즈니스 작업에 관련된 메시지를 식별하고 해당 메시지를 함께 처리할 수 있습니다.

응용프로그램 상태구성^#

 대화 그룹의 한 가지 이점은 대화 그룹 식별자가 응용 프로그램 상태를 식별하고 검색할 수 있는 편리한 키라는 사실입니다.

 대화 그룹 식별자를 사용하면 데이터베이스에서 응용 프로그램 상태를 쉽게 유지 관리할 수 있습니다. 계속해서 메시지 교환과 관련된 작업 수행이 증가할 경우 응용 프로그램 상태를 유지 관리하기 위해 응용 프로그램을 계속 실행하는 것은 비효율적입니다.

SQL Server에서 응용 프로그램이 메시지를 보내거나 받을 때마다 대화 그룹을 잠그므로 응용 프로그램은 다른 프로그램이 동시에 같은 상태 데이터를 업데이트하지 않도록 명시적으로 방지할 필요가 없습니다. 응용 프로그램은 간단하게 대화 그룹을 잠그고 상태를 복원하고 메시지를 처리하며 상태를 업데이트한 다음 트랜잭션을 커밋합니다.

 대화 그룹 수명^#

• 응용 프로그램이 기존 대화 그룹과 관련되지 않은 새 대화를 시작합니다. Service Broker는 새 대화 그룹을 만들어 대화 그룹에 새로운 식별자를 할당합니다.
• 응용 프로그램이 현재 존재하지 않는 대화 그룹 식별자와 관련된 대화를 시작합니다. 이 경우 Service Broker는 지정된 식별자를 가진 새 대화 그룹을 만듭니다. 그러면 대화 그룹 식별자에 원하는 값을 직접 할당할 수 있습니다

• Service Broker가 다른 서비스에서 시작한 새 대화의 첫 번째 메시지를 받습니다. 이 경우 Service Broker는 서비스 이름과 Broker 인스턴스 식별자(있을 경우)를 사용하여 다음을 수행합니다.
  
  

  1. 알맞은 큐를 찾습니다.
  2. 새 대화 그룹을 만들고 대화 그룹을 큐에 연결합니다.
  3. 새 대화 핸들을 만들어 새 대화 그룹에 추가합니다.
  4. 들어오는 메시지를 큐에 넣습니다

서비스 아키텍처^#

 메시지 유형 - 응용 프로그램 간에 교환된 메시지의 이름을 정의합니다. 필요에 따라 메시지에 대한 유효성 검사를 제공합니다.

• 계약 - 특정 대화의 메시지 방향 및 유형을 지정합니다.
• 큐 - 메시지를 저장합니다. 이 저장 메커니즘은 서비스 간 비동기 통신을 허용합니다. Service Broker 큐는 같은 대화 그룹에 있는 메시지의 자동 잠금과 같은 추가 이점을 제공합니다.
• 서비스 - 대화에 대해 주소를 지정할 수 있는 끝점입니다. Service Broker 메시지는 한 서비스에서 다른 서비스로 전송됩니다. 서비스는 메시지를 보관할 큐를 지정하고 대상이 될 수 있는 서비스에 계약을 지정합니다. 계약은 서비스에 잘 정의된 메시지 유형 집합을 제공합니다.
  

그림에서와 같이 ProcessExpenses 계약은 세 가지 메시지 유형 SubmitExpense, AcceptDenyExpense 및 ReimbursementIssued를 지정합니다. 계약은 비용 보상 작업을 수행하는 대화에 필요한 메시지 유형을 나열합니다. ProcessExpenses 계약은 ProcessExpense 서비스 간의 대화와 ProcessExpense 서비스로 대화를 시작하는 모든 대화를 제어합니다. ProcessExpense 서비스는 들어오는 메시지와 나가는 메시지를 ExpenseQueue 큐에 저장합니다. ExpenseProcessing 저장 프로시저는 이 큐에서 메시지를 받아서 처리한 다음 회신이 필요한 경우 해당 Broker로 라우팅하는 데 사용하는 큐로 메시지를 다시 보냅니다.

 메세지 유형

• Servive Broker를 사용하는 응용프로그램은 서로 메세지를 대화의 일부로 보내 통신한다.
• 대화 참가자는 각 메시지의 이름과 내용에 동의해야한다. 메세지 유형개체 는 메세지의 유형의 이름을 정의하고 메세지의 포함된 데이터 유형을 정의한다.
• 메세지 유형은 생성된 데이터 베이스에서 유지되며, 대화에 참가한 각 데이터 베이스의 동일한 메세지 유형을 만든다.
• 빈 메세지의 경우 메세지 본문에 데이터가 없어야 한다.
• DEFAULT 라는 기본 제공 메세지 유형을 제공하고 Service Broker SEND 명령에 메세지 유형을 지정하지 않으면 DEFAULT메세지 유형을 사용한다.

계약

• 응용프로그램에서 특정 작업을 수행하는데 사용하는 메세지 유형을 정의한다.
• 각 서비스가 특정 작업을 수행하기 위해 보내는 메세지의 대한 두 서비스 간의 게약이다., 생성된 데이터베이스에서 유지된다.
• 대화에 참여한 각 데이터베이스는 동일한 게약을 만든다.
•  DEFAULT 라는 기본 계약도 포함되어 있다. DEFALT 계약에는 SENT BY ANY 메세지 유형만 포함된다.

큐

• 메세지를 저장한다. 메세지를 받으면 서비스는 큐에 메세지가 삽임된다. 서비스에 메세지를 가져오기 위해 응용 프로그램은 쿠에서 메세지를 받는다.
• 각 서비스는 하나의 큐에 연결된다.  큐에서 메세지는 하나의 행이 된다.

서비스

• 서비스는 특정 비즈니스 작업 또는 비즈니스 작업 집하의 이름입니다
• 서비스 간에 대화가 발생합니다. 
• 서비스 브로거는 서비스 이름을 사용하여 데이터베이스 내의 올바른 큐로 메세지를 배달하고 베세지를 라우팅하고 대화를 위한 계약을 강제 적용하고 새 대화를 위한 원격 보안을 결정합니다.

 네트워킹 및 원격 보안

이 글은 스프링노트에서 작성되었습니다.

 소개

Service Broker는 SQL Server에 큐 기능과 안정적인 메시징 기능을 제공합니다. Service Broker는 단일 SQL Server 인스턴스를 사용하는 응용 프로그램과 여러 인스턴스에 작업을 분산하는 응용 프로그램에서 모두 사용됩니다.

Service Broker는 단일 SQL Server 인스턴스 내에서 강력한 비동기 프로그래밍 모델을 제공합니다. 데이터베이스 응용 프로그램은 일반적으로 비동기 프로그래밍을 사용하여 대화형 응답 시간을 줄이고 전반적인 응용 프로그램 처리량을 늘립니다.

또한 Service Broker는 SQL Server 인스턴스 간에 안정적인 메시징을 제공합니다. Service Broker는 개발자가 서비스라고 하는, 독립적인 자체 포함 구성 요소에서 응용 프로그램을 작성하는 데 도움을 제공합니다. 이러한 서비스에서 제공하는 기능을 필요로 하는 응용 프로그램은 메시지를 사용하여 해당 서비스와 상호 작용합니다. Service Broker는 TCP/IP를 사용하여 인스턴스 간에 메시지를 교환합니다. Service Broker에는 네트워크에서의 무단 액세스를 차단하고 네트워크를 통해 전송되는 메시지를 암호화하는 기능이 있습니다.

역활

• 대화

  • Service Broker는 메시지를 보내고 받는 기본적인 기능을 기반으로 설계되었습니다. 각 메시지는 안정적이고 지속적인 통신 채널인 대화의 일부분을 구성합니다. 각 메시지와 대화에는 개발자의 안정적인 응용 프로그램 작성을 돕기 위해 Service Broker가 강제 적용하는 특정 유형이 있습니다.
  • 새 Transact-SQL 문을 통해 응용 프로그램에서 안정적으로 메시지를 보내고 받을 수 있습니다. 응용 프로그램에서는 관련된 작업 집합에 대한 이름인 서비스에 메시지를 보내고 내부 테이블 보기인 큐로부터 메시지를 받습니다.
  • 같은 작업에 대한 메시지는 같은 대화에 속합니다. 각 대화 내에서 Service Broker는 응용 프로그램이 모든 메시지를 전송된 순서대로 각각 한 번씩만 받도록 합니다.
  • 같은 대화를 대화그룹으로 연결할 수도 있습니다.

• 메세지 순서 지정 및 조정

  • 큐가 통합되어 데이터베이스 유지 관리 운영에 Service Broker도 포함된다.  관리자가 일상적으로 수행해야 할 유지 관리 작업이 없습니다.

• 트랜잭션 비동기 프로그래밍

  • 메세징은 트랜잭션 방식이므로 트랜잭션이 롤백 될 경우 트랜잭션의 모든 Service Broker 작업이 롤백된다.
  • 비동기 프로그래밍을 통해 개발자는 큐를 사용하는 응용 프로그램을 쉽게 작성할 수 있습니다. 많은 데이터베이스 응용 프로그램에는 리소스가 허용될 때 수행할 작업에 대한 큐 역할을 하는 테이블이 포함되어 있습니다. 큐를 사용하면 데이터베이스가 사용 가능한 리소스를 효율적으로 사용하면서 대화형 사용자에 대한 응답성을 유지할 수 있습니다. Service Broker는 큐를 데이터베이스 엔진의 중요한 부분으로 제공합니다.

• 느슨하게 연결된 응용 프로그램에 대한 지원

  •  느슨하게 연결된 응용 프로그램은 서로 독립적으로 메시지를 주고받는 여러 프로그램으로부터 구성됩니다.
  •  이러한 응용 프로그램은 교환되는 메시지에 대해 동일한 정의를 포함하고 서비스 간의 상호 작용에 대해 전체적으로 동일한 구조를 정의해야 합니다.
  •  응용 프로그램은 동시에 실행되거나 같은 SQL Server 인스턴스 내에서 실행되거나 구현 정보를 공유해야 할 필요는 없습니다.
  • 응용프로그램은 대화내 다른 참가자의 물리적 위치 또는 구현을 알 필요가 없습니다.

Service Broker 구성요소

• 대화 구성요소

  • 대화그룹, 대화 메세지, 런타임 구조를 구성한다.
  • 대화 아키텍처 참조

• 서비스 정의 구성요소

  •  응용프로그램에서 사용하는 대화의 기본 구조를 지정하는 디자인 타임 구성요소
  • 메세지 유형, 대화 흐름, 데이터베이스 저장소 등 정의
  • 서비스 아키텍처 참조

• 네트워크 및 구성 요소

  • SQL Server 인스턴스 외부의 메세지 교화을 위한 인프라 정의
•  

이 글은 스프링노트에서 작성되었습니다.