Blogroll

From Agile to Serverless

If you prefer, read the same post on Medium

Looking back. And forth.

The microservices architecture was born as a technological answer for the iterative Agile development methodology. At the early days of microservices, many companies were doing a form of Agile (XP, Scrum, Kanban, or a broken mixture of these) during development, but the existing software architectures didn't allow an incremental way of design and deployment. As a result, features were developed in fortnight iterations but deployed every six to twelve months iteration. Microservices came as a panacea in the right time, promising to address all these challenges. Architects and developers strangled the monoliths into tens of services which enabled them to touch and change different parts of the system without breaking the rest (in theory).

Microservices on its own put light into the existing challenges of distributed systems and created new ones as well. Creating tens of new services didn't mean they are ready to deploy into production and use. The process of releasing and handing them over to Ops teams had to be improved. While some fell for the extreme of "You Build It, You Run It", others joined the DevOps movement. DevOps meant, better CI/CD pipelines, better interaction between Devs and Ops and everything it takes. But a practice without the enabling tools wasn't a leap, and burning large VMs per service didn't last for a very long. That led to containers with the Docker format which took over the IT industry overnight. Containers came as a technical solution to the pain of microservices architecture and DevOps practice. With containers, applications could be packaged and run in a format that the Devs and Ops would both understand and use. Even at the very early days, it was clear that managing tens or hundreds of containers will require automation, and Kubernetes came from the heavens and swept all the competition with a swing.

Now, we do Agile development and use microservices architectures. We have one-click build and deployment pipelines with a unified application format. We practice DevOps and manage hundreds of microservices at scale, do blue-green and canary releases with Kubernetes. This was supposed to be the time of long-lasting technological peace where we can focus on the business problems and solve them. But it was not.

From Agile to Serverless and Beyond

With Kubernetes, Devs can develop and Ops can deploy in a self-service manner. But there are still only one or two company-wide Kubernetes clusters that occasionally run out of resources. The cluster is now the center of the universe. And it is even more critical than the monolith was before as it runs the build server, and the git server, and the maven repository, the website, MongoDB, and a few other things. So a promise for a serverless platform came from the clouds. It came even before the containers reached into production. With serverless, every service would have its own cluster, a cluster where resources are limited only by the limit of the credit cards. It is a platform to which you tightly couple, and bet the existence of your company for the price of going faster. So it started all over again.

How Blockchain will Influence Open Source

This post was originally published on Opensource.com under CC BY-SA 4.0. If you prefer, read the same post on Medium.

Interactions between users and developers enabled by blockchain technology can create self-sustaining, decentralized open source.

What Satoshi Nakamoto started as Bitcoin a decade ago has found a lot of followers and turned into a movement for decentralisation. For some, blockchain technology is a religion and will have the same impact on humanity as the Internet had. For others, it is another hype and a technology suitable for Ponzi schemes only. While blockchain is still evolving and trying to find its place, one thing is for sure: it is a disruptive technology that will fundamentally transform certain industries. And my bet is, open source will be one of them.

The Open Source Model

Open source is a collaborative software development and distribution model that allows people with common interests to gather and produce something that no individual can create on their own. It allows the creation of value that is bigger than the sum of its parts. It is enabled by distributed collaboration tools (IRC, email, git, wiki, issue trackers, etc), distributed and protected by an open source licensing model and often governed by software foundations (such as Apache Software Foundation (ASF), Cloud Native Computing Foundation (CNCF), etc.).

