The mediator describes how we merge the two protocols together. This describes how the behaviour flows from one automaton to the other (i.e. from the corba client automaton to the xml-rpc service automaton); and in the process performs the required interoperability between the two. Hence, when specifying the merge you should think about the points you wish transfer behaviour (these states are known as bi-coloured states in the mediator).
To specify these - we split existing nodes of the two automaton using the split tag:
<start>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm11</label>
</node>
</start>
<split>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm102</label>
</node>
</split>
<split>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm103</label>
</node>
</split>
<split>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm12</label>
</node>
</split>
Here we have stated that the behaviour of the mediator starts at node Bm11 of the client automaton. We then split three nodes of the client: Bm102, Bm103, Bm12. For each the state is replaced by two parts of the bi-coloured state. Bm102 is replaced by Bm1021 (or Bm102 branch 1) and **Bm1022 (or Bm102 branch 2).
All that remains to do is to describe the bridges that transfer and interoperate between the two automata. For example, we need one that transfers from Bm102 to the correct operation on the weather service automaton:
<bridge>
<from>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm102</label>
<branch>1</branch>
<action>getWeatherInfo</action>
</node>
</from>
<to>
<node>
<protocol>XMLWeatherService</protocol>
<label>Am21Bis</label>
<action>Weather.getHumidity</action>
</node>
</to>
<translationlogic>
<assignment>
<field>
<state>Bm101</state>
<message>getWeatherInfo</message>
<label>token</label>
</field>
<field>
<state>Am21Bis</state>
<message>Weather.getHumidity</message>
<label>sessionId</label>
</field>
</assignment>
<assignment>
<field>
<state>Bm101</state>
<message>getWeatherInfo</message>
<label>token</label>
</field>
<field>
<state>Am26</state>
<message>Weather.getTemperature</message>
<label>sessionId</label>
</field>
</assignment>
</translationlogic>
</bridge>
Here we bridge from the Bm102-1 node using the label and branch tags to indicate the from node. We bridge to the Am21Bis node in the weather service as identified in the to tag. All that remains is to perform any translation logic (this is optional, although usually necessary ... unless it involves actions with no parameters). Here we translate the content of field for the from/to bridge. This can be an assignment as shown in the example - the content of the first field is assigned to the second field e.g. the token field of getWeatherInfo message received at state Bm101 is assigned to the sessionId field of the Weather.getHumidity send transition of the AM21Bis state of the service.
Typically there is another bridge back from the service to the client that is described using the same format:
<bridge>
<from>
<node>
<protocol>XMLWeatherService</protocol>
<label>Am21</label>
<action>getTemperatureResponse</action>
</node>
</from>
<to>
<node>
<protocol>CORBAWeatherClient</protocol>
<label>Bm102</label>
<branch>2</branch>
<action>getWeatherInfoResponse</action>
</node>
</to>
<translationlogic>
<assignment>
<field>
<state>Am23</state>
<message>getHumidityResponse</message>
<label>return</label>
</field>
<field>
<state>Bm1022</state>
<message>getWeatherInfoResponse</message>
<label>return.humidity</label>
</field>
</assignment>
<assignment>
<field>
<state>Am24</state>
<message>getTemperatureResponse</message>
<label>return</label>
</field>
<field>
<state>Bm1022</state>
<message>getWeatherInfoResponse</message>
<label>return.temperature</label>
</field>
</assignment>
</translationlogic>
</bridge>