CORBAWeatherClient.xml

This is the coloured automaton describing a CORBA weather client.

Inside a <protocol> tag you first give the automaton a name for identification:</protocol>

<protocolName>CORBAWeatherClient</protocolName>

Then you 'colour' the automaton with <attributes>. This generally states the [Protocol Colour] type; in this case we want the automaton to be executed using CORBA:</attributes>

<attributes>
    <ProtocolBinding>IIOPClientObjectBinding.xml</ProtocolBinding>
</attributes>

We are now ready to specify the automaton. Each state has a label identifier and we should specify the label of the start state

<automaton>
 <start>Bm11</start>

The automaton specification is then a list of state, where a state is label and one or more transitions to a toState. The following is send actin with a simple string parameter - hence Outputs are used n.b. ** a state with a send operation MUST HAVE only one transition:

<state>
    <label>Bm103</label>
    <transition>
    <action>quitStationResponse</action>
    <operation>send</operation>
    <Outputs>
            <Output>
                <simpleType>
                    <name>response</name>
                    <type>java.lang.string</type>
                </simpleType>
            </Output>
        </Outputs>
    <toState>Bm51</toState>
    </transition>
</state>

Complex structured data types can be used in similar fashion to the previous simple data types. Hence the output type is labelled return and the value is referenced by return.humidity or return.temperature:

    <state>
        <label>Bm102</label>
        <transition>
            <action>getWeatherInfoResponse</action>
            <operation>send</operation>
            <Outputs>
                <Output>
                    <complexType name="return">
                        <simpleType>
                            <name>humidity</name>
                            <type>java.lang.string</type>
                        </simpleType>
                        <simpleType>
                            <name>temperature</name>
                            <type>java.lang.string</type>
                        </simpleType>
                    </complexType>
                </Output>
            </Outputs>
            <toState>Bm101</toState>
        </transition>
    </state>

A state can have one or more receiving transitions. For example if a getWeather action is received the automaton moves to Bm102, or if it receives quitStation action it moves to Bm103:

<state>
    <label>Bm101</label>
    <transition>
        <action>getWeatherInfo</action>
        <operation>recv</operation>
        <Inputs>
            <Input>
                <simpleType>
                    <name>token</name>
                    <type>java.lang.string</type>
                </simpleType>
            </Input>
        </Inputs>
        <toState>Bm102</toState>
    </transition>
    <transition>
        <action>quitStation</action>
        <operation>recv</operation>
        <Inputs>
            <Input>
                <simpleType>
                    <name>token</name>
                    <type>java.lang.string</type>
                </simpleType>
            </Input>
        </Inputs>
        <toState>Bm103</toState>
    </transition>
</state>

This automaton describes the behaviour of a client; here it is best to think of mirroring the operations. If the client is sending then the description should be a receive (recv) because we are modelling the behaviour of a mediator that receives the client's actions - we are not modelling the behaviour of the client itself.