WHAT IS SOA?

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 defi ned 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 defi nition 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 defi nes 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 defi ne a workfl ow 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