13.5.13

Channel Channel Channel!!

DirectChannel

First of all, DirectChannel is not Pollable Channel. Since it is not Pollable Channel, it is not based on BlockingQueue. I was wrong about that before.

DirectChannel is a Subscribable Channel but with Point-to-point Semantics. It would be easy to understand from the implementation's point of view.

private boolean doDispatch(Message<?> message) {
boolean success = false;
Iterator<MessageHandler> handlerIterator = this.getHandlerIterator(message);
if (!handlerIterator.hasNext()) {
throw new MessageDispatchingException(message, "Dispatcher has no subscribers");
}
List<RuntimeException> exceptions = new ArrayList<RuntimeException>();
while (success == false && handlerIterator.hasNext()) {
MessageHandler handler = handlerIterator.next();
try {
handler.handleMessage(message);
success = true; // we have a winner.
}
catch (Exception e) {
RuntimeException runtimeException = (e instanceof RuntimeException)
? (RuntimeException) e
: new MessageDeliveryException(message,
"Dispatcher failed to deliver Message.", e);
if (e instanceof MessagingException &&
((MessagingException) e).getFailedMessage() == null) {
((MessagingException) e).setFailedMessage(message);
}
exceptions.add(runtimeException);
this.handleExceptions(exceptions, message, !handlerIterator.hasNext());
}
}
return success;
}

DirectChannel picks up the next available Handler and calls its handleMessage() method to send out the message. And that's it.
  • It's point-to-point.
    • It only call one handler successfully.
  • And it won't queue!
    • When the message arrives and the handler is not there, it will throw an exception. 

11.5.13

Half-duplex Mode

Slow network card: what is half duplex mode? | TuxRadar Linux
Change NIC settings betwee Full / Half duplex
Going from full to half duplex on cable, any real speed difference on Net? - AnandTech Forums

In full duplex operation, you have, in essence, 10Mb/s guaranteed bandwidth up and down. When you go to full duplex, you move back to "regular" ethernet, which is a collision-based system. In a half duplex network, it's a first-come-first-serve operation. Your computer transmits when it sees the network is clear. It is very possible (and, in fact, very very likely under high traffic conditions) that another computer will have ALSO started transmitting at the same time you did. Both your signals go across the wire and interfere with each other, effectively cancelling out both transmissions. This is called a collision. When your computer sees a collision it stops transmitting and pauses for a random amount of time before trying to re-transmit.

What is Half Duplex and Full Duplex Ethernet Modes? | Technology Updates

Ethernet IEEE 802.3 standard defines the half duplex; Cisco describes, it uses a digital signal on a wire pair flowing in both tracks on the wire. Half Duplex always employs the Carrier Sense Multiple Access with Collision Domain (CSMA/CD), so that it can retransmit the transmission if collision occurs. Hub always works in half duplex mode. Half duplex Ethernet is not efficient because it has the limit up to 10BaseT, as Cisco describes 10BaseT is not more than 3 to 4Mbps.

The Difference Between Half and Full Duplex Explained

10.5.13

Output-channel of Service Activator


public class SimpleServiceActivatorWithOutput {

@ServiceActivator
public String sayHello(String name) {
return "Hello to " + name;
}
}


<int:channel id="output">
<int:queue/>
</int:channel>

<int:channel id="input"/>

<int:service-activator id="activator" ref="handler" input-channel="input" output-channel="output" />


@Test
public void test() {
input.send(MessageBuilder.withPayload("Jeff").build());
Message<?> r = output.receive();
System.out.println(r.getPayload());
}

If I replace SimpleServiceActivatorWithOutput with SimpleDelayedHandler:


public class SimpleDelayedHandler {

@ServiceActivator
public Object justDelay(Object obj) throws Exception {
int wait = new Random().nextInt(5);
System.out.println("Delays in thread " + Thread.currentThread().getId() + " for " + wait + " secs.");
TimeUnit.SECONDS.sleep(wait);
System.out.println("Ends Delaying in thread " + Thread.currentThread().getId());
return null;
}


I can't get things out of output-channel. But if I change "return null" to "return """, then everything works fine.




9.5.13

Understanding Service Activator

From EIP

