Introducing SOA: What is Service-Oriented Architecture?
Introducing SOA: What is Service-Oriented Architecture?
Learn all about Service-Oriented Architecture (SOA), and see a run down of how SOA has evolved over the years.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
Some people get scared when they hear SOA (Service-Oriented Architecture) and they assume that it’s a very complex thing and they don’t want to get into it. Actually, SOA is a very easy to understand but it’s a little bit harder to implement.
We’re going to take a look at SOA and its related stuff. This topic has been divided into four main parts. First, the architecture in general and its relation with SOA. Second, the code development and how to create applications that fit in SOA model. Third, the SOA related technology like: Web service, WSDL, ESB,.. etc. Finally we're going to talk about the business benefits of SOA and how business should looking and adopting this technology for their enterprise applications.
We first discuss what is meant by the letter ‘A’ (Architecture) and how this has been evolved in the past years. What is the architecture?
Architecture: 1960s - 1970s
Let’s go back to the 60's & 70's as the main architecture was precisely talking about how to lay out the application. In that period things were pretty easy and there was only one type of architecture out there as depicted in the below diagram:
This architecture consists of two parts: The Main frame and the Dump terminal. Users can access the main frame through the dump terminal. Actually, the dump terminal called “dump” as it doesn't do any processing itself, just receiving request from the application when the user interact with it. Then it send the information to the main frame which does all the processing needed and send back the information to the dump terminal. So, as mentioned there is nothing really happened in the dump terminal.
Pros & Cons :
Let’s talk a little bit about the pros and cos of this model. The pros here that this model is relatively easy. When you’re creating an application you know where they are going to live and you know the environment that you’re going to deploy your application. Also, you know how you can access it (via the Dumb Terminal). The cons of this model are basically in the scalability level. Scalability refers to the fact that how the application is going to handle: more users come on board and when more application functionality developed. The Main Frame here is really doing everything. So, we don’t have a lot of scalability here. Main Frame is going to hold the data, business logic and any type pf presentation logic.
By moving to the 80's we can see what happened to such model and the modifications which have been applied to make it more adaptable to the new changes and scales. We started seeing a lot of users use PCs to access information. So, we still have the Main Frame here., but a lot of work that main frame was doing could now off loaded to the PCs. Stuff like the presentation logic has been moved to the PCs. So, if we had to draw a graph or looking for a data in different ways, the PC can handle all of this stuff. The Main Frame could be just isolated to hold the data. We could also distribute the business logic and stuff like validations to the PCs.
As a result, we can see now, instead of having the Dump Terminal which does nothing and every time it should go to the main frame, now the PCs could handle most of these processing. So, here the main frame could act as the data server. Actually not all business logic exist in the PCs, we still have business logic live in the main frame. This model called Client/Server model. The server here is the Main Frame and the client is the PCs as depicted in the below diagram:
The pros here could be the scalability level which has improved significantly. The PCs now can do more tasks, so it’s easier to add more users and more business logic. The most important con here is the maintenance. Actually it’s the biggest problem in this level; let’s say we have 5000 users who are running some applications, when it comes the time to update the application, whether we do bug fix, handling more functionality inside the application, we've to go to the 5000 PCs and update their application on all of these different PCs. It’s really hassle to do such process frequently. Another problem we had that all PCs had different configurations, if you work in a large organization, you might have users running windows 95, windows 98, windows 98 SE, windows 2000, windows 2000 SP1, windows XP, windows XP SP1, windows XP SP2, .. etc. Getting all of those PCs to work with whether the application you are working in could be a real challenge and you know this will be a real nightmare for a lot of organization.
Architecture: 1990 - 2005
In the late of 90's and the early of 00's we had what became known as 3-tier Architecture, we can substitute the ‘3’ with N because we might have a whole bunch of tiers. What are the main 3 tiers here? We’ve the main Server that holds that probably hold the data base and the most important business logic, then we have an Application Server in the middle and the client (usually PCs running a browser). Do we have scalability? Absolutely we have a great scale of scalability as we can add more application server at this level, we might cluster some of them or we can have a load balancer to handle all different PCs that going to access information from server. The below diagram shows the connectivity between model parts:
Let’s go to the maintenance which is the biggest problem in Client/Server architecture. Instead of going to the whole bunch of PCs and updating the application, we just update it in one side, we update the Application Server. So, when we want to roll out some functionality or bug fix, we just roll out to the Application Server, the PCs access the application server and get the new application, the Application Server interacts with the Data Server and do the appropriate business logic. As a result scalability and maintenance are the most important pros of this model. As we can see here, the model had been refined but actually it had high level of complexity. We’re looking to a true distributed system here and it’s hard to figure out in a lot of cases in these large applications where does the code live. So, if we have some validation code, does it live in JSP (Browser in PCs)? Is the validation going on the application server? Is the validation going on the data base level of the server or in the business logic? Although we have really true scalability and eliminated a lot of the maintenance issues, but this getting real complex in terms of how we construct our application or in other word how we are going to architect all of these systems together.
Architecture: Late 2000s
In the late 00's we've this concept of SOA. We've seen how was complexity of the distributed applications of the 3-tier model. We’re going to isolate each one of those individual pieces in the 3-tier architecture as the below diagram:
Now, we’ve a really complex application like ERP we’ve stuff like Oracle E-Business suites R12 and SAP. These applications have: Account Receivable (AR), Account Payable (AP), General Ledger (GL), Purchase Order (PO), Inventory Management (IM), Credit Check, .. etc. What if we can isolate these pieces and called them Web Service. The Web Service is like a black box that can be accessed to provide a specific functionality within the system. So, here we have a Web Service for AR, AP, GL, PO, IM and credit check.
Let’s say that we’re going to develop a Web Service for credit check. Credit check actually does what it sounds like, may put some vendors information in it, how much money we want to give them credit for and doing some analysis of how they paid their bills, .. etc. We’ve now another level of flexibility, a flexibility to isolate and understand the functionality of each single Web Service. We can use this web service across all of our different application inside our organization. We can also re-use the code of the Web Service over and over.
As a result of SOA, it’s a kind of evolution we’ve evolved to isolate a really large applications and isolating individual pieces of these applications which could be exposed as a Web Service.
In the next part, we will take a look of some of the other things that go along with SOA.
Hopefully, we give you a better understanding of why SOA is so important in today’s development world.
Published at DZone with permission of Bassam Abou-Zaid . See the original article here.
Opinions expressed by DZone contributors are their own.