Service Oriented Architecture

What is SOA?

Service Oriented Architecture (SOA) is a software design and architecture pattern that defines how different services communicate with each other in a distributed system. A distributed system is a collection of autonomous computers connected to a network, which work together as a single system to perform a task or a set of tasks. Each service in the system has its own memory, CPU, and other resources, and communicates with other services by exchanging messages over the network. Distributed systems are used to solve complex problems that require more processing power, storage, or bandwidth than a single computer can provide. They are also used for providing high availability, fault tolerance, and scalability for applications and services.

Visualize service as "containerized app" in Kubernetes

If you are not familiar with kubernetes, you can consider service as ECS in AWS data centers. ref Pod in Kubernetes

In SOA, applications are broken down into independent and modular services, which can be combined together to create complex IT systems. These services are typically accessed through well-defined application interfaces (API), making it easier to integrate applications from different vendors or upgrade individual components of a system without disrupting the entire application. Additionally, SOA allows for greater flexibility and scalability in enterprise systems, as services can be reused and easily modified to meet changing business needs.

Why do we need a service?

In SOA, services are the building blocks of an application or system. They are independent units of functionality that can communicate with each other to perform a specific task. Services are designed to be self-contained, modular and reusable components that can be easily modified or replaced without affecting the other components in the system.

The main reason for using services in SOA is to achieve better scalability, flexibility, and reusability in software development. By breaking down a large application into smaller services, each service can be developed and maintained independently. This allows developers to make changes or updates to a particular service without having to modify the entire application. As a result, services enable faster development cycles, reduced development costs, and increased agility in responding to changing business needs.

How to describe a service?

In Service Oriented Architecture (SOA), there are various ways to describe a service through different ways. Each way can help developers understand different aspects of a service and define it based on specific requirements.

Service::Operation

To describe a service in the context of Service Oriented Architecture (SOA), you can use Web Services Description Language (WSDL). WSDL is an XML language that provides information on how to access a web service and what operations it supports. It defines various components, such as the types of data used, messages exchanged between the client and server, and the location where the actual service can be found.

smithy.io is an interface definition language and set of tools that allows developers to build clients and servers in multiple languages. Smithy models define a service as a collection of resources, operations, and shapes. A Smithy model enables API providers to generate clients and servers in various programming languages, API documentation, test automation, and example code.

In this example, we define a WSDL file for a service called myService with a single operation called myOperation. The WSDL code defines the input and output messages for the operation, the types used in the messages, and how the service is bound to a specific transport protocol (SOAP over HTTP). The location attribute in the soap:address element specifies the endpoint URL for the service.

<definitions 
    xmlns="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
    targetNamespace="http://example.com/myService">
  <types>
    <xs:schema targetNamespace="http://example.com/myData">
      <xs:element name="myRequest" type="xs:string"/>
      <xs:element name="myResponse" type="xs:string"/>
    </xs:schema>
  </types>
  <message name="myOperationRequest">
    <part name="request" element="tns:myRequest"/>
  </message>
  <message name="myOperationResponse">
    <part name="response" element="tns:myResponse"/>
  </message>
  <portType name="myPortType">
    <operation name="myOperation">
      <input message="tns:myOperationRequest"/>
      <output message="tns:myOperationResponse"/>
    </operation>
  </portType>
  <binding name="myBinding" type="tns:myPortType">
    <soap:binding style="document" 
        transport="http://schemas.xmlsoap.org/soap/http" />
    <operation name="myOperation">
      <soap:operation soapAction="myAction" />
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
  <service name="myService">
    <port name="myPort" binding="tns:myBinding">
      <soap:address location="http://example.com/myService"/>
    </port>
  </service>
</definitions>

Flowcharts

Flowcharts represent a control flow of a process. A flowchart is an ideal way to address the complex logic of multiple components of services and multiple interactions between the components.

image source

Cloud Architecture diagrams

Cloud architecture diagrams make it easier to understand the process of architecting, building, and running applications within the cloud. Your cloud architecture is the backbone of your network so it should be carefully and thoughtfully designed.

image source

Sequence Diagrams

Sequence Diagrams are a great way to visualize interaction between objects and functions. In SOA, sequence diagrams can capture the protocols that should be followed while making requests to the service.

image source

State Machine Diagrams

State machine diagrams showcase the behavior of objects with respect to state changes. They can be used to define how states of objects and retrievals of different data records flows in a service.

image source

Entity Relationship Diagrams

ER diagrams depict the relationship between entities and attributes within a database schema. They can be used to represent the data structures that services require for input or output.

image source

https://amazon-dynamodb-labs.workshop.aws/game-player-data.html

UML Class Diagrams

These diagrams show the structure and relationships between objects/classes in a system. In SOA, class diagrams can be used to model the structure of a service, its operations, and their inputs/outputs.

image source

How to test a service?

Testing is a critical part of building a Service-Oriented Architecture system. Implementing all types of testing can be time-consuming and expensive, so a company will likely choose the types of testing based on the requirements and the criticality of the service.

Unit Testing: Unit tests are used to test individual modules or functions in your service code. In a SOA environment, unit tests ensure that these modules are functioning correctly and providing the intended responses.
Integration Testing: Integration tests put together various parts of the system and verify that they behave correctly together as a group. Integration testing of a service may include testing with other services it interacts with.
- Smoke Testing: Smoke testing, also known as sanity testing, is a preliminary testing process to check whether the most crucial functionalities of the software work. It verifies that the critical components of the system are working fine, and a full-scale testing can proceed. In a SOA system, smoke testing can ensure that basic service functionalities are operational before more comprehensive testing is conducted.
Load Testing: Load testing involves testing the services to see how they cope under high volumes of usage or transactions. This kind of testing helps identify performance bottlenecks and potential issues.
End-to-End Testing: End-to-End testing checks that multiple services work seamlessly together to complete an end-to-end process. This type of testing typically starts from the user interface and covers all the services that are utilized into completing a specific function.
Security Testing: Security testing verifies the security of services by simulating unauthorized access and vulnerabilities in the design and implementation.