One interesting aspect of the open source model is the lack of financial incentives in its core. There are some who believe open source work should remain detached from money and remain a free and voluntary activity driven by intrinsic motivators only (such as "common purpose" and "for the greater good”). And there are others who believe open source work should be rewarded directly or indirectly through extrinsic motivators (such as financial incentive). While the idea of open source projects prospering only through voluntary contributions is a very romantic one, in reality the majority of the open source contributions are done through paid development. Yes, we have a lot of voluntary contributions, but that is on a temporary basis from contributors that come and go, or for exceptionally popular projects while they are at their peak. Creating and sustaining open source projects that are useful for the enterprises, requires developing, documenting, testing, bug fixing for prolonged periods even when the software is no longer no longer shiny and exciting. It is a boring activity that can be best motivated through financial incentives.

Commercial Open Source

Software foundations such as ASF accept and survive on donations and other income streams suchs as sponsorships, conference fees, etc. But those funds are primarily used to run the foundations, to ensure there is a legal protection for the projects, to ensure there are enough servers to run builds, issue trackers, mailing lists, etc. 
In a similar manner, CNCF has member fees (and similar other income streams as well) used to run the foundation and provide resources for the projects. Nowadays, most software is not build on laptops, it is run and tested on hundreds of machines on the cloud, and that requires money. Creating marketing campaigns, brand designs, distributing stickers, etc. all takes money and some foundations can assist with that as well. At its core, foundations implement the right processes for interacting with users, developers, and control mechanisms for distribution of the available financial resources to the open source projects for the common good. 

If users of the open source projects can donate money and the foundations can distribute it in a fair way, what is missing then? What is missing is a direct, transparent, trusted, decentralized, automated bidirectional link for transfer of value between the open source producers and the open source consumer. Currently, the link is either:

  • Unidirectional: a developer (BTW, I'm saying a developer, but think of it as any role that is involved in the production, maintenance and distribution of software) can use their brain juice and devote time to do a contribution and share that value with all open source users. But there is no reverse link.
  • or Indirect: if there is a bug that affects a specific user/company, the options are:
  • To have in-house developers to fix the bug and do a pull request. That is ideal, but not always possible to hire in-house developers knowledgeable about hundreds of open source projects used daily.
  • To hire a freelancer specialising around that specific open source project and pay for the services. Ideally, the freelancer is also a committer for the open source project and can directly change the project code quickly. Otherwise, the fix might not make it to the project ever.
  • Or to approach a company providing services around the open source project. Such companies typically employ open source committers to influence and gain credibility in the community and offer products, expertise and professional services, etc.
And the last one has been a successful model for sustaining many open source projects. Whether that is through services (training, consulting, workshops), support, packaging, open core, SaaS, there are companies employing hundreds of staff to work on the open source for full time. There is a long list of companies that have managed to build a successful open source business model over the years and the list is growing steadily. 

The companies backing open source projects have a very important role to play in the ecosystem. They are the catalyst between the open source projects and the users. The ones that add real value are not only packaging software nicely, but do much more. They can identify user needs, technology trends and create a full stack and even ecosystem of open source projects to address these needs. They can take a boring project and support it for years. If there is a missing piece in the stack, they can start an open source project from scratch and build a community around it. They can acquire a closed source software company and open source the projects. Here I got a little bit carried away, but yes, I'm talking about my employer Red Hat and what we do among other things.

To summarise, with the commercial open source model, the projects are officially or unofficially managed and controlled by a very few individuals or companies that monetise them and also give back to the ecosystem by ensuring the project is successful. It is a win-win-win for the open source developers, managing companies and end users. The alternative is inactive projects and expensive closed source software.

Self-sustaining, Decentralized Open Source

In order for a project to become part of a reputable foundation it has to conform to certain criteria. For example, at ASF and CNCF there are incubation and graduation processes respectively where apart from all the technical and formal requirements, a project must have a healthy number of active committer and users. And that is in the essence of forming a sustainable open source project. Having source code on Github is not the same as having an active open source project. The latter requires committers that write the code, and users using the code, and both groups enforcing each other continuously by exchanging value and forming an ecosystem where everybody benefits. Some project ecosystems might be tiny and short lived, and some may consist of multiple projects and competing service providers, with very complex interactions lasting for many years. But as long as there is an exchange of value and everybody benefits from it, the project is developed, maintained and sustaining.

If you loot at ASF Attic, you will find projects that have reached their end of life. Usually, that is the natural end of a project when it is not technologically fit for purpose any longer. Similarly in the ASF Incubator you can find tens of projects that have never graduated but got retired instead. Typically, these are projects that are not able to build a large enough community because they are very specialized or there are better alternatives available. But there are also cases where projects with high potential and superior technology cannot sustain themselves because they cannot form or maintain a functioning ecosystem for exchange of value. The open source model and the foundations do not provide a framework and mechanisms assisting developers get paid for their work, or users get their requests heard. There isn’t a common value commitment framework for either party. As a result, some projects can only sustain themselves in the context of commercial open source where a company acts as an intermediary and value adder between developers and users. That puts another constraint and the necessity of a service provider company for sustaining some open source projects. Ideally, users should be able to express their interest in a project and developers should be able to show their commitment to the project in a transparent and measurable way and form a community with common interest and intent for exchange of value.

Now, let's imagine there is a model, mechanisms and tools that enable direct interaction between the open source users and the developers. Not only code contributions through pull requests, questions over the mailing lists, GitHub stars, stickers on laptops, but also other ways to allow users influence projects destinies through a more richer, self-controlled and transparent means. That could include incentives for actions such as the following:

  • Funding open source projects directly (rather than through software foundations)
  • Influence the direction of projects through voting (by token holders)
  • Feature requests driven by user needs
  • On-time pull request merges
  • Bounties for bug hunts
  • Better test coverage incentives
  • Up-to-date documentation rewards
  • Long-term support guarantees
  • Timely security fixes
  • Expert assistance, support and services
  • Budget for evangelism and promotion of the projects
  • Budget for regular boring activities
  • Fast email and chat assistance
  • Full visibility of the overall project findings, etc. 
If you haven't guessed already, I'm talking about using blockchain and smart contracts that will allow such interactions between users and developers. Smart contracts that will give power to the hand of token holders to influence projects.

The usage of blockchain in the open source ecosystem.
The existing channels in the open source ecosystem provide ways for users to influence projects through financial commitments to the service providers or other limited means through the foundations. But the addition of blockchain based technology to the open source ecosystem could open new channels for interaction between users and developers. I'm not saying this will replace the commercial open source model. Most companies working with open source do much more and cannot be replaced by smart contracts. But smart contracts can spark a new way for bootstrapping new open source projects. A new way to give a second life to commodity projects that are a burden to maintain. A new way to motivate developers to apply boring pull requests, write documentation, get tests to pass, etc. A direct value exchange channel between users and open source developers. It can add new channels to open source projects to grow and be self-sustaining in the long term even when a company backing is not feasible. A new complementary model for self-sustaining open source projects. A win-win.

Tokenizing Open Source

There are already a number of initiatives aiming to tokenize open source. Some are focused only on an open source model, and some are generic but apply to open source development as well. Here is a list I built so far:
  • Gitcoin - grow open source, one of the most promising ones in this area.
  • Oscoin - cryptocurrency for open source
  • Open Collective - platform for supporting open source projects.
  • Fund Yourself
  • Kauri - support for open source project documentation.
  • Liberapay - recurrent donations platform.
  • FundRequest - a decentralized marketplace for open source collaboration.
  • CanYa - who recently acquired Bountysource - the world’s largest open source P2P bounty platform.
  • OpenGift - a new model for open source monetization.
  • Hacken - a white hat token for hackers.
  • Coinlancer - decentralized job market.
  • CodeFund - open source ad platform.
  • IssueHunt - funding platform for open source maintainers and contributors.
  • District0x 1Hive - crowdfunding and curation platform.
  • District0x Fixit - github bug bounties.
The list above is varied and growing rapidly. Some of these projects will disappear, some will pivot, but a few will emerge as the SourceForge, the ASF, the Github of the future. Not necessarily replacing these platforms, but complementing them with token models and creating a richer open source ecosystem. So every project can pick its distribution model (license), governing model (foundation), and incentive model (token). In all cases, this will pump fresh blood to the open source world.

The Future is Open and Decentralised

  • Software is eating the world.
  • Every company is a software company.
  • Open source is where innovation happens.
Given this, it is clear that open source is too big to fail, too important to be controlled by few or left to its own destiny. Open source is a shared-resource system that has value to all, and more more importantly it must be managed as such. It is only a matter of time until every company on earth will want to have a stake and a say in the open source world. Unfortunately, don't have the tools and the habits to do it yet. Such tools would allow anybody to show their appreciation or ignorance of software projects. It would create a direct and faster feedback loop between producers and consumers, between developers and users. It will foster innovation, innovation driven by user needs and expressed through token metrics.

Enterprise Integration for Ethereum

If you prefer, read the same post on Medium.
The most popular open source Java integration library — Apache Camel supports Ethereum’s JSON-RPC API now.

The Ethereum Ecosystem

Ethereum is an open source, public, blockchain platform for running smart contracts. It provides a decentralized Turing-complete virtual machine that can execute scripts and a cryptocurrency used to compensate participant mining nodes for computations performed or to mitigate spam. Today, Ethereum is one of the most established and mature blockchain platforms with interests from small and large companies, nonprofit organizations and governments. There is a lot that can be said about Ethereum ecosystem and the pace it moves with. But the facts talk for themselves, Ethereum has the momentum and all the indications of a technology with a potential:
  • Ethereum has an order of magnitude more active developers than any other blockchain platform and as dictated by the Metcalfe's law, this gap widens day by the day. Ethereum coding school CryptoZombies has over 200K users, Truffle development framework has over half a million downloads.
  • The cloud platforms Amazon Web Services and Microsoft Azure offer services for one-click Ethereum infrastructure deployment and management.
  • The Ethereum technology has the interest of enterprise software companies. Customized Ethereum-based applications are being developed and experimented by financial institutions such as JPMorgan Chase, Deloitte, R3, Innovate UK,  Barclays, UBS, Credit Suisse and many others. One of the best known in this area is the J. P. Morgan Chase developed permissioned of Ethereum blockchain called Quorum.
  • In 2017, Enterprise Ethereum Alliance (EEA) was setup up by various blockchain start-ups, Fortune 500 companies, research groups and others with the aim to help adoption of Ethereum based technology. It provides standards, resources for businesses to learn about Ethereum and leverage this groundbreaking technology to address specific industry use cases.
Ethereum has passed the moment when it was a hipster technology or a scientific experiment, and now it is a fundamental open source decentralization technology that enterprise companies are looking into. Talking about open source and the enterprise, I thought I also do my tiny piece of contribution to the Ethereum ecosystem and help for its adoption. Let's see what is it.

Open Source Enterprise Integration

Ethereum is distributed and decentralized, but it is mostly a closed system with the embedded ledger, the currency, and the executing nodes. In order to be useful for the enterprise, Ethereum has to be well integrated with existing legacy and new systems. Luckily, Ethereum offers a robust and lightweight JSON-RPC API with a good support for the JavaScript language. But in the enterprise companies, JavaScript is not the primary choice for integration, it is rather Java followed by .Net. Java is not necessary lightweight or fast evolving, but it has a huge developer community and a mature library ecosystem making it the top choice for the majority of enterprise companies. The main factor contributing to the productivity of the Java language is the reuse of existing libraries and avoiding reinventing the wheel. One of the most popular libraries enabling reuse and avoiding reinventing the wheel for integration is Apache Camel. Luckily, Camel happens to be my passion and a project I have been contributing for many years, so connecting the two was the most natural thing for me to do.
Apache Camel building blocks
Building blocks of Apache Camel
For those who are coming from a blockchain background and are not familiar with Camel, here is a very brief intro. Apache Camel is a lightweight open source integration library that is composed conceptually of three parts:
  • Implementations of the widely used Enterprise Integration Patterns (EIPs). (Notice this are not Ethereum Improvement Proposal that shares the same acronym.) EIPs provide a common notation, language and definition of the concepts in the enterprise integration space (think of publish-subscribe, dead letter channel, content-based router, filter, splitter, aggregator, throttler, retry, circuit breaker, etc.). Some of these patterns have been around for over a decade and some are new, but they are well known by anyone doing messaging and distributed system integration for a living.
  • The second major part of Apache Camel is the huge connectors library. Basically, as long as there is a Java library for a protocol, system endpoint, SaaS API, most likely there is a Camel connector for it (think of HTTP, JMS, SOAP, REST, AWS SQS, DropBox, Twitter, and now Ethereum, etc). Connectors abstract away the complexity of configuring the different libraries and provide a unified URI based approach for connecting to all kind of systems.
  • And the last piece of Apache Camel is the Domain Specific Language (DSL) that wires together connectors and EIPs in a higher level integration focused language. The DSL, combined with connectors and patterns makes developers highly productive in connecting systems and creates solutions that are industry standard and easier to maintain for long periods. All these are characteristics that are important for enterprise companies looking to create modern solutions based on mature technology.
    Companies are more integrated than ever, the systems within the companies are more integrated than ever. And if you are a Java shop, most likely there is already some Apache Camel based integration in use somewhere in the organization. Now you can use Camel and all the capabilities it provides also to talk to Ethereum.

    Apache Camel Connector for Ethereum

    The natural intersection of the two technologies is a Camel connector for Ethereum. Such a connector would allow integrating Ethereum with any other system, interaction style, and protocol. For that purpose, I evaluated the existing Java libraries for Ethereum and came to the conclusion that web3j is the right fit for this use case. Web3j is an actively developed, feature rich, Java library for interacting with Ethereum compatibles nodes over JSON-RPC. Camel-web3j connector (the technical name for the Camel Ethereum connector) is a thin wrapper that gives an easy way to use the capabilities offered by web3j from Apache Camel DSL. Currently, the connector offers the following features:
    The full power of this integration comes not from the connector features, but when the connector is used together with the other connectors, patterns and all other Camel capabilities to provide a complete integration framework around Ethereum.

    Ethereum compatible JSON-RPC APIs
    Next, I'm going to focus on adding support for Parity's Personal, and Geth's Personal client API, Ethereum wallet support, and others. The aim is to keep the component up-to-date with the web3j capabilities that are useful in system-to-system integration scenarios with Apache Camel. The connector is pushed to Apache Camel 2.22 and ready for early adopters to give it a try and provide feedback. To get started, have a look at the unit tests to discover how each operation is configured, and the integration tests to see how to connect to Ganache or Ethereum mainnet, etc. Enjoy.

    Use Cases for Apache Camel

    Bellow is the Enterprise Ethereum Architecture Stack (EEAS) which represents a conceptual framework of the common layers and components of an Enterprise Ethereum (EE) application according to the client specification v1.0.

    Enterprise Ethereum Architecture Stack
    Enterprise Ethereum Architecture Stack
    If you wonder where exactly Camel fits here, Camel-web3j is part of the tooling layer as an integration library with a focus on system-to-system integration. It uses the public Ethereum JSON-RPC API, which any Enterprise Ethereum compatible implementation must support and keep backward compatible with.
    Then, Camel would primarily be used to interact with services that are external to Ethereum but trusted by the smart contracts (so-called Oracles). In a similar manner, Camel can be used to interact with Enterprise Management Systems to send alerts and metrics, report faults, change configurations, etc.

    The main use cases I can think of for this connector are:
    • Listen for new blocks, events, happening in the Ethereum network, filter, transform, enrich and publish them into other systems. For example listen for new blocks, retrieving its transactions, filter out uninteresting ones, enriching others, and process them. That can be done using Ethereum node filters capabilities, or purely with Camel, using polling consumers to query a node periodically and idempotent filters to prevent processing previously processed blocks, etc.
    • The other use case would be, to listen for events and commands coming from an enterprise system (maybe a step in the business process) and then tell the Ethereum network about it. For example, a KYC is approved or payment is received in one system, which causes Camel to talk to the second system and retrieve a user's ERC20 address and perform an Ethereum transaction.
    Real world uses of Camel would involve a more complex mixture of the above scenarios ensuring high availability, resilience, replay, auditing, etc, in which Camel is really good at.

    Ethereum Oracle Implemented in Apache Camel

    "Talk is cheap. Show me the code." - Linus Torvalds

    In many occasions, smart contracts need information from the real world to operate. An oracle is, simply put, a smart contract that is able to interact with the outside world. The demonstrate the usage of Camel-web3j, I created a Camel route that represents an oracle. The route listens for CallbackGetBTCCap events on a specific topic, and when such an event is received, the Camel route generates a random value and passes it to the same contract by calling setBTCCap method. That is basically a "Hello world!" the Ethereum way.

    To trigger the event, you can call updateBTCCap method on the smart contract using the following unit test:
    mvn test -Dtest=CamelOracleRouteTest#updateBTCCap
    To check the current price in the contract, you can call getBTCCap method on the smart contract using the following unit test:
    mvn test -Dtest=CamelOracleRouteTest#getBTCCap
    Check the full instructions, the smart contract, Camel routes on Github and try it for yourself. If you use the component and have questions or feedback, if you like this and you are interested from implementing Camel connector for other blockchain projects, reach out. Take care. eth jar: 0x6fc1bF6A69B92C444772aCE4CB040705Afd255bD

    Cryptocurrencies with Bus Factor of One

    The Bus Factor

    As defined by Wikipedia, the bus factor is a measurement of the risk resulting from capabilities not being shared among members of an endeavour "in case they get hit by a bus". When looking at cryptocurrencies and trying to predict which one would grow in value and survive the test of time, one risk factor to keep in mind is the bus factor. Let's see some of the most popular cryptocurrencies and their bus factor.

    Bitcoin Bus Factor

    Let's imagine that the person on the Bus Factor Wikipedia page is the real Satoshi Nakamoto and he is about to be hit by a bus. If such a terrible event happens, since nobody knows who is Satoshi, and more importantly, since he is not any longer involved actively with the bitcoin project, such an event would not affect Bitcoin slightest.

    Bus Factor by Wikipedia

    Unless Satoshi has shared his private keys for the 980,000 Bitcoins with his grandchildren, the coins would remain locked forever but Bitcoin still would strive until the end of time. Since we cannot name one person as the face of Bitcoin, its Bus Factor is determined by the core team members and the supporting community as a whole. The risk is distributed and much smaller scale.

    Ethereum Bust Factor

    Now let's imagine the Etehreum founder Vitalik is declared dead. Actually that happent in the past where Etheresum lost 4$ Billion in market value instantly. That forced Vitalik to use PoL (Prove of Liveness) to calm the markets down.
    Vitaliks self prove of liveness
    Vitalik being the creator and still very actively involved in defining the project vision  increases Ethereum Bus Factor to a solid 1. Meaning, it takes only one bus accident to significantly impact the project.

    That is not to suggest that Bitcoin is infinitely decentralised and Ethereum is centralised. Actually, Cornell Professor Emin Gun Sirer proved that Ethereum is more distributed and decentralised than Bitcoin from node distribution point of view. Ethereum nodes are better distributed and spread compared to Bitcoin nodes where the majority are managed by limited large miners.
    But from visionary, leadership and influence point of view,  by hiding his/her real identity, Satoshi potentially removed the most centralized point in his decentralized system. Etehreum is the second most popular currency with huge community already that can supports years ahead, but Vitalik still remains the most centralazed point in the Ethereum system.

    Bus Factor in Action

    Bus Factor is not dictated only by life and death situations. Similar risk hovered over Ethereum also when Vitalik tweeted his views about child porn. But Factor can express itself in so many different unpredictable situations and ways. A recent example that comes to mind is when the founder of ZClassic (ZCL), Rhett Chreighton decided to fork and abandon the project and start Bitcoin Private project. The price chart below is self explanatory for the result of such an action.
    ZClassic drops 97%

    An example on the opposite site is the creator of Litecoin, Charlie Lee who took a different route, and publicly announced that he sold all of his Litecoin, to remain impartial to the project. He is basically an evangelist for Litecoin now who tries to make the project to survive without him.

    Personality Cult Coins

    There are other examples where a coin has the market cap close to the budget of a small country and that is primarily driven by a project founder or advisor. The common pattern to be aware is, when there is 1 to 1 association between a project and a single person, which is an indication of a bus factor of 1.
    A recent tweet by Kevin Pham pointed out coins that are driven by a single person. Expanding that list, I came to the following one:
    Notice the people listed here have a much bigger influence on their project than a developer would have. Most of the people listed here are typically the visionary, the face, the blood and the flesh of the coins. It is a risk much bigger than a bus factor which is typically measuring the dependency of projects to a software developer or sys admin role.

    Surviving Bus Accidents

    I've been working with open source over a decade now and there are good lessons to learn from Apache Software Foundation (ASF) and other open source foundations about creating long living project ecosystems. The main criteria at ASF for a project to graduate from incubation to a top level project is when it builds a self sustaining community. That is a diverse community (from multiple organizations) of committers, contributors and users. There is a similar criteria at Cloud Native Computing Foundation (CNCF) where the focus on supporting organizations rather than supporting individuals as in ASF. Ideally, you want senior developers and visionaries from multiple organizations and independent contributors all together.

    In the crypto world, one of the primary criteria to measure community is the number of telegram/twitter/reddit followers . While that is an indication of a user interest, it can be easily manipulated, and actually it is a common and mandatory practise nowdays to pump these statistics through bounty programs and airdrops by project themselves. On the other hand growing the develop community and project visionaries is much harder and takes longer and it is a more accurate indicator for long term success. Make your picks wisely

    Upvote this article on Steemit or ETH Tips Jar: 0x8b8945972392ed8E6983B6EE66e9777eE5Bd81aD

    Spreading Freedom with Mainframe

    If you prefer, read the same post on Medium.

     The value of freedom

    Freedom is one of these intrinsic human values that are not appreciated until lost. But how do you measure freedom and how important is it for you? Let me tell you my story.

    I was born in an ex-communist country in eastern Europe where I learned the value of freedom at a very early age. At that time, I wasn’t allowed to practice my religion and even forced to change my name. I wasn’t allowed to use my mother language. Not allowed to listen and speak, not allowed to watch, not allowed to read and write in it. Luckily these times are far behind now, but it thought me at an early age to notice freedom, the absence of freedom, and its importance.
    Now I live in London UK - a city with the highest level of individual freedom in the world. It society operates on the principles of individual liberty and tolerance of those with different faiths and beliefs. In the professional life, I always participated in open source and free communities and naturally end up working at Red Hat which is build on the open source model. There I help customers replace proprietary software with open source and open standards. I’m not saying it is the perfect free world I live now, but having experienced the absence of freedom at a young age, I noticed that freedom attracts me more than anything.

    I have also witnessed first hand how “democratic” governments suppress free exchange of ideas, ban Youtube, Wikipedia, and Twitter, first-world countries where technology is used for mass censorship or deliberate deception. For different societies, freedom matters at different levels, but it matters to everybody, from life and death matters to a simple expression of opinions. And as we have seen many times in the history, freedom can be taken away anywhere in the world, and it takes courage, vision and hard work to preserve and spread it further.

    Freedom enabling technology

    In the technology world, one of the primary manifestations of what free exchange of ideas and free collaboration can create is the rise of open source. The open source model allows individuals with a common goal to come together (virtually), collaborate and create something that is bigger than what any individual can create and even bigger than what commercial software companies can create. But such collaborative models are only possible when there is a technology that enables effective and free human interaction, where ideas are evaluated, work is valued based on merit and conflicts resolved through discussion.

    To create the next generation collaborations, to achieve the next level of freedom, we need the next generation freedom enabling technology. A technology that scales globally, a platform resistant to censorship and guaranteeing individual privacy. Only then we can be assured that individuals can contribute to their fullest ability. Only then we can unlock the world's potential!

    A mission greater than the sum of its parts

    We have seen how the Internet gives access to the world’s knowledge even in the poorest parts of the world. We have seen how social apps can connect people and lead to revolutions during the Arab Spring. We have seen how Bitcoin can revolutionize borderless value exchange. Mainframe mission is at a similar scale. Having a decentralized protocol for censorship-resistant messaging will serve as a foundation for creative minds to build applications that spread freedom on a scale that the world has not seen before. We cannot imagine what such platform will bring us, but we can be sure it will be spreading more freedom.

    The first in need for such a platform is the crypto world itself. With crypto related censorship coming from Facebook, Google and soon Twitter, we need a censorship-free messaging platform for the crypto existence. Decentralization revolution cannot be stopped, but with enough censorship, it can be delayed and momentum can be taken away. Without the free exchange of ideas, we cannot invent, build, grow and spread more freedom fast enough. We need a Mainframe first for ourselves than any other industry right now. The Mainframe mission is bigger than the success of Mainframe only, it is existential for the whole crypto world and anybody in need of freedom.

    Free Employee Scheduling Application with OptaPlanner and Apache Isis

    Here, I want to briefly talk about two open source projects I love playing with.

    OptaPlanner is a constraint solver. It optimises business resource planning use cases, such as Vehicle Routing, Employee Rostering, Cloud Optimization, Task Assignment, Job Scheduling, Bin Packing and many more that every companies face daily. It can help squeeze the last bit of optimisation in your planning challenges and improve service quality and reduce costs. It is a lightweight, embeddable planning engine, consisting from a single .jar file.


    Apache Isis on the other hand is a framework for rapidly developing domain-driven apps in Java. Write your business logic in entities, domain services or view models, and the framework dynamically generates a representation of that domain model as a webapp or a rich hypermedia REST API. It is a full-stack application where once you write your domain layer, you get the persistence and presentation layer for free. It let's you very quickly to developer and iterate over the domain model.

    Both of these projects allow developers create user focused applications and solve read world problems. And both of them are centred around domain-driven design approach and fit nicely into Java development model using annotations. Last year, around this time, I decide to combine them and created a pet project called RotaBuilder. I migrated the existing Java Swing based Employee Rostering application from OptaPlanner examples to Apache Isis and turn it into a containerized web application. Below is a screenshot of an employee view.

    An employee view created in Apache Isis and OptaPlanner
    The application is on github and offers the following features:
    • Manage employees
    • Manage skills
    • Manage days on/off requests
    • Manage shift on/off requests
    • Manage contracts
    • Manage shifts
    • Create automatic employee-shift assignments
    It is far from complete, but I probably will not have time to work on it in a near future. I decide to push on public github in case anybody wants to learn these projects by developing an employee rostering application. For me, the best way for learning something has been doing it.

    Local Build and Run with Maven

    It is straightforward to locally build and run with maven.
    mvn clean install -DskipTests=true
    cd webapp
    mvn jetty:run
     
    then go to http://localhost:8080/

    Run with Docker

    It is also available as Docker image
    docker run -p 8080:8080 bibryam/rotabuilder

    Live Demo on Red Hat OpenShift

    See live demo (if it is) running at http://rotabuilder.com

    Which Camel DSL to Choose and Why?

    (This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.)

    Apache Camel is a powerful integration library that provides mainly three things: lot’s of integration connectors + implementation of multiple integration patterns + a higher level Domain Specific Language abstraction to glue all together nicely. While the connectors and pattern choices are use case and feature driven and easy to make, choosing which Camel DSL to use might be a little hard to reason about. I hope this article will be able to guide you in you first Camel journey.

    I work for Red Hat Consulting as an Integration architect and one of my primary goals is to help customers get the design and the architecture of their future systems as right as possible, and consequently get the best value out of Apache Camel. One of the common questions I get at the start of every new Camel based project is: “Which Camel DSL should we use? What are the pros and cons of each?

    I have one good news and one more good news for you. First, by choosing to use Apache Camel you have already done the right choice and Camel will turn out to be a very useful toolkit in your arsenal of libraries for lot’s of future use cases and projects to come. And second, the DSL is just a technicality and it will not impact the success of your project and you can always change your mind later and even mix and match.

    If you are a part of large company, with multiple independent two-pizza size teams that use Java language here and there, the chances are that some teams are already using Camel. Even in small companies, teams use Camel without being aware of each other as it is useful for all kind of tasks and a small enough library you to add to your pom.xml and use it without a permission from the technical design board. If that is the case, just talk to your colleagues and learn from first hand their experience with their DSL of choice.

    If you need a more comprehensive comparison and a reason to choose one of the DSLs, below is a brain dump from multiple engineers developing developing Apache Camel and consultants using Camel at multiple customer projects across the globe. Pick the arguments that are valid in your context and make your choice.

    Comparing Apache Camel's XML and Java DSLs
    Comparing Apache Camel's XML and Java DSLs
    If this table doesn’t give you the straight answer you were looking for, probably the answer is: it doesn’t matter. Camel has multiple DSLs, but there are good reasons for both Java and XML based DSLs to be equally popular. The more important takeaway from here is for developers to get used to think in terms of Pipes and Filters, learn the Enterprise Integration Patterns and their notations. Then using one of the Camel DSLs to express these patterns is a technicality without a technical consequence. Usually it is a team preference and culture based choice, such as “We are a hard-core Java shop and we hate XML” or “Can we do all through drag and drop?”.

    All that said, the only advice I can suggest is strive for consistency. Avoid using different DSLs in the same service, even for different services in the same project. And if you can convince everybody in the company to use the same DSL even better.

    Check out my Camel Design Patterns book for more Camel related topoics and follow me @bibryam for future blog posts.

    Rapid SEMAT Application Development with Apache Isis

    TL;DR This post talks about a SEMAT pet project I created using Apache Isis and deployed to OpenShift Online here http://semat.ofbizian.com

    Apache Isis

    As a Java developer who is working primarily on backend systems, I hate do not enjoy creating user interfaces and dealing with Javascript. Luckily, there are Java projects such as JSF (grrr), Apache Wicket, Vaadin that can help avoid Javascript altogether and still create functional user interfaces. But even with these projects, the developer has to think about and actively create the user interface from Java code. That is similar to writing your own SQL statements in the age of ORMs such as Hibernate - an activity we do only when OOTB ORM is not good enough for the use case. And that is exactly where Apache Isis fits in: given a domain model and mapping annotations, it generates the complete user interface at runtime. In a sense, Apache Isis is a OUIM (Object/User Interface Mapping) framework for Java.
    There is much more to Apache Isis than only creating user interfaces, it is a full stack rapid application development framework focused on domain driven design. But rather than talking about it, let's see a complete application created with Apache Isis.

    SEMAT Essence Kernel

    To learn Apache Isis, I decided to implement the SEMAT model and deploy it to OpenShift Online asa  Docker container. Simply said, SEMAT (Software Engineering Method and Theory) Essence Kernel is a OMG Standard that helps define among other things a framework for describing the state of software projects from multiple perspectives (called alphas).


    SEMAT Alpa States
    The idea is, that every project can be described in a generic way using the following seven alphas:
    Stakeholders, Opportunity, Requirements, Software System, Work, Team, Way-of-Working. And each Alpha can be in one or multiple states, for example, the Stakeholders can be: Recognized, Represented, Involved, In Agreement, Satisfied, etc. In addition, each state has certain items to be satisfied before an Alpha can be transitioned to that state.

    Stakeholders Alpha's States
    As you can see, this is a pretty simple domain model with a state machine logic behid it.

    The Showcase Application

    Enough said, to see how much Java I had to write for this application, check the dom module of the project on github. All of the other skeleton code is generated through a maven plugin and no user interface code is required. And here is a screenshot of the Project domain entity screen rendering:

    Project view as Apache Wicket screen
    In addition to generating a user interface, Apache Isis will generate also a REST API using the same domain model. How cool is that.
    SEMAT REST API generated from domain model
    And the beauty of all this is, that generating UI allows you quickly to iterate over the domain model, show it to the business owners to get feedback and contonue evolving the model.

    Some of the SEMAT Application Features implemented/enabled

    • Multi tenancy
    • Manage multiple projects per tenant
    • Manage project Alpha states
    • Custom Essence Alpha state list per tenancy
    • Custom Essence Checklist items per tenancy
    • Alpha state spider/radar diagram
    • Automatic Apache Wicket based UI generation from domain model
    • Automatic REST API generation from the same domain model
    • Self Signup/Registration
    • Auditing user actions
    • Session logging
    • Internationalization
    • Breadcrumb trail
    • Bookmarks

    Build and Run

    Check the readme for full details, but you can build and run the application locally or on OpenShift to try it out.
    mvn clean install
    cd webapp
    mvn jetty:run

    
    
    or 
    
    
    mvn clean install
    docker build --rm -t bibryam/semat .
    docker run -p 8080:8080 bibryam/semat
    Then go to http://localhost:8080/ and login: user/user
     

    Deploy to OpenShift

    Once you have got an OpenShift running either locally or online, and have a oc client installed, then you can deploy the already build semat docker image with the following commands:
    oc new-project semat
    oc new-app bibryam/semat:latest -e CATALINA_OPTS=“-Xmx300m”
    oc expose service semat
    If you do not trust docker images build by others (you should not!) then you can build your own docker image as shown above with options 2 and 3 and push it your own docker registry and run the application from it:
    oc new-app your_name/semat:latest -e CATALINA_OPTS=“-Xmx300m”
    Alternatively, you could avoid installing and running docker all together, and have the source code and the docker image build on OpenShift. That is called OpenShift Source-to-Image approach. You can do this from OpenShift UI by using for example "Red Hat JBoss Web Server 3.1 Tomcat 8 1.0" template and pointing to the SEMAT github repo. Or use the template provided in the project itself:
    oc create -f semat-openshift-template.json
    oc process semat
    Using source to image approach allows setting up github webhooks, have a Red Hat base image, have jolokia added, Java memory configurations done, etc.

    Live demo on OpenShift

    See try out the application, check live demo running on a OpenShift Online http://semat.ofbizian.com

    In summary, if you have a domain model that changes often, and the agility in changing the domain logic is more important than how the user user interface looks like, check out Apache Isis. It is an incredible productive and fast business application development framework.
    Follow me @bibryam for future blog posts on related topics.

    Hexagonal Architecture as a Natural fit for Apache Camel

    (This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.)

    There are architectures and patterns that look cool on a paper, and there are ones that are good in practice. Implementing the hexagonal architecture with Camel is both: cool to talk about, and a natural implementation outcome. I love going hexagonal with Camel because it is one of these combinations where the architecture and the tool come together naturally and many end up doing it without realising it. Let’s see why that is the case.

    Why go Hexagonal?

    Hexagonal architecture is originally described by Alistair Cockburn as an approach for dividing an application into inside and outside parts. Its intent is to move focus from multiple conceptual layers of an application to a distinction between the inside and outside parts of the application. The inside part represents the domain layer or the business logic, and the outside part consists of all the possible incoming or outgoing interaction points of the application. The same architecture is also known as Ports and Adapters as the the connection between the inside and the outside of the application is realized through ports and adapters. The word “port” is inspired by the operating systems ports where any application that conform to the protocol of a port can send or receive signals from an application. In a sense, a port represent a purposeful conversation. And the adapters represent the technology specific implementations of a port. Depending on the business benefits offered through the port, there might be multiple adapters that would like to expose the port using different technologies.
    Hexagonal architecture visualized with Enterprise Integration Patterns
    Hexagonal architecture visualized with Enterprise Integration Patterns
    Notice that all ports and adapters are fundamentally similar at the architectural level, but Alistair acknowledges that the ports and adapters come up in two flavours: primary and secondary or driving and driven. For example, if there is a simple REST based service that reads and writes to a database, the REST side of the service would be the primary actor port and adapter as it initiates and drives the interactions. The port and adapter for writing to the database side would be the secondary and driven actor as it is not initiating any calls (assuming we are not using any data change capture listeners in which case this adapter would also be a primary one).
    Briefly said, hexagonal architecture helps us avoid multi-layered architectures that are prone to end up being baklava architecture (anti-pattern). Instead it pushes us towards simplified separation of concerns, and onion-architecture, clean architecture, and similar.

    Why is Camel Hexagonal in Nature?

    Let’s look at the two extremes: a layered architecture manages the complexity of a large application by decomposing it and structuring into groups of subtasks of particular abstraction level called layer. Each layer has a specific role and responsibility within the application and changes made in one layer of the architecture usually don’t impact the components of other layers. In practice, this architecture splits an application into horizontal layers, and it is a very common approach for large monolithic web or ESB applications of the JEE world.
    Layered architecture compared to Pipes and Filters pattern
    Layered architecture compared to Pipes and Filters pattern
    On the other extreme is Camel with its expressive DSL and route/flow abstractions. Based on Pipes and Filters pattern, Camel would divide a large processing task into a sequence of smaller independent processing steps (Filters) connected by channel (Pipes). There is no notion of layers that depend on each other, and in fact, because of its powerful DSL, a simple integration can be done in few lines and a single layer only. In practice, Camel routes split your application by use case and business flow into vertical flows rather than horizontal layers. And a typical Camel application is composed of multiple independently working Camel routes that collaborate for achieving the common business goals. As mentioned previously, when working with Camel, services created with it tend to end up as a single layer. Whereas this is fine for most of the simpler cases, applying the hexagonal architecture principles will help with creating better applications when working on large scale projects. What I mean by that is, split your Camel routes into two layers that represent the inside and the outside of the application. The inside of the application is represented by Camel routes that implement the business logic of your integration, and intended to be reused by multiple other routes and protocols. The outside of the application would be implemented by Camel routes that are the adapters in the hexagonal architecture i.e. routes that provide technology specific logic e.g. handle a specific protocol, error handling logic specific for the endpoint, transactionality and recovery actions specific for the endpoint as well.

    How to Map Hexagonal Architecture to Camel?

    Identify the inside of your application

    Even the simplest services created with Camel have some kind of business logic. Usually that is a combination of transforming data, content-based routing, filtering, splitting, aggregating, etc. Very often, none of the out of the box enterprise integration patterns will be applicable and you will have to use your own custom Java bean as part of a Camel route. The awesome part is that Camel is completely non-intrusive and you can develop, test and use Java beans in Camel routes with absolute no dependency on the Camel APIs. Camel bean component will make sure that the bean method parameters are populated with the correct values and also take the return value and put it back into Camel routes. If you have identified the routes containing the elements mentioned above, typically these represent the inside of your application. These kind of routes should not contain logic that is technology and protocol specific. For example avoid using data that is directly populated by components, such as http headers, jms headers, and also error handling retry logic common for the HTTP protocol, compensating action logic, etc. Instead keep this inside Camel routes focused on the business logic only and isolated from outside Camel routes.

    Isolate the inside from the outside

    In the hexagonal architecture, the inside of the application is reached through ports that abstract conversations. Camel direct component is the perfect implementation of a port. It provides synchronous invocation, the same as a method call in Java. It is not technology and protocol specific, there is no specific data format or schema validation requirement and can be used to pass in and out any kind of data. Typically the preferred data format to pass is a POJO as it is the easiest and most flexible structure to manipulate in a Camel route. But if in your domain, the primary data format is XML, JSON, or anything else, you can keep to such a format as well. No strong rules to follow, but whatever works for you. The only thing that is fixed with direct component is that it is a synchronous interaction model and I think that is the correct one by default. If asynchronicity is required, rather than using SEDA component for a port, it would be better to implement asynchronous logic either as part of the outside route (if asynchronicity is required by an adapter) or in the inside route if it is part of the business logic. But don’t limit the port to asynchronous model only. A port represents a meaningful conversation in the context of a service. That in Camel is represented by direct component which is identified uniquely as a String value in the context of a JVM. One would think that direct component was implemented as a response for Alistairs port definition.

    Keep outside out

    So we have the business logic of our application implemented as Camel routes accessible only through direct component endpoints as ports. Such a setup allows testing, reusing, and exposing the business logic over multiple protocols to the outside world using other routes. The outside of the application contains any logic that is dependent on the endpoints. Nowadays most common of these are the messaging or file based for asynchronous interaction, and HTTP based for synchronous interaction. But it can also be any of the other over 200 connectors that are present in Camel. Keep in mind that the components you use for the outside, are not only dictating the interaction model, but also usually define the data format, the transaction semantics, the error handling logic, and potentially even other aspects of the applications. For example a SOAP endpoint will perform a schema validation, but consuming a JMS message will require an additional validation step. A transactional endpoint will perform rollback in the case of a failure, but a non-transactional endpoint will require a recovery action, an idempotent endpoint will allow retry, and a non-idempotent endpoint will not. I have described these kind of considerations and other related Camel use cases in more details in the Camel Design Patterns book. Putting it all together, a Camel based service that exposes some business functionality over SOAP and JMS is visualized below. The same business functionality is accessible through direct component for JMS and SOAP based routes. Also, on the right hand side, the same route is using an email notifications port and adapter for sending emails.

    Ports and Adapters based Camel service
    Ports and Adapters based Camel service
     Notice that, outside routes are not only on the consumer side, they are also on the producer side, i.e. routes that send messages to other systems (remember driving and driven ports/adapters). The intent of the outside routes is to represent the various adapters that should handle everything that is outside specific: protocol, data format, additional logic specific for the endpoint. In addition, an outside route should prepare the data in format that is expected by the port by populating expected headers and the message body. This would allow the same port to be reused by multiple adapter routes. This includes also test fixtures in Camel for unit testing Camel routes, and even the error handling code. The error handling constructs in Camel (no doTry, doCatch, doFinally, but the onException construct) is actually representing a port that is automatically called by the framework on different types of exceptional conditions. Such a concept doesn’t exist in the Java language, but in Camel it is a very commonly used execution path for unhappy scenarios. And treating the error handling flow as just another port in your application (even if it is not called by you but the framework on certain occasion), will help you to reuse it for common error handling across multiple Camel routes.

    In Summary

    There are no clear rules or guidelines on how to compose an application with Camel routes. Defining those at design time usually limits the creativity of developers at implementation time, and not having guidelines can be a recipe for a spaghetti architecture. In this line of thought, I think hexagonal architecture is sufficiently lightweight, doesn’t kill creativity and imagination during implementation by forcing specific structure. At the same time, it provides just enough guidance for structuring routes. And the best part is, it naturally fits the Camel programing model.
    My suggestion would be start with VETRO pattern (Validate, Enrich, Transform, Route, Operate), then apply hexagonal architecture style (Edge Component Pattern as described in Camel Design Patterns book). This is a good starting point for structuring Camel routes for the happy paths. Then pay special attention to achieving data consistency with the various error handling and recovery patterns. And don’t forget, there are no best practices, but only good practices in a context. Focus on your context and Camel will be on your side.
    Follow me @bibryam for future blog posts on related topics.

    Short Retry vs Long Retry in Apache Camel

    (This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.)

    Camel Design Patterns book describes 20 patterns and numerous tips and best practices for designing Apache Camel based integration solutions. Each pattern is based on a real world use case and provides Camel specific implementation details and best practises. To get a feel of the book, below is an extract from the Retry Pattern from the book describing how to do Short and Long retires in Apache Camel.

    Context and Problem

    By their very nature integration applications have to interact with other systems over the network. With dynamic cloud-based environments becoming the norm, and the microservices architectural style partitioning applications into more granular services, the successful service communication has become a fundamental prerequisite for many distributed applications. Services that communicate with other services must be able to handle transient failures that can occur in downstream systems transparently, and continue operating without any disruption. As a transient failure can be considered an infrastructure-level fault, a loss of network connectivity, timeouts and throttling applied by busy services, etc. These conditions occur infrequently and they are typically self- correcting, and usually retrying an operation succeeds.

    Forces and Solution       

    Reproducing and explaining transient failures can be a difficult task as these might be caused by a combination of factors happening irregularly and related to external systems. Tools such as Chaos Monkey can be used to simulate unpredictable system outages and let you test the application resiliency if needed. A good strategy for dealing with transient failures is to retry the operation and hope that it will succeed (if the error is truly transient, it will succeed; just keep calm and keep retrying).
    To implement a “retry” logic there are a few areas to consider:            

    Which failures to retry?

    Certain service operations, such as HTTP calls and relational database interactions, are potential candidates for a retry logic, but further analysis is needed before implementing it. A relational database may reject a connection attempt because it is throttling against excessive resource usage, or reject an SQL insert operation because of concurrent modification. Retrying in these situations could be successful. But if an relational database rejects a connection because of wrong credentials, or an SQL insert operation has failed because of foreign key constraints, retrying the operation will not help. Similarly with HTTP calls, retrying a connection timeout or response timeout may help, but retrying a SOAP Fault caused by a business error does not make any sense. So choose your retries carefully.

    How often to retry?

    Once a retry necessity has been identified, the specific retry policy should be tuned to satisfy the nature of both applications: the service consumer with the retry logic and the service provider with the transient failure. For example, if a real time integration service fails to process a request, it might be allowed to do only few retry attempts with short delays before returning a response, whereas a batch-based asynchronous service may be able to afford to do more retries with longer delays and exponential back off. The retry strategy should also consider other factors such as the service consumption contracts and the SLAs of the service provider. For example, a very aggressive retry strategy may cause further throttling and even a blacklisting of a service consumer, or it can fully overload and degrade a busy service and prevent it from recovering at all. Some APIs may give you an indication of the remaining request count for a time period and blacklisting information in the response, but some may not. So a retry strategy defines how often to retry and for how long before you should accept the fact that it is a non-transient failure and give up.

    Idempotency

    When retrying an operation, consider the possible side effects on that operation. A service operation that will be consumed with retry logic should be designed and implemented as idempotent. Retrying the same operation with the same data input should not have any side effects. Imagine a request that has processed successfully, but the response has not reached back. The service consumer may assume that the request has failed and retry the same operation which may have some unexpected side effects.

    Monitoring

    Tracking and reporting retries is important too. If certain operations are constantly retried before succeeding or they are retried too many times before failing, these have to be identified and fixed. Since retries in a service are supposed to be transparent to the service consumer, without proper monitoring in place, they may remain undetected and affect the stability and the performance of the whole system in a negative way.

    Timeouts and SLAs

    When transient failures happen in the downstream systems and the retry logic kicks in, the overall processing time of the retrying service will increase significantly. Rather than thinking about the retry parameters from the perspective of the number of retries and delays, it is important to drive these values from the perspective of service SLAs and service consumer timeouts. So take the maximum amount of time allowed to handle the request, and determine the maximum number of retries and delays (including the processing time) that can be squeezed into that time frame.

    Mechanics

    There are a few different ways of performing retries with Camel and ActiveMQ.

    Camel RedeliveryPolicy (Short Retry)

    This is the most popular and generic way of doing retries in a Camel. A redelivery policy defines the retry rules (such as the number of retries and delays, whether to use collision avoidance and an exponential backoff multiplier, and logging) which can then be applied to multiple errorHandler and onException blocks of the processing flow. Whenever an exception is thrown up, the rules in the redelivery policy will be applied.
    Camel RedeliveryPolicy example
    The key differentiator of the retry mechanism is that Camel error handling logic will not retry the whole route, but it will retry only the failed endpoint in the processing flow. This is achieved thanks to the channels that connect the endpoints in the Camel route. Whenever an exception is thrown up by the processing node, it is propagated back and caught by the channel, which can then apply various error handling policies. Another important difference here is that Camel-based error handling and redelivery logic is in-memory, and it blocks a thread during retries, which has consequences. You may run out of threads if all threads are blocked and waiting to do retries. The owner of the threads may be the consumer, or some parallel processing construct with a thread pool from the route (such as a parallel splitter, recipient list, or Threads DSL). If, for example, we have an HTTP consumer with ten request processing threads, a database that is busy and rejects connections, and a RedeliveryPolicy with exponential backoff, after ten requests all the threads will end up waiting to do retries and no thread will be available to handle new requests. A solution for this blocking of threads problem is opting for asyncDelayedRedelivery where Camel will use a thread pool and schedule the redelivery asynchronously. But the thread pool stores the redelivery requests in an internal queue, so this option can consume all of the heap very quickly. Also keep in mind that there is one thread pool for all error handlers and redeliveries for a CamelContext, so unless you configure a specific thread pool for long-lasting redelivery, the pool can be exhausted in one route and block threads in another. Another implication is that because of the in-memory nature of the retry logic, restarting the application will lose the retry state, and there will be no way of distributing or persisting this state.
    Overall, this Camel retry mechanism is good for short-lived local retries, and to overcome network glitches or short locks on resources. For longer-lasting delays, it is a better option to redesign the application with persistent redeliveries that are clustered and non-thread-blocking (such a solution is described below).

    ActiveMQ Broker Redelivery (Long Retry)

    This retry mechanism has different characteristics to the previous two since it is managed by the broker itself (rather than the message consumer or the Camel routing engine). ActiveMQ has the ability to deliver messages with delays thanks to its scheduler. This functionality is the base for the broker redelivery plug-in. The redelivery plug-in can intercept dead letter processing and reschedule the failing messages for redelivery. Rather than being delivered to a DLQ, a failing message is scheduled to go to the tail of the original queue and redelivered to a message consumer. This is useful when the total message order is not important and when throughput and load distribution among consumers is.
    ActiveMQ redelivery example
    The difference to the previous approaches is that the message is persistent in the broker message store and it would survive broker or Camel route restart without affecting the redelivery timings. Another advantage is that there is no thread blocked for each retried message. Since the message is returned back to the broker, the Competing Consumers Pattern can be used to deliver the message to a different consumer. But the side effect is that the message order is lost as the message will be put at the tail of the message queue. Also, running the broker with a scheduler has some performance impact. This retry mechanism is useful for long-delayed retries where you cannot afford to have a blocked thread for every failing message. It is also useful when you want the message to be persisted and clustered for the redelivery.
    Notice that it is easy to implement the broker redelivery logic manually rather than by using the broker redelivery plug-in. All you have to do is catch the exception and send the message with an AMQ_SCHEDULED_DELAY header to an intermediary queue. Once the delay has passed, the message will be consumed and the same operation will be retried. You can reschedule and process the same message multiple times until giving up and putting the message in a backoff or dead letter queue.

    Side note - I know, shameless plug, but I'm pretty excited about my book on this topic. You can check it out here at a 40% discount until end of June! And hope you like it.

    About Me