Service Oriented Architecture

Service Oriented Architecture


The modern enterprise is a complex one, In today’s world enterprise needs to be agile to remain competitive, the enterprise is always in a hurry to design a new product and put them into the market to retain a competitive advantage. The market is getting disrupted, new products and services are getting launched every day. Agility has become critical to the survival of the enterprise.


Information Technology has become the backbone of the organization and has become critical in change. The old IT systems and processes are becoming increasingly a bottleneck in change, So Organization needs to rethink their IT strategy, In the old world, there was a homogeneous application that was tightly coupled. These systems were built by in house team. Though from an existing business perspective the old system worked fine due to change in the business process,  obsolescence in technologies and resources required to support them have become a risk to the organization.


There was the advent of SOA architecture, which has underpinning that application needs to be aligned to the business process. There should be flexibility that multiple business processes can co-exist and interact easily with each other under human or automated workflow.  The interoperability between applications should not become a constraint. Also, Application mesh on multiple platforms or language application or platform should not be a hindrance. As application architecture moves for 2-3 layer to n layer. The application becomes a COG in the business process of an enterprise and hence should be treated as whole or part of service a Hence this approach utilizes the available service to form an application and communicate through the internet.


The principle  of SOA: 


  • Identification of business processes
  • Break those business processes into granular processes.
  • Map those granular processes in existing application.
  • Create services of those granular processes.
  • Use a tool to loosely connected process residing into a set of interoperable applications.
  • Ability to merge multiple sub process into multiple application into create a composite and integrated service into coherent and decentralized systems.
  • SOA based computing packages functionalities into a set of interoperable services, which can be integrated into different software systems belonging to separate business domains.


  • Service Provider: The service provider maintains service, The services are made available through service contract and are published to the registry. So service consumers can utilize this service based on its requirement and contract agreement.
  • Service Consumers: The service consumers use the service provider based on the service agreement.

SOA Architecture, Components and Principle

SOA Components


  • Presentation Layer –  The presentation layer is where the services will be invoked and could be done through portal, device,translation, messaging or security. This is gateway for multiple business process which are tied through business rule running on disjointed and desperate systems to interact.
  • Oracle, SOA, Middleware

    SOA – Oracle

  • Adapter: A software module added to an application or system that allows access to its capabilities via a standards-compliant services interface.
    SOA, Oracle , ESB


  • Business Process Modeling: A procedure for mapping out what the business process does both in terms of what various applications are expected to do and what the human participants in the business process are expected to do.
  • Enterprise Service Bus: The enterprise service bus is the communications nerve center for services in a service-oriented architecture. It tends to be a jack-of-all-trades, connecting to various types of middleware, repositories of metadata definitions (such as how you define a customer number), registries (how to locate information), and interfaces of every kind (for just about any application).
  • Service Broker: Software in a SOA framework that brings components together using the rules associated with each component.
  • SOA Governance: SOA governance is an element of overall IT governance and as such lays down the law when it comes to policy, process, and metadata management. (Metadata here simply means data that defines the source of the data, the owner of the data, and who can change the data.)
  • SOA Repository: A database for all SOA software and components, with an emphasis on revision control and configuration management, where they keep the good stuff, in other words
  • SOA Service Manager: Software that orchestrates the SOA infrastructure — so that the business services can be supported and managed according to well-defined Service Level Agreements.
  • SOA Registry: A single source for all the metadata needed to utilize the Web service of a software component in a SOA environment.


SOA Architecture Principle


The key principle of SOA architecture is as following


  • Service contract:  The standardized service contract is a Services share a formal contract for services to interact, they need not share anything but a formal contract that describes each service and defines the terms of information exchange.
  • Loosely Integrated architecture:  The loosely coupled architecture combine with service contract provides a design guideline so each service contract can be used to one or multiple service contracts. This service contract can be used for consumption-based on service logic. This provides an option to evolve.

SOA, Oracle, ESB, SOA Rules

  • Service Abstraction: The service abstraction means that the information published in a service contract is precise and which will enable effective utilization of service contract by the service provider and service consumer.
  • Service reusability: The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services that can be reused across a business. These reusable services are designed so that their solution logic is independent of any particular business process or technology.
  • Autonomy: Service autonomy is a design principle that is applied within the service-orientation design paradigm, to provide services with improved independence from their execution environments. This results in greater reliability since services can operate with less dependence on resources over which there is little or no control.
  • Statelessness: Service statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in a reduction of the resources consumed by service as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner.
  • Discoverability: Service should be discoverable and be available in registry.
  • Compositive : In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition. This principal is directly responsible for the agility promised by SOA as it promotes composing new solutions by reusing existing services.

Advantages of SOA:

  • Service reusability: In SOA, applications are made from existing services.Thus, services can be reused to make many applications.
  • Easy maintenance: As services are independent of each other they can be updated and modified easily without affecting other services.
  • Platform independant: SOA allows making a complex application by combining services picked from different sources, independent of the platform.
  • Availability: SOA facilities are easily available to anyone on request.
  • Reliability: SOA applications are more reliable because it is easy to debug small services rather than huge codes
  • Scalability: Services can run on different servers within an environment, this increases scalability

Disadvantages of SOA:

  • High overhead: A validation of input parameters of services is done whenever services interact this decreases performance as it increases load and response time.
  • High investment: A huge initial investment is required for SOA.
  • Complex service management: When services interact they exchange messages to tasks. the number of messages may go in millions. It becomes a cumbersome task to handle a large number of messages.

Practical applications of SOA:

  • SOA infrastructure is used by many armies and air force to deploy situational awareness systems.
  • SOA is used to improve healthcare delivery.
  • Nowadays many apps are games and they use inbuilt functions to run. For example, an app might need GPS so it uses inbuilt GPS functions of the device. This is SOA in mobile solutions.
  • SOA helps maintain museums a virtualized storage pool for their information and content.

How to implement SOA ?

Before embarking into SOA implementation, there should be through understanding on following:


  • Strategic requirement : Business needs to understand the strategic requirement clearly, Which needs to be documented and agreed to authorised stakeholders. 
  • Business Requirement: The business requirement needs to be clearly defined and then engage as many sub business owners to create to be design processes. The design process could be built by data flow diagram.
  • Regulatory Requirement : The regulatory requirement needs to be determined for business,information security and data security compliance perspective.
  • Technological Requirement : This involves understanding of current IT Application and associated IT Infra and what is needed to ascertain if the current solution can be utilized for SOA implementation and what type of IT investment will be required.


Typical SOA project.

The SOA project is complex activity and hence this good to understand what it takes to move your organization into SOA. The thumb rule is that 6-9 month is required to do prototyping and later on depending on use case and can extend to 24 to 36 month.





Leave a Reply

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