ServiceBroker•Chapter12 537 There are two ways that SQL Server can listen for an Endpoint; those options are TCP and HTTP. SERVICE BROKER Endpoints require that the listener be a TCP endpoint. The LISTENER_PORT can be set to whatever TCP port number you wish to use to allow communication from other servers. It is recommended that you use a TCP port number over 1024 as most ports under 1024 are assigned to other services. Some key ports over 1024 that you do not want are: 1270 Microsoft MOM Agent 1293 IPSec 1311 Dell OpenManage 1433 SQL Servers Port Number 1512 WINS 1521 Oracle Default Port Number 2381 HP Insight Manager 3389 Remote Desktop’s Port Number 3306 MySQL If you are having trouble selecting a port number to use you can find the list of registered port numbers and the applications that claim them at http://en.wikipedia. org/wiki/List_of_TCP_and_UDP_port_numbers. In the example shown I specify the LISTENER_IP of ALL. This allows a remote SQL Server’s SERVICE BROKER to connect on any IP address that is assigned to the server. If the server has a DHCP address then this would be the setting you would want to use. If the server has multiple IP addresses then you will want to use this setting as well if you wish to have the remote system connect to any of the IP addresses. If you wish to have the remote systems connect to a single IP address only then specify the IP address there within single quotes. The IP address that you specify must be an IP address currently hosted by the SQL Server or the CREATE ENDPOINT command will fail with an error. We then tell the CREATE ENDPOINT command that we are creating this endpoint FOR SERVICE_BROKER to use. We are then setting the Authentication to Windows Authentication. If you choose you can use Certification-based authentication. You can also specify whether NTLM or KERBEROS authentication should be used, in addition to being able to tell the Endpoint to NEGOTIATE the more secure connection. Because we do not specify which Windows Authentication protocol (NTML or KERBEROS) to use, NEGOTIATE is used by default. 538 Chapter12•ServiceBroker When we create the Endpoint we can also specify if Encryption is DISABLED, SUPPORTED, or REQUIRED. In the example I selected REQUIRED, which prevents anyone from listening to the network traffic and seeing what data is being passed from server to server. This helps protect the databases from attack because we are encrypting the data as it flows between the two servers. REQUIRED is the default encryption setting when creating an Endpoint. You can also specify which encryption algorithm you wish to use when encrypting the data between servers. The default is the RC4 algorithm. The other options are AES, AES RC4, and RC4 AES. If you specify the AES RC4 or the RC4 AES algorithm this tells the Endpoint to use either algorithm, attempting the first one specified, and then falling back to the second one. When specifying the encryption algorithm to use it is important to know the difference between the two. The AES algorithm is a much stronger encryption algorithm than the RC4 algorithm, but that increased level of protection comes at a cost of additional CPU power being needed to encrypt and decrypt the data. If security is a high priority for you it is recommended that you use the AES algorithm. If you have TCP encryption, offload chips on the network cards of your servers; then encryption can be disabled, because the network card will handle all encryption and decryption for you before the data leaves the server. Routes Routes are used to tell the SQL SERVICE BROKER that a message needs to be sent to another server on the network. The function of a route is pretty basic. When a message is sent to a service, before delivering that message to the receiving service the SQL SERVICE BROKER checks the routes table to see if there is a route defined on that service. If there is, then the route is used to send the message to the remote machine instead of delivering it to the local service. When setting up a route to a remote instance of SQL Server you will need three pieces of information from the remote machine. The first piece of information you will need is the IP address of the remote machine. If the remote machine is at another company then you will need the public IP address that is being NATed to the SQL Server. The second piece of information you will need is the port number that was configured on the remote machine’s Endpoint. If the Endpoint was set up a while ago, you can query the sys.service_broker_endpoints and sys. tcp_endpoints catalog views to get this information. SELECT p.port FROM sys.tcp_endpoints as p JOIN sys.service_broker_endpoints as s ON s.endpoint_id = p.endpoint_id; ServiceBroker•Chapter12 539 The third piece of information that you will need is the GUID, which uniquely identifies the remote database’s SERVICE BROKER from other systems in your enterprise. This can be found by querying the sys.databases catalog view on the remote server. The value you are looking for can be found in the service_broker_guid column. If the value is all zeros then you will need to issue an ALTER DATABASE command against the remote database to configure the SERVICE BROKER. Routes are created to the remote system by using the CREATE ROUTE command. The CREATE ROUTE command must be run on both servers so that each server knows about each other so that the messages can flow from the sender to the receiver, and so that the acknowledgements can flow from the receiver to the sender. CREATE ROUTE YourRoute AUTHORIZATION dbo WITH SERVICE_NAME = 'YourApplication\YourService', BROKER_INSTANCE='', LIFETIME=68400, ADDRESS='tCP://RemoteMachine:5555', MIRROR_ADDRESS='tCP://OtherRemoteMachine:5555'; The SERVICE_NAME is where the case sensitivity comes into play that was mentioned earlier. When the local server does its matching to see if the service name you are sending to matches that of the route it does a byte-by-byte comparison against the values. If there is any case sensitivity mismatch then the messages will not follow the route to the remote machine. You can also create a route with no service name. Doing this will cause all messages to follow the route, however, this will happen at a lower priority than if a route exists for a specific service. In other words, if you have a route to SERVER1 with no service name, and a route to SERVER2 for the YourApplication\YourService service, then messages to the YourApplication\YourService will be sent to the SERVER2 and messages to all other services will be sent to SERVER1. The BROKER_INSTANCE parameter is also optional, however, it is recommend that you specify the value so that you can more easily control which database on the remote server receives the message. When the conversation is created you can also specify the BROKER_INSTANCE if you would prefer to specify it there. The LIFETIME is another optional parameter. This parameter will allow you to set the time (in seconds from the time the route was created) that the route is valid. When the specified number of seconds has passed the route will automatically be deleted. If the LIFETIME is not specified then the route will never expire and will remain until manually deleted with the DROP ROUTE command. 540 Chapter12•ServiceBroker The ADDRESS parameter is a required parameter that tells the route the name or IP address and port number of the remote machine to connect to. You can specify a local machine name as was done in the example, or the full DNS name of the machine, or the IP address of the machine if there is no DNS name or host name set up. The machine name is followed by a colon and the port number on which the Endpoint is listening. The MIRROR_ADDRESS parameter is an optional parameter. If you are not using database mirroring on the remote database then this setting is not needed. If you are using database mirroring then it is strongly recommended that you provide the Endpoint information for the mirror server. If you do not, and the mirror fails over, then the SERVICE BROKER will not be able to send the messages to the remote machine until the mirror fails back. The MIRROR_ADDRESS parameter uses the same syntax as the ADDRESS parameter. If you are sending messages to a clustered instance the MIRROR_ADDRESS is not needed, because when a cluster fails over, the same IP address is used on the remote machine. If you are using Windows 2008 clustering and have different IP address subnets on both sides of the cluster because you are clustering between data centers, you can specify the second subnet’s IP address in the MIRROR_ ADDRESS field, but it is recommended that you instead use the DNS name of the SQL Server so that when the cluster fails over and updates DNS the connection simply is redirected to the correct host. Like all the other SERVICE BROKER objects there is no easy way to see to which service a route is bound. The only way to view this information short of scripting out the route is to view the meta data for the routes in the sys. routes catalog view. Sending a Message Once the SQL SERVICE BROKER objects have been created you are ready to send a message. Sending a message is actually a two part process. First you must create a conversation upon which you can send messages by using the BEGIN DIALOG command. Then you can send your message using the SEND command. When you begin a conversation with the BEGIN DIALOG command you must specify from which service you are sending the message, to which service you are sending the message, as well as the contract to which the messages will conform (remember that the contract contains a bunch of message types). When you specify the source of the message you will be formatting the name as a database object. When you specify the destination of the message you will be formatting the ServiceBroker•Chapter12 541 name as a text string. The contract will also be formatted as a database object. This means that you cannot use variables to define your source service or your contract. DECLARE @conversation_handle UNIQUEIDENTIFIER BEGIN DIALOG @conversation_handle FROM SERVICE [YourApplication\YourService] TO SERVICE 'YourApplication\YourService' ON CONTRACT [YourApplication/Contract1] You’ll notice that the TO SERVICE line has the service name wrapped in single quotes, not square brackets, since it is a text string, not an object name. The value now contained within the @conversation_handle variable will be used within the SEND command. Most typically the SEND command will be the next command in the stored procedure that is sending the message. When sending a message you have to provide the Conversation Id on which the message will be sent, the message type of the data in the message, as well as the data to be sent within the message. All fields are required with the exception of the data within the message, which is optional if the message type validation was specified as EMPTY or NONE. Sample code of a message with data in the message body would look like this: DECLARE @conversation_handle UNIQUEIDENTIFIER DECLARE @message_body XML BEGIN DIALOG @conversation_handle FROM SERVICE [YourApplication\YourService] TO SERVICE 'YourApplication\YourService' ON CONTRACT [YourApplication/Contract1] SET @message_body = (SELECT * FROM sys.tables FOR XML AUTO) SEND ON CONVERSATION @conversation_handle MESSAGE TYPE [YourApplication/YourMessageType] (@message_body); At this point your message text has been sent. If you query the queue using the SELECT statement you should see the message in there. If not check the sys.transmission_queue and sys.conversation_endpoints DMVs and see if there are any errors that need to be resolved. Now that you have sent the message, you need to be able to receive the message. Being able to look at the message using the SELECT statement is all well and good, but if you used the SELECT statement to get the values out of the queue . remote SQL Server s SERVICE BROKER to connect on any IP address that is assigned to the server. If the server has a DHCP address then this would be the setting you would want to use. If the server. use the DNS name of the SQL Server so that when the cluster fails over and updates DNS the connection simply is redirected to the correct host. Like all the other SERVICE BROKER objects there. another company then you will need the public IP address that is being NATed to the SQL Server. The second piece of information you will need is the port number that was configured on the