* 참고: 글자수 제한으로 소스1,2,3는 파일로 올린다.
도움말의 Service Broker의 역할을 보면 다음과 같은 그림이 나온다.
요걸 구현해 보것다. 편의상 왼쪽의 편지를 보내는 사람을 ‘Sender’라고 하고, 오른쪽의 편지를 받는 사람을 ‘Receiver’라고 하것다.
무조건 아래의 코드를 입력해보자. (복사보다는 직접 타자를 쳐보는 것이 더 좋겠지?)
편지를 보내고, 받는 사람, 우체국, 우편차, 어떻게 편지를 전달하는지에 대한 것을 구현한다.
소스1: Source1.doc
이제 메시지를 보내보자. 2~3회 실행해보자.
소스2: Source2.doc
메시지는 Queue에 쌓이게 되고, 메시지를 받아서 Msg테이블에 잘 저장해보자.
소스3: Source3.doc
오~ 메시지가 잘 도착했다. ㅎㅎ
그러면 이제 Person테이블이 없는 사람에게 메시지를 보내보자.
메시지 보내기 부분에서 다음과 같이 Receiver를 Person테이블에 ‘없는놈’에게 메시지를 보내보고(소스2 수정하여 실행),
위에서 실행했던 메시지를 받아보자.(소스3 실행)
--메세지보내기(소스2를 고친다.) DECLARE @handle uniqueidentifier , @Sender varchar(20) , @Receiver varchar(20) , @Msg nvarchar(max); SET @Sender = 'yasi'; SET @Receiver = '없는놈'; --이부분을 고친다.) SET @Msg = N'하이~ 방가방가(^^)/'; . . . . |
<소스4>
이제 ‘수취인불명’ 메시지를 받아보자. 아래 소스는 <소스3>과 비스무리하다.
--수취인불명메세지 DECLARE @handle uniqueidentifier , @message_body xml , @Sender varchar(20) , @Receiver varchar(20) , @Msg nvarchar(max) , @PersonName varchar(20); BEGIN TRY BEGIN TRAN; WHILE(1=1) BEGIN --보낸편지를받는다. RECEIVE TOP(1) @handle = conversation_handle , @message_body = CONVERT(nvarchar(max), message_body) FROM ReceivedMsgQueue; IF @@ROWCOUNT = 1 BEGIN SELECT @Sender = A.Sender , @Receiver = A.Receiver , @Msg = A.Msg FROM ( SELECT x.item.value('Sender[1]', 'varchar(20)') AS Sender , x.item.value('Receiver[1]', 'varchar(20)') AS Receiver , x.item.value('Message[1]', 'nvarchar(max)') AS Msg FROM @message_body.nodes('/Letter') AS x(item)) A LEFT OUTER JOIN Person B ON A.Receiver = B.PersonName; IF @Sender IS NOT NULL BEGIN INSERT Msg(Sender, Receiver, Msg, ReceiveDT) VALUES(@Sender, @Receiver, @Msg, GETDATE()); END ELSE BEGIN END CONVERSATION @handle; END END ELSE BEGIN END CONVERSATION @handle; BREAK; END END COMMIT; END TRY BEGIN CATCH IF (XACT_STATE()) = -1 ROLLBACK; ELSE IF (XACT_STATE()) = 1 COMMIT;
END CATCH;GO |
<소스5>
자~ 이제 또 한번 한 숨 돌리고(5초 가량 기둘린다.)메시지가 잘 도착했는데 살펴보자.
--메세지가잘도착했나? SELECT * FROM Msg 
|
역시 잘 된다. 보낸놈과 받는놈이 바뀐 것을 볼 수 있다.
예제만 보면 ‘아~ 조낸 복잡하네~!! 무어여 이게~~ 간단한 것을 이따시로 복잡하게 해논기여~~’라고 말하는게 눈에 훤하다.
하지만 비동기 통신, 안정적인 메시지 처리, 보내진 순서대로 처리하는 등의 내부적인 것을 구현하려면
이 정도 복잡함은 진짜 새 발의 피다.
중요한 것은 Service Broker가 SOA의 구현이라는 것이다.
또한 프로시저화 한다면 이러한 복잡함은 숨겨진다.
프로시저화 한다면 인터페이스를 단순해져 불러다가 쓰는 입장에서는 복잡함을 느끼지는 못할 것이다.
다시 한번 말하지만 이것은 절대 복잡한 것이 아니다. 복잡한 것은 이미 SQL Server 2005에 구현되어 있다.
아주 무궁무진한 가능성을 지닌 기능임에는 틀림없다. 허허..
<강좌후기>
아..띠부럴..
취침시간을 1시간 43분이나 넘겨버렸다. 24시 정각에 잠들었어야 하는데..
내일 또 하루죙일 골골 대겠다..떱..
허허 간만에 문서 만들었당~
