Service-Oriented Architecture Definition
Service-Oriented Architecture (SOA) is a software design/software development model for application components that incorporates discovery, control, security and more over a network.
What is Service-Oriented Architecture?
Service-oriented architecture (SOA) is a software architecture style that supports and distributes application components that incorporates discovery, data mapping, security and more. Service oriented architecture has two main functions:
1) Create a architectural model that defines goals of applications and methods that will help achieve those goals.
2) Define implementations specifications linked through WSDL (Web Services Description Language) and SOAP (Simple Object Access Protocol) specifications.
Service-oriented architecture principles are made up of nine main elements:
1. Standardized Service Contract where services are defined making it easier for client applications to understand the purpose of the service.
2. Loose Coupling is a way to interconnecting components within the system or network so that the components can depend on one another to the least extent acceptable. When a service functionality or setting changes there is no downtime or breakage of the application running.
3. Service Abstraction hides the logic behind what the application is doing. It only relays to the client application what it is doing, not how it executes the action.
4. Service Reusability divides the services with the intent of reusing as much as possible to avoid spending resources on building the same code and configurations.
5. Service Autonomy ensures the logic of a task or a request is completed within the code.
6. Service Statelessness whereby services do not withhold information from one state to another in the client application.
7. Service Discoverability allows services to be discovered via a service registry.
8. Service Composability breaks down larger problems into smaller elements, segmenting the service into modules, making it more manageable.
9. Service Interoperability governs the use of standards (e.g. XML) to ensure larger usability and compatibility.
How Does Service-Oriented Architecture Work?
A service-oriented architecture (SOA) works as an components provider of application services to other components over a network. Service-oriented architecture makes it easier for software components to work with each other over multiple networks.
Service-oriented architecture is implemented with web services (based on WSDL and SOAP), to be more accessible over standard internet protocols that are on independent platforms and programming languages.
Service-oriented architecture has 3 major objectives all of which focus on parts of the application cycle:
1) Structure process and software components as services – making it easier for software developers to create applications in a consistent way.
2) Provide a way to publish available services (functionality and input/output requirements) – allowing developers to easily incorporate them into applications.
3) Control the usage of these services for security purposes – mainly around the components within the architecture, and securing the connections between those components.
Microservices architecture software is largely an updated implementation of service-oriented architecture (SOA). The software components are created as services to be used via APIs ensuring security and best practices, just as in traditional service-oriented architectures.
Benefits of Service-Oriented Architecture?
The main benefits of service-oriented architecture solutions are:
• Extensibility – easily able to expand or add to it.
• Reusability – opportunity to reuse multi-purpose logic.
• Maintainability – the ability to keep it up to date without having to remake and build the architecture again with the same configurations.
What is Service-Oriented Architecture Testing?
Service oriented architecture has a testing phase so that the end is satisfied in terms of the quality of the product. Service oriented architecture testing is not limited to layers and web service, it is the overall testing of the whole architecture. The testing process is within three layers in architecture: Service Consumers, Process Layers, and Service layers. Testing can be divided into four different tiers:
• Tier 1 – Includes service level testing, functional testing, security testing, performance testing. In service level testing it is important to do this first, it tests individual services based on request and response. Functional testing is conducted for services on their business needs to find if the response they receive is correct, business needs are turned into test cases and then requests are formed, the formats of the response scenarios positive and negative have to be executed. Security testing plays a big role in the testing process, authentication of gateways, should be encrypted when the data deciphered, and then the verification of vulnerabilities when it comes to XML; CSRF and SQL injection.
• Tier 2 – Process Testing process involves testing multiple business processes, comprising the integration scenarios and applications covering business requirements. Using stimulators you can generate sample input data and validation for respective outputs. In this process you also test the data flow from different layers to show a smooth functioning when it is integrated.
• Tier 3 – End to End Testing is to validate business requirements functional and non functional, also validating UI of the application, end to end data flow, and all the services integration.
• Tier 4 – Regression Testing is testing the system’s stability, and archiving by manual testing or automated testing.
Does Avi Offer A Service-Oriented Architecture?
No, Avi delivers multi-cloud application services such as load balancing for containerized applications with microservices architecture through dynamic service discovery, application maps, and micro-segmentation. Avi integrates with OpenShift and Kubernetes for container orchestration and security.
Containerized applications based on microservices architecture require a modern, distributed application services platform to deliver an ingress gateway. Manual inputs are no longer an option for web-scale, cloud-native applications deployed using container technology as microservices. In some instances, container clusters can have tens and hundreds of pods, each containing hundreds and thousands of containers, mandating full automation and policy driven deployments.
For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.
For more information on Service-Oriented Architecture see the following resources: