Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

INT-1420: add docs for control bus and tidy JMX

Browse Source
This commit is contained in:
Dave Syer
2010-11-11 14:51:35 +00:00
parent e617de54c8
commit a0db55a75e
6 changed files with 128 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/src/reference/docbook/control-bus.xml Normal file
View File

@@ -0,0 +1,35 @@
<?xml version="1.0" encoding="UTF-8"?>
<section version="5.0" xml:id="jmx" 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"><![CDATA[
<groovy:control-bus input-channel="operationChannel"/></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
downsatrem 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 just exposes all the beans in the
application context by name.
</para>
</section>

117
docs/src/reference/docbook/groovy.xml
View File

@@ -1,30 +1,34 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="groovy"
xmlns:xlink="http://www.w3.org/1999/xlink">
<section version="5.0" xml:id="groovy" 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>Groovy support</title>
<para>
With Spring Integration 2.0 we've added Groovy support allowing you to use Groovy scripting language to provide
integration and business logic  for various integration components similar to the way Spring Expression Language (SpEL)
is use to implement routing, transformation and other integration concerns.
For more information about Groovy please refer to Groovy documentation which you can find here: http://groovy.codehaus.org/
</para>
<para>With Spring Integration 2.0 we've added Groovy support allowing you to
use Groovy scripting language to provide integration and business logic  for
various integration components similar to the way Spring Expression Language
(SpEL) is use to implement routing, transformation and other integration
concerns. For more information about Groovy please refer to Groovy
documentation which you can find
on the <ulink url="http://groovy.codehaus.org">project website</ulink></para>
<section id="groovy-config">
<title>Groovy configuration</title>
<para>
Depending on the complexity of your integration requirements Groovy scripts could be provided inline as CDATA in XML
configuration or as a reference to a file containing Groovy script.
To enable Groovy support Spring Integration defines <classname>GroovyScriptExecutingMessageProcessor</classname> which will
create a groovy Binding object identifying Message Payload as <code>payload</code> variable and Message Headers as
<code>headers</code> variable. All that is left for you to do is write script that uses these variables.
Below are couple of sample configurations:
</para>
<para>Depending on the complexity of your integration requirements Groovy
scripts could be provided inline as CDATA in XML configuration or as a
reference to a file containing Groovy script. To enable Groovy support
Spring Integration defines
<classname>GroovyScriptExecutingMessageProcessor</classname> which will
create a groovy Binding object identifying Message Payload as
<code>payload</code> variable and Message Headers as <code>headers</code>
variable. All that is left for you to do is write script that uses these
variables. Below are couple of sample configurations:</para>
<para>
<emphasis>Filter</emphasis>
<programlisting language="xml">&lt;filter input-channel="referencedScriptInput"&gt;
<para><emphasis>Filter</emphasis> <programlisting language="xml">&lt;filter input-channel="referencedScriptInput"&gt;
&lt;groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/&gt;
&lt;/filter&gt;
@@ -32,41 +36,50 @@
&lt;groovy:script&gt;&lt;![CDATA[
return payload == 'good'
]]&gt;&lt;/groovy:script&gt;
&lt;/filter&gt;</programlisting>
You see that script could be included inline or via <code>location</code> attribute using the groovy namespace sport. 
</para>
&lt;/filter&gt;</programlisting> You see that script could be included inline
or via <code>location</code> attribute using the groovy namespace
sport. </para>
<para>
Other supported elements are <emphasis>router, service-activator, transformer, splitter</emphasis>
</para>
<para>
Another interesting aspect of using Groovy support is framework's ability to update (reload) scripts 
without restarting the Application Context.
To accomplish this all you need is specify <code>refresh-check-delay</code> attribute on <emphasis>script</emphasis>
element. The reason for this attribute is to make reloading of the script more efficient. 
<programlisting language="xml"><![CDATA[<groovy:script location="..." refresh-check-delay="5000"/>]]></programlisting>
In the above example for the next 5 seconds after you update the script you'll still be using the old script and
after 5 seconds the context will be updated with the new script. This is a good example where  'near real time'
is acceptable.
<programlisting language="xml"><![CDATA[<groovy:script location="..." refresh-check-delay="0"/>]]></programlisting>
In the above example the context will be updated with the new script every time the script is modified. Basically this is the example of the
'real-time' and might not be the most efficient way.
<programlisting language="xml"><![CDATA[<groovy:script location="..." refresh-check-delay="-1"/>]]></programlisting>
Any negative number value means the script will never be refreshed after initial initialization of application context.
DEFAULT BEHAVIOR
<important>Inline defined script can not be reloaded.</important>
</para>
<para>Other supported elements are <emphasis>router, service-activator,
transformer, splitter</emphasis></para>
<para>Another interesting aspect of using Groovy support is framework's
ability to update (reload) scripts  without restarting the Application
Context. To accomplish this all you need is specify
<code>refresh-check-delay</code> attribute on <emphasis>script</emphasis>
element. The reason for this attribute is to make reloading of the script
more efficient.  <programlisting language="xml">&lt;groovy:script location="..." refresh-check-delay="5000"/&gt;</programlisting>
In the above example for the next 5 seconds after you update the script
you'll still be using the old script and after 5 seconds the context will
be updated with the new script. This is a good example where  'near real
time' is acceptable. <programlisting language="xml">&lt;groovy:script location="..." refresh-check-delay="0"/&gt;</programlisting>
In the above example the context will be updated with the new script every
time the script is modified. Basically this is the example of the
'real-time' and might not be the most efficient way. <programlisting
language="xml">&lt;groovy:script location="..." refresh-check-delay="-1"/&gt;</programlisting>
Any negative number value means the script will never be refreshed after
initial initialization of application context. DEFAULT BEHAVIOR
<important>Inline defined script can not be reloaded.</important></para>
</section>
<section id="groovy-control-bus">
<title>Control Bus</title>
<para>As described in (<ulink
url="http://www.eaipatterns.com/ControlBus.html">EIP</ulink>), 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.<programlisting language="xml"> &lt;groovy:control-bus input-channel="operationChannel"/&gt;</programlisting></para>
<para>The Control Bus has an input channel that can be accessed for
invoking operations on the beans in the application context.</para>
<para>The groovy control bus executes messages on the input channel as
Groovy scripts. It takes a message, compiles the body to a Script,
customizes it with a GroovyObjectCustomizer, and then executes it. The
default customizer just exposes all the beans in the application context
as script context objects.</para>
</section>
</section>