  • An application has a service that it would like to make available to other application.
Now I understand that this is the context. I am sorry I didn't realize this was part of the Pattern Language (Pattern Language) when I was trying to understand Messaging Gateway.
  • How can an application design a service to be invoked both via various messaging technologies and via non-messaging techniques?
This is the System of Forces part. We need to handle messaging technologies and non-messaging technologies. In this way, we need the decoupled solution, right? Talking about decoupling, I would think about Messaging Gateway. However, Messaging Gateway would have a Messaging System on one side while a non-Messaging System on the other. Service Activator doesn't expect this restriction. It just can't tell what would be there on each side, I think.

The problem here is about service invocation. We need to expose the interface to other application. That includes:
  • Access point. Like the function name, or alike.
  • The parameters.
  • Design a Service Activator that connects the messages on the channel to the service being accessed.
Here comes the solution: a guy named Service Activator sitting on the way the messages will come. When the expected message comes by, the Service Activator just invokes the target service.

Does it still supposed to have messaging system on one side? It sounds like an opposite of Messaging Gateway, isn't it?

What about the parameters? What about the return messages if there is any? Since it just wants to invoke a service, doesn't it imply Asynchronous?
  • A Service Activator can be one-way (request only) or two-way (Request-Reply). 
  • The service can be as simple a method call - synchronous and non-remote - perhaps part of a Service Layer [EAA]. 
  • The activator can be hard-coded to always invoke the same service, or can use reflection to invoke the service indicated by the message. 
  • The activator handles all of the messaging details and invokes the service like any other client, such that the service doesn't even know it's being invoked through messaging.
This is a very good summary of what characteristics a Service Activator has. From the very last characteristics, it confirms my guess that Service Activator works to handle messaging system request and translates it into a service out of the messaging system.

The Original Service Activator


Service Activator was originally named here. 

Problem 

You want to invoke services asynchronously.

Forces

  • You want to invoke business services, POJOs, or EJB components in a asynchronous manner.
  • You want to integrate publish/subscribe and point-to-point messaging to enable asynchronous processing services.
  • You want to perform a business task that is logically composed of several business tasks.

The Half-Sync/Half-Async Pattern in POSA2


  • EIP's Service Activator pattern is related to the Half-Sync/Half-Async pattern, which separates service processing into synchronous and asynchronous layers.
  • The Half-Sync/Half-Async architectural pattern decouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing.
  • It is hard to develop applications and higher-level system services using asynchrony mechanisms, .... For example, asynchrony can cause subtle timing problems and race conditions when an interrupt preempts a running computation unexpectedly.
  • Blocking I/O, in turn, enables developers to maintain state information and execution history implicitly in the run-time stacks of their threads, rather than in separate data structures that must be managed explicitly by developers.
  • Within the context of an operating system, however, synchronous and asynchronous processing is not wholly independently.
  • A key challenge in the development of ... was the structuring of asynchronous and synchronous processing, to enhance both programming simplicity and system performance.
    • Developers of synchronous application programs must be shields from the complex details of asynchronous programming.
    • The overall performance of the system must not be degraded by using inefficient synchronous processing mechanisms ...
All descriptions above are very natural. The only thing left to us is the solution.
  • Decompose the services in the system into two layers: synchronous and asynchronous, and add a queuing layer between them to mediate the communication between services ...
Really? Before I go further, I would like to recall things that I've done with JBoss Netty. Netty provides a totally event-driven programming model, which is naturally asynchronous. To alleviate the burden of my developers, I encapsulated those Event-Driven API into a set of synchronous API. Did I create a queuing layer in between? No, I didn't. 

I looked into the code again. Oh, yeah, I didn't make everything works synchronously. The major part of the system still relies on Netty's pipeline solution, which is still Event-Driven, or asynchronous. I almost forget about those headache I had.

So, if I had had done those half-sync/half-async things, should I have create a queuing layer in between? And how? I need to think.

  • If services residing in separate synchronous and asynchronous layers must communicate or synchronize their processing, allow them to pass messages to each other via a queuing layer.
To be honest, I am lost here. First of all, I think I didn't really design such a system before. For the Netty usage, I did create a data transferring implementation and made it synchronous. What I did was implementing a data sender and a data receiver using Netty's Event-Driven API and then expose these two as a library for my developers. Nothing more. And I don't know why I need more. Yes, this is too simple, right.

I needed to implement a list of commands sending and receiving between the client and server. I didn't make it synchronous because it was not too difficult to just use Netty's API. I built my own layers for the protocol and encapsulated them though. But I still exposed a callback interface for event handler. So it is still Event-Driven.

Oh, wait. They always related synchrony with long-duration, while asynchrony with short-living.

