MDB vs JMS listener

Notes around MDB ( Message Driven Bean) vs Standard JMS listener, and their advantages and limitations around concurrency, scalability etc.


JMS ListenerJMS has NO built-in mechanism to handle more than one incoming request at a time. Meaning that, if you have JMS listener which is listening a queue, where loads of messages coming in, then your JMS listener will consume one message at a time, which results in picking up messages one by one, which might cause message piling up on queue!

MDB The main advantage that MDBs have over simple JMS message consumers is that the EJB container can instantiate multiple MDB instances to handle multiple messages simultaneously.

Now, in order to handle concurrently in JMS listener you have two options:-

a) Dynamic scaling of JMS listener by spawning multiple threads for JMS listener via configuration.

This can be done by adding property concurrency="15-40" to <jms:listener-container>
This sets concurrentConsumer to 15 and maxConcurrentConsumer to 40 in the properties of DefalutMessagingListenerContainer ( DMLC ) of Spring.

Above configuration instructs DMLC to always start up a minimum of 15 consumers. When a new message has been received, if the maxConcurrentConsumers has not been reached and the value of the idleConsumerLimit property has not been reached, then a new consumer is created to process the message. 
This behavior from the DMLC continues up to the limit set by the maxConcurrentConsumers property. When no messages are being received and the consumers become idle, the number of consumers is automatically decreased

b) Deploy JMS listener on multiple JVM instances.This allows multiple consumers listening to queue.

IMP Note-> One should NOT increase number of concurrent consumers for a JMS topic. This leads to concurrent consumption of same message, which is NOT desirable.

MDB Limitation
MDB can be linked to listen from only one queue or topic whereas standard JMS listener can be linked to listen to multiple queues or topic.
In order to allow a MDB to listen to multiple queues or topic, you will have to deploy multiple MDB classes.

XA, Non-XA transaction and 2PC Protocol

Wisely choose transaction type while designing your application. Transaction, a key aspect of any application should be taken care well in advance. Here are few tips while choosing between XA and Non-XA transaction.

XA transactions
  1. XA transaction is like global transaction.
  2. When you have multiple resources involved for a single transaction, you should be using XA transaction.Multiple resource means, 2 or more databases or JMS listener and a database etc.
  3. Transaction manager (TM) is responsible for bringing multiple resources under a single transaction.
  4. Transaction manger is the capability of the container.
  5. TM uses 2PC (Two phase commit) pattern for committing the transaction.
  6. The resources (JMS, DB etc ) involved in the transaction should have capability to support 2PC pattern otherwise XA will not work.

 NON-XA transaction

  1. Non-XA transaction is like a local transaction.
  2. Use this approach when a single resource is doing all it’s transaction work itself.
What is 2PC ( TWO Phase commit ) Protocol?
  1. 2PC is used to make sure the transactions are in sync when you have 2 or more DBs.
  2. Assume I have two databases ( DB-1 and DB-2) using 2PC, both of these databases are in two different locations.
  3. Now, before DB-1 and DB-2 are ready to commit transactions, they will notify transaction manager that they are ready to commit ( PHASE 1 ). So when the transaction manager is acknowledge, it will send a signal to DB-1 and DB-2 telling them go ahead for commit (PHASE – 2 )..
Important note-> Two phase commit does not guarantee that a distributed transaction can't fail, but it does guarantee that it can't fail silently without the TM being aware of it.

What is Blockchain, What is Bitcoin, Why it is needed?

I planned to participate in a Hackathon event on BlockChain and it was completely new to me, so I read various blogs, articles on this to understand very basic of block chain. Putting together my notes around basic learning on this.

1) what is Blockchain?
2) what is Bitcoin?
3) why is Blockchain needed?

What is Blockchain?
Blockchain is a technology that maintains transactions on distributed network of computers in a transparent fashion! 
So think of this as " a data units ( block ) which are distributed over a network ( chain ) of computers.
The authenticity of each transaction is protected by digital signatures.

When we say "transparent", yes it is truly transparent and made accessible to public. Of course over some secured API's!

It is the first decentralized peer-to-peer payment network that is powered by its users with no central authority or middlemen, Hence eliminating third party involvement.

The most powerful fact of blockchain technology is, it minimizes or eliminates third party involvements.

Example:- You are working on app that requires money to be transferred from User 1 account to User 2 account then how would you find that user 1 has sufficient money in account for this transfer? You would certainly need a third party, yeah? Which is bank! But, using blockchain technology, all previous transactions of user 1 and user 2 can be stored as string of blocks over distributed networks and since it is transparent and available to public , we would know ( without bank involvement ), who can send what and to whom and how much!

What is Bitcoin?
You might have heard people to talking about Bitcoin while having discussion on blockchain? 

Bitcoin is the application ( most popular till date ) of blockchain. By analogy it is like being able to send a gold coin via email!! :-)

Yes, you can buy and sell bitcoins! Interesting!! Probably your next investment!

There are bitcoin wallet apps which enables you to make bitcoin transaction.

Why block chain is needed?
There are many aspect but if you see on the point, "Transparency and Cost", these two gets shared whenever third party gets involved, which results in money gets distributed to middlemen and thus true value creator often doesn't get what they actually deserve.

So, blockchain enables removing middlemen, creating trust less deals and indelible reputation systems, blockchain could finally make micro transactions and micro payments feasible.

