Service Oriented Architecture

Part – I

SOA – An Introduction

An Introduction to Enterprise organization

An enterprise organization will have multiple systems like HR, Payroll, Stock, SAP, any other ERP system, etc.

The applications present in the enterprise organization were predominantly silo in nature. Though the applications are independent but they would be dependent on data from each other.

The interchange of information is required for the other system to process data for example the stock system might be dependent on the procurement system for stock purchase which in turn will be dependent on the financial details on the SAP system.

Hence on non-availability of data for a day might give a distorted information in stock or the purchase system. These systems might be silo in operation but are highly dependent on one another to operate as a whole for the management to take appropriate decisions. This makes the applications within the organization very tightly coupled. Which makes it very critical for the organization to keep a 99.99% uptime for the applications.

The paragraph below explains the exchange of data between applications in an enterprise organization.

Evolution of Data Interchange Between Applications

Applications in the departments were of monolithic (tightly coupled applications) in nature. Hence the dependence on each other was immense, meaning if one application fails the other applications would also fail and might stop the entire application.

The exchange of data between applications were predominantly by using fixed length text files, delimited text files or comma separated value files. The files were placed at a specific location and at a specific time.

Batch jobs were written to process the data that was placed in the location by the applications to generate reports.

However, the data generated by the applications are not real time and hence the decisions being taken by the management will not be in accordance to the prevailing market conditions.

The diagram below shows how data is exchanged between applications via files

In the early 1990’s, in an attempt to get real time data organizations started Remote Procedure Calls via CORBA, COM/DCOM in their applications for communicating with other applications.

Enterprise Service Bus

In the early 2000’s the enterprise service bus arrived at the scene, to avoid point to point integration. ESB was used to integrate heterogenous/homogeneous applications share data with each other. Applications needed to be a registered with the queue in order to receive messages from other applications.

Once the application is registered with the messaging queue the application is bound to receive all the information that is being pushed into the message queue.

Some of the software for message queues are RabbitMQ, IBM MQ Series etc.

The diagram below is an example of how data is sent and consumed by applications in messaging queue.

The advantage of message queue’s is that any application can be added and removed from the message queue. Meaning that applications can be loosely coupled.

Data was also consumed by applications via XML which is a rigid and structured format of sending data. The structure of the XML was always defined by XSD (XML Schema Definition).

WebServices

With the advent of internet; webservices is also used for communication between applications. XML (Xtended Markup Language) is used by and the structure of the data is defined by WSDL (Web Service Definition Language) and UDDI (Universal Description Discovery and Integration).

However nowadays even JSON (Java Script Object Notation) is also used for passing data across applications in web services. The JSON data format does not follow a specific structure and is flexible in nature. However, OpenAPI Specification can be used to give structure to JSON data.

SOAP protocol is used for carrying the message from one application to the other using XML webservices and REST protocol is used for RESTful webservices

Applications became interoperable (A Java application talking to VB application) and could be exposed to the internet via HTTP by using webservices.

 

The diagram above gives you the basic structure of a webservice

Service Requester is a consumer of the webservice,

Service Provider is the Provider for the webservice and

Service Registry is a logically centralized directory of services where existing services can be found and new service can be published.

The webservice model is used for implementing Service Oriented Architecture

Service Oriented Architecture (SOA)

Service Oriented Architecture refers to a software design practice that allows applications to be loosely coupled, separate, autonomous and interoperable network accessible units.

The component’s called services are business applications associated with a business functionality or multiple business functionality.

The services can communicate with other services or across platforms.

SOA PRINCIPLES

There are no defined standard guidelines for implementing SOA however some the basic principles that is implemented in any SOA implementation are explained as below

  • Standardized Service Contract: A Service must have a description. This would make the application consuming the service understand the nature of service and data that would be provided by it.

  • Loose Coupling: Service must be loosely coupled meaning that it would not have any dependence on the data model or information systems.

    The service must adhere to statelessness which means that data from past transactions or sessions would not be stored.

    The statelessness of the service would cause minimal impact to the application consuming the service on modification of functionality from the service provider.

  • Abstraction: All service should appear as a black box, the business logic or the implementation of the service should not be seen or shared with other service.

    The abstracted service should have control over the functionality and business logic of the service. In other words, functional or code modification made to a service should not impact other services.

  • Reusability: The basic advantage of a service is to re-use business functionality as and when required by different applications.

  • Granularity: A service needs to be in appropriate size and scope. Ideally speaking a service can be mapped to one discrete functionality. These services can be put together to form one composite service performing various business operations.

SOA Advantages

The following paragraphs explains the major benefits of a SOA implementation

  • Flexibility and Faster Time to Market: Re-usability is the core of service oriented architecture; since components can be re-used, it is easier for the organization to assemble the application in a short period of time rather than writing the integration from scratch.

  • Usage of Legacy Application in New Markets: The organization scale the functionality of the legacy application from one platform and extend it to a new one.

  • Ease of Maintenance: Since services are encapsulated it is easy to modify the functionality of the service with out affecting other services.

  • Scalability: SOA uses the standard protocols and communicates across varied platforms and programming languages. Applications can be scaled because they can adapt to new technologies and services can be modified efficiently and effectively.

SOA Roles/Components

The following are the major Roles/Components of SOA

  • Service Provider: Creates the webservice and provides them to the registry

  • Service Registry/Service Broker: Responsible for providing information about the service to the Consumer

  • Service Requester/ Service Consumer: Connects to the provider after finding the relevant service in the registry and gets serviced by the provider.

SOA IMPLEMENTATION:

Implementation of SOA can be done via various methods however some methods are via Enterprise Service Bus and Service Oriented Integration which explained below.

Enterprise Service Bus: One of the approaches to implement SOA is the Enterprise Service Bus to provide the infrastructural element to provide the distributed services on the network. Though ESB’s provide interoperability between applications via document exchange, loose coupling between applications and coarse granularity to meet evolving SOA needs is not guaranteed, however implementing SOA in ESB would require the addition of extra functionality of coarse-grained business services provided by policy driven managed and secure service interactions.

Service Oriented Integration: This methodology uses the construct of creating an ecosystem of services that business can usually dynamically combine to create a high level business process. That meet evolving and changing business scenarios.

The SOI implementation can be done via Webservices as discussed in the above paragraphs.

Conclusion

SOA has made application integration simpler. SOA has helped the legacy application to scale and adapt to newer technologies. The consumer of SOA is not concerned with the implementation and the business logic of the service that is being consumed.

With the usage of Cloud technologies on the rise, the value of SOA has been renewed. In short SOA will be crucial in data exchange from enterprise to cloud or cloud to enterprise.

Upcoming series will cover SOA and microservices and SOA in cloud.

The next part would cover examples of implementation of SOA and Microservices.