What to set in conversation FROM SERVICE argument if message is sent by trigger?

I have database trigger that sends messages to Service Broker Service. To send a message, conversation has to be created first because that is how Service Broker works (messages are sent on the conversation between the services). I read that conversations should be reused because creating new conversation each time can have bad impact on performance and number of conversations can grow to much. Whether or not I will reuse conversations, I have to create at least first conversation. Beginning conversation has following syntax:

BEGIN DIALOG [ CONVERSATION ] @dialog_handle  
   FROM SERVICE initiator_service_name  
   TO SERVICE 'target_service_name'  
       [ , { 'service_broker_guid' | 'CURRENT DATABASE' }]   
   [ ON CONTRACT contract_name ]  
   [ WITH  
   [  { RELATED_CONVERSATION = related_conversation_handle   
      | RELATED_CONVERSATION_GROUP = related_conversation_group_id } ]   
   [ [ , ] LIFETIME = dialog_lifetime ]   
   [ [ , ] ENCRYPTION = { ON | OFF }  ] ]  
[ ; ]

I do not know what should I set in FROM SERVICE argument. In general, Service Broker conversation is bidirectional. I want to send messages from trigger to service and I do not want to get any feedback, I want to send messages only in one direction. I set target service in FROM SERVICE argument and it works but I am not sure if it is good practice. Should I create additional service and set it in FROM SERVICE argument for conversations used from my trigger? Maybe this service should have activation procedure that ends conversation if EndDialog message arrive?

Is it good practice that I do not expect any response from target service? I know that I can get some management messages like http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog or http://schemas.microsoft.com/SQL/ServiceBroker/Error. I have an impressions that Service Broker forces using bidirectional conversation.

Solution

Service Broker requires a service for both initiator and target. Your trigger is the from initiator service so you should create a service and queue for that. However, the trigger does not need to implement receiving messages from the initiator queue.

You can have a separate process (perhaps a scheduled batch process) to monitor the initiator queue for unexpected error and end dialog messages, and perhaps start a new long-running conversation when needed.