diff --git a/spring-integration-reference/reference/src/adapters.xml b/spring-integration-reference/reference/src/adapters.xml new file mode 100644 index 0000000000..6f5a688981 --- /dev/null +++ b/spring-integration-reference/reference/src/adapters.xml @@ -0,0 +1,15 @@ + + + Channel Adapters + +
+ Introduction + + 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 MessageChannel. Within + Spring Integration, there is a distinction between source adapters and target + adapters. + +
+ \ No newline at end of file diff --git a/spring-integration-reference/reference/src/configuration.xml b/spring-integration-reference/reference/src/configuration.xml new file mode 100644 index 0000000000..32ad71b8be --- /dev/null +++ b/spring-integration-reference/reference/src/configuration.xml @@ -0,0 +1,22 @@ + + + Configuration + +
+ Introduction + + 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 options 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 + . We expect that most users will choose one of the higher-level options, such as the + namespace-based or annotation-driven configuration. + +
+ \ No newline at end of file diff --git a/spring-integration-reference/reference/src/core-api.xml b/spring-integration-reference/reference/src/core-api.xml index c3ee8c9948..fde7de0fc7 100644 --- a/spring-integration-reference/reference/src/core-api.xml +++ b/spring-integration-reference/reference/src/core-api.xml @@ -1,6 +1,6 @@ - Spring Integration Core API + The Core API
Message @@ -149,7 +149,7 @@ public void registerHandler(String name, MessageHandler handler, Subscription su 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 DispatcherPolicy contains metadata for + handlers subscribed to that channel. The DispatcherPolicy contains metadata for configuring those dispatchers: Properties of the DispatcherPolicy @@ -282,5 +282,10 @@ public void registerHandler(String name, MessageHandler handler, Subscription su ConcurrencyPolicy getConcurrencyPolicy(); } + + 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: DefaultMessageEndpoint. + \ No newline at end of file diff --git a/spring-integration-reference/reference/src/overview.xml b/spring-integration-reference/reference/src/overview.xml index e62530fa91..d8bea7e1d3 100644 --- a/spring-integration-reference/reference/src/overview.xml +++ b/spring-integration-reference/reference/src/overview.xml @@ -75,6 +75,22 @@
Main Components + + + From the vertical 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 + horizontal 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. +
Message @@ -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 MessageHandler callback interface as described in + .
diff --git a/spring-integration-reference/reference/src/resources.xml b/spring-integration-reference/reference/src/resources.xml new file mode 100644 index 0000000000..e340567e97 --- /dev/null +++ b/spring-integration-reference/reference/src/resources.xml @@ -0,0 +1,16 @@ + + + Additional Resources + +
+ Spring Integration Home + + The definitive source of information about Spring Integration is the + Spring Integration Home at + http://www.springframework.org. 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. + +
+ + \ No newline at end of file diff --git a/spring-integration-reference/reference/src/samples.xml b/spring-integration-reference/reference/src/samples.xml new file mode 100644 index 0000000000..fa99b0d6c6 --- /dev/null +++ b/spring-integration-reference/reference/src/samples.xml @@ -0,0 +1,12 @@ + + + Spring Integration Samples + +
+ Introduction + + 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. + +
+ \ No newline at end of file diff --git a/spring-integration-reference/reference/src/spring-integration-reference.xml b/spring-integration-reference/reference/src/spring-integration-reference.xml index 4de4fe7a29..2c9b198559 100644 --- a/spring-integration-reference/reference/src/spring-integration-reference.xml +++ b/spring-integration-reference/reference/src/spring-integration-reference.xml @@ -3,6 +3,10 @@ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ + + + + ]> @@ -34,5 +38,9 @@ &overview; &core-api; + &adapters; + &configuration; + &samples; + &resources; \ No newline at end of file