What is SOA?
SOA or service oriented architecture is a style of programming, an architectural approach in software development, where an application is organized in functional units of code with a given behavior called services.
Services are a group of methods that share a common set of requirements and functional goals. They are called by other parts that need to execute its logic, depending on the outcome (such as data, results of calculations, and so on). The functions have a clearly defined and public signature which is published so other code (service clients) can use the functions in the service as a black box. The service operations are invisible — there is no direct interaction with a user and the work is executed as instructed by the given input parameters. SOA allows distributed applications to be organized. This means that the service consumers are running on different machines than the services. This allows the business logic and run user interfaces to be centralized or other consumers to be decentralized across the network. To make this happen in SOA, structured messages are sent between machines containing data.
The main idea behind SOA is to create a loosely coupled system where the only element a consumer of a service and the implementation of the services have in common is the list of public service operations and the definition of the structures of the parameters.
The client only knows the signatures describing the name, names and types of input parameters, and return type of the functions of the service. There’s no other dependency. The application platform and programming language can be different on both client and service.
It’s clear that this dependency is a functional one and is not based on technical infrastructure. This makes it possible to interact easily from different platforms with a service. A technical cornerstone in the SOA paradigm is the use of the SOAP standard. SOAP is the XML language that defines the content of messages sent to and received by a service operation.
Messages are formed out of the value of the parameters or return values and the data is formatted by SOAP. Every development platform has a SOAP stack, so working with service is supported in many environments. Supporting multiple environments is the goal of working in a SOA style.
This approach makes it possible to create systems that are built out of services. The services make up the building blocks for the application which can be composed out of the service operations. Either an end user application or another service can make use of these building blocks. SOA makes it possible to define a workflow of a business process in which they make calls to service operations.
Implementing an application in this architecture is the way to make code and the functional behavior of it reusable for unknown uses in the future. As the business logic is not coupled to some kind of user interface technology, it’s possible to access these functions from clients that use newer technologies for creating user interfaces.
Separation of concerns is also an advantage. When structuring a development team for a project, different sub teams or individual members can be assigned to both sides of the service boundaries.
One team concentrates on building only the user interaction experience without concern about the code dealing with the business logic and data access. The UI team receives the service interface and can start coding against this interface. Meanwhile, another team works out the implementation of the defi ned service interface without the need to build a user interface. This means a developer is no longer responsible for the code end – to – end, including user interface, business logic, and data access for a given requirement. This results in assigning developers which can focus their knowledge of technology for one layer of the complete application.
Separation of concerns also means that the development of UI and services can be started at the same time directly after the publication of the agreed service interfaces. This is a huge advantage that allows the creation of the UI to be outsourced and keeps the creation of the real business logic in – house.
SOA is a way to build distributed systems where autonomous logic is called using loosely coupled messages via a well – defi ned interface.
Having a stable defi nition of a service interface is absolutely needed. The advantages of SOA are only present when the service contract is agreed on by multiple parties and is not subjected to changes during development. It ’ s the business, defi ning the requirements, that has to have a clear view of the needed functionality. This is done in combination with a functional architect that defi nes the interface on a technical level. Of course this is not always easy or even possible as business requirements tend to change a lot in most environments. To solve this contradiction, it ’ s wise to have an iterative development process that typically lasts 1 to 4 weeks. The service interface is not changed and the modifi cations to the interface are clearly discussed and reported to the development teams at every new iteration.
As application and software systems get bigger and more complex, a strict development architecture is needed that supports a great maintainability with a reusability of components. In the more distributed environments we see today — with applications implemented on different platforms — the need for a simple development approach that supports interconnectivity is a big value.
Implementing a SOA architecture is needed to solve problems that object orientation alone cannot solve for very large systems with integration between multiple parts. Integration of existing components needs a well – thought – out and industry – wide paradigm in the form of SOA.
Four Tenets of SOA
To have a good and deeper defi nition of SOA, some principles need to be described in more detail. Tenets in the software industry are the way to do this. In SOA, the four tenets of service orientation are discussed.
These tenets include the following:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is based on policy
Boundaries Are Explicit
When working in a SOA approach, the boundaries a consumer needs to cross to reach the implementation should be defi ned explicitly. Services run in a process and memory space separated from the clients using them. Up – front thinking is needed to defi ne the boundaries and should be communicated to each possible participant. The boundaries are defi ned by means of the contract and the address where a service can be reached. This information should be considered important and be easily accessed.
It is impossible to execute the logic in a service without having a contract and address. The logic is allowed to execute only in one way. This is by calling the contract, which is considered as the boundary. Boundaries are explicit, which means the client only needs to be aware of the existence of functions in the service that can only be executed via the contract This tenet also means that all possible exceptions must be described and a method can only stop executing by either giving the needed answer as an explicitly known data structure or as a structure containing the details of the exception. No data enters the service operation and no data leaves the service operation without a clear allowance to do so.
Services Are Autonomous
Services are considered standalone pieces of code that do not rely on the behavior of other services. Services are considered available without the need to explicitly instantiate it. They should be deployed and versioned independently from each other, and installing a new version of a service should not influence the behavior of other service operations. Services should not be coupled to each other as classes are coupled in a compiled executable. Services should instead use a loosely coupled architecture.
Services Share Schema and Contract, Not Class
A schema is the defi nition of a service operation and describes the signature in a platform – neutral way: the name of the functions, types of parameters, and the type of return value. A contract is considered metadata for the service being a black box with only this well – described interface. Schemas are the defi nition of the structure of the parameters. This tenet clearly indicates that the class itself (in code or as UML notation) is not shared across services and their clients.
As SOA is aimed at cross – platform interaction between different parts, it is not useful to bring the code for a class to other parties. In a lot of cases that code is meaningless. The inner workings (behavior of the code) of the class are not relevant to the consumer. The application (or other service) that uses a service is only interested in the outcome of the service operation. Clients send messages to part of the schema operations that conform to this contract to obtain this outcome.
Clients should interact with a service and back through an explicitly defined public interface including faults. Each version of a service should have one version of the interface. After an interface is in production it should not change, as changing the interface would be the result of modifications in the behavior of some service operations and should result in a new version of the interface.
Service Compatibility Is Based On Policy
This tenet means that a service decides which conditions process the message. A policy is used to
negotiate elements in the communication, such as message format and security requirements. The
policy is there to further indicate the semantics of the service and its expectation of the behavior
on client side.