Core Examples

Attention:

Be sure that the Corba Naming Service is running and the NameServiceIOR environment-variable is set correctly! (see Installation - CORBA Naming Service)
Most examples do not unbind themself from the naming service properly (they just abort on Ctrl-C). Therefore, it might be necessary to restart the naming service between two tests. Will be changed soon!

First example

Demonstrates:

  • query communication pattern (QueryClient, QueryServer, Communication Objects)

WHAT DOES THE FIRST EXAMPLE ?

  • Component1 provides a server reporting the current time and also a server which returns the sum of the received values.
  • Component2 is a multithreaded client.

This examples illustrates the organisation of the communication patterns including the file structure etc. A component provides several services which can be accessed by a client component. By looking at the component description file you get further information on which services a component requires and which one it provides. Look at the Makefile to see how libraries of communication objects needed by a component are linked.

See also Tenth example for dynamic wiring of components and for an active query handler.

Components:

  • smartExampleComponent1 : Example server query (standard query handler)
  • smartExampleComponent2 : Example client query

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent1 &
    # xterm -e bin/smartExampleComponent2 &

Second example

Demonstrates

  • push newest communication pattern (PushNewestClient, PushNewestServer)
  • thread management

WHAT DOES THE SECOND EXAMPLE ?

  • Component10 pushes the current time to every subscribed client every 2 seconds
  • Component11 subscribes / unsubscribes and illustrates the blocking call which waits for the next new data

Components:

  • smartExampleComponent10 : Example server pushNewest
  • smartExampleComponent11 : Example client pushNewest

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent10 &
    # xterm -e bin/smartExampleComponent11 &

Third Example

Demonstrates:

  • query communication pattern
  • state management pattern
  • thread management

WHAT DOES THE THIRD EXAMPLE ?

  • Component20 consists of several user threads which run only if the appropriate states are set. One of the threads requests the current time from Component22 which however delays every answer by 10 seconds. This is used to demonstrate how a blocking query can be cancelled by enforcing the neutral state.
  • Component21 is the master of Component20 and demonstrates how states can be set.
  • Component22 provides the already mentioned time service

notice the behaviour of the state pattern:

  • you can see the state changes and how the different threads are activated / deactivated
  • when setting the "neutral" state, this is delayed until all threads release their locks
  • when enforcing the "neutral" state by "deactivated", the pending query to receive the time is aborted with state SMART_CANCELLED

Components:

  • smartExampleComponent20 : Example of component with state (Slave component)
  • smartExampleComponent21 : Example of master to set states in smartExampleComponent20
  • smartExampleComponent22 : A very slow time server

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent20 &
    # xterm -e bin/smartExampleComponent21 &
    # xterm -e bin/smartExampleComponent22 &

Fourth Example

Demonstrates:

  • query communication pattern
  • usage of STL in communication objects
  • thread management
  • components both client and server to each other

WHAT DOES THE FOURTH EXAMPLE ?

  • two components access each other since both are client and server to each other

Components:

  • smartExampleComponent30 : Server for time service and client of calculation service
  • smartExampleComponent31 : Server for calculation and client of time service

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent30 &
    # xterm -e bin/smartExampleComponent31 &

Fifth Example

Demonstrates:

  • event communication pattern
  • thread management

WHAT DOES THE FIFTH EXAMPLE ?

One component provides a cyclic counter in the interval 0 ... 49. The first event fires as soon as the counter is greater than the parameter given by the event activation. If the event fires, it returns the current counter value. This event is used in single and continuous mode. The second event checks whether the current counter value is in the specified interval. It reports only state changes and is therefore used in continuous mode. The second event gives an example of a state based event. The parameter object contains a state which allows to report the current state with the next test of the event condition.

Components:

  • smartExampleComponent40 : Server providing an event
  • smartExampleComponent41 : Client using the event

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent40 &
    # xterm -e bin/smartExampleComponent41 &

Sixth Example

Demonstrates

  • send communication pattern
  • thread management
  • timer

WHAT DOES THE SIXTH EXAMPLE ?

One component simply sends several messages from several threads. The content of the messages is printed by the server component. One component contains time triggered send commands to demonstrate how to register objects at the time service.

Components

  • smartExampleComponent50 : Server providing a print service
  • smartExampleComponent51 : Client using the print service
  • smartExampleComponent52 : Client using the print service & timers

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent50 &
    # xterm -e bin/smartExampleComponent51 &
    # xterm -e bin/smartExampleComponent52 &

Seventh Example

Demonstrates:

  • parameter management

WHAT DOES THE SEVENTH EXAMPLE ?

Accept command line arguments and read the parameter file.

Component:

  • smartExampleComponent60 : Component to show usage of parameter class

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent60 &

Eighth Example

Demonstrates

  • push timed pattern

WHAT DOES THE EIGHTH EXAMPLE ?

One component regularly provides (every 2 seconds) the current time based on a pushTimed-service. The other component subscribes for an update every second time so it gets an update every 4 seconds.

Components

  • smartExampleComponent70 : Server providing a pushTimed service
  • smartExampleComponent71 : Client using the pushTimed service

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent70 &
    # xterm -e bin/smartExampleComponent71 &

Ninth Example

Demonstrates

  • wiring pattern for dynamic wiring of component connections
  • query communication pattern (QueryClient, QueryServer, Communication Objects)
  • thread management
  • handling of slow and/or blocking queries

WHAT DOES THE NINTH EXAMPLE ?

Two components provide exactly the same services which are dynamically connected by a client. When to connect which server is configured from another component. Rewiring is done without taking into account the internal state of the client component. This example is a modified version of the first example.

Components

  • smartExampleComponent101 : first component providing time and calc service
  • smartExampleComponent102 : client which is dynamically wired to connect either component 101 or 103
  • smartExampleComponent103 : second component providing time and calc service, threaded query handler
  • smartExampleComponent104 : contains the master to regularly change the wiring of the other components

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent101 &
    # xterm -e bin/smartExampleComponent102 &
    # xterm -e bin/smartExampleComponent103 &
    # xterm -e bin/smartExampleComponent104 &

Tenth example

Demonstrates:

  • query communication pattern (QueryClient, QueryServer, Communication Objects)
  • thread management
  • handling of slow and/or blocking queries

WHAT DOES THE TENTH EXAMPLE ?

  • Component80 provides a server reporting the current time and also a server which returns the sum of the received values
  • Component81 is a multithreaded client with alternating connections to the server Component80 and Component82.
  • Thread B of component81 demonstrates the asynchronous behavior of the deferred query. The query request immediately returns after invoking the request without waiting for the server to complete the query.
  • Component82 is another version of Component80 and provides the exactly same services. Component82 shows how to use a threaded query handler to handle slow query processing in a separate thread.

This example illustrates how a component can change its connections by itself using the dynamic wiring capabilities.

Components:

  • smartExampleComponent80 : Example server query (standard query handler)
  • smartExampleComponent81 : Example client query
  • smartExampleComponent82 : Example server query (threaded query handler)

run:

    # cd $SMART_ROOT
    # xterm -e bin/smartExampleComponent80 &
    # xterm -e bin/smartExampleComponent81 &
    # xterm -e bin/smartExampleComponent82 &