There are a couple scenarios in which you will need to perform additional configuration in the configuration files for the individual Responder Services (Data Services, Prediction Services, and Archive Services).

Responder Services are on different machines

At least one Responder Service resides on a machine separate from the other two, or all three reside on different machines. The services must be configured to communicate with one another.

Archive Services and Prediction Services both access Data Services as clients (and vice versa). However, Archive Services and Prediction Services have no need to communicate and do not access each other.

Look for the <system.runtime.remoting> tag. Within this tag you will find the <application> tag that contains the XML in the sample below.

Line 1: The <client> tag contains a listing of remote objects to which the service requires access (as a client). Each service accessed (both remote and local) should have a <wellknown> tag here. For example, Prediction services accesses only Data Services. So the Prediction Services configuration file would require a <wellknown> tag for Data Services (and not Archive Services). These remote objects are exposed for use by this client application (see line 9).

Line 3: The url attribute in the <wellknown> tag points to the services being accessed. If the service is remote, replace the period (.) that appears after OS: with the name of the machine on which the service resides. If the service is local, there is no need to modify the <wellknown> tag. In the example below, "RxPrediction" is the name of the queue and "PredictionServices.rem" is the service name. This service name is established in Miner.Responder.PredictionServices.exe.config in the <service> tag (example in line 9).

Line 7: The <service> tag contains objects that are exposed by this application via .NET remoting. The contents of this tag should NOT be edited.

Line 9: The objectUri attribute of the <wellknown> tag exposes the service name. Use this service name to point to a service (example in line 3) from another configuration XML file.

1
2
3
4
5
6
7
8
9
10

<client>
  <wellknown type="Miner.Responder.Shared.IPredictionServices, Miner.Responder.Shared" 
    url="msmq://FormatName:DIRECT=OS:.\private$\RxPrediction/PredictionServices.rem" />
  <wellknown type="Miner.Responder.Shared.IArchiveServices, Miner.Responder.Shared" 
    url="msmq://FormatName:DIRECT=OS:.\private$\RxArchive/ArchiveServices.rem" />
</client>
<service>
  <wellknown mode="Singleton" type="Miner.Responder.Processors.DataServices, Miner.Responder.Processors" 
  objectUri="DataServices.rem" />
</service>

Example from Miner.Responder.DataServices.exe.config

Responder message queues reside on a different machine than Responder Services

The configuration for this is the same in configuration files for all Responder Services. When one of the Responder Services is remote from its message queues, modify its configuration file.

Look for the following bit of code in the <system.runtime.remoting> section just under the <service> tags discussed previously. Line 2 in the sample below will need to be modified to look for message queues remotely.

1
2
3

<channels>
  <channel ref="msmq" isServer="true" />
</channels>

The "msmq" channel offers several optional attributes. Use the queueName attribute if the Service is remote from its message queues.

• isServer: This attribute specifies whether the channel should behave as a server and actively listen for incoming requests. Responder middle-tier servers must specify "true" and any clients will usually specify "false". Default = False
• useAuthentication: This attribute specifies whether the request queue should be marked to require authentication. This option requires Active Directory. Default = False
• queueName: This attribute specifies the name of the message queue. This value must have the following format: FormatName:DIRECT=OS:{machine}\private$\{name}

  {machine} = The remote machine or "." (without quotes) for the local machine

  {name} = The base-name of the queues to use. Note that the base-name will always be appending with _ack, _req, _rsp because three queues are needed for communicating via the msmq remoting transport channel.

  If this attribute is not specified, the ServerChannel will use the first acceptable queue name obtained from the following locations (in order):

  1. value specified in .\@queueName (see description: "queueName" attribute)
  2. value specified in ..\application\@name (see element: <application name="RxServer">)
  3. the application executable name (e.g., "dataservices" when application is Miner.Responder.DataServices.exe)
• autoCreateQueues: This attribute specifies whether the ServerChannel should attempt to create the required message queues. This only applies if "isServer" is set to True. This option will only work when the server is using local queues. Default = True

Below is a sample in which message queues are accessed remotely. The values highlighted in yellow are those that were modified. The first is the name of the machine on which the message queues reside. The second is the base name of the Prediction Services message queues.

1
2
3

<channels>
  <channel ref="msmq" queueName="FormatName:DIRECT=OS:Madison\private$\rxprediction" isServer="true" />
</channels>

Send Comment to ArcFMdocumentation@schneider-electric.com