Category Archives: Coding practice

The Vital Guide to React.js Interviewing


Another wave of evolution in client-side application development is approaching. It involves ES6, the new version of JavaScript, universal applications, functional programming, server-side rendering and a webpack, which is like a task-runner with a jetpack.

Also, React is super hot right now. It is a concise and excellent framework to build performant components. Since we already have all that, how do you find the missing piece — the engineer who will embrace it and build state-of-the-art software for you?

React revolutionized the way we think about apps

React revolutionized the way we think about apps

React Plainly

First things first. In the context of React being marketed as only a views library, and as client-side applications consist of more than just views, React won’t be the only tool that your candidate will use. Still, it is a crucial one. Here are a few screening questions.

Q: What are higher-order components in React?

Broadly speaking, a higher-order component is a wrapper. It is a function which takes a component as its argument and returns a new one. It can be used to extend or modify the behaviour (including the rendered output) of the contained component. Such use of components that change behavior without modifying the underlying class in React is well characterized by the decorator pattern.

The higher-order components are a way to build components using composition. An example use case would be to abstract out pieces of code, which are common to multiple components:


import React, {Component, PropTypes} from 'react';

export default class Player extends Component {
  static propTypes = {
    black: PropTypes.bool,
    data: PropTypes.object,
    styles: PropTypes.object

  static defaultProps = {
    black: false,
    data: {
      src: null,
      caption: ''
    styles: {}

  render() {
    const { black, data, styles } =;
    return (
      <div className={
        'module-wrapper' +
        (styles ? ' ' + styles : '') +
        (black ? ' module-black' : '')}>
        <section className="player-wrapper video-player-wrapper">
          <video className="player" src={data.src} />
          <p className="player-caption">{data.caption}</p>

Consider this component, which holds a Player but also contains module markup. That markup could be reused for other components. Let’s abstract it, and also allow for passthrough of properties:


import React, {Component, PropTypes} from 'react';
import ModuleContainer from './ModuleContainer';

export class PlayerInline extends Component {
  static propTypes = {
    data: PropTypes.object

  static defaultProps = {
    data: {
      src: null,
      caption: ''

  render() {
    const { src, caption } =;
    return (
      <section className="player-wrapper video-player-wrapper">
        <video className="player" src={src} />
        <p className="player-caption">{caption}</p>

const Player = new ModuleContainer(Player);
export default Player;


import React, {Component, PropTypes} from 'react';

export default function ModuleContainer(Module) {
  return class extends Component {
    static propTypes = {
      black: PropTypes.bool,
      styles: PropTypes.object

    render() {
      const { black, styles } = this.props // eslint-disable-lint
      return (
        <div className={
          'module-wrapper' +
          (styles ? ' ' + styles : '') +
          (black ? ' module-black' : '')
          <Module {...this.props} />

Now we can still use the previous way of instantiating Player, no changes here. We can also use the inline player if we prefer. Then the module wrapper markup and props can be used with other modules:

<Player data={playerData} styles={moduleStyles} />

<PlayerInline data={playerData} />

Higher order components are the immediate answer to the design decision of moving away from mix-ins in React for ES6, which was done in early 2015. In fact, higher-order components make for a clearer structure, and they are easier to maintain because they are hierarchical, whereas mix-ins have a bigger chance of conflicting due to a flat structure.

To learn more, check out another example use case of higher order components, with a focus on messaging props. Also check the introduction to the preference of higher-order components over mixins, outlined by Dan Abramov, the author of Redux, and an interesting example of advanced composition using refs by Ben Nadel.

Q: Which components should rely on state, and why?

Having separation of concerns in mind, it seems wise to decouple the presentation from the logic. In the React world, everything is a component. But the components used to present data should not have to obtain that data from an API. The convention is to have presentational (dumb) components stateless, and container components that rely on the state.

That said, the convention is not strict. There is also more than one type of state in React. Despite varying opinions, utilising local state in presentational and especially interactive components does not seem to be a bad practice.

Another distinction is between component classes and stateless function components. Obviously, the latter does not have a state. Speaking of the stateless function components, it is an official recommendation to use them when possible.

Q: What is JSX? How does it work, and why would you use it?

JSX is syntactic sugar for React JavaScript, which makes it easy to write components because it has XML-like syntax. However, JSX is JavaScript and not HTML, and React transforms the JSX syntax to pure JavaScript.

It looks awkward at first sight, although many developers are used to it by now. The main reason to use it is simplicity. Defining even mildly complex structures which will eventually be rendered into HTML can be daunting and repetitive:

React.createElement('ul', { className: 'my-list' }, 
  React.createElement('li', { className: 'list-element' }, 
    React.createElement('a', { className: 'list-anchor', href: '' }, ''),
    React.createElement('span', { className: 'list-text' }, ' Welcome to the network')
  React.createElement('li', { className: 'list-element' }, 
    React.createElement('div', { className: 'list-item-content' }, 
      React.createElement(SomeCustomElement, {data: elementData})


<ul className="my-list">
  <li className="list-element">
    <a className="list-anchor" href=""></a>
    <span className="link-text"> Welcome to the network</span>
  <li className="list-element">
    <div className="list-item-content">
      <SomeCustomElement data={elementData} />

Consider more complex elements navigation components, with multiple nestings. Conciseness is one reason most frameworks have some template engine, and React has JSX.

To learn more, check influential discussion on JSX in the context of container components.

The New Approach to Front-End Development

ES6 (ECMA Script 2015), the new version of JavaScript, was released some time ago. The majority of React materials in the open-source community utilise ES6, and sometimes even ES7. The new version adds in expressiveness to JavaScript and also fixes a few problems of the language. The current standard procedure is to use Babel, which compiles ES6 to ES5. It allows us to write code in ES6, and let it execute correctly on the majority of current browsers as ES5. Therefore, it is crucial that the developer you will hire is proficient with ES6.

Q: What are the new features for functions in ES6?

There are a few, actually. The most prominent is the arrow function expression, which is a concise way of writing anonymous function expressions:

var counterArrow = counter => counter++;
// equivalent to function (counter) { return counter++; }

There is a significant difference. With arrow functions, the this object captures the value of the enclosing scope. So there is no more need to write var that = this.

Another difference is in the way arguments can be defined or passed in. ES6 brings default parameters and rest parameters. Default parameters are a very useful way to set the default value of a parameter when it is not provided in the call. The rest parameters, which have a similar syntax to the spread operator, allow processing an indefinite number of arguments passed to a function in an elegant manner.

var businessLogic = (product, price = 1, => {
  product.price = price;
  product.details = => detail);

Q: What are classes in ES6 and React?

ES6 classes provide means to create objects, and actually still rely on prototypal inheritance. They are mostly syntactical sugar, but very handy. However, they are not required for React classes.

React classes are components. They can be defined in one of three ways: using the React.createClass()method, using an ES6 class, or using a function to create stateless function components:

const Counter1 = React.createClass({
  propTypes: {
    count: PropTypes.number

  defaultProps: {
    count: 0

  render: function() {
    return <span>Count: {this.props.count}</span>;
class Counter2 extends Component {
  static propTypes = {
    count: PropTypes.number

  static defaultProps = {
    count: 0

  render() {
    return <span>Count: {this.props.count}</span>;
function Counter3(props) {
  return <span>Count: {props.count}</span>;

Counter3.propTypes = {
  count: PropTypes.number

Counter3.defaultProps = {
  count: 0

As we previously stated, stateless function components are recommended to use when possible. However, those components are not yet optimised for performance. Consider following GitHub issues in Redux and React to learn more.

Q: What are local, or inline styles, the new trend for styles in web development?

This one is pretty rad. Until now, the declarative CSS always shared a global scope. To add styles to a reusable component, the developer had to choose a namespace carefully. Another thing, sometimes it is hard to work with CSS, because some style had to be computed, and so that single style became an exception. Of course, there is calc(), but it is not always sufficient.

Local styles, sometimes also called referred to as inline styles, solve both these problems. Now it is possible to bind a stylesheet to a component know that they remain local in relation to their scope. The styles will not affect elements out of their scope. If that was not enough, the styles become readily available in JavaScript.


.alertWidget {
  font-variant: italics;
  border: 1px solid red;
  padding: 13px;

.alert {
  font-weight: 700;
  color: red;


import React, {PropTypes} from 'react';

function AlertWidget(props) {
  const styles = require('./AlertWidget.scss');
  return (



</div> ); } AlertWidget.propTypes = { alert: PropTypes.text, text: PropTypes.text }; export default AlertWidget;

It may not always be the case all styles have to be local, but it certainly is a very powerful tool. To learn more, check influential introduction to local styles on Medium and discussion on the pros and cons of inline styles on CSS-tricks

React revolutionized the way we think about apps

How Do You State

Applications which encompass more than a single component, especially larger applications, can be difficult to maintain using just local component states. It also feels like a bad practice to put anything more than controller-style logic into React. But do not worry, there are already solutions for that.

Q: What is the application state in React, and what governs the state?

The answer is simple – it is an object which represents the current set of data and other properties of the application. The application state differs from the component local state in the way it can be referred to by multiple components.

Another difference is that the application state should not be changed directly. The only place where it can be updated is a store. Stores govern application state, and also define actions which can be dispatched, such as a result of user interactions.

Most React components should not depend on application scope. It is likely the presentational components should have access to pieces of data, but then that data should be provided to them via properties. In React, the convention is to have only the container elements dispatching actions and referring to the application scope.

Q: So, what tools for governing the state in React are out there?

Handling application state in applications built with React is usually done outside of React. Facebook, who brought us React, also introduced the Flux architecture and just enough of its implementation. The Flux part of the client-side application is where front-end business logic takes place.

React is not tightly coupled with Flux. There is also more than one Flux implementation. In fact, there are many, and there are also other very popular ones which are inspired by Flux. The most popular Flux implementations are Facebook Flux, Reflux and Alt.js. There is also Redux, which is based on Flux principles and many people believe improves on Flux.

These libraries will all get the job done. However, a choice needs to be made and it is crucial for the developer to do it consciously. Some reasonable criteria for making the choice:

  • How popular is the repository? Look for GitHub stars and fork count.
  • Is the framework maintained? Check how many commits were done in the last two weeks. Also, read the author’s notes and the open and closed issue counts.
  • What is the state of the documentation? This one is particularly important, team members can be added or changed but the codebase of your software needs to be clear.
  • How well does the developer know that particular framework?

At the moment of writing this article, Redux is by far the most popular of the bunch. It was also reviewed by the authors of Flux, who agreed that it was excellent work. The documentation is excellent, and there are 30 free short video tutorial lessons by the author. The framework itself is very simple, and most aligned with functional programming paradigms.

Alt.js also has a vibrant community, is highly praised in numerous articles, and has excellent documentation. Alt.js is also a pure Flux implementation. Several other implementations were dropped in favour of the two mentioned.

Here’s an article on the different Flux implementations by Dan Abramov, the author of Redux

Q: What is the unidirectional data flow? What benefits does it bring?

The unidirectional data flow constitutes that all changes to the application state are done in the same general way. That flow follows a similar pattern in Flux implementations, as well as in Redux. The pattern starts with an action, which is dispatched and processed by the stores and has the effect of an updated state, which in turn results in updated views.

By following that pattern, applications which govern their state with Flux or Redux are predictable and normalised. Every state version is a result of calling a set of actions. That means that it is now easier to reproduce every user experience by monitoring which actions were dispatched. A useful example is this article about logging and replaying user actions with Flux on Auth0.

It is also extremely helpful when debugging. In fact, one of the most popular frameworks inspired by Flux, Redux, was created as a side effect of creating a new set of developer tools which themselves rely on Flux concepts. There is a speech to it, called “Hot Reloading with Time Travel”, by Dan Abramov.


There are many approaches to programming, and also to software engineering in general. The programming paradigms differ far beyond the style. Recently, there are many mentions of functional programming in JavaScript. There are many advantages awaiting for the developers who seek to embrace it.

Q: Explain the functional programming paradigm.

Functional programming is a paradigm, which stresses on:

  • Writing pure functions.
  • Not having a global state.
  • Not mutating data.
  • Composition with higher-order functions.

Pure functions do not produce side-effects, and also are idempotent, meaning they always return the same value when given the same arguments.

Programs which rely on functional programming have two major advantages. They are easy to understand, and also easy to test. In contrast, assigning variables to the global scope, relying on events, and mutating data makes it very easy for the application to become chaotic. From a JavaScript developer’s perspective, I would even say it is overly easy to end up with code which is difficult to understand and prone to errors.

JavaScript is not a strictly functional language. However, with functions as first-class citizens, which means that they can be assigned and passed around just like other types and are composable, it is certainly possible to embrace functional programming for JavaScript developers.

There are many recent articles that praise this style. Still, what seems to be most important are the new tools, which become very popular very quickly. The tools incorporate the key functional programming ideas in various degrees, and include Redux, recent updates to React, and also others like Bacon.js.

Q: How to incline towards functional programming in React?

Primarily, writing React code is mostly focused on writing good JavaScript code. The general way of writing functional programming in JavaScript would be to keep a consistent style of programming, focused on:

  • Writing pure functions.
  • Keeping the functions small.
  • Always returning a value.
  • Composing functions (utilising higher order functions).
  • Never mutating data.
  • Not producing side effects.

There are many tools in JavaScript which are suited for functional programming, among others: .map(), .reduce(), .filter(), .concat. There are also new ES6 features available, like native promises or the …spread operator.

Also, there are available linters, like eslint in particular, combined with linter configurations based on the Airbnb JavaScript and React style guides. There are also other tools, like immutable.js and code patterns like deepFreeze function, which help prevent the data from mutating which is particularly valuable in tests.

React version 0.14 introduced stateless function components, which are a step towards functional programming from object-oriented programming. Those components are minimal, and should be used when possible. Generally, the vast majority of components in React applications should be presentational.

Using Redux is yet another step in functional programming direction. Redux uses function calls, unlike Flux which relies on events. All Redux reducers are also pure functions. Redux never mutates the application state. Instead, the reducers always return a new state.

Q: How to test React applications?

Last but not least comes the developer’s approach to testing. Regression issues are the ultimate source of frustration. Besides allowing the developer and the client to be assured that the application is working as expected, the tests are the remedy for regression issues.

Building a continuous integration or deployment environment in which every pushed commit is automatically tested, and if successful is deployed, has become a standard these days. It is very easy to set up, with free plans on many SaaS. Codeship for example, has good integrations and a free plan. Another good example is Travis CI which delivers a more stable and mature feeling, and is free for open source projects.

There also have to be actual tests to run. Tests are usually written using some framework. Facebook provided a testing framework for React, it is called Jest, and is based on the popular Jasmine. Another industry standard and a more flexible one is Mocha, often combined with the test runner Karma.

React provides another super feature, the TestUtils. Those provide a full quiver of tools, built specifically for testing the components. They create an abstraction instead of inserting the components into an actual page, which allows to compile and test components using unit tests.

To get more insight into testing React applications, you can read on our blog. I also recommend watching the materials available at, where there are some series addressing React, and also Flux and Redux, and even a series with a focus on testing React applications.


React brings high performance to client-side apps, and aligns projects which use it in a good position. The library is widely used, and has a vibrant community. Most often, turning to React, also requires the inclusion of other tools to deliver complete apps. Sometimes, it may call for a more general technology upgrade.

Web development is known to evolve at a very fast pace. New tools gain popularity, become valuable and ready to use within months. The innovations encompass more than just the tools, and often span to the code style, application structure and also system architecture. Front-end developers are expected to build reliable software and to optimize the process. The best are open-minded, and state sound arguments with confidence. Toptal engineers are also able lead teams and projects, and introduce new technology for the benefit of the products.

This article originally appeared on Toptal

Writing Tests That Matter: Tackle The Most Complex Code First

There are a lot of discussions, articles, and blogs around the topic of code quality. People say – use Test Driven techniques! Tests are a “must have” to start any refactoring! That’s all cool, but it’s 2016 and there is a massive volume of products and code bases still in production that were created ten, fifteen, or even twenty years ago. It’s no secret that a lot of them have legacy code with low test coverage.

While I’d like to be always at the leading, or even bleeding, edge of the technology world – engaged with new cool projects and technologies – unfortunately it’s not always possible and often I have to deal with old systems. I like to say that when you develop from scratch, you act as a creator, mastering new matter. But when you’re working on legacy code, you’re more like a surgeon – you know how the system works in general, but you never know for sure whether the patient will survive your “operation”. And since it’s legacy code, there are not many up to date tests for you to rely on. This means that very frequently one of the very first steps is to cover it with tests. More precisely, not merely to provide coverage, but to develop a test coverage strategy.

Coupling and Cyclomatic Complexity: Metrics for Smarter Test Coverage

Forget 100% coverage. Test smarter by identifying classes that are more likely to break.

Basically, what I needed to determine was what parts (classes / packages) of the system we needed to cover with tests in the first place, where we needed unit tests, where integration tests would be more helpful etc. There are admittedly many ways to approach this type of analysis and the one that I’ve used may not be the best, but it’s kind of an automatic approach. Once my approach is implemented, it takes minimal time to actually do the analysis itself and, what is more important, it brings some fun into legacy code analysis.

The main idea here is to analyse two metrics – coupling (i.e., afferent coupling, or CA) and complexity (i.e. cyclomatic complexity).

The first one measures how many classes use our class, so it basically tells us how close a particular class is to the heart of the system; the more classes there are that use our class, the more important it is to cover it with tests.

On the other hand, if a class is very simple (e.g. contains only constants), then even if it’s used by many other parts of the system, it’s not nearly as important to create a test for. Here is where the second metric can help. If a class contains a lot of logic, the Cyclomatic complexity will be high.

The same logic can also be applied in reverse; i.e., even if a class is not used by many classes and represents just one particular use case, it still makes sense to cover it with tests if its internal logic is complex.

There is one caveat though: let’s say we have two classes – one with the CA 100 and complexity 2 and the other one with the CA 60 and complexity 20. Even though the sum of the metrics is higher for the first one we should definitely cover the second one first. This is because the first class is being used by a lot of other classes, but is not very complex. On the other hand, the second class is also being used by a lot of other classes but is relatively more complex than the first class.

To summarize: we need to identify classes with high CA and Cyclomatic complexity. In mathematical terms, a fitness function is needed that can be used as a rating – f(CA,Complexity) – whose values increase along with CA and Complexity.

Generally speaking, the classes with the smallest differences between the two metrics should be given the highest priority for test coverage.

Finding tools to calculate CA and Complexity for the whole code base, and provide a simple way to extract this information in CSV format, proved to be a challenge. During my search, I came across two tools that are free so it would be unfair not to mention them:

A Bit Of Math

The main problem here is that we have two criteria – CA and Cyclomatic complexity – so we need to combine them and convert into one scalar value. If we had a slightly different task – e.g., to find a class with the worst combination of our criteria – we would have a classical multi-objective optimization problem:

We would need to find a point on the so called Pareto front (red in the picture above). What is interesting about the Pareto set is that every point in the set is a solution to the optimization task. Whenever we move along the red line we need to make a compromise between our criteria – if one gets better the other one gets worse. This is called Scalarization and the final result depends on how we do it.

There are a lot of techniques that we can use here. Each has its own pros and cons. However, the most popular ones are linear scalarizing and the one based on an reference point. Linear is the easiest one. Our fitness function will look like a linear combination of CA and Complexity:

f(CA, Complexity) = A×CA + B×Complexity

where A and B are some coefficients.

The point which represents a solution to our optimization problem will lie on the line (blue in the picture below). More precisely, it will be at the intersection of the blue line and red Pareto front. Our original problem is not exactly an optimization problem. Rather, we need to create a ranking function. Let’s consider two values of our ranking function, basically two values in our Rank column:

R1 = A∗CA + B∗Complexity and R2 = A∗CA + B∗Complexity

Both of the formulas written above are equations of lines, moreover these lines are parallel. Taking more rank values into consideration we’ll get more lines and therefore more points where the Pareto line intersects with the (dotted) blue lines. These points will be classes corresponding to a particular rank value.

Unfortunately, there is an issue with this approach. For any line (Rank value), we’ll have points with very small CA and very big Complexity (and visa versa) lying on it. This immediately puts points with a big difference between metric values in the top of the list which is exactly what we wanted to avoid.

The other way to do the scalarizing is based on the reference point. Reference point is a point with the maximum values of both criteria:

(max(CA), max(Complexity))

The fitness function will be the distance between the Reference point and the data points:

f(CA,Complexity) = √((CA−CA )2 + (Complexity−Complexity)2)

We can think about this fitness function as a circle with the center at the reference point. The radius in this case is the value of the Rank. The solution to the optimization problem will be the point where the circle touches the Pareto front. The solution to the original problem will be sets of points corresponding to the different circle radii as shown in the following picture (parts of circles for different ranks are shown as dotted blue curves):

This approach deals better with extreme values but there are still two issues: First – I’d like to have more points near the reference points to better overcome the problem that we’ve faced with linear combination. Second – CA and Cyclomatic complexity are inherently different and have different values set, so we need to normalize them (e.g. so that all the values of both metrics would be from 1 to 100).

Here is a small trick that we can apply to solve the first issue – instead of looking at the CA and Cyclomatic Complexity, we can look at their inverted values. The reference point in this case will be (0,0). To solve the second issue, we can just normalize metrics using minimum value. Here is how it looks:

Inverted and normalized complexity – NormComplexity:

(1 + min(Complexity)) / (1 + Complexity)∗100

Inverted and normalized CA – NormCA:

(1 + min(CA)) / (1+CA)∗100

Note: I added 1 to make sure that there is no division by 0.

The following picture shows a plot with the inverted values:

Final Ranking

We are now coming to the last step – calculating the rank. As mentioned, I’m using the reference point method, so the only thing that we need to do is to calculate the length of the vector, normalize it, and make it ascend with the importance of a unit test creation for a class. Here is the final formula:

Rank(NormComplexity , NormCA) = 100 − √(NormComplexity2 + NormCA2) / √2

More Statistics

There is one more thought that I’d like to add, but let’s first have a look at some statistics. Here is a histogram of the Coupling metrics:

What is interesting about this picture is the number of classes with low CA (0-2). Classes with CA 0 are either not used at all or are top level services. These represent API endpoints, so it’s fine that we have a lot of them. But classes with CA 1 are the ones that are directly used by the endpoints and we have more of these classes than endpoints. What does this mean from architecture / design perspective?

In general, it means that we have a kind of script oriented approach – we script every business case separately (we can’t really reuse the code as business cases are too diverse). If that is the case, then it’s definitely a code smell and we need to do refactoring. Otherwise, it means the cohesion of our system is low, in which case we also need refactoring, but architectural refactoring this time.

Additional useful information we can get from the histogram above is that we can completely filter out classes with low coupling (CA in {0,1}) from the list of the classes eligible for coverage with unit tests. The same classes, though, are good candidates for the integration / functional tests.

You can find all the scripts and resources that I have used in this GitHub repository: ashalitkin/code-base-stats.

Does It Always Work?

Not necessarily. First of all it’s all about static analysis, not runtime. If a class is linked from many other classes it can be a sign that it’s heavily used, but it’s not always true. For example, we don’t know whether the functionality is really heavily used by end users. Second, if the design and the quality of the system is good enough, then most likely different parts / layers of it are decoupled via interfaces so static analysis of the CA will not give us a true picture. I guess it’s one of the main reasons why CA is not that popular in tools like Sonar. Fortunately, it’s totally fine for us since, if you remember, we are interested in applying this specifically to old ugly code bases.

In general, I’d say that runtime analysis would give much better results, but unfortunately it’s much more costly, time consuming, and complex, so our approach is a potentially useful and lower cost alternative.

This article was written by Andrey Shalitkin, a Toptal Java developer.

Spring Integration -Getting started tutorial

A brief update, over past years I have continued working with spring integration and in quest to share my experience I have put challenges faced by me and it’s programmatic solution in a book name spring integration essentials which is available at amazon and packtpub. , and code samples at Github -please free to connect with me for any clarification or issues.

It’s NOT a theory book, you can directly dive into using code samples (they are available on Github, so you can try experimenting with them right away)

Let’s start with our Introduction 🙂
I worked on one of the projects using spring integration. thought of sharing a quick hands on tutorial. I will cover following along with code snippet.

  1. Introduction
    • What problem does Spring Integration solves –Enterprise Application Integration
    • A brief overview of Spring Integration
    • What are alternatives
    • Why Spring Integration over other
  2. Getting Started
    • Main components (Message, Message Channel, Message End Point)
    • Message Endpoints (Transformer, Filter, Activator, Adapter)
  3. Scaling UP
    • How to implement multiple executors
  4. Infrastructural Support
    • JMX
  5. IDE -STS
  6. Basic hands On
    • A Example with REST based API and transformer
  • Introduction
  • Enterprise application have heterogeneous interfaces and applications, for example accounting, payroll, reporting, maintenance etc. which have been developed over a period of time with using different platforms (e.g. financial in COBOL, payroll in J2ee, maintenance in c/c++ etc. )

    Intercommunication between these modules have always been a challenge. How a c/c++ application talk with Java app, how CORBA and SOAP can be made seamless, how a File system and DB interaction be made possible -these all have been tried in multiple different ways. Enterprise Application Integration is an effort to address these kind of scenario.

      Major EAI approaches are

      • File Transfer: System interacts via files. For example an external provider can put files on a FTP
        server which contains input for other application.

      • Shared Database: Two systems interact via same database. For example in a SaaS environment,
        catalogue of product can be stored at same DB location which different vendors can use.
      • Remote Procedure Call: We see this everyday –Avatars are SOAP, REST most talked and “Hot”
      • Messaging: Two words- JMS architecture

    enterprise pattern defines major patterns for enterprise integration. Spring Integration is one of the implementation of the enterprise patterns.
    When we talk of heterogeneous communication, additional challenges comes in terms of synchronous and asynchronous communication mode. One of endpoints may not be available at time of interaction, or may be less responsive -this necessitates a need for an orchestrator which can retry, communication back, audit and do other stuff in role of a mediator. Here enters Enterprise Service Bus (ESB). ESB acts as mediator between these heterogeneous interfaces.

  • A brief introduction of Spring Integration:
  • Quoted from official Spring Integration
    “Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns. It enables lightweight messaging within Spring-based applications and supports integration with external systems via declarative adapters. Those adapters provide a higher-level of abstraction over Spring’s support for remoting, messaging, and scheduling. Spring Integration’s primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.”

  • Alternatives:
  • As discussed earlier, there have been numerous attempts to address the EAI. It’s difficult to list all –but two examples are.
    Mule ESB : It is a container, application need to be dropped in to leverage its support.
    Service Mix: It is another ESB, having a heavy footprint and trying to address lot of issues with lot of modules (OSGI Bundles)!
    Description of any of the above is beyond scope.

  • Why Spring Integration:
    • Does not need a container or separate process space, can be invoked in existing program
    • Very light footprint, it is just a JAR which can be dropped with WAR or standalone systems
    • spring framework module, goes easily with existing spring and java project
  • Getting started
    • An ESB must support following components

      • Routing: It should be able to route messages across different endpoints based on configured rules or conditional logic.
      • Messaging: Convert message to and from different incompatible format to a normalized format.
      • Mediation: Making communication possible between heterogeneous interfaces.
      • Complex Event Processing (CEP): Capability to listen for events and trigger it as well.
      • Invocation: It should be able to orchestrate service interaction and invocation.

    It should also support logging, auditing, authentication (security), and management, etc, above and beyond the services listed above.

  • What are the major components supported by Spring:
  • (Definitions and images are standard and taken from Spring Integration Reference. The purpose is to provide quick reference)
    In Spring Integration, a Message is a generic wrapper for any Java object combined with metadata used
    by the framework while handling that object. It consists of a payload and headers. The payload can be of any type and the headers hold commonly required information such as id, timestamp, correlation id, and return address.

    Message Channel
    A Message Channel represents the “pipe” of a pipes-and-filters architecture. Producers send Messages to a channel, and consumers receive Messages from a channel. The Message Channel therefore decouples the messaging components, and also provides a convenient point for interception and monitoring of Messages.
    A Message Channel may follow either Point-to-Point or Publish/Subscribe semantics. With a Point-to-Point channel, at most one consumer can receive each Message sent to the channel. Publish/Subscribe channels, on the other hand, will attempt to broadcast each Message to all of its subscribers.

    Should channels buffer the messages?
    Pollable Channels are capable of buffering Messages within a queue. The advantage of buffering is that it allows for throttling the inbound Messages and thereby prevents overloading a consumer.
    On the other hand, a consumer connected to a Subscribable Channel is simply Message-driven.

  • Message Endpoints
    A Message Endpoint represents the “filter” of a pipes-and-filters architecture. As mentioned above, the endpoint’s primary role is to connect application code to the messaging framework and to do so in a noninvasive manner. In other words, the application code should ideally have no awareness of the Message objects or the Message Channels. This is similar to the role of a Controller in the MVC paradigm. Just as a Controller handles HTTP requests, the Message Endpoint handles Messages. Just as Controllers are mapped to URL patterns, Message Endpoints are mapped to Message Channels.
    The goal is the same in both cases: isolate application code from the infrastructure.

    Typical endpoints:

    • Transformer
    • A Message Transformer is responsible for converting a Message’s content or structure and returning the modified Message. Probably the most common type of transformer is one that converts the payload of the Message from one format to another (e.g. from XML Document to java.lang.String).

      Typical use case : Convert XML and File based payloads to Domain objects.

    • Filter
    • A Message Filter determines whether a Message should be passed to an output channel at all. This simply requires a boolean test method that may check for a particular payload content type, a property value, the presence of a header, etc.

      Typical use case: Drop all message which does not meet the minimum criteria

    • Router
    • A Message Router is responsible for deciding what channel or channels should receive the Message next (if any).

      Typical use case: If a XML is parsed successfully, it is passed on to next channel for further processing else is routed on a retry channel.

    • Splitter
    • A Splitter is another type of Message Endpoint whose responsibility is to accept a Message from its input channel, split that Message into multiple Messages, and then send each of those to its output channel.

      Typical use case: After fetching list of files from a remote FTP server, list of files is put on a splitter, which then puts it on a gateway –one by one, so that each file can be fetched.

    • Aggregator
    • Basically a mirror-image of the Splitter, the Aggregator is a type of Message Endpoint that receives multiple Messages and combines them into a single Message. Spring Integration provides a completion strategy as well as configurable settings for timeout, whether to send partial results upon timeout, and the discard channel.

      Typical use case: PDF and related images are available from FTP server. Aggregator is used to wait for both (PDF and associated JPEG) of them to be available –correlation strategy decides if both are available or not. Once available it is passed on for further processing.

    • Service Activator
    • A Service Activator is a generic endpoint for connecting a service instance to the messaging system. The input Message Channel must be configured, and if the service method to be invoked is capable of returning a value, an output Message Channel may also be provided. The output channel is optional, since each message may also provide its own ‘Return Address’ header. This same rule applies for all consumer endpoints channel specified in the Message’s “return address” if available.

      Typical use case: All business processing done in service activator, for example persistence.

    • Channel Adapter
    • A Channel Adapter is an endpoint that connects a Message Channel to some other system or transport. Channel Adapters may be either inbound or outbound.
      An inbound “Channel Adapter” endpoint connects a source system to a MessageChannel

      An outbound “Channel Adapter” endpoint connects a MessageChannel to a target system.

    • Threading support:
    • Multiple instances of service activator can be configured to work on same channel. This will help in avoiding build up of channel. For optimal performance of threading, polling interval and max messages per poll should be set appropriately. Lets say, requirement is to process ~7k files in an hour–thread pool executor have been implemented to process items parallel y. A sample code:

    • Infrastructural Support
      • JMX
      • Sing line of configuration exposes all of the channels on standard JMX console.
      • Sample code snippet:
        • ‹context:mbean-server/›
        • ‹int-jmx:mbean-export id=”integrationMbeanExporter”/›

    • STS Visual Editor –
    • It can depict the Integration flow diagrammatically.

      • An in bound channel adapter post dummy message on trigger channel
      • HTTP outbound gateway listens on trigger channel and initiates a HTTP request as soon as channel gets some data
      • HTTP outbound gateway writes its response to HTTP response channel.
      • Transformer is connected to HTTP response channel, which transforms the message and passes on to a persister channel
      • Service Activator takes input from persister channel and performs business logic.
    • Basic hands On -A small code example
    • It is a code example as per above flow. Download the code hosted at Github. It is a maven project -download it and import it as a maven project. Details of class files:

      • : main class, this boots up the application.
      • : Post dummy message on the trigger channel
      • :Transformer, which transforms the message –it just adds some custom string. It can be more meaning full as transforming to domain object.
      • : Service activator –here business logic as persistence can go. For e.g. have just logged it in a log file.
      • spring-sample-app\src\main\resources\META-INF\application-context-root.xml : All the configurations for adapter, transformer and service activator here. Quite self explanatory
      • spring-sample-app\src\main\resources\ : Log file settings.

      A brief update, over past years I have continued working with spring integration and in quest to share my experience I have put challenges faced by me and it’s programmatic solution in a book name spring integration essentials which is available at amazon and packtpub. , and code samples at Github -please free to connect with me for any clarification or issues.

      It’s NOT a theory book, you can directly dive into using code samples (they are available on Github, so you can try experimenting with them right away)

Never use data which can be localized as part of business logic

I was reviewing a code and came across something as

public doSomeStuff(String shortMonthName){
 //do something}

In this code client passes a month name based on which some logic is executed.

At first it might look as whats wrong? hmm ..what if in future multilingual support is introduced -the month names will be localized and the client supplies equivalant of “jan” in a language other than english –it will simply fail.This is a very simplistic use case, but hope I make my point

Never use data which can be localized as part of a business logic