What is Service Oriented Architecture – SOA ?
Service Oriented Architecture – SOA is a software design pattern, or style, where the the system is divided into separate service that communicate thought a communication protocol.
But, What exactly is a service ?
Due to extensive use of the word “service” in many areas, the meaning of it in SOA is confusing. Depending on the context “service” can be a web service, a Java service class, service provided by the organization or company.
To clarify what “service” is in SOA lets go through some myths:
- No, not every service is a web service
- Consumer of service can be IT systems as well as humans
- Not every service has to be automated ( consider a support portal service, when having a question the service is not automated to answer, the support guy on the other side is who answers your question)
Putting it together – what is SOA?
Service Oriented Architecture is a reference architecture that is based on services.
This means that SOA is a speciic structured approach, based on services.
If architecture is deined from the perspective of services, it is called “serviceoriented”
or SOA in short.
So, a service can be a java/.NET class service, A PL/SQL procedure, Micro-service etc ..
What are Elements of Service ?
Every service must have:
- A Contract ( What does the service do and what are it’s rules )
- An Interface ( How to access the service and interact with it, what input to provide and what output to expect )
- An Implementation ( How the service is actually implemented )
How to Identify Services ?
There are mainly three approaches to identify services :
- Top-down : service identification typically happens when executing enterprise architecture or solution architecture activities. Top-down is used when new services are developed. It involves high level architectures.
- Bottom-Up: service identification occurs when you investigate your existing IT assets, and derive services from there. Use this approach when adding new services to exiting ones or expanding their functionalities.
- Meet in the middle: As with so many things, the truth is in the middle. Top-down can be too abstract while Bottom-up can too specific.
How to design my Service Oriented Architecture ?
Designing a service consists of several actions, such as:
- Design the functionality it offers
- Design the interface
- Design the operations and the functionality the operations offer.
- Design the parameters of the operations.
- Design the return value or the effect of the operation.
- Design test cases for the operations.
- Design the contract
- Define who is allowed to use the service and who can use what operation.
- Decide how often the service is available.
- Define the load the service should be able to handle
- Define other relevant quality of service attributes.
- Design the implementation
- Decide what tool or language you are going to use for the implementation.
- Design the components you need for the implementation.
- Decide what tools to use to test the implementation.
What are classifications of services in SOA ?
- Elementary services: The smallest possible components that qualify as
services. For example, a service that can be used for zip code lookups.
- Composite services: Services that result from combining two or more other
services into one service that provides more value. Composite services are
executed in a single transaction and their execution time is relatively short.
An example is a service to book a hotel and light together.
- Process services: Longer running services that can take a couple of hours,
days, or even more to complete and span multiple transactions. An example
is a service for ordering a book online. The entire process (order, pay, ship,
deliver) involves multiple transactions and takes a couple of hours at least.
Regardless of how services are implemented, they are commonly classified into one of the following service models:
- Entity Services (An entity service is a form of business service with a functional context that is derived from one or more related business entities. Examples of business entities include order, client, timesheet, and invoice.)
- Task Services (and Orchestrated Task Services) : A task service is a form of business service with a functional context based on a specific business process. As a result, task services are not generally considered agnostic and therefore have less reuse potential than other service models
- Utility Services : A utility service is intentionally based on a non-business-centric functional context. It typically encapsulates common, cross-cutting functionality that is useful to many service compositions, but which is not related to or derived from existing business models.
What are stateful and stateless services ?
- A stateful service is a service that stores state and the services that the service provides depends on this state e.g user is login in or not .
- A stateless service is a service that doesn’t keep state and the services it provides doesn’t depend on any state.