Commit eeb1015c authored by dwentzel's avatar dwentzel

completed code for Services post

parent 732b3b4b
......@@ -14,6 +14,10 @@ This folder contains the source code for my [Service Broker Demystified blog ser
`GUIDs.sql` covers interesting aspects of SET NEW_BROKER vs ENABLE_BROKER.
`more_on_services.sql` demos how to determine if a service is "send-only" as well as some other anomalies of services.
`ServicesAndQueues.sql` demonstrates why we need to have both service and queue objects in Service Broker.
`URIs.sql` dispels the myth that if you use URI naming that your SQL Server will access external resources for validation.
......
/*
This is the source code for http://www.davewentzel.com/content/service-broker-demystified-services.
This covers some interesting "features" of SSB services.
*/
--basic setup
USE master
GO
CREATE DATABASE SBTest
GO
ALTER DATABASE SBTest SET NEW_BROKER
GO
USE SBTest
GO
/*
What is the difference between these services?
*/
CREATE QUEUE QueueA;
CREATE SERVICE ServiceA ON QUEUE QueueA;
CREATE SERVICE ServiceB ON QUEUE QueueA ([DEFAULT]);
--this works
BEGIN TRANSACTION
DECLARE @h UNIQUEIDENTIFIER;
BEGIN DIALOG @h
FROM SERVICE [ServiceA]
TO SERVICE 'ServiceB'
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @h ('Success!');
COMMIT;
select message_body, transmission_status from sys.transmission_queue
select message_type_name, convert(xml,message_body) as MsgBody from QueueA
--but ServiceB sending to ServiceA will not work
BEGIN TRANSACTION
DECLARE @h1 UNIQUEIDENTIFIER;
BEGIN DIALOG @h1
FROM SERVICE [ServiceB]
TO SERVICE 'ServiceA'
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @h1 ('Failure');
COMMIT;
select message_body, transmission_status from sys.transmission_queue
select message_type_name, convert(xml,message_body)as MsgBody from QueueA
--let's cleanup sys.transmission_queue
DECLARE @ch uniqueidentifier;
SELECT @ch = conversation_handle from sys.transmission_queue
END CONVERSATION @ch WITH CLEANUP;
/*
This is a (bad) design pattern where one "master" service
performs many responsibilities, each denoted by separate
contracts bound to the service. With this pattern we would
also want multiple message types as well, omitting them here
from brevity.
*/
CREATE MESSAGE TYPE EnterpriseWorkflow VALIDATION = WELL_FORMED_XML;
CREATE CONTRACT [ExpenseSubmission] (EnterpriseWorkflow SENT BY INITIATOR);
CREATE CONTRACT [TimeSheetSubmission] (EnterpriseWorkflow SENT BY INITIATOR);
CREATE CONTRACT [Status] (EnterpriseWorkflow SENT BY ANY);
CREATE QUEUE GenericQ;
CREATE SERVICE EnterpriseSvc ON QUEUE GenericQ (
[ExpenseSubmission],
[TimeSheetSubmission],
[Status]);
/*
We've proved that we can create send-only services.
Is it possible to create a receive-only service?
In other words, ReceiverSvc should NEVER be able to initiate a dialog
with another service.
*/
--Let's create the scaffolding
CREATE MESSAGE TYPE Request VALIDATION = NONE;
CREATE MESSAGE TYPE Response VALIDATION = NONE;
CREATE CONTRACT ReceiveOnlyContract (Request SENT BY INITIATOR, Response SENT BY TARGET);
--we want this service as "open" as possible
CREATE QUEUE SomeGenericQ;
CREATE SERVICE SomeGenericSvc ON QUEUE SomeGenericQ([DEFAULT]);
--and we want this service to not be able to ever by an initiator
CREATE QUEUE ReceiverQ;
CREATE SERVICE ReceiverSvc ON QUEUE ReceiverQ (ReceiveOnlyContract);
--the message will be as basic as possible
BEGIN TRANSACTION
DECLARE @h2 UNIQUEIDENTIFIER;
BEGIN DIALOG @h2
FROM SERVICE [ReceiverSvc]
TO SERVICE 'SomeGenericSvc'
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @h2;
COMMIT;
--the message was successful
select count(*) AS SomeGenericQ_count from SomeGenericQ
--basic cleanup
USE master;
GO
DROP DATABASE SBTest;
GO
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment