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

Updated reference documentation

Browse Source
This commit is contained in:
Mark Fisher
2008-01-18 17:15:55 +00:00
parent 3a53c35f0b
commit 19dabafa89
7 changed files with 101 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
spring-integration-reference/reference/src/adapters.xml Normal file
View File

@@ -0,0 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="adapters">
<title>Channel Adapters</title>
<section id="adapters-intro">
<title>Introduction</title>
<para>
Channel Adapters are the components responsible for interacting with external systems or other components that
are external to the messaging system. As the name implies, the interaction consists of adapting the external
system or component to send to and/or receive from a <interfacename>MessageChannel</interfacename>. Within
Spring Integration, there is a distinction between <emphasis>source adapters</emphasis> and <emphasis>target
adapters</emphasis>.
</para>
</section>
</chapter>

22
spring-integration-reference/reference/src/configuration.xml Normal file
View File

@@ -0,0 +1,22 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="config">
<title>Configuration</title>
<section id="config-intro">
<title>Introduction</title>
<para>
Following the Spring philosophy, Spring Integration offers a number of configuration options. Which option you
choose depends upon your particular needs and at what level you prefer to work. As with the Spring framework in
general, it is also possible to mix and match the various techniques according to the particular problem at hand.
For example, you may choose the XSD-based namespace for the majority of configuration combined with a handful of
objects that are configured with annotations. Of course, it is also possible to always follow a single approach.
The main point is that these are <emphasis>options</emphasis> for configuration - none of which are required.
The goal is to support a user community with a wide range of needs and preferences. That said, there has also
been a concerted effort to provide consistent naming so that, for example, the XML elements defined by the XSD
schema will match the names of annotations, and the attributes of those XML elements will match the names of
annotation properties. Direct usage of the API is of course always an option and is described in detail in
<xref linkend="api"/>. We expect that most users will choose one of the higher-level options, such as the
namespace-based or annotation-driven configuration.
</para>
</section>
</chapter>

9
spring-integration-reference/reference/src/core-api.xml
View File

@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="api">
<title>Spring Integration Core API</title>
<title>The Core API</title>
<section id="api-message">
<title>Message</title>
@@ -149,7 +149,7 @@ public void registerHandler(String name, MessageHandler handler, Subscription su
</para>
<para>
The bus creates and manages dispatchers that pull messages from a channel in order to push those messages to
handlers registered on that channel. The <classname>DispatcherPolicy</classname> contains metadata for
handlers subscribed to that channel. The <classname>DispatcherPolicy</classname> contains metadata for
configuring those dispatchers:
<table id="api-messagebus-dispatcherpolicy">
<title>Properties of the DispatcherPolicy</title>
@@ -282,5 +282,10 @@ public void registerHandler(String name, MessageHandler handler, Subscription su
ConcurrencyPolicy getConcurrencyPolicy();
}</programlisting>
</para>
<para>
When using the API, it's simpler to register handlers with metadata and leave the message endpoint as an internal
responsibility of the bus. However, it is possible to create endpoints directly. Spring Integration provides a
single implementation: <classname>DefaultMessageEndpoint</classname>.
</para>
</section>
</chapter>

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

@@ -75,6 +75,22 @@
<section id="overview-components">
<title>Main Components</title>
<para>
From the <emphasis>vertical</emphasis> perspective, a layered architecture facilitates separation of concerns,
and interface-based contracts between layers promote loose coupling. Spring-based applications are typically
designed this way, and the Spring framework and portfolio provide a strong foundation for following this best
practice for the full-stack of an enterprise application. Message-driven architectures add a
<emphasis>horizontal</emphasis> perspective, yet these same goals are still relevant. Just as "layered
architecture" is an extremely generic and abstract paradigm, messaging systems typically follow the similarly
abstract "pipes-and-filters" model. The "filters" represent any component that is capable of producing and/or
consuming messages, and the "pipes" transport the messages between filters so that the components themselves
remain loosely-coupled. It is important to note that these two high-level paradigms are not mutually exclusive.
The underlying messaging infrastructure that supports the "pipes" should still be encapsulated in a layer whose
contracts are defined as interfaces. Likewise, the "filters" themselves would typically be managed within a layer
that is logically above the application's service layer, interacting with those services through interfaces much
in the same way that a web-tier would.
</para>
<section id="overview-components-message">
<title>Message</title>
<para>
@@ -99,9 +115,11 @@
A Message Endpoint represents the "filter" of a pipes-and-filters architecture. The endpoint's primary role is
to connect application code to the messaging framework and to do so in a non-invasive manner. In other words,
the application code should have no awareness of the messaging framework. This is similar to the role of a
Controller in the MVC paradigm. Just as a Controller handles HttpRequests, the endpoint handles Messages. Just
as Controllers are mapped to URL patterns, endpoints are mapped to MessageChannels. The goal is the same in both
cases: isolate application code from the infrastructure.
Controller in the MVC paradigm. Just as a Controller handles HTTP requests, the endpoint handles Messages. Just
as Controllers are mapped to URL patterns, endpoints are mapped to Message Channels. The goal is the same in
both cases: isolate application code from the infrastructure. In Spring Integration, the Message Endpoint
invokes a <interfacename>MessageHandler</interfacename> callback interface as described in
<xref linkend="api-messagehandler"/>.
</para>
</section>
<section id="overview-component-bus">

16
spring-integration-reference/reference/src/resources.xml Normal file
View File

@@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="resources">
<title>Additional Resources</title>
<section id="resources-home">
<title>Spring Integration Home</title>
<para>
The definitive source of information about Spring Integration is the
<ulink url="http://www.springframework.org/spring-integration">Spring Integration Home</ulink> at
<ulink url="http://www.springframework.org">http://www.springframework.org</ulink>. That site serves as a hub of
information and is the best place to find up-to-date announcements about the project as well as links to
articles, blogs, and new sample applications.
</para>
</section>
</chapter>

12
spring-integration-reference/reference/src/samples.xml Normal file
View File

@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="samples">
<title>Spring Integration Samples</title>
<section id="samples-intro">
<title>Introduction</title>
<para>
The Spring Integration 1.0 Milestone 1 release includes a limited number of sample applications. Several more
interesting and comprehensive samples are in the works for upcoming releases.
</para>
</section>
</chapter>

8
spring-integration-reference/reference/src/spring-integration-reference.xml
View File

@@ -3,6 +3,10 @@
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY overview SYSTEM "overview.xml">
<!ENTITY core-api SYSTEM "core-api.xml">
<!ENTITY adapters SYSTEM "adapters.xml">
<!ENTITY configuration SYSTEM "configuration.xml">
<!ENTITY samples SYSTEM "samples.xml">
<!ENTITY resources SYSTEM "resources.xml">
]>
<book>
<bookinfo>
@@ -34,5 +38,9 @@
&overview;
&core-api;
&adapters;
&configuration;
&samples;
&resources;
</book>