Confusing SOA and Microservices as the Same or Similar?

Although both SOA and microservices are architecture styles (an architecture style is a formal notation to explain how a software application is assembled and its implications),these two variations have a lot of differences:

SOA

• Its approach is to connect existing applications via a single instance, the ESB, via disparate protocols.
• The connection and message delivery between the endpoints must be orchestratedwithin the ESB.
• The service that is exposed in the ESB should be written in a specific language and follow mostly SOAP protocol (with or without WS* stack) or REST, via HTTP protocol.
• Costly when you have a huge payload to exchange between the parties, due to the phases of marshaling and unmarshaling.
• Vertically scalable.
• ESB as a single point of failure.
• Harder to deploy in comparison to MSA (microservices style architecture) due to dependencies of the application endpoint and ESB mediation itself.
• Services are registered in advance of the execution and consumption of their contract by other services.

Microservices

• Its approach is to create a single, self-sufficient application that can run in an isolated environment with its own database.
• The connections between the services are choreographed – this way the microservice can respond to a specific event received.
• The microservice can be written in any programming language available for the creation of services (Java, Python, JavaScript, .NET, etc).
• Follows only REST conventions. Can use binary protocols such as Google Protobuf and Twitter Finagle.
• Corresponds to a functional feature of our current monolith system.
• Fault-tolerant.
• Horizontally scalable.
• Easy to deploy with CD/CI in place.
• Microservices register themselves in an entity called an API Gateway and are automatically discovered by other microservices.

 

ThreadLocal in Java

ThreadLocal is one of the rarely used class in Java. I found it is one of the powerful class in Java on multi-threaded programming. In multi threaded program generally we use session object to track the current users information.

These information is passed to various method to retrieve desired value. For example in Struts execute method passes HttpServletRequest and HttpServletResponse, what if we want the instance of ServletContext? we have to change the method signatore to pass ServletContext. One can use ThreadLocal to keep certain objects/values available throught the thread execution.

ThreadLocal object is not required on day to day programming unlike ArrayList or HashMap. But it is good choice to solve a few problems at framework level. In one of my recent project I have used ThreadLocal to expose user specific information like User info, UserId, Roles and access, etc.

The main reason is I want hide the code which identifies these values so that in future it is easy to change the behavior and fine tune the code across the application.

Abstract vs Interface

ü  Abstract class is a class which contains one or more abstract methods, which has to be implemented by sub classes. An abstract class can contain no abstract methods also i.e. abstract class may contain concrete methods. A Java Interface can contain only method declarations and public static final constants and doesn’t contain their implementation. The classes which implement the Interface must provide the method definition for all the methods present.

ü  Abstract class definition begins with the keyword “abstract” keyword followed by Class definition. An Interface definition begins with the keyword “interface”.

ü  Abstract classes are useful in a situation when some general methods should be implemented and specialization behavior should be implemented by subclasses. Interfaces are useful in a situation when all its properties need to be implemented by subclasses

ü  All variables in an Interface are by default – public static final while an abstract class can have instance variables.

ü  An interface is also used in situations when a class needs to extend another class apart from the abstract class. In such situations it’s not possible to have multiple inheritances of classes. An interface on the other hand can be used when it is required to implement one or more interfaces. Abstract class does not support Multiple Inheritance whereas an Interface supports multiple Inheritances.

ü  An Interface can only have public members whereas an abstract class can contain private as well as protected members.

ü  A class implementing an interface must implement all of the methods defined in the interface, while a class extending an abstract class need not implement any of the methods defined in the abstract class.

ü  The problem with an interface is, if you want to add a new feature (method) in its contract, then you MUST implement those methods in all of the classes which implement that interface. However, in the case of an abstract class, the method can be simply implemented in the abstract class and the same can be called by its subclass

ü  Interfaces are slow as it requires extra indirection to find corresponding method in the actual class. Abstract classes are fast

ü  Interfaces are often used to describe the peripheral abilities of a class, and not its central identity,

 E.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.

Note: There is no difference between a fully abstract class (all methods declared as abstract and all fields are public static final) and an interface.

Note: If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they
share is a set of method signatures, then tend towards an interface.

Similarities:
Neither Abstract classes nor Interface can be instantiated.