Khoa Pham
March 16, 2023
Service-oriented architecture (SOA) describes how to make software components interchangeable and reusable by using service interfaces. By employing standardized interfaces and an architectural design, SOA enables quick integration into new applications.
Each service in an SOA contains the data and code necessary to carry out a full, distinct business function. In order to reduce dependencies across applications, the service interfaces offer loose coupling, which allows them to be called with little to no understanding of how the service is implemented. As a result, developers will no longer need to redevelop or duplicate existing functionality or to understand how to connect to or provide interoperability with existing functions.
Despite the current rising trend of SOA and microservices, it is still uncommon for an application to have this architecture from the beginning. Developers typically use monoliths to build MVPs and initial app iterations, then later transition projects to SOA once they gain traction.
When it comes to legacy code issues, SOA is adopted to minimize the cost and difficulty when switching to a new application structure.
However, no one would claim that SOA is superior to monolithic since it presents unique difficulties. For example, it's more difficult to test and orchestrate SOA applications.
Each service within the application only does a small number of activities while hardware infrastructure is utilized to maximize speed.
Each service is created, implemented, and maintained independently by a team with little bearing on the other components of the system.
Each service may be built in the language that is most appropriate for its function, and they all communicate with one another via a common protocol.
SOA services are self-contained code packages, allowing the application of macro-level code reuse. As a result, creating and releasing new features is faster.
Infrastructure may be used more effectively when separate services can be scaled up and down to handle the load that they receive.
Every service's scope and requirements are simpler to define and record since they correspond to specific business activities and objectives.
Since SOA services often transmit and receive a large number of requests every day, in order to ensure service stability, a fast server with large data storage is required.
Every time a service interacts with one another, complete validation of every input parameter takes place. This increases the response time and machine load, and thereby reduces the overall performance.
Implementation of SOA requires a large upfront investment in development, technology, and human resources.
Since the services exchange millions of untraceable messages, service administration is challenging.
Since SOA components are distributed, SOA communication will be inter-service communication. And these inter-service communications are handled by:
While SOAP-based web services are less versatile than RESTful or microservices, they are far more flexible than early SOA implementations. SOAP-based web services consist of protocols such as SOAP, XSD, and WSDL.
A REST API (also known as RESTful API) is an API that conforms to the constraints of REST architectural style and allows interaction with RESTful web services.
Apache Thrift allows us to define data types and service interfaces in a simple definition file. Taking this file as input, the compiler generates code to build RPC clients and servers that communicate seamlessly across programming languages. Instead of having to write a load of boilerplate code to serialize and transport our objects and invoke remote methods, we can get right down to business.
Apache ActiveMQ is an open-source message broker, written in Java with a full Java Message Service client. It provides "Enterprise Features" which means fostering communication from more than one client or server.
The Jakarta Messaging API (formerly Java Message Service or JMS API) is a Java API for message-oriented middleware. It provides generic messaging models to solve the producer–consumer problem by facilitating the sending and receiving of messages between software systems.
The fundamental building blocks of SOA is services. They may be private and accessible solely to an organization's internal users, or public and available to everyone with an internet connection. Each service has three primary characteristics:
The service implementation is the code that constructs the logic for carrying out a particular function, such as user authentication or bill calculation.
The service contract specifies the terms and conditions of the service, including the requirements for use, the price, and the standard of the service rendered.
The interface specifies how to call the service in order to carry out tasks or exchange data. It reduces the reliance on the service requester in relation to the services. For instance, consumers can utilize a service through its interface even if they have little to no knowledge of the logic included in the underlying code.
Service provider develops, manages, and offers one or more services for use by others. Organizations have the option of developing their own services or acquiring them from outside service providers.
The service consumer requests the service provider to run a specific service. It can be an entire system, application, or other services. The service contract specifies the rules that the service provider and consumer must follow when interacting with each other. Service providers and consumers can belong to different departments, organizations, and even industries.
A service registry, or service repository, is a network-accessible directory of available services. It keeps records of service descriptions from service providers. The description documents provide details on the service, including contact information. Using the service register, service users may quickly find the services they require.
Ease of deployment is another major difference between monolithic architecture and SOA. Since the services in SOA are smaller and independent of one another, they are deployed faster and easier than those in a monolithic architecture.
Here is a diagram of how an SOA is deployed.
SOA allows developers to add, remove, or modify any individual component within the system without impacting any other parts, making it ideal for corporate growth and development. Moreover, the concept of SOA has become the central component of modern virtualization and cloud computing in microservices. In the next and final part of the series, let’s take a look at microservices.
