Sunday, September 20, 2015

What is service layer?

There are many factors that go into the decision of creating a service layer. I have created service layers in the past for the following reasons.
  1. Code that needs to be re-used by multiple clients.
  2. Third party libraries that we have limited licenses for.
  3. Third parties that need an integration point into our system.
  4. Centralizing duplicated business logic.
Case 1: You are creating base functionality that needs to be used by a myriad of different clients. Service layer builds in functionality for different clients to tap into your provided functionality right out of the box.
Case 2: You normally host code in app space but you are using a third party library that you have limited licenses for. In this case you have a resource you would like to use everywhere, but only a limited number of them. If you host it behind a service then your whole organization can get usage of it from their applications without having to buy a license for each individual hosting.
Case 3: You are building functionality for third parties to communicate to you. In your example you could set up an inventory endpoint to allow vendors to pass messages to you about incoming product shipments.
Case 4: You have analyzed your code enterprise wide and found that separate teams have created the same thing (just implemented slightly differently). With a service layer you can pick the best approach(es) and now you can implement the process the same across all teams by having them call into the service. Another benefit to centralizing logic is when bugs are found. Now you can deploy the fix once and all clients enjoy the benefit at the same time.
All this being said there are potential negatives to a service layer.
  1. Adds system complexity. Where before you only had one application to debug now you have two. Production problems require checking client app setting, service app settings, or communication problems between otherwise correctly setup client and server apps. This can be tricky if you've never done it before.
  2. One point of failure. If you have a service outage all clients are affected. When code is not deployed in this manner the risk can be less (though there are ways to mitigate this).
  3. Versioning can be harder to do. When you have one app using a service deploying interface changes can be done at the same time between the two. When you have multiple clients now you must manage who is on V1, who is on V2, and coordinating the removal of V1 (once you know everyone has updated to V2).

Tuesday, September 15, 2015

What are Micro-Services?


What are Micro-Services?

Micro-services are application architectures in enterprise infrastructure. They allow for rapid development, smaller code-bases, enterprise integration, and modular deployables.
Example of micro service is a Restful web service which accesses database for reading and writing to it.
It's basically not a whole application but a tiny application.

Micro services are also called SOA 2.0 because it's the same concept that came around during SOA.

Micro services however can be built using Rest over HTTP or STOMP over websocket. This is different from Web services which are XML over HTTP.

There are various benefits of SOA2.0 micro services architecture.
1. Scaling is easy : X axis (copies of application), Y Axis (sharding) is possible.
2. Two services could be built using different languages.
3. One service's problems such as memory leak would not bring down all services.
4. Easy to maintain because of smaller size.

What is Spring boot

What is Spring Boot?

Spring boot is startup application for Spring framework.

It's not a new design pattern. It's not a new application architecture. Spring boot simply provide a place holder application where you can start working. It reduces lot of your efforts while writing new application and also reduces boiler plate code.
Spring boot is one step closer to removing the xml configurations from spring application.

What is Spring boot

What is Spring Boot?

Spring boot is startup application for Spring framework.

It's not a new design pattern. It's not a new application architecture. Spring boot simply provide a place holder application where you can start working. It reduces lot of your efforts while writing new application and also reduces boiler plate code.
Spring boot is one step closer to removing the xml configurations from spring application.