4
docs/src/reference/docbook/index.xml
View File

@@ -45,6 +45,10 @@
<firstname>Gary</firstname>
<surname>Russell</surname>
</author>
<author>
<firstname>Dave</firstname>
<surname>Syer</surname>
</author>
<author>
<firstname>Josh</firstname>
<surname>Long</surname>

40
docs/src/reference/docbook/jmx.xml
View File

@@ -1,6 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="jmx"
xmlns:xlink="http://www.w3.org/1999/xlink">
<section version="5.0" xml:id="jmx" 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>JMX Support</title>
<para>Spring Integration provides Channel Adapters for receiving and
@@ -17,18 +21,17 @@
<programlisting language="xml"> &lt;jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"/&gt;
</programlisting> <tip>
The
<emphasis>notification-listening-channel-adapter</emphasis>
registers with an MBeanServer at startup, and the default bean name is "mbeanServer" which happens to be the same bean name generated when using Spring's &lt;context:mbean-server/&gt; element. If you need to use a different name be sure to include the "mbean-server" attribute.
</tip> The adapter can also accept a reference to a NotificationFilter
and a "handback" Object to provide some context that is passed back with
each Notification. Both of those attributes are optional. Extending the
above example to include those attributes as well as an explicit
MBeanServer bean name would produce the following: <programlisting
language="xml"> &lt;jmx:notification-listening-channel-adapter id="adapter"
</programlisting> <tip> The
<emphasis>notification-listening-channel-adapter</emphasis> registers with
an MBeanServer at startup, and the default bean name is "mbeanServer"
which happens to be the same bean name generated when using Spring's
&lt;context:mbean-server/&gt; element. If you need to use a different name
be sure to include the "mbean-server" attribute. </tip> The adapter can
also accept a reference to a NotificationFilter and a "handback" Object to
provide some context that is passed back with each Notification. Both of
those attributes are optional. Extending the above example to include
those attributes as well as an explicit MBeanServer bean name would
produce the following: <programlisting language="xml"> &lt;jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
mbean-server="someServer"
object-name="example.domain:name=somePublisher"
@@ -145,16 +148,17 @@
create an instance of the <classname>IntegrationMBeanExporter</classname>,
define a bean and provide a reference to an MBeanServer and a domain name
(if desired). The domain can be left out in which case the default domain
is "spring.application". <programlisting language="xml"> &lt;jmx:mbean-exporter domain="my.company.domain" mbean-server="mbeanServer"/&gt;
is "org.springframework.integration". <programlisting language="xml"> &lt;jmx:mbean-exporter domain="my.company.domain" mbean-server="mbeanServer"/&gt;
&lt;bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean"&gt;
&lt;property name="locateExistingServerIfPossible" value="true"/&gt;
&lt;/bean&gt;</programlisting></para>
<para>The MBean exporter is orthogonal to the one provided in Spring core
- it registers message channels and message handlers, but not itself (you
can expose the exporter itself using the standard
<literal>&lt;context:mbean-export/&gt;</literal> tag).</para>
- it registers message channels and message handlers, but not itself. You
can expose the exporter itself, and certain other components in Spring
Integration, using the standard
<literal>&lt;context:mbean-export/&gt;</literal> tag. </para>
</section>
<section id="jmx-control-bus">

1
docs/src/reference/docbook/system-management.xml
View File

@@ -5,6 +5,7 @@
<title>System Management</title>
<xi:include href="./message-history.xml"/>
<xi:include href="./control-bus.xml"/>
<xi:include href="./jmx.xml"/>
</chapter>

2
spring-integration-groovy/src/main/resources/org/springframework/integration/groovy/config/spring-integration-groovy-2.0.xsd
View File

@@ -51,6 +51,7 @@
<xsd:all minOccurs="0" maxOccurs="1">
<xsd:element name="poller" type="integration:innerPollerType" minOccurs="0" maxOccurs="1" />
</xsd:all>
<xsd:attributeGroup ref="integration:inputOutputChannelGroup" />
<xsd:attribute name="customizer" use="optional">
<xsd:annotation>
<xsd:documentation>
@@ -65,7 +66,6 @@
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="integration:inputOutputChannelGroup" />
</xsd:complexType>
</xsd:element>