The objective of this discussion is to introduce SOA, to provide a view of how software can be integrated and developed in such manner to allow software solutions to be interconnected, the problems of this approach, suggestion of solutions and at the end a conclusion.
SOA – THE SERVICE ORIENTED ARCHITECTURE
The SOA – Service Oriented Architecture was born based on the need of the legacy software systems to get interconnected. You can imagine a bunch of many systems developed during many years in different locations inside a company, what leads to a high granular reality in the company software space (and you should consider all that applications built in many different languages and technologies) (Abrams, 2008).
SOA is based on low coupled services, which can be written in different technologies or programming languages, what makes the integration between solutions in an interoperable reality (Kodali, 2005).
PROBLEMS THAT MAY ARISE DURING INTEGRATION
In the list below, it is enumerated some of the common problems on the attempts on integration with SOA.
#1 DIFFERENT DOMAINS: Based on my experience, most systems do not capture the reality of the business equally, so for one system a client can be designed simply as a client but for another system it was designed as a company. Different languages in SOA leads to the use of the Enterprise Service Bus translators.
#2 SECURITY CONCERNS: While there are OASIS standards to implement security with SOA Webservices (Oasis, 2005), the need of transmitting data may lead to security interception of data or even a man-in-the-middle attack, something can compromise the whole company and data.
#3 DESIGN FOR PERFORMANCE: A bunch of XML traffic would not have its better performance while working with SOAP standards.
SUGGESTIONS TO DEAL WITH SUCH PROBLEMS
#1 DIFFERENT DOMAINS: Different languages in SOA leads to the use of the Enterprise Service Bus translators, it may have the mapping of from-to, which will allow the integration to be done, however when designing new solutions, I would suggest using common libraries with common domain classes, which represents the whole company domain and to be shared on the company projects.
#2 SECURITY CONCERNS: The use of HTTPS joined together with WS-security (Oasis, 2005), would allow more security to the system and securing the man-in-the-middle attacks.
#3 DESIGN FOR PERFORMANCE: A REST approach would best fit for solutions which needs more performance with the use of resources of the HTTP protocol (Roy, 2000). The use of Java Script Object Notation (JSON) as a protocol would allow the use of less network traffic.
The use of the Service Oriented Architecture design pattern allows system integration, in a world which connection is a key concern, removing all that spreadsheet and importation integration used in the past.
SOA became a standard in the market for years, now a new design pattern is emerging to solve most of the problems SOA had in the past, which is called the microservices architectural design pattern.
Charles Abrams, R. W. S., 2008. Service-Oriented Architecture Overview and Guide to SOA Research, [Electronic Article] USA: Gartner. Available at: <http://download.microsoft.com/documents/australia/soa/gartner.pdf> [Accessed 16 July 2017].
Kodali, R. R., 2005. What is service-oriented architecture?. [Online] Available at: <http://www.javaworld.com/article/2071889/soa/what-is-service-oriented-architecture.html> [Accessed 16 July 2017].
OASIS, 2005. Web Services Security UsernameToken Profile 1.1. [Online] Available at: <https://www.oasis-opena.org/committees/download.php/13392/wss-v1.1-spec-pr-UsernameTokenProfile-01.htm> [Accessed 16 July 2017].
Thomas Fielding, Roy, 2000. Architectural Styles and the Design of Network-based Software Architectures. Doctor. California: UC Irvine.