SOA (Service-oriented Architecture)   

  • Introduction
SOA is a style of software design where services are provided to the other components by application components, through a communication protocol over a network.
Many organizations believe Service Oriented Architecture (SOA) is dead, but that is not the case. Instead, the heavyweight, high upfront investment, top-down approach to SOA has been replaced by a much faster, lighter, bottom-up approach.

  • Bottom-Up and Top-Down approach
  • Bottom-Up Approach
    In a typical SOA service layers, bottom layer always represented by integration services, partner services, data access services, infrastructure and information services. The next upper layer would be business services and then business process services. Identifying required services for bottom layer then moving upwards to achieve the integration process requirement called bottom-up approach. This approach has been followed and proven by many integration projects.

  • Top-Down Approach
    Approaching SOA at enterprise level is the preferred approach to gain the maximum benefits. The reason for approaching at enterprise level is to make sure that IT and business processes are aligned to achieve business goals. So identifying required business process services at enterprise level will be a starting point for top-down approach. Once the enterprise process services are identified, identifying the business activities to fulfil each business processes would be a next step.

    • Finally the bottom layers to be identified like bottom-up approach. Top-down approach is a preferred approach for realizing complete SOA benefits.
    Mule Runtime enables a bottom-up approach to SOA. A bottom-up method allows organisations to leverage a lightweight standalone Runtime rather than a full proprietary stack, giving them more flexibility.
    With Mule Runtime, businesses can leverage numerous SOA and API design patterns to overcome complex integration challenges.
    SOA design patterns allow organizations to solve design problems quickly and easily through the use of proven solutions.
  • Key principles of SOA
  • Standardized Service Contract :  Services adhere to a service description. A service must have some sort of description which describes what the service is about. This makes it easier for client applications to understand what the service does.

  • Loose Coupling :  Less dependency on each other. This is one of the main characteristics of web services which just states that there should be as less dependency as possible between the web services and the client invoking the web service.

  • Service Abstraction :  Services hide the logic they encapsulate from the outside world. The service should not expose how it executes its functionality; it should just tell the client application on what it does and not on how it does it.

  • Service Reusability :  Logic is divided into services with the intent of maximizing reuse. In any development company re-usability is a big topic because obviously one wouldn't want to spend time and effort building the same code again and again across multiple applications which require them. Hence, once the code for a web service is written it should have the ability work with various application types.

  • Service Autonomy :  Services should have control over the logic they encapsulate. The service knows everything on what functionality it offers and hence should also have complete control over the code it contains.

  • Service Statelessness :  Ideally, services should be stateless. This means that services should not withhold information from one state to the other. This would need to be done from either the client application.

    An example can be an order placed on a shopping site. Now you can have a web service which gives you the price of a particular item. But if the items are added to a shopping cart and the web page navigates to the page where you do the payment, the responsibility of the price of the item to be transferred to the payment page should not be done by the web service. Instead, it needs to be done by the web application.

  • Service Discoverability :  Services can be discovered (usually in a service registry). We have already seen this in the concept of the UDDI, which performs a registry which can hold information about the web service.

  • Service Composability :  Services break big problems into little problems. One should never embed all functionality of an application into one single service but instead, break the service down into modules each with a separate business functionality.

  • Service Interoperability :  Services should use standards that allow diverse subscribers to use the service. In web services, standards as XML and communication over HTTP is used to ensure it conforms to this principle.

  • Most 10 SOA design patterns that are widely used
  • SOA supports by Mulesoft
Avoid wasting time and resources developing integration solutions when leveraging design patterns with Mule Runtime provides the framework for repeatable, consistent, and proven solutions.
MuleSoft provides support for many integration design patterns through Anypoint Platform.
  1. Integration styles
  2. Messaging systems
  3. Messaging channels
  4. Message routing
  5. Message transformation
  6. Message endpoints
  7. System management
  • Each SOA building block can play any of the three roles:
Service provider
It creates a web service and provides its information to the service registry. Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance: security or easy availability, what price to offer the service for and many more. The provider also has to decide what category the service should be listed in for a given broker service[16] and what sort of trading partner agreements are required to use the service.
Service broker, service registry or service repository
Its main functionality is to make the information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker. Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public. UDDI was an early, no longer actively supported attempt to provide Web services discovery.
Service requester/consumer
It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
If you got some knowledge about SOA Architecture, please follow with me in next topic to know about API-led Architecture.

Comments