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.

Dynamic Registration of Servlets and Filters at application startup


Recently I read about one of the nice feature of JAVA EE 6 - Dynamic Registration of Servlets and Filters at application startup.

I then thought of use cases around this feature. 
I think, this is mostly desinged for framework creators but developers could also get benefits from this.

You can use this fefature by using new methods introduced in the ServletContext class which are able to programmatically add servlets and servlet filters to a web application during startup. 

The methods are addServlet() method to add a servlet to the web application, and the corresponding addFilter() method to add a servlet filter.

Here's an example, which dynamically registers a Servlet as soon as the ServletContextListener is triggered:

//Register Servlet
public class MyServletContextListener implements ServletContextListener {
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        // Register Servlet here
        ServletRegistration sr = sc.addServlet("DynamicServlet",
            "com.sample.DynamicServlet");
        sr.setInitParameter("servletInitParamName", "servletInitParamValue");
        sr.addMapping("/mydynamicServlet");
    }


The same steps can be used to register a Filter named MyDynamicFilter bound to the class com.sample.TestFilter:


// Register Filter
FilterRegistration fr = sc.addFilter("DynamicFilter","com.sample.TestFilter");
fr.setInitParameter("filterInitName", "filterInitValue");
fr.addMappingForServletNames(EnumSet.of(DispatcherType.REQUEST),
                                     true, "DynamicServlet");


 
Would be great if readers of this post, could suggest creative use cases which could add useful functionality to an applications.

How to programatically refresh data from LDAP

Came across to this article which very well details out, how one can Programatically refresh date from LDAP.


The articles also have a Sample Code to programatically refresh data from the LDAP.

I am sure, this would be helpful for those who encounter this use case.