Hi Guys,
It's been a while since I have blogged. Without any shame on my face, I am going to say the same truth, "I was busy". There has been a lot of discussion going on in my team about this buzz word SOA - Service Oriented Architecture and I am here to just share my views on it.
According to me, Service Oriented Architecture is an architectural design pattern which you apply while building your application. There is/has been a lot of commotion around about whether SOA is good or bad but my personal view is that it is really fruitful if used controllably (Yeah, It sounds like One of those primary school debates, I understand - "Science - A boon or a bane to mankind", where the judge gives a diplomatic answer).
Nevertheless, I ll just divulge my views on why it is both a boon and a bane and we can just draw a line as to how to use it effectively. Bringing SOA in the design of your application mainly means that you are conspicuously going to have multiple clients using your services. Only in those cases will I go for an SOA. So when we have multiple clients, we just provide the clients with a particular end point (URL) to hit, with a WSDL associated that specifies the operations we can perform with the end point.
Now how do you design a Service? Can we multiple services in our application with only some of them being exposed, others being private? (or) Should we have only Services, with end points, those which we are going to expose to the client?
My opinion is that since a Service is by definition that which is going to be exposed, to the clients as an end point, there should be no concept called Private Services. It is just an overkill to have services for intra-communication in an application. This is where Services will become a bane if not architected properly. Our application will get bloated up with a lot of end points. Lot of end points means a lot of message exchanges within the system which eventually means a lot of unnecessary network traffic. So we need to draw a line here as to when to create a service and when to just use the interface of one module in another.
One more question about SOA is that should we have centralised or a decentralised data - in the context of a service. For Example, If there is a Customer Service, in the case of centralised data, all data associated with a customer will only be present and accessible by the Customer Service and any other service, if it needs customer data, should contact this service. The problem I perceive here is an one point of failure. If the customer service goes down, the application by itself goes down and is screwed.
Decentralised data, on the other hand means, since a customer data will be used by most of the other services, the customer data will be present as a local copy with all the other services and they do not contact Customer Service for trivial operations(lookup?, update?). The problem here as I perceive is that, as and when the customer data is updated, a message has to be sent to all the services to update their local copy. At any point of time, it is not certain that all the copies of customer data will be in sync.
Now this presents an interesting debate - whether centralised or decentralised data is better. (Obviously the question is only for data that will be used across the application and frequently and not for all the data. For other data, the centralised scheme is the best, because obviously that is OO way). But in this case, my point of view would be to use a decentralised data as my mind, heart and brain weighs that the application itself going down as the primary concern and anything to prevent that would be the ideal solution. But that's just me!! We can argue either ways!!
As such, there are many interesting design issues with SOA and I seriously find it captivating. If you are really interested in knowing more about what I discussed here, and you want to feel the heat, visit http://bill-poole.blogspot.com/. This is one awesome blog about SOA and for discussions. Most of the things in this post of mine are excerpts from that and from our team discussions.
OK chalo, till I get another heated discussion in our team on some other interesting topic, Adieu!!
It's been a while since I have blogged. Without any shame on my face, I am going to say the same truth, "I was busy". There has been a lot of discussion going on in my team about this buzz word SOA - Service Oriented Architecture and I am here to just share my views on it.
According to me, Service Oriented Architecture is an architectural design pattern which you apply while building your application. There is/has been a lot of commotion around about whether SOA is good or bad but my personal view is that it is really fruitful if used controllably (Yeah, It sounds like One of those primary school debates, I understand - "Science - A boon or a bane to mankind", where the judge gives a diplomatic answer).
Nevertheless, I ll just divulge my views on why it is both a boon and a bane and we can just draw a line as to how to use it effectively. Bringing SOA in the design of your application mainly means that you are conspicuously going to have multiple clients using your services. Only in those cases will I go for an SOA. So when we have multiple clients, we just provide the clients with a particular end point (URL) to hit, with a WSDL associated that specifies the operations we can perform with the end point.
Now how do you design a Service? Can we multiple services in our application with only some of them being exposed, others being private? (or) Should we have only Services, with end points, those which we are going to expose to the client?
My opinion is that since a Service is by definition that which is going to be exposed, to the clients as an end point, there should be no concept called Private Services. It is just an overkill to have services for intra-communication in an application. This is where Services will become a bane if not architected properly. Our application will get bloated up with a lot of end points. Lot of end points means a lot of message exchanges within the system which eventually means a lot of unnecessary network traffic. So we need to draw a line here as to when to create a service and when to just use the interface of one module in another.
One more question about SOA is that should we have centralised or a decentralised data - in the context of a service. For Example, If there is a Customer Service, in the case of centralised data, all data associated with a customer will only be present and accessible by the Customer Service and any other service, if it needs customer data, should contact this service. The problem I perceive here is an one point of failure. If the customer service goes down, the application by itself goes down and is screwed.
Decentralised data, on the other hand means, since a customer data will be used by most of the other services, the customer data will be present as a local copy with all the other services and they do not contact Customer Service for trivial operations(lookup?, update?). The problem here as I perceive is that, as and when the customer data is updated, a message has to be sent to all the services to update their local copy. At any point of time, it is not certain that all the copies of customer data will be in sync.
Now this presents an interesting debate - whether centralised or decentralised data is better. (Obviously the question is only for data that will be used across the application and frequently and not for all the data. For other data, the centralised scheme is the best, because obviously that is OO way). But in this case, my point of view would be to use a decentralised data as my mind, heart and brain weighs that the application itself going down as the primary concern and anything to prevent that would be the ideal solution. But that's just me!! We can argue either ways!!
As such, there are many interesting design issues with SOA and I seriously find it captivating. If you are really interested in knowing more about what I discussed here, and you want to feel the heat, visit http://bill-poole.blogspot.com/. This is one awesome blog about SOA and for discussions. Most of the things in this post of mine are excerpts from that and from our team discussions.
OK chalo, till I get another heated discussion in our team on some other interesting topic, Adieu!!
