So In our last post I promised that we will talk about how to make monolithic code into distributed SOA architecture.
Well its not easy. Once you have decided that you want to re-architect the single chunk of software in distributed manner you have to decide about different parts of the system which can be deployed on different machines and still everything will work fine.
There are many problems while doing so.
- How will you host these services (S in SOA).
- How will you communicate and how serialisation/deserialisation will happen?
- How do you make sure that you are able to implement the same workflow which you had in single monolithic component assuming you were doing things sequentially.
To answer the first question there are many options available but I will list down some which I have personal experience with.
- Design your services as RESTful and deploy them in you preferred container like weblogic.
- Pros
- Location transparency. You refer to the services using URI.
- Interacting with RESTful service is pretty easy in any language.
- Cons
- Serious overhead of HTTP protocol.
- Serious maintenance issues with container management not to mention huge performance hit.
- Pros
- Design your services as Java processes and interact with them using a service bus like JMS (ActiveMQ, Fiorano etc.).
- Design your services as Thrift based and interact with them by passing pre-generated client code.
- Pros
- Serialization/Deserialization take care by thrift. You just interact with POJOs everywhere.
- Lightweight highly scalable proven architecture (Facebook?). Forget about converting from Json to POJO and vice-versa.
- Cons
- Every time service or schema is changed you need to redistribute client code.
- Schema definition in thrift file has some limitations of its own.
- Pros
- Design your services as separate Java Processes and have a networking library like ZeroMQ take care of communication.
- Pros
- ZeroMQ is battle tested and used in many mission critical projects. Takes care of networking needs.
- Cons
- Low level programming is needed compared to other approaches.
- Many scenarios will have to be handled even with this approach so code size will swell up.
- Pros
For long time I had been dealign with Hub and Spoke Model by using a ServiceBus like MSMQ, ActiveMQ.
ServiceBus is a popular approach especially in financial institutions who invest in enterprise grade product like TIBCO MQ.
Problem with service bus approach is that you have to write code specific to Messaging Bus. So another layer is added which increases complexity.
So for some time I had been tracking if there is a way to remove this layer. Given my experience in Industry there are some areas I believe a company should not invest until absolutely necessary and one such area is networking.
Having said that one day while learning Scala I came across a project called Akka. Akka is a framework which addresses many problems with simple concept of Actors.
Networking and Concurrency provide easy way to program local or distributed services. What you get is complete location transparency as you communicate with remote actors in same way as you communicate with local actors.
There is no hub and spoke model so no new software has to be installed/maintained or written specific code to make things work.
It’s P2P…networking complexities are hidden deep inside and you never have to deal with thread. WOW !! Sounds too good to be true.
Completely asynchronous with a programming paradigm that is easy to understand and concept of actors is already proven in telecom industry.
In the next post we will talk about some sample code for how location transparency can be achieved.
