After reading the Service Oriented Architecture Principles site and the respective Wikipedia article I had a thought: the Erlang/OTP platform can be considered as an SOA platform and SOA applications can be built on it.
The only thing is that the Service Contract for each service in such a system is very specific: in order to call a service in Erlang/OTP the Orchestrating layer would have to make calls via Erlang messages or calls to gen_server (depends on the implementation).
This would not let making any calls to the services outside of Erlang/OTP platform scope.
But what if we try to build each Service by moving all the respective Service functionality into an Erlang-based webserver, like Mochiweb and essentially changing the interface of each Service from gen_server:call to XML?
This will allow to compose various applications from standardized ‘bricks’ with universal Service Contracts based on WSDL.
Moreover, this approach will let us continue using OTP supervisors and other OTP features, because such a Service will still be an OTP application.
So, the question is:
Do you think that building a software application with the Service Oriented Architecture approach by using OTP webservers (Mochiweb) as Services is a good idea? Can the additional XML processing layer destroy all the advantages of such approach?
The primary reason this is not done is because you would limit yourself to the protocol of SOA. Erlang implements the protocol of IP with some added points (monitors). While you can do it, I wonder if it would be worth it.
In principle, Erlang already has all the tooling for the idea of SOA but without all the bloat of SOAP and WSDL 🙂