IMPORTANT in .NET

Draw PDF417 in .NET IMPORTANT

All names in a Service Broker application are case sensitive. All messages are transmitted with a binary collation to ensure that different collation sequences between endpoints do not cause data loss due to character set compatibility issues.

20

What validation options are available for message types EMPTY specifies that no data is contained in the message. NONE specifies that the message can contain any data and is not validated. WELL_FORMED_XML uses an XML parser to guarantee that a valid XML document is within the message body. VALID_XML WITH SCHEMA COLLECTION loads an XML parser and validates the message body against the schemas in the specified schema collection.

A contract contains a list of message types and the services that are allowed to send them. The generic form of the statement to create a contract is as follows:

CREATE CONTRACT contract_name [ AUTHORIZATION owner_name ] ( { { message_type_name | [ DEFAULT ] } SENT BY { INITIATOR | TARGET | ANY } } [ ,...n] )

The contract_name clause provides a convenient way to refer to a group of message types. The name must conform to the rules for identifiers and, like all other names in Service Broker components, is case sensitive. The AUTHORIZATION clause sets the owner of the contract. The body of a contract specifies the message types that are allowed as well as which service is allowed to send a given message type. If the SENT BY clause specifies INITIATOR, only the service that started the conversation can use that message type. If the SENT BY clause specifies TARGET, only the service that is processing messages on the queue can send that message type. If the SENT BY clause specifies ANY, either service can send a message of that type. Let s look at an example of defining a contract for several message types. Let s say you are developing an application that lets a user select a product from a list. The product ID that the user selects will be sent by the application to the database, and the database will return a result set that includes the Bill Of Materials associated

with the specified product ID. After the Bill Of Materials is received, additional processing will occur. The sending of the product ID and the returning of the associated Bill Of Materials might take awhile, so you also need to define a mechanism to allow either side to find out the status of their request. Here is how you can use Service Broker message types and a contract to accomplish this processing. First, you would create a message type of RequestBillOfMaterials, which is used to send the product ID to the database; a message type of ReturnBillOfMaterials, which is used to return the result set to the application; and a message type of StatusRequest. Because all three message types define a logical process, you can combine them into a contract. The process is initiated with a message type of RequestBillOfMaterials, so the contract would specify this message type with a SENT BY INITIATOR clause because the destination for the message would not have the capability to generate a message that contained the product ID. The database that accepts the product ID input and returns the result set will use the ReturnBillOfMaterials message type with a SENT BY TARGET clause because the source of the product ID would not have the capability to generate a result set. The StatusRequest message type can be used by either one, so you will define it with the SENT BY ANY clause because either participant in the conversation can request the status at any time. Because contracts define the type of messages allowed as well as which side of the conversation can use a particular message type, there is one more requirement for defining a contract. Messages cannot be sent spontaneously. Therefore, every contract must contain at least one message type that can be used by the service that initiates a conversation, meaning that at least one message type must have the SENT BY clause specifying either INITIATOR or ANY.