<?xml version="1.0" encoding="UTF-8"?>
<section version="5.0" xml:id="control-bus"
         xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:ns5="http://www.w3.org/1999/xhtml"
         xmlns:ns4="http://www.w3.org/1998/Math/MathML"
         xmlns:ns3="http://www.w3.org/2000/svg"
         xmlns:ns="http://docbook.org/ns/docbook">
  <title>Control Bus</title>

  <para>As described in (EIP), the idea behind the Control Bus is that the
  same messaging system can be used for monitoring and managing the components
  within the framework as is used for "application-level" messaging. In Spring
  Integration we build upon the adapters described above so that it's possible
  to send Messages as a means of invoking exposed operations.</para>

  <programlisting language="xml">&lt;int:control-bus input-channel="operationChannel"/&gt;</programlisting>

  <para>The Control Bus has an input channel that can be accessed for invoking
  operations on the beans in the application context. It also has all the
  common properties of a service activating endpoint, e.g. you can specify an
  output channel if the result of the operation has a return value that you
  want to send on to a downstream channel.</para>

  <para>The Control Bus executes messages on the input channel as Spring
  Expression Language expressions. It takes a message, compiles the body to an
  expression, adds some context, and then executes it. The default context
  supports any method that has been annotated with @ManagedAttribute or @ManagedOperation.
  It also supports the methods on Spring's Lifecycle interface, and it supports methods
  that are used to configure several of Spring's TaskExecutor and TaskScheduler implementations.
  The simplest way to ensure that your own methods are available to the Control Bus is to
  use the @ManagedAttribute and/or @ManagedOperation annotations. Since those are also used
  for exposing methods to a JMX MBean registry, it's a convenient by-product (often the same
  types of operations you want to expose to the Control Bus would be reasonable for exposing
  via JMS). Resolution of any particular instance within the application context is achieved
  in the typical SpEL syntax. Simply provide the bean name with the SpEL prefix for beans (@).
  For example, to execute a method on a Spring Bean a client
  could send a message to the operation channel as follows:</para>

  <programlisting>Message operation = MessageBuilder.withPayload("@myServiceBean.shutdown()").build();
operationChannel.send(operation)</programlisting>

  <para>The root of the context for the expression is the
  <classname>Message</classname> itself, so you also have access to the 'payload'
  and 'headers' as variables within your expression. This is consistent with all the other expression
  support in Spring Integration endpoints.</para>

</section>
