CSC/ECE 517 Fall 2010/ch6 6j SO: Difference between revisions
| Line 4: | Line 4: | ||
SOA (service-oriented architecture) has become a buzzword of late. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems. | SOA (service-oriented architecture) has become a buzzword of late. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems. | ||
== The Problem == | |||
Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction. | |||
Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly. | |||
Revision as of 19:30, 13 November 2010
Service-oriented architecture
Introduction
SOA (service-oriented architecture) has become a buzzword of late. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems.
The Problem
Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction.
Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.