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.

What are Service Models ? 

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.  




Leave a comment

Your email address will not be published. Required fields are marked *