Service-oriented architecture facts for kids

Kids Encyclopedia Facts

Service-oriented architecture (SOA) is a way to design computer systems. Instead of building one giant program, SOA breaks things down into smaller, independent parts called services. Think of it like building with LEGO bricks instead of carving one big block of wood. Each LEGO brick is a service.

SOA is great for connecting different computer programs. It helps them talk to each other over a network, like the internet. A service is a small piece of a program that can do one specific job. For example, getting your credit card statement online could be a service. These services are designed to work on their own. They don't care who made them or what technology they use.

Service orientation is simply thinking about how to build software using these independent services.

A service has four main features:

It does a specific business task, like checking a customer's order.
It works by itself.
It's like a black box for other programs. They use it without needing to know how it works inside.
It can be made up of other smaller services.

Different services can work together to create a bigger program. This is similar to how modular programming works, where a big program is split into smaller, manageable parts. SOA helps connect software parts that are kept and updated separately. It uses special rules and technologies to let these parts communicate over a network.

SOA is also related to an API. An API is like a menu that tells you what a program can do and how to ask it to do something. You can think of an API as the service itself, and SOA as the overall plan that lets all these services work together.

It's important not to confuse Service-Oriented Architecture (SOA) with Service Based Architecture. They are different ways of designing software.

What is a Service?
How Services Work Together
Principles of SOA
Who Does What? (Roles in SOA)
How SOA is Built
Why SOA is Helpful
Extensions and Variants
Images for kids
See also

What is a Service?

In SOA, services use special rules called protocols. These rules describe how services send and understand messages. They also include information about what the service does and how well it performs. The goal of SOA is to let users combine many different services. This creates new applications by simply linking existing services together.

A service shows a simple way for other programs to use it. It hides all the complex details inside, like a black box. This means users can access these services without knowing how they are built.

How Services Work Together

A key idea in SOA is loose coupling. This means services are connected in a flexible way. If one service changes, it doesn't break other services that use it. SOA divides big tasks into smaller services. Developers make these services available over a network. This allows users to combine and reuse them to build new applications.

These services and the programs that use them communicate by sending data. They use a clear, shared format. Or they work together to coordinate an activity between two or more services.

SOA is part of a bigger story in computer science. It connects older ideas like distributed computing (where parts of a program run on different computers) and modular programming. It also leads to newer ideas like mashups, SaaS (software you use over the internet), and cloud computing. Some people even see cloud computing as an evolution of SOA.

Principles of SOA

There isn't one single rulebook for building a service-oriented architecture. However, many experts have shared their own ideas. Here are some common principles:

Standardized service contract: Services agree to a common way of communicating. This is written down in documents that describe what the service does.

Who Does What? (Roles in SOA)

In SOA, there are three main roles that different parts of the system can play:

Service provider: This is the part that creates a service and makes it available. It decides what services to offer, how secure they should be, and if they cost money. The provider also decides where to list the service so others can find it.
Service broker, service registry, or service repository: This is like a directory or a phone book for services. Its main job is to list information about services so that anyone who needs a service can find it. Some brokers are public, meaning anyone can use them. Others are private, for a limited group of users. UDDI was an early attempt at a public directory for web services, but it's not used much anymore.
Service requester/consumer: This is the part that needs a service. It looks up services in the broker's directory. Once it finds the right service, it connects to the service provider to use that service. A requester can use many services if needed.

The relationship between the service consumer and the provider is set by a standardized service contract. This contract covers business, functional, and technical details.

Services can also be combined in different ways. This is called service composition. Two main ways to do this are choreography and orchestration.

How SOA is Built

SOA can be built using web services or Microservices. This makes the different parts of the program available using standard internet rules. These rules work no matter what type of computer or programming language is used. Services can be brand new programs. Or they can be like "wrappers" around older programs, making them able to connect to the network.

Many people build SOAs using web service standards. One common standard is SOAP. This standard helps different programs work together. It also helps avoid being stuck with one company's software. However, you can also build SOA using other technologies like REST or gRPC.

SOA designs can work with many different technologies. These include:

