There are many ways of implementing SOA, now latest buzz word for example is micro services. Many are using some sort of enterprise bus, some says that REST is the way of implementing SOA. Problem is that neither is enough for being even capable of being SOA. It's because they are only dealing with protocols, and protocols are never services and when talking about services the means by reaching it, even REST(whatever flavor) cannot act or even be a service. Even some notation of not using services, whatever that might be, like just wrapping data to JSON, is begging for trouble.
If your goal is to write a sustainable, maintainable and flexible system it will never be about what protocols you are using. It will never be about which application server you are using, or if you are using micro services and particularly never if you are using an enterprise bus, or using some sort event driven distribution. It will and will always be about when you are doing transformations.
Now for example you are using a enterprise service bus with an application server you have failed to being even remotely close to deliver a SOA system. This is because you are not keeping track of your transformations, and fundamentally spread your functionality over several abstraction layers, just by using an ESB. Are you trying to aggregate other services with an ESB you are still creating stronger coupling by just using it because you are not adhering to those interfaces which are defined by either service/resource.
You have just begun your journey to a incredibly much more expensive development, much more entangled system and not creating a flexible system. Everything else is just sales talk. The only way of creating a flexible system is by WRITING it in a way so it won't entangle into a big ball of mud. No external system will or cannot fix anything just by adding it as some additional layer. It will look perfectly good in the simplest cases, particular in a PoC, but in all scenarios and over time you will end up with a more complex solution which will create a less flexible solution as you would without it. If you are using a product for "managing" your API's (WSDL's) or anything which describes your service, you are by just doing this, creating a non-flexible system, because you are not using your abstractions correctly. Using an ESB for anything else than translating a protocol to another protocol is abusing your abstractions and cause your system to turn into a ball of mud over time.
So why is it important to keep track of your transformations? We'll this is because this is where you are providing the interface for your data. But when doing this you must transform your functionality as well if you are going to use your abstractions correctly. Whenever you are transforming data 1:1 and there are some notion of functionality present, directly or indirectly, you are abusing your abstractions and creating a worse system. Which is ALWAYS the case when using an ESB with an application server, other than when transforming from one protocol to another (and that's only because you have no other choice because the application server doesn't understand the protocol).
I don't know when it became some sort of standard when protocols became services. Protocols to me is how you talk to a service, by such means, you could talk about decoupling, ie you have decoupled how you would talk to the service. But a protocol cannot decouple the service from the client since the protocol is not the service, thus the contextual meaning of whatever data you receives from the service cannot be decoupled. The only thing you can decouple from the client is theimplementation of the service. But that will not be done simply by putting a WSDL infront of the service. This also applies to REST, since this is just a protocol a swell, a means of how to reach your resources whatever they be. However the service still needs to define what the resource means. And that will never be done by the protocol.
No comments:
Post a Comment