Edit What is the problem today?
Why do we want SOA in the first place? Well many leading consulting firms has conducted many analysis on what the budget of IT is used fore. All of them agree that in-between 74% - 86% of the time and money goes into maintenance of the current system portfolio. So this means that only 14% - 26% is devoted to new functionality. The analysis also points to the reason for this - Its because the programs are dependent on each other, with program-to-program calls, defined parameter lengths etc. witch means that changing one program have a huge influence on the rest of the system. Not only the function itself, but all the other programs that has to be changed in order for the first one to be deployed (recompile, recursive test etc.).
Problem: The backend applications is not flexible enough because - in essence - the way programs call each other aren't flexible.
Edit Current problem with - programs and methods
Edit Visual components inside the programs
Display files, displaying of error messages, managing colours of fields, and subfile control subroutines have nothing to do with the business logic, its the way we display information not the way we process them . So each time a user wants to see information differently or see more information or change a field behaviour, we need to change a program. And when we change a program, everything have to be tested again, to make sure that no errors sneak into production.
Edit Navigation logic inside. (Fkeys, subfile choices etc.)
When the business changes the workflow, programs have to be changed and tested. (Not logic are changes only the navigation) but all the functionality has to be tested and deployed.
Edit Programs call other programs and parameter in call to programs
This makes them dependent to changes in the call structure. So a change in the call structure requires changes in many other programs and full testing is required again.
Edit Different business functions uses the same program modules
Well this is one of the more controversial subjects, because we have all learned over the last 25 years - that reuse of modules are important. But over the years the modules are mistreated and have les than 80% of the code inside the program in common but the rest is separated by "If company=A then" and "If company=B then" statements, making them complicated to change (the 74%-86%)
Edit Spread functionality
To complete one business function many programs has to be called in the correct order and all have to work perfect and the intercommunication between them are essential, this means that the developer has to have a vast knowledge of the application before they can change it. This have a significant cost in "Learning the system", usually it takes years to master the application, for a new developer.
Edit Conclution
So if we could solve the problems stated above, having simple programs, separated from the visual part, with no "Company A/B hardcoding", with no decencies on other programs and functions, free of navigation and organised into business functions that operate freely, minimal testing and easy deployment - wouldn't that be a fantastic future! - get rid of all the extra coding that have to be done, and all the programs that have to be tested, and all the hassle with deployment, and production errors......
Well SOA is the answer. Next - you will find out how to get to the finish line - quick and easy!
Edit What it's NOT!
Many companies try to sell functionality that sets Webservices in front of the current application. The same and others try to sell products that can "web-enable" green-screen applications. But all of them is missing a key point.
When the problem is in the backend applications lack of flexibility, you can set all the web-services in-front and web-enable all the applications you want - but the problem persists. Your backend application is still not flexible. And you will still use 74% - 86% of the budget to change the backend applications when changes are a required in the the newly created web-services or web-applications.
So it is clearly NOT the solution to add more layers to the application without changing anything.
Edit What is SOA?
First of all SOA means Service Orientated Architecture. This means that you backend application is organised into services that can:
- Stand alone e.g. decupled functions.
- Function without other programs or functions.
- Be changed without influencing other functions.
- Be deployed into production without coordinating with other programs
- Programs can be rearranged to form new functions or adapt to new business requirements, with no or minimal changes.
SOA gives you the flexibility and agility in your backend applications, you need to meet the future demands from the business.
Note!
SOA has many other aspects such as the Business Process Manager (BPM), An Enterprise Service Bus (ESB), Business processes (BP) etc. We will get back to all these later in the explanation and implantation. But for now we look at the simplest way of setting up a SOA environment.
Edit How does it work?
If one program is not supposed to "CALL" another, we need another way of doing this. iSeries2web provides this functionality, through the "Service bus". A simple explanation is that you "ask" the service bus to execute a function, and you don't care how or what is does, as long as the correct program ends up being called!
Edit Classic application model
In this classic model programs call each other in a normal structure, this results in a hard coded structure. Where changes and new functionality requires a lot of maintenance.
Programs call each other with paramaters.
Example 1: If program F is to have another parameter programs A to E has to be changed to transport this variable. No other change has to be done in programs A to E, but in real life they have to be testet. Dependng on the functionality, this takes a long time.
Example 2: If program E has to be changed all the programs in its "call structure" (all the other programs) has to be testet to make sure that the changes has no effect on the other programs. Again this takes a long time.
Edit SOA application model
In the SOA model programs are created as individual SOA modules. These modules (or SOA modules) are in-dependent of other programs. this means that they can be activated (e.g. called) with out parameters (how this is actually done is explained later) these SOA modules are put together to form functions.
This is done by a BP (business process) This "putting things together" is called orchestration. So in this example we orchestrated 3 business processes. BP1, BP2 and BP3. Business processes can activate SOA modules or other business processes.
The individual programs uses XML to communicate with the surrounding environment, but NOT with other programs, as this would mean that they are depending on another program to deliver information, and this is not allowed in a SOA environment.
All this XML and activations has to be controlled by a system…
- This system is iSeries2web.
Edit How to learn more
This is the end of the simple explanation of SOA and why we want these advantages. Next you should proceed to "
Class 1 - Hello World" to se and try the first example of a SOA program...