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

Added <para/> elements for lists, tips, and notes.

Browse Source
This commit is contained in:
Mark Fisher
2008-05-22 15:51:52 +00:00
parent 94e55c7f8c
commit 88cbe186eb
2 changed files with 24 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
spring-integration-reference/src/configuration.xml
View File

@@ -176,10 +176,12 @@
</handler-endpoint>]]></programlisting>
</para>
<note>
Individual endpoint schedules only apply for "Point-to-Point" channels, since in that case only a single
subscriber needs to receive the message. On the other hand, when a Spring Integration channel is configured as
a "Publish-Subscribe" channel, then the dispatcher will drive all endpoint notifications according to its own
default schedule, and any 'schedule' element configured for those endpoints will be ignored.
<para>
Individual endpoint schedules only apply for "Point-to-Point" channels, since in that case only a single
subscriber needs to receive the message. On the other hand, when a Spring Integration channel is configured as
a "Publish-Subscribe" channel, then the dispatcher will drive all endpoint notifications according to its own
default schedule, and any 'schedule' element configured for those endpoints will be ignored.
</para>
</note>
<para>
One of the most important configuration options for endpoints is the concurrency policy. Each endpoint is
@@ -197,13 +199,16 @@
<classname>ConcurrencyPolicy</classname>), the endpoint's handler will be invoked in the caller's thread.
</para>
<tip>
The default queue capacity of 0 triggers the creation of a <classname>SynchronousQueue</classname>. In many
cases, this is preferable since the direct handoff eliminates the chance of a message handling task being
"stuck" in the queue (thread pool executors will favor adding to the queue rather than increasing the pool
size). Specifically, whenever a dispatcher for a Point-to-Point channel has more than one subscribed endpoint,
a task that is rejected due to an exhausted thread pool can be handled immediately by another endpoint whose
pool has one or more threads available. On the other hand, when a particular channel/endpoint may be expecting
bursts of activity, setting a queue capacity value might be the best way to accommodate the volume.
<para>
The default queue capacity of 0 triggers the creation of a <classname>SynchronousQueue</classname>. In many
cases, this is preferable since the direct handoff eliminates the chance of a message handling task being
"stuck" in the queue (thread pool executors will favor adding to the queue rather than increasing the pool
size). Specifically, whenever a dispatcher for a Point-to-Point channel has more than one subscribed
endpoint, a task that is rejected due to an exhausted thread pool can be handled immediately by another
endpoint whose pool has one or more threads available. On the other hand, when a particular channel/endpoint
may be expecting bursts of activity, setting a queue capacity value might be the best way to accommodate the
volume.
</para>
</tip>
</section>

16
spring-integration-reference/src/overview.xml
View File

@@ -48,28 +48,28 @@
<para>Spring Integration is motivated by the following goals:
<itemizedlist>
<listitem>
Provide a simple model for implementing complex enterprise integration solutions.
<para>Provide a simple model for implementing complex enterprise integration solutions.</para>
</listitem>
<listitem>
Facilitate asynchronous, message-driven behavior within a Spring-based application.
<para>Facilitate asynchronous, message-driven behavior within a Spring-based application.</para>
</listitem>
<listitem>
Promote intuitive, incremental adoption for existing Spring users.
<para>Promote intuitive, incremental adoption for existing Spring users.</para>
</listitem>
</itemizedlist>
</para>
<para>Spring Integration is guided by the following principles:
<itemizedlist>
<listitem>
Components should be <emphasis>loosely coupled</emphasis> for modularity and testability.
<para>Components should be <emphasis>loosely coupled</emphasis> for modularity and testability.</para>
</listitem>
<listitem>
The framework should enforce <emphasis>separation of concerns</emphasis> between business logic and
integration logic.
<para>The framework should enforce <emphasis>separation of concerns</emphasis> between business logic and
integration logic.</para>
</listitem>
<listitem>
Extension points should be abstract in nature but within well-defined boundaries to promote
<emphasis>reuse</emphasis> and <emphasis>portability</emphasis>.
<para>Extension points should be abstract in nature but within well-defined boundaries to promote
<emphasis>reuse</emphasis> and <emphasis>portability</emphasis>.</para>
</listitem>
</itemizedlist>
</para>