  • Services in the synchronous layer run in separate threads or processes that can block while performing operations.
  • Services in the asynchronous layer cannot block while performing operations without unduly degrating the performance of other services.
I think this could be a very good example for everyone:
  • Many restaurants use a variant of the Half-Sync/Half-Async pattern. For example, restaurants often employ a host or hostess who is responsible for greeting patrons and keeping track of the order in which they will be seated if the restaurant is busy and it is necessary to queue them waiting for an available table. The host or hostess is 'shared' by all the patrons and thus cannot spend much time with any given party. After patrons are seated at a table, a waiter or waitress is dedicated to service that table.
Oh, yeah! That makes a lot of sense. But how Service Activator pattern is related to Half-Sync/Half-Async Architectural Pattern?

How Service Activator Pattern is Related to Half-Sync/Half-Async Architectural Pattern?

Apparently this is from Core J2EE Patterns.

I could understand that Service Activator separates the Synchronous Layer and the Asynchronous Layer, although this is not necessary to be true. But which is the queuing layer? The Messaging System? So that Service Activator encapsulates the service within the hosting application and works as an Asynchronous Layer. It returns the result and put it into the Messaging System for the Client to poll and use in the Synchronous manner? I don't see another way around, because I would believe Asynchronous layer is always the lower layer:
  • The asynchronous service layer performs lower-level processing services, which typically emanate from one or more external event sources.
However, in Half-sync/Hals-Async Architecture, the Asynchronous services are supposed to be short-lived, aren't they?
  • Services in the asynchronous layer cannot block while performing operations without unduly degrading the performance of the other services.

Service Activator in Spring Integration

  • The Service Activator is the endpoint type for connecting any Spring-managed Object to an input channel so that it may play the role of a service.
I really like this description, and I really hate it also.

I like it because it is clear and matches the original definition in EIP very well. We could adapt the context in EIP to something like this here:
  • I have a Spring-managed Object and want to use it as a service for another application.
I really hate it, because service is a very ambiguous concept. You can have whatever things as a service. And you can do whatever you want in a service. As long as it could be configured as a Spring-managed Object, which is essentially a Spring IoC bean, and which is basically everything in Spring, you could use Service Activator pattern.

And this is why Service Activator is usually abused. 

I need to admit that Service Activator could be a good one to start with when you can't find a matched candidate. The start point. However, we need to evolve it into something after you find out more. Service Activator, as the name suggest, is the Activator. And as the name implies, it should connect heterogeneous systems, like the Messaging Gateway. If the service it would activate will just add some headers into the message, we should not use Service Activator.

8.5.13

Verifying Multi-threading Feature of Spring Integration Message Endpoints

I wanted to verify that Spring Integration would handle message in a concurrent manner. So I built this sample project.

demo-multithreading.xml


<beans ...>
<bean id="taskExec" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="10" />
</bean>

<int:gateway id="gateway" service-interface="sdemo.SimpleGateway"/>

<bean id="service" class="demo.SimpleDelayedHandler"/>

<int:service-activator input-channel="channel-in" ref="service"/>

</beans>

SimpleGateway.java


public interface SimpleGateway {
@Gateway(requestChannel = "channel-in")
public Message<String> sayHello(Message<String> helloMsg);
}

SimpleDelayedHandler.java

public class SimpleDelayedHandler {

@ServiceActivator
public void justDelay(Object obj) throws Exception {
System.out.println("Delays in thread " + Thread.currentThread().getId());
TimeUnit.SECONDS.sleep(new Random().nextInt(20));
System.out.println("Ends Delaying in thread " + Thread.currentThread().getId());
}
}


Test.java

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:demo-multithreading.xml" } )
public class Test {

@Autowired SimpleGateway gateway;
@Autowired TaskExecutor taskExec;

@Test
public void test() throws Exception {
Runnable r = new Runnable() {

@Override
public void run() {
System.out.println("Saying hello from thread : " + Thread.currentThread().getId());
gateway.sayHello(MessageBuilder.withPayload("").build());
}
};

for(int k=0; k<10; ++k) {
taskExec.execute(r);
}

TimeUnit.MINUTES.sleep(1);
}
}

Output:


Saying hello from thread : 11
Saying hello from thread : 12
Saying hello from thread : 13
Saying hello from thread : 14
Saying hello from thread : 16
Saying hello from thread : 18
Saying hello from thread : 20
Saying hello from thread : 17
Saying hello from thread : 15
Saying hello from thread : 19
Delays in thread 17
Delays in thread 15
Delays in thread 20
Delays in thread 14
Delays in thread 16
Delays in thread 12
Delays in thread 13
Delays in thread 11
Delays in thread 18
Delays in thread 19
Ends Delaying in thread 12
Ends Delaying in thread 11
Ends Delaying in thread 19
Ends Delaying in thread 14
Ends Delaying in thread 16
Ends Delaying in thread 13
Ends Delaying in thread 20
Ends Delaying in thread 18
Ends Delaying in thread 17
Ends Delaying in thread 15




Why and How with Message Handler Chain in Spring Integration?

5.6 Message Handler Chain <int:chain/> is not a pattern in EIP. It is a convenient usage in Spring Integration to make the configuration simpler.

The MessageHandlerChain is an implementation of MessageHandler that can be configured as a single Message Endpoint while actually delegating to a chain of other handlers, such as Filters, Transformers, Splitters, and so on. This can lead to a much simpler configuration when several handlers need to be connected in a fixed, linear progression. For example, it is fairly common to provide a Transformer before other components. Similarly, when providing a Filter before some other component in a chain, you are essentially creating a Selective Consumer. In either case, the chain only requires a single input-channel and a single output-channel eliminating the need to define channels for each individual component.

This is a good one to explain Message Handler Chain with an example.

java - Spring integration Message handler chain usage? - Stack Overflow

Understand Spring Integration's Gateway

Why am I interested in Gateway?


When I was learning the Claim-check pattern using Spring Integration on the above article, I was lost at Spring Integration's Gateway.

It seemed that Spring Integration Gateway was much more than I would have expected to be: I sent out a message via the Gateway, and received a very final message through out the whole procedure.

Is that what Messaging Gateway supposed to be? Or is this just some trick by Spring Integration?

What is Messaging Gateway in EIP?

