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 :)
This is our main application of Erlang: web services. We normally use Yaws Appmods and an article here can show you a lot on how its done. Erlang has been a good platform for SOA, because of the following:
1. Side Effect free code is very easilly written and tested.
2. Isolation: Processes in Erlang help isolate each service request in a clean way.
3. Most Erlang Libraries like mochiweb, misultin and Chicago Boss have been built from ground-up to support SOA systems written in Erlang.
Its a great idea to apply your own OTP application behind any one of these frameworks. Another great reason why erlang is suitable for SOA is redundancy. SOA systems need to be up. If a service request fails, its re-tried along a different path (which, of course at physical layer, its being handled by a different machine where you OTP app has been distributed).
Give it a shot, great idea
SOA can be applied to many implementation technologies, not just SOAPy Web Services, and I've found it always has be beneficial. For instance, you can model your database views and stored procedures as services. You can model your java APIs are services. etc.
Now, getting to your actual questions:
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?
No. Everyone is moving away from SOAP and towards REST; however building a software application with the Service Oriented Architecture approach by using OTP webservers (Mochiweb) as RESTful Services might be good idea.
Can the additional XML processing layer destroy all the advantages of such approach?
It depends what your objective is. If you are just adding an XML layer because you think it's "The Right Thing to Do™", then you will always have problems with the XML layer because it will be a solution looking for a problem to solve. If your objective is to decouple the server implementation technology from the client implementation, by creating commonly understood representations for your entities, then the additional XML (or JSON or whatever is most suitable) processing layer is worth it.
来源：https://stackoverflow.com/questions/11173252/soa-why-do-not-use-erlang-otp-web-servers-as-services