Routes routes are used to tell the sQL service Broker that a message needs to be sent to another server on the network.. if there is, then the route is used to send the message to the re
Trang 1There 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
Trang 2When 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;
Trang 3The 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
Trang 4The 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
Trang 5name 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