Web services using WSDL and SOAP
Messaging systems, like ActiveMQ or RabbitMQ
RESTful HTTP, which is its own way of designing systems
Data Distribution Service (DDS)
OPC-UA
Internet Communications Engine
WCF (Microsoft's web services)
Apache Thrift
gRPC
SORCER

The main idea is to have independent services. They have clear rules for how to use them. You can call these services to do their jobs in a standard way. The program using the service doesn't need to know how the service actually does its work. SOA helps create applications by combining services that are loosely connected and can work together.

These services work together based on a formal definition. This definition is separate from the computer system or programming language used. For example, services written in C# (for .NET) and services written in Java can both be used by the same main application. This makes it easy to reuse services. Even old COBOL systems can be "wrapped" and used as services.

Special programming languages like BPEL help define how smaller services can be combined into bigger business services. These bigger services can then be used in workflows or business processes.

Service-oriented modeling is a way to plan and design SOA systems. It helps people understand how to create and manage their services. The Service-oriented modeling framework (SOMF) provides a way to map out the steps needed for a successful SOA project. It helps connect business goals with the technology used.

Why SOA is Helpful

Some computer architects believe SOA can help businesses react faster and cheaper to changes in the market. This way of designing systems encourages reusing big parts of software (services) instead of tiny parts (like individual code classes). It also makes it easier to connect to and use existing computer systems.

With SOA, a business can look at a problem as a whole. They have more control. Instead of many developers using different tools, they can all follow a standard set by the business. They can build a company-wide SOA that helps manage their business systems. IBM's Michael Liebow once said SOA "builds highways." This means it creates a smooth way for different parts of a business to work together efficiently.

In some ways, SOA is an improvement on older ways of building software, not a completely new idea. It uses many good practices from past software designs. For example, in communication systems, programs rarely talk to other equipment in a fixed, unchanging way. By using SOA, these systems can focus on having clear ways for different parts to communicate. Other ideas that came before SOA include Component-based software engineering and designing remote objects, like in CORBA.

A service is a standalone piece of code that does a job. It's only available through a clearly defined way of using it. Services can be small, like "nano-enterprises" that are easy to create and improve. Or they can be large, like "mega-corporations" built from many smaller services working together.

It's often good to treat building services as separate projects from bigger ones because:

It helps businesses see that services can be delivered quickly and on their own. This makes the business more flexible and helps new ideas get to market faster.
It helps keep services separate from the projects that use them. This means the service is designed to work for anyone, without knowing who will use it.
The instructions and tests for the service are not hidden inside a bigger project. This is important when the service needs to be reused later.

SOA also helps simplify testing. Services are independent, don't remember past actions, have clear instructions, and are separate from other parts of the program. If you have good test data, you can build a fake version of a service to test it. You can also create a full set of tests for the service. The service can be tested like a 'black box' using these fake versions of other services it calls. Testing becomes about making sure the service works as described.

Extensions and Variants

Application Programming Interfaces (APIs)

APIs are like sets of rules. They allow different software programs to talk to each other. Developers use APIs to connect their programs to web applications.

Web 2.0

The term "Web 2.0" describes a time when web applications became more interactive and social. People have talked a lot about how Web 2.0 and SOA are related.

SOA is about putting program logic into services with clear ways to use them. These services are made public so others can find them. Both SOA and Web 2.0 focus on hiding complexity and reusing parts. Some people think Web 2.0 and SOA are very different. Others see them as working together, with Web 2.0 being like a global SOA.

While Web 2.0 and SOA serve different user needs, they can be combined. Many examples show how technologies and ideas from both can work together.

Microservices

Microservices are a newer way of thinking about SOA. They are used to build distributed software systems. In a microservice design, services are small programs that talk to each other over a network to achieve a goal. These services use communication rules that don't depend on specific technologies. This means each service can choose its own programming language and tools. Microservices have become very popular since 2014. They also focus on quickly releasing new software and other agile practices.

There isn't one perfect definition of microservices. But they often have these features:

Small, independent services that can be released on their own.
Development driven by business needs.
Good for cloud computing applications.
Using different programming languages and databases.
Easy to deploy using lightweight containers.
Continuous delivery (releasing updates often) in a decentralized way.
DevOps (combining development and operations) with full service monitoring.

Images for kids

Elements of SOA
SOA meta-model