  • An application accesses another system via Messaging.

From this description, it sounds like that a Messaging Gateway is an application. It doesn't seem right here with Spring Integration. But maybe it was right at the time EIP was developed.

  • How do you encapsulate access to the messaging system from the rest of the application.
So, this is a question for the reader, me here. Encapsulation means we don't want to expose the rest of the system to the underlying Messaging implementation. That makes sense to a Gateway.
  • Use a Messaging Gateway, a class that wraps messaging-specific method calls and exposes domain-specific methods to the application.
Ok, I know this is the answer for the above question. In a word, Messaging Gateway is a class for Messaging system encapsulation.
  • The Messaging Gateway encapsulates messaging-specific code (e.g., the code required to send or receive a message) and separates it from the rest of the application code. This way, only the Messaging Gateway code knows about the messaging systems; the rest of the application code does not. 
  • The Messaging Gateway exposes a business function to the rest of the application so that instead of requiring the application to set properties like Message.MessageReadPropertyFilter.AppSpecific, a Messaging Gateway exposes methods such as GetCreditScore that accept strongly typed parameters just like any other method. 
  • A Message Gateway is a messing-specific version of the more general Gateway pattern.
Still, no more than the literal meaning of "Gateway".

Let's take a look at the combination of Request-Reply pattern and Messaging Gateway pattern:
  • Many Messaging Gateways send a message to another component and expect a reply message (see Request-Reply [154]). Such a Messaging Gateway can be implemented in two different ways:
    • Blocking (Synchronous) Messaging Gateway.
    • Event-Driven (Asynchronous) Messaging Gateway
In the Claim-Check example, the Messaging Gateway works as a blocking Messaging Gateway.

With all these information, I think what Spring Integration implements about Messaging Gateway fits the definition in EIP very well. But I still need to look closer into Spring Integration's implementation to understand more about its configurations.

@Gateway and <int:gateway/> in Spring Integration

There are many Gateway Things in Spring Integration, such as JDBC Outbound Gateways, JMS Inbound and Outbound Gateways, Web Service Inbound and Outbound Gateways, etc. What I am really interested in this moment is the @Gateway annotation, and <int:gateway/> namespace, which is defined as Messaging Gateways (7. Messaging Endpoints), while previously named Inbound Messaging Gateways (16. Inbound Messaging Gateways). 

I don't have time to find out the change history. But Messaging Gateways makes more sense to me than Inbound Messaging Gateways, mostly because I have problem to tell the directions, I guess.

default-request-channel and request-channel

According to the above reading with EIP, Spring Integration's Messaging Gateways are Request-Reply Messaging Gateways. In that case, I could easily understand the request-channel and reply-channel, which are part of its XML Namespace Support or @Gateway annotation.

However, things are tricky with request-channel. Literally, the request-channel is the channel that the Messaging Endpoint, which is Messaging Gateway here, receives requests with. However, with Messaging Gateway, the interface, will immediately delegate those request to the next hop, which is the first component on the other side, the Messaging System in this case.

public interface ClaimCheckGateway {
public static final String CLAIM_CHECK_ID = "ClaimCheckID";
@Gateway(requestChannel = "claim-check-in-channel")
public Message<String> send(Message<String> message);
}

<int:gateway id="claimCheckGateway" service-interface="simple.demo.springintegration.demo.chapter5.ClaimCheckGateway"/>
<int:chain input-channel="claim-check-in-channel" output-channel="processing-channel">
<int:claim-check-in message-store="simpleMessageStore"/>
<int:header-enricher>
<int:header 
name="#{T(simple.demo.springintegration.demo.chapter5.ClaimCheckGateway).CLAIM_CHECK_ID}"
expression="payload"/>
</int:header-enricher>
</int:chain>

From the above example, the requestChannel in ClaimCheckGateway is exactly the same channel for the first <int:chain/> component. It confused me in the first place, because I would have expected the input-channel of <int:chain/> was some output-channel from the previous component.

So as the reply-channel.

In the Claim-check example, no reply-channel was assigned to the Gateway, neither to the last component, which was the last <int:chain/> with "claim-check-out-channel" as its input-channel. Here is the explanation:

Typically you don't have to specify the default-reply-channel, since a Gateway will auto-create a temporary, anonymous reply channel, where it will listen for the reply. 

A Gateway will create a temporary point-to-point reply channel which is anonymous and is added to the Message Headers with the name replyChannel. When providing an explicit default-reply-channel (reply-channel with remote adapter gateways), you have the option to point to a publish-subscribe channel, which is so named because you can add more than one subscriber to it. Internally Spring Integration will create a Bridge between the temporary replyChannel and the explicitly defined default-reply-channel.

Now I think I begin to understand how Spring Integration's Gateway works. But I still want to take a look at how these things are implemented.

Implementation of Messaging Gateway in Spring Integration

The XML Namespace Parser



@Override
protected String getBeanClassName(Element element) {
return IntegrationNamespaceUtils.BASE_PACKAGE + ".gateway.GatewayProxyFactoryBean";
}

There are other important information for this XML namespace, but I am good with this at this moment.

GatewayProxyFactoryBean was mentioned a couple of time in Spring Integration's documentation.

Same as other FactoryBeans, here is the entry point I would take a look at:


public Object getObject() throws Exception {
if (this.serviceProxy == null) {
this.onInit();
Assert.notNull(this.serviceProxy, "failed to initialize proxy");
}
return this.serviceProxy;
}


And in turn:


@Override
protected void onInit() {
synchronized (this.initializationMonitor) {
if (this.initialized) {
return;
}
BeanFactory beanFactory = this.getBeanFactory();
if (this.channelResolver == null && beanFactory != null) {
this.channelResolver = new BeanFactoryChannelResolver(beanFactory);
}
Class<?> proxyInterface = this.determineServiceInterface();
Method[] methods = ReflectionUtils.getAllDeclaredMethods(proxyInterface);
for (Method method : methods) {
MethodInvocationGateway gateway = this.createGatewayForMethod(method);
this.gatewayMap.put(method, gateway);
}
this.serviceProxy = new ProxyFactory(proxyInterface, this).getProxy(this.beanClassLoader);
this.start();
this.initialized = true;
}
}

In method createGatewayForMethod(...):


