Enterprise Integration with Spring 1 - WordPress.com · Enterprise Integration with Spring 1.x...
Transcript of Enterprise Integration with Spring 1 - WordPress.com · Enterprise Integration with Spring 1.x...
EnterpriseIntegrationwithSpring1.x
Acknoledgement
This document was created by Horatiu Dan following the points in the Enterprise Integration with Spring
1.x Certification Study Guide (Completed: January, 2011). The information in the document is based on
the resources mentioned at the bottom and on his own understanding.
Remoting
General
1. The concepts involved with Spring Remoting on both server- and client-side
Remoting – synchronous remote procedure call (RPC), all methods are blocking in RMI
Server-side:
- Exporters that bind to registry or expose an endpoint declaratively, allow exposing a POJO
- RmiServiceExporter knows: the service interface, service name, backing bean
(implementation of service to expose)
Cliet-side:
- Proxy FactoryBean generates proxies that communicate with the server-side endpoints
- Translate remote exceptions to a runtime hierarchy
- RmiProxyFactoryBean knows: the service interface, url
Client (JVM 2)
2 - Lookup
3 - Transfer RMI Registry
1 - Expose
Server (JVM 1)
2. The benefits of Spring Remoting over traditional remoting technologies
- Hide plumbing code (decouples business logic from remoting infrastructure)
- Configure and expose services declaratively, without code changes
- Support multiple protocols in a consistent way
3. The remoting protocols supported by Spring
RMI – port: 1099 + “random”, io.Serializable
Hessian – ports: 80 + 443, XML binary, more efficient
Burlap – ports: 80 + 443, XML plain, more readable
HttpInvoker – ports: 80 + 443, io.Serializable
JAX-RPC – replaced by JAX-WS from Java EE 5/ Java 6
Stateless Session Beans (EJB)
RMI-based Spring Remoting
1. How Spring Remoting-based RMI is less invasive than plain RMI
Server:
- Transparently and declaratively exposes a POJO service using a configuration-based
approach (RmiServiceExporter)
- Expose a single service for multiple protocols
- Service interfaces does not extend java.rmi.Remote
- The binding in the RMI registry is done automatically
Client:
- Invoke remote methods from existing code
- Translates the remote checked exceptions to runtime ones (RemoteAccessException)
- Dynamically generates the proxy (RmiProxyFactoryBean)
- Simpler to use than traditional RMI stub
Spring HTTP Invoker
1. How client and server interact with each other
Method invocation request is converted to HTTP POST.
Method result is returned as a HTTP response.
Method parameters are marshalled using Java Serialization.
Server: HttpInvokerServiceExporter
- Declare the bean to expose - transferService
- Declare the invoker bean
<bean name=”/transfer” class=”…HttpInvokerServiceExporter”>
<property name=”serviceInterface” value=”foo.TransferService” />
<property name=”service” ref=”transferService” />
</bean>
- Expose it using either DispatcherServlet or HttpRequestHandlerServlet (when the former is
not available, declare the servlet directly in the root application context)
Client: HttpInvokerProxy
- Define a factory bean to generate the proxy
<bean id=”transferService” class=”…HttpInvokerProxyFactoryBean”>
<property name=”serviceInterface” value=”foo.TransferService” />
<property name=”serviceUrl” value=”http://foo:8080/sv/transfer”/>
</bean>
Web Services
General
1. How do Web Services compare to Remoting and Messaging
- Loosely coupled - Document-Oriented contract between consumers and providers is defined
- Interoperable with other Java platforms as they are based on XML
Spring Web Services
1. The approach to building web services that Spring-WS supports
Spring uses contract-first approach – the XSD/WSDL is written first:
- Create a simple message - XML
- Infer a contract using 3rd
party tools – generate XSD from XML
- Adjust and tweak the resulting contract / message – impose restrictions, patterns
Dynamically generates the WSDL from XSD.
2. The Object-to-XML frameworks supported by Spring-OXM (Note that Spring-OXM is now a
module in Spring 3.0, not in Spring-WS, but for what you need to know that doesn't matter)
Techniques for handling SOAP requests:
- Low level parsing of XML: DOM, SAX, StAX
- Marshalling: JAXB 1, JAXB 2, Castor, XMLBeans, JiBX, XStream
- XPath argument binding
Marshaller can be declared manually:
<oxm:jaxb2-marshaller id="marshaller" contextPath="rewards.ws.types" />
No explicit marshaller bean definition is needed:
<ws:annotation-driven /> - registers all infrastructure beans needed for annotation-based
endpoints, including the JAXB2 (un)marshalling.
3. The strategies supported to map requests to endpoints
Server-side:
- Entry point of the SOAP request is MessageDispatcherServlet
- Based on the EndpointMapping determines the endpoint to invoke
- The Endpoint invocation is done indirectly using EndpointAdapter, which also handles the
unmarshalling
@Endpoint annotated classes are component-scanned.
Mapping techniques:
- Message Payload (@PayloadRoot)
- SOAP Action Header (@SoapAction)
- WS-Addressing - based on SOAP Action, ReplyTo and To headers
- XPath
4. Of these strategies, how does @PayloadRoot work exactly?
@Endpoint (class) – marks the class as a web services endpoint bean
@PayloadRoot (method) – maps the root tag of the SOAP request body to the method
localPart – XSD/WSDL root element of the request payload
namespace – namespace URL
@RequestPayload - the method parameter - mapped to the payload of the request message
@ResponsePayload - the return value - used as the payload of the response message. If the return value
is void (no annotation), no response is sent.
@PayloadRoot(localPart="helloRequest", namespace="http://myapp.com/hello")
public @ResponsePayload Hello sayHello (@RequestPayload Person onePerson)
5. The functionality offered by the WebServiceTemplate
- Used on the client-side
- Simplifies the web service access
- Works directly with the XML payload:
o Body of a SOAP message
o With POX
- Can use mashallers/unmarshallers
- Can use interceptors (e.g. for validation)
- Provides methods for sending / receiving WS messages
- Provides callbacks for low level access – e.g access to SOAP message header
- Handles errors using SoapFaultMessageResolver that encapsulates errors in a
SoapFaultClientException
- Allows multiple protocols: HTTP, Mail, JMS, XMPP
- Send Source objects as request
- Receive response messages as Result
Web Services Security
1. The underlying WS-Security implementations supported by Spring-WS
WS-Security in terms of authentication, signing and encryption is implemented using interceptors:
- XwsSecurityInterceptor – for Sun’s XWSS, requires Sun (Oracle) JVM and Saaj
It requires a security policy file to operate.
- Wss4jSecurityInterceptor - for integrating Apache WSS4J, supports non-Sun JVMs and
Axiom.
Standards:
o SOAP Message Security 1.0 (OASIS)
o Username Token profile 1.0
o X.509 Token Profile 1.0
2. How key stores are supported by Spring-WS for use with WS-Security
A key store is used within a security interceptor inside a KeyStoreCallbackHandler.
KeyStoreCallbackHandler has three properties:
- keyStore – for private keys, uses WS-Security to sign and decrypt
- trustStore – for determining trust relations
- symmetricStore – symmetric key (secret key), client and server store the same key
The exact stores used by the handler depend on the cryptographic operations that are to be performed.
privateKeyPassword property is used to unlock the private key(s) contained in the key store.
If symmetricStore is not set, it will default to the keyStore.
If neither keyStore nor trustStore is set, it will default to using the Java standard mechanism to load or
create it.
A key store stores three types of elements: private keys, symmetric keys (or secret key), certificates
(X509).
RESTful services with Spring-MVC
General
1. The main REST principles
REST - architectural style, based on HTTP.
HTTP is used as the application protocol and not just as a transport protocol as for SOAP.
- Identifiable resources - expressed by their URIs
- Uniform interface
o HTTP used as interface
o Methods:
GET – retrieves a representation of a resource (e.g. /resource/123)
� Safe
� Idempotent
� Cacheable – servers return an ETag header that is sent by clients on
subsequent request as If-None-Match header – if not modified (304), empty
body is returned
� Response – 200 OK
HEAD – similar to GET but without response body
� Safe
� Idempotent
� Not-cacheable
� Response – 200 OK
PUT – updates a resource or creates it with a known destination URI (e.g.
/resource/123)
� Not-safe
� Idempotent
� Not-cacheable
� Response – 204 No Content
POST – creates a new resource, response Location header used to indicate the URI
of the created resource
� Not-safe
� Not-idempotent
� Not-cacheable
� Response – 201 Created
DELETE – deletes a resource (e.g. /resource/123)
� Not-safe
� Idempotent
� Not-cacheable
� Response – 204 No Content
- Stateless conversation
o Server maintains no state, client maintains state through links
o Very scalable architecture – opposite to RMI
- Resource representation
o Multiple representations possible (text/html, image/png):
� Request specifies it via Accept HTTP header
� Response specifies it via Content-Type HTTP header
- Hypermedia
o Resources contain links provided by the server which allow client state transitions
Security:
- Sent on every request
- HTTP Basic (user and pass concatenated by browser, encoded, not encrypted) or
- Digest (user and pass concatenated by browser, digested, not encrypted)
- SSL is needed
- XML-Encryption and XML-DSIG may be used for message level security.
Not designed for long running transactions – compensating transactions (designed and implemented by
the developer).
REST support in Spring-MVC
1. Spring-MVC is an alternative to JAX-RS, not an implementation
Two options to use Spring for REST:
JAX-RS:
- The standard for implementing RESTful Web Services (JSR-311).
- Jersey is the reference implementation; RESTEasy, CXF, Restlet support Spring as well
- Focuses more on app-to-app communication than using browsers as REST clients
- Annotations: @Path, @GET, @POST, @Produces, @PathParam
Spring-MVC:
- Uses Spring MVC annotations: @RequestMapping, @PathVariable
- URI template support: /resource/{id}
- Content negotiation
- Declarative status codes @ResponseStatus(HttpStatus.CREATED)
- Message converters:
<mvc:annotation-driven/> configures by default several converters
(e.g. Jaxb2RootElementHttpMessageConverter)
- RestTemplate for client-side
- Supports browsers as REST clients
2. The @RequestMapping annotation, including URI template support
@RequestMapping maps an HTTP request on a class (Controller) and method.
Parameters:
- value – designates the URI that may contain a template with {}. @PathVariable on a method
parameter extracts the value, converts it and sets the method parameter with it
- method – the HTTP request method used (RequestMethod.GET, POST, PUT, DELETE, HEAD,
OPTIONS, TRACE)
- params – parameters of the HTTP request to be mapped
- headers – HTTP headers of the mapped request
- consumes, produces – consumable and producible media types
@PathVariable:
- parameter is not necessary if the parameter name is the same as the pattern
- when a @PathVariable annotation is used on a Map<String, String> argument, the map is
populated with all URI template variables
- regular expressions can be used
@RequestMapping("/spring-web/{version:\\d\\.\\d\\.\\d}{ext:\\.[a-z]+}")
public void handle(@PathVariable String version, @PathVariable String ext)
3. The @RequestBody and @ResponseBody annotations
@RequestBody:
- used for PUTs and POSTs
- converts the HTTP request body to the annotated method parameter
- a converter is chosen based on the Content-Type of the request
@ResponseBody:
- used for methods that return values – e.g. GETs
- converts the annotated return value of a method into the HTTP response body
- a converter is chosen based on the Accept header of the request
4. The functionality offered by the RestTemplate
- Client-side class for consuming RESTful web services
- Supports URI templates and HttpMessageConverters
- Provides direct access to the body of the request / response
- Uses HttpEntity for modelling a HTTP request / response and access both body and headers
- Can be instantiated directly or as a bean
- Can be configured to rely on Apache Commons Http Client
Methods by methods:
GET: getForObject(String url, Class<T> responseType, String… urlVars) getForEntity(String url, Class<T> responseType, String… urlVars)
POST: postForLocation(String url, Object request, String… urlVars) postForObject(String url, Object request,Class<T> responseType, String… urlVars) postForEntity(String url, Object request,Class<T> responseType, String… urlVars)
PUT: put(String url, Object request, String… urlVars)
DELETE: delete(String url, String… urlVars)
HEAD: headForHeaders(String url, String… urlVars)
OPTIONS: optionsForAllow(String url, String… urlVars)
- First part indicates what HTTP method to invoke, the second part indicates what is returned.
e.g. postForLocation() – do a POST, converting the given request Object into a HTTP request that returns
the response HTTP Location header where the newly created object may be found
- Each method takes a URL parameter as the first argument which can support URI templates.
e.g. Item[] result = template.getForObject(“http://service/resources/{id}/items”, Item[].class, “123”);
- Objects passed and returned from the methods getForObject(), postForLocation(), put() are
converted to HTTP requests and from HTTP responses by HttpMessageConverters that are
registered by default.
JMS with Spring
General
1. Where can Spring-JMS applications obtain their JMS resources from
In general:
ConnectionFactory – in an enterprise application, it is a managed resource - bound to JNDI
Connection – obtained from a ConnectionFactory
Session – created from a Connection, it is a unit-of-work, provides transactional capability, it creates
message producers, message consumers, messages of different types
In Spring:
ConnectionFactory – can be standalone (receives brokerUrl), or retrieved via JNDI.
Destination – can be standalone (receives queue name) or retrieved via JNDI.
The framework instantiates the JMS resources.
2. The functionality offered by Spring's JMS message listener container, including the use of a
MessageListenerAdapter through the 'method' attribute in the <jms:listener/> element
Spring message listener containers are an alternative to requiring an EJB container:
- Used for asynchronous message reception from JMS message queues and drive
MessageListener that is injected into it
- Provides two implementations:
o SimpleMessageListenerContainer – fewest requirements on the JMS provider, uses
plain JMS client API, fixed number of sessions, does not allow dynamic adaptation to
runtime demands, cannot participate in externally managed transactions.
o DefaultMessageListenerContainer – used in most cases, adds transactional
capabilities, adds dynamic adaptation to runtime demands, scales better, can
participate in externally managed transactions, each received message is registered
with an XA transaction when configured with a JtaTransactionManager.
JMS namespace simplifies the declaration of a container containing a list of JMS listeners. Also, it
allows the configuration of concurrency, task execution strategy, container type, transaction
manager
<jms:listener-container connection-fatory="jmsCF">
<jms:listener destination="queue.order" ref="orderListener"/>
<jms:listener destination="queue.conf" ref="confListener"/>
</jms:listener-container>
Listener bean can:
- implement MessageListener (implement onMessage()) or SessionAwareMessageListener
(allows tweaking with JMS Session)
- be used in any bean directly via MessageListenerAdapter
o through the use of “method” attribute of a <jms:listener/> allows specifying a POJO
as a MDO
<jms:listener ref=”orderService”
method=”order”
destination=”queue.orders”
response-destination=”queue.conf” />
public class OrderService {
public OrderConfirmation order(Order o) {}
}
The result of a MD POJO is sent to the destination (if one exists) defined in the JMS
Reply-To property of the original Message.
3. The functionality offered by the JmsTemplate
- Reduces boilerplate code
- Manages resources transparently
- Handles exceptions properly (converts checked JMSException to the corresponding runtime)
- Provides convenience methods and callbacks
- Delegates to collaborators to handle extra work:
MessageConverter:
- converts between objects and messages (String to text, byte[] to Byte, Map to Map,
Serializable to Object )
- default is SimpleMessageConverter
- custom implementation
o implement the two methods: Message toMessage(Object object, Session session)
Object fromMessage(Message message)
o suitable for XML marshalling into TextMessage – JAXB, Castor, XMLBeans, XStream
DestinationResolver
- resolves destination names at runtime
- default is DynamicDestinationResolver
- custom implementation – implement the method: Destination resolveDestinationName(Session session,
String destinationName, Boolean pubSubDomain) throws JMSException
- By using a CachingConnectionFactory, it allows reusing of the JMS resources which will
otherwise be closed; usually used when a pool is not available from the vendor
- Created by providing a connectionFactory and optionally messageConverter,
destinationResolver, defaultDestination, defaultDestinationName
- Sending:
o one-line methods for sending simple messages – convertAndSend
o callback-accepting methods when more control is needed:
void convertAndSend(Object message, MessagePostProcessor mpp) void send(MessageCreator creator) <–- createMessage(Session session)
Object execute(ProducerCallback<T> action) Object execute(SessionCallback<T> action)
- Receiving:
o Synchronous, blocking the caller thread with timeout
receive()
receive(Destination destination)
receive(String destinationName)
receiveAndConvert(destination) - MessageConverter is leveraged
Transactions
Local JMS Transactions with Spring
1. How to enable local JMS transactions with Spring's message listener container
Spring’s message listener container allows using either local JMS transactions (transacted session) or
one of the acknowledge modes. Local transaction:
- acknowledge=”transacted”
- transaction-manager=”localTransactionManager”
Mutually exclusive acknowledge attribute <jms:listener-container acknowledge = "…">:
- transacted
o the transaction applies only to the JMS resource
o all JMS operations must use the same session
o the transaction starts when the message is received
The following indicate when a message is successfully delivered outside a transaction:
- auto
o after every successful receive() or onMessage()
o successful reception marks the message delivered and removes it from the queue
o slower than the other modes
o results in message loss if processing after reception fails
- client
o client takes the responsibility for the acknowledgement – Message.acknowledge()
o multiple messages can be acknowledged at once
o if the client fails before acknowledging the message, it is redelivered -> duplicates
- dups_ok
o messages are lazily acknowledged
o if the JMS provider fails before acknowledgement -> duplicates
o has better performance than auto
2. If and if so, how is a local JMS transaction made available to the JmsTemplate
Used in a listener with acknowledge=“transacted” mode, JmsTemplate uses the same JMS session and is
therefore involved in the same transaction initiated by the listener.
sessionTransacted and sessionAcknowledgeMode attributes can be specified for local transacted
session or acknowledgement mode.
Read and write operations use the same Session when transaction is in progress – internally obtained
through ConnectionFactoryUtils.doGetTransactionalSession().
3. How does Spring attempt to synchronize a local JMS transaction and a local database
Transaction
Best-effort strategy is used:
- Database commit before JMS commit – never loses messages, but causes duplicates if JMS
commit fails
- Put commits close together to reduce failure possibility
Only XA distributed transactions guarantees once-and-only-once delivery.
4. The functionality offered by the JmsTransactionManager
It performs local resource transactions, binding a JMS Connection / Session pair from the specified
ConnectionFactory to the thread.
JmsTemplate automatically detects an attached thread and participates automatically with Session.
It allows a CachingConnectionFactory that uses a single JMS Connection for all access (performance
gain); all Sessions belong to the same Connection.
JTA and Two-phase commit transactions with Spring
1. What guarantees does JTA provide that local transaction do not provide
- Ensures ACID principles when multiple resources are involved
- Enable multiple resources to participate in a single transaction – the commit is coordinated
- Message duplication is not an issue any more – once and only once delivery is assured
2. How to switch from local to global JTA transactions
- Through reconfiguration in XML (no code changes) – configure JtaTransactionManager
and add it to the container configuration (instead of the PlatformTransactionManager)
- JtaTransactionManager does not provide JTA support, it only integrates local
transactions with external (application server) JTA transaction manager
- If application server specific subclass is used, it allows using features that are not in the JTA
spec (transaction suspension)
- JTA is required when the transactions are handled using an EJB container (even for local
transactions), it is optional when using Spring
- TX Resources:
o JDBC and JMS – using XA-aware types is enough
o Other code (e.g. Hibernate) may require additional information to find the JTA TX
- Databases and synch JMS – no changes (@Transactional, <tx:annotation-driven />)
- Asynch JMS – pass JTA transaction manager to listener container <jms:listener-container transaction-manager=”transactionManager”>
3. Where can you obtain a JTA transaction manager from
In a J2EE application server:
- ask for the look-up of the JTA TX manager and use server-specific subclass if present: <tx:jta-transaction-manager />
- each XA transactional resource (dataSource for DB access, connectionFactory for JMS
access) can be retrieved by a JNDI look-up.
Stand-alone applications:
- define the JtaTransactionManager plain bean and define the properties using a third party
(e.g. Atomikos, JOTM, Jboss Transactions)
<bean id="transactionManager" class="org.sf.tr.jta.JtaTransactionManager"
p:transactionManager-ref="3rd party”
p:userTransaction-ref=”3rd party />
Batching processing with Spring Batch
General
1. Main concepts (Job, Step, Job Instance, Job Execution, Step Execution etc.)
Job Repository – is the keeper of all knowledge and metadata for each Job
Job Launcher:
- interface to start a Job with a set of Job Parameters
Job:
- defines what needs to be done, encapsulates the entire batch process
- has one or more Steps, one after another
Step:
- has one or more Tasklets
- has one or more Step Executions
- can be concurrent
Job Instance:
- is consisted of Job + Job Parameters, the same Job with different Job Parameters
- it is unique because of the Job Parameters associated with the Job
- when run a new Job Execution is created
- can be restarted and the subsequent run creates another Job Execution
Job Execution:
- every run / restart of a Job Instance
- has as many Step Executions as many Steps the Job has
- provides the ExitStatus
Step Execution:
- physical attempt to execute a Step
- for every Step in a Job there is a Step Execution in the Job Execution
2. The interfaces typically used to implement a chunk-oriented step
ItemReader<T> - T read()
- reads a chunk from the source (invoked multiple times – chunk size)
- null return value indicates no more items are left
ItemProcessor<T, S> - S process(T)
- optional
- processes the chunk (invoked multiple times – chunk size)
- represents the business processing of an element
- null return value indicates the item should not be written out
ItemWriter<S> - write(List<? extends S> list)
- writes the chunk to destination (invoked once)
3. How and where state can be stored
JobRepository interface provides a persistence mechanism that includes CRUD operations for Jobs’
executions and Steps’ executions.
Spring Batch provides two mechanisms:
- In memory, into a volatile Map
- In a relational database
Readers and Writers are stateful and may persist data using the ExecutionContext (key/value pairs
persisted and controlled by the framework).
Job Execution Context commits at the end of each Step.
Step Execution Context commits at the end of each Chunk.
StepExecutionListener, @BeforeStep, ItemStream
4. What are job parameters and how are they used
- represent the runtime parameters of a batch job
- together with the job provide uniqueness to the Job Instance (can be used for identification
or even as reference data of JobInstance during the run)
- can be String, Date, Long, Double
5. What is a FieldSetMapper and what is it used for
FieldSetMapper is an interface used to map the data obtained from a FieldsSet into a domain object:
T mapFieldSet (FieldSet fs)
The FieldSet provides access to the fields from a line by index, name or type.
Two types of FieldsSetMapper:
- PassThroughFieldSetMapper – returns the FieldSet unchanged
- BeanWrapperFieldSetMapper – uses introspection based on the names of the bean
properties and the name of the fields in the FieldSet
Spring Integration
General
1. Main concepts (Messages, Channels, Endpoint types)
Message
- wrapper for any Java object combined with metadata used by SI
- payload contains the Java object, Map<String, Object> of headers represents the metadata
- is immutable
- has a unique identifier
Message Channel
- connects the Endpoints
- component through which the messages are moved
- effectively decouples the producer from the consumer – loose coupling
- in memory by default (no persistence), but with the ability to persist messages (JMS or JDBC
Message Store)
- may be:
o point-to-point - a message is received only once by a single consumer
o publish-subscribe – a message is received by all consumers
Message Endpoint
- abstraction layer between the application code and the messaging framework
- handles the producing and consuming of messages, interfacing with application code or
external services or applications
Types of Endpoints:
- Service Activator
o Interface between the message channel and a service instance, containing the
application code for business logic
o Invoke any bean method (if not specified) for incoming messages on input-channel
o Specify method attribute or @ServiceActivator if multiple methods exist
o void and null returning methods are supported – no response message sent,
similar to <outbound-channel-adapter>
o If no output channel is specified, the message is sent back on the input channel
o requires-reply=”true” to throw an exception
<service-activator input-channel="input" output-channel="output"
ref="someService" method="someMethod"/>
- Channel Adapter
o One way integration - connects the message channel to another system or transport
o May be:
� inbound – messages enter the application (soap, file � message)
� outbound – messages leave the application (message � mail, jms)
- Gateway
o 2 way integration
o Hides the messaging API provided by SI – acts as a proxy
o May be:
� inbound – bring messages into the application and wait for response
� outbound – invoke external system and bring the response back into the
application
o Gateway interface methods may return:
� a result – it is sent to the reply channel
� void – nothing is sent to the reply channel – acts as an inbound adapter
� Future<Result> - turns into async, non-blocking
<int:gateway id="cafeService" service-interface="org.ICafeService"
default-request-channel="request" default-reply-channel="reply" />
o The default-reply-channel attribute is optional. SI creates a disposable Temporary
Channel if the former is not provided.
- Filter
o Decides whether to pass or drop a message
o By default, silently drop the message
o If throw-exception-on-rejection=“true”, throw exception on rejection
o If discard-channel=”invalidItems”, pass message to discard channel on
rejection (2 way router or switch)
<filter input-channel="input" output-channel="output" ref="filterBean"
method="filter" />
- Router
o Decides which channel to send a message to, based on payload or headers
<router input-channel="input" ref="routerBean" method="route" />
- Transformer
o Service activator with specific intent:
� Payload format conversion
� Payload or header enriching
<transformer input-channel="input" output-channel="output"
ref="transformerBean" method="transform" />
- Splitter
o splits a message into multiple messages
o splitting strategy should be provided in a dedicated method
o it sets in header of the messages CORRELATION_ID (MESSAGE_ID of original),
SEQUENCE_SIZE, SEQUENCE_NUMBER
<splitter input-channel="input" output-channel="output" ref="splitterBean"
method="split" />
- Aggregator
o recomposes a message from multiple messages
o aggregating strategy should be provided in a dedicated method
o holds messages until a set of correlated messages is ready for release
o Correlation:
� CORRELATION_ID header is used by default
� correlation-strategy, correlation-method, correlation-expression may be set
o Release:
� SEQUENCE_SIZE header is used by default
� release-strategy, release-strategy-method, release-strategy-expression may
be set
<aggregator input-channel="input" output-channel="output"
ref="aggregatorBean"
correlation-strategy="correlationBean"
release-strategy-expression="#this.size () gt 10" />
2. How to programmatically create a new Message
- MessageBuilder.withPayload("test").setHeader("foo", "bar").build();
- new GenericMessage(payload, headers)
3. Using chains and bridges
- Chain
o Ease the configuration when working with many endpoints – unmarshal, filter
redundant messages, invoke service
o All endpoints are wired with DirectChannels in the declared order
o All endpoints except for the last must return output
o If the last endpoint returns output, either output-channel or reply-channel
must be set
o Endpoints can filter messages by returning null
<chain input-channel="input" output-channel="output">
<filter ref = "someSelector" />
<service-activator ref="someService" method="someMethod" />
</chain>
- Bridge
o Used to connect to channels or two channel adapters
o Can have a poller for throttling messages
<bridge input-channel="input" output-channel="output">
<poller max-messages-per-poll="5" fixed-rate="200"/>
</bridge>
Synchronous vs. asynchronous message passing
1. The different channel types and how each of them should be used
- Point-to-point
o Only one receiver that receives the message from the sender
o May be:
� DirectChannel – send blocking, synchronous reception in the sender’s
thread, ability to have multiple subscribers in failover mode or load
balancer
� ExecutorChannel – send non-blocking, asynchronous reception in a single
thread
� QueueChannle – send non-blocking, asynchronous reception in one or more
threads based on a polling mechanism
• RendezvousChannel – zero-capacity
• PriorityChannel – header priprity
� NullChannel
- Publish-subscribe
o One or many receivers receive the same message. The message is marked as
received and removed from the channel when all receivers have consumed the
message.
o Synchronous – sequential calls in the sender thread
o Asynchronous –parallel calls, using a TaskExecutor
2. The corresponding effects on things like transactions and security
The type of channel has significant implications for applications, including transactional boundaries.
Synchronous:
- DirectChannel and PublishSubscribe Channel with no TaskExecutor
- Sending thread invokes receiver(s) directly
- Treated as method calls:
o Transactional contexts and security (ThreadLocal)
o Exceptions returned to the caller
o Low overhead
o Not scalable
<channel id=”direct” />
<publish-subscribe-channel id=”pubsub” />
Asynchronous:
- All other channel types different from above
- Receivers get the messages in different threads
- Transactions and security contexts are lost if thread boundary is broken
- Exceptions are not propagated to the caller
<channel id=”direct”>
<queue capacity=”10” />
</channel>
<publish-subscribe-channel id=”pubsub” task-executor=”taskExecutor” />
Transactional context is preserved as long as it is ensured that the flow continues on the same
thread.
Transactional channels may be used where a thread boundary is being broken by using:
- Queue-backed Channel that delegates to a transactional MessageStore
- JMS-backed Channel
3. The need for active polling and how to configure that
Channels are passive so polling is required to enable the consumption of the messages from the
PollableChannels.
By default, a single thread does the polling, but a thread pool may be configured.
Endpoints use default poller when needed:
<poller default="true" task-executor="pool" fixed-delay="200" />
but can override it with their own:
<service-activator ...>
<poller task executor="otherpool" fixed-rate="500" />
</service-activator>
Pollers can be declared transactional so that the message handling flow is atomic. Pre-conditions:
- Flow is single threaded
- The transaction includes the call to receive() method of PollableChannel
<service-activator ...>
<poller fixed-rate="500">
<transactional />
</ poller>
</service-activator>
Advanced mechanisms
1. Point-to-point Dispatch
- Point-to-point SubscribableChannel ensures single handler per message, but still have
multiple subscribers
- By default, SI uses a round-robin load balancer with fail-over to rotate over subscribers (call
the next when an exception is thrown) – handlers can have order set, otherwise the order of
subscribing is used
- failover = “false” � exception propagates back to the caller
- load-balancer = “none” � subscribers are always called in the same order
- Asynchronous dispatching :
o ExecutorChannel instead of DirectChannel
o Sending does not block
o Subscribers still called from a single thread, other than the sender’s one
References
- Spring Framework Reference Documentation, version 3.2.13.RELEASE -
http://docs.spring.io/spring/docs/3.2.13.RELEASE/spring-framework-reference/htmlsingle/
- Spring Web Services Reference Documentation, version 2.2.0.RELEASE -
http://docs.spring.io/spring-ws/docs/2.2.0.RELEASE/reference/htmlsingle/
- Spring Batch Reference Documentation, version 3.0.3.RELEASE -
http://docs.spring.io/spring-batch/trunk/reference/html/index.html
- Spring Integration Reference Manual, version 3.0.6.RELEASE - http://docs.spring.io/spring-
integration/docs/3.0.6.RELEASE/reference/html/
- Lubos Krnac’s resources and study-notes -
http://java.dzone.com/announcements/enterprise-integration-spring
- Java et Moi resources and study-notes - http://javaetmoi.com/2012/09/certified-spring-
enterprise-integration-specialist-study-notes/