Example:- Development of applications like "Smart contract" that defines agreement contacts, which can be attached to blockchains in order to bring clarity to deal making.
Artists could load up their content on a blockchain and invite the likes of record labels to access it by agreeing to their terms of use. The benefit is that all parties concerned would see how much content is being used and when, reducing confusion, paperwork and allowing for near instantaneous royalty payments.

There are blockchain enabled music application being developed.

Read hereon how Yes bank is using blockchain technology to help companies to fully digitize their systems.

There are very innovative and interesting apps are being developed on blockchain in Transport industry, AI, internet connected devices etc.

Thanks for the read, I hope this gives you very basic understanding of blockchain.

Microservices/API design principles

My notes on MicroService design principles.

Microservice design principles - microservies has nothing to do with physical size or lines of code!!! It's about minimizing complexity.

"instead of having single complex service for your systems, design bunch of small services based on specific business capabilities. Small service means, it should minimize complexity, should serve a focused purpose and should minimize inter-service communication"

Design principles for MicroServices

1) Develop and Deployed independently 
Each service shuould be developed and deployed independently. Deployment of one service should not impact other services and a each service should have it's own code base.

You are doing wrong if
you find a need to deploy services together
you have one code base for multiple services
you need to send notification to before you deploy a service

2) Data ownership

Service should have it's own databased or preferably set of tables that is manged by only a specific service.
should avoid scenario where multiple services are writing and reading from the same set of tables, any changes to table would require changes in all services.  
having each service has it's own data ownership introduce loose coupling between service and database.
key point is , services should NOT have knowledge of each others underlying database.

Having own database for a services allows to choose right database technologies based on service functionality.

3) loosely coupled from all other services,

   once you adhere to point 1 and 2, you have already initiated loose coupling        but there are more on loose coupling:-
   minimal dependency on other services
   communication with other services should be over exposed public interfaces( API, events etc )
   such interfaces or API should NOT expose internal details  

4) Follow High cohesion methodology

    closely related functionality must stay together in a single service. this minimizes intercommunication between services.

5) Resilient service

   Single point of failure in system should NOT impact multiple services. if you have a service with independent data ownership, loose coupling, independent deployable artifact, it is a step towards resilient system!

Remember- Total resilience in the face of all situations is NOT possible.Implement what is feasible in the short term and work to achieve greater resilience in stages.

6) shared library

  carefully watch out implications of shared library introduction to your services.
  You are doing something wrong when changes to shared library requires    updates to all services simultaneously.

7) Introduce Asynchronous workers
   very important design principle - introduce asynchronous workers to minimize impact on primary service API.
example-> A batch job can be introduced in a service as an asynchronous worker which is responsible to process high volume request, re-try mechanism for failed request etc.
This asynchronous  worker provide following benefits:-

  • speed up the primary request path
  • spread load to asynchronous  worker in case of high volume request
  • reduce error scenarios on primary API
8) Service Versioning
    An API is never going to be completely stable. Change is inevitable!!  
    it's always a best practice to version your service.
   Versioning can be added to header or in the service url.
   Following technique can be used to maintain service version:- 

 The URL has a major version number (v1), but the API has date based sub-     versions which can be chosen using a custom HTTP request header. In this case, the major version provides structural stability of the API as a whole while the sub-versions accounts for smaller changes (field deprecations, endpoint changes, etc).

Risk Storming

Risk Storming - Collaborative and Visual Technique for identifying technical risk

My notes

1) Draw you app design on board - high level to show each like component, class, container etc
2) Identify risk individually - each and every member of team has different view of looking at risk!
3) Highlight risk at component/flow/integration level
4) Discuss and Priorities

Excellent write up by Simon here @ Risk Storming.


Java EE - the next inception!

Read this article on WebSphere and found this interesting about basics of how IBM WebSphere Application Server Liberty profile works, and how its architecture differs significantly from that of older Java EE application servers

Please read here complete article at Java EE, the next inception: A primer to WebSphere Liberty for Java EE developers

Portlet Preferences Usage - Best Practices

PortletPreferences should be used very carefully and in situations only when there is a valid use case for it.
So ideally, one should have good knowledge of portlet preference and most imortantly, where to apply it.

The PortletPreferences object provides the ability to store information persistently about how a client wants to use a particular portlet. 

For example, with the stock portlet, a user can provide stock code information to the portlet, and the portlet will store that information persistently using the PortletPreferences object. The next time the user visits the view mode of the portlet, the stock details for that user's choice will be displayed. 
Persistently storing this information, is all done behind the scenes for you by the portal framework.

So when you use portlet preference, did you ever think about where does portlet preference gets stored? In hard drive, some KB's data in DB or as CLOB or something that is not efficient. 
So how to store portlet preference is completely upto portal vendors and hence we as a developer or DB administrator don't have much control over the data which is stored in portlet preference.

Let's talk about application efficiency, where in if you want to store just a Boolean flag and if you choose to store it in portlet preference, you don't know how it will be stored and what size it would use for storage compared to if we chose to use our own DB to store the flag which would just take few tiny bit of space.

Furthermore, mining information from data stored in portlet prefernce is almost very difficult.

So, If you don't know how the portal stores your PortletPreferences data, and you don't know how the portal ties a particular preference to a particular user, you're going to have a pretty hard time mining your own data.

The best use of portlet preference could fall in below situations where a user wants 

1) To have red background.
2) configurable pagination numbers
3) configurable TimeZone
4) configurable portotol ( http or https etc )
5) Configurable fonts etc.

Conclusion -

  • Use portlet preference for simple configurable parameters
  • Don't ever use preference to store information where it would become impossible to do data mining from preference storage because you don't have control over preference storage.