  MethodInvocationGateway gateway = new MethodInvocationGateway(messageMapper);
gateway.setErrorChannel(this.errorChannel);
if (this.getTaskScheduler() != null) {
gateway.setTaskScheduler(this.getTaskScheduler());
}
gateway.setBeanName(this.getComponentName());
gateway.setRequestChannel(requestChannel);
gateway.setReplyChannel(replyChannel);
if (requestTimeout == null) {
gateway.setRequestTimeout(-1);
}
else {
gateway.setRequestTimeout(requestTimeout);
}
if (replyTimeout == null) {
gateway.setReplyTimeout(-1);
}
else {
gateway.setReplyTimeout(replyTimeout);
}
if (this.getBeanFactory() != null) {
gateway.setBeanFactory(this.getBeanFactory());
}
if (this.shouldTrack) {
gateway.setShouldTrack(this.shouldTrack);
}
gateway.afterPropertiesSet();
return gateway;

The hierarchy of Messaging Gateway implementation


And here is the implementation of send() method:

protected void send(Object object) {
this.initializeIfNecessary();
Assert.notNull(object, "request must not be null");
Assert.state(this.requestChannel != null,
"send is not supported, because no request channel has been configured");
try {
this.messagingTemplate.convertAndSend(this.requestChannel, object, this.historyWritingPostProcessor);
}
catch (Exception e) {
if (this.errorChannel != null) {
this.messagingTemplate.send(this.errorChannel, new ErrorMessage(e));
}
else {
this.rethrow(e, "failed to send message");
}
}
}

This matches the idea that the requestChannel is delegated directly to the following messaging component.

The doSendAndReceive() method is more important. But it is too complex to list here.