Service Oriented Architecture: SOA

SOA

Introduction

In the earlier days, connecting systems could be challenging until SOA was formed. Yes SOA is the perfect architectural approach for creating an open and interoperable computing environment. It should not be seen just from a technology perspective, but the policies, practices and frameworks by which we ensure the right services are provided and consumed by clients across the platforms.

What is SOA?

SOA: Service Oriented Architectureis an architectural approach in software development where the application is organized as "Services". Services are a group of methods that contain the business logic to connect a DB or other services. Methods have clearly defined and published methods for use by the clients as a black box. So what is a black box? It's nothing but a system or an object that can be viewed in terms of its input, output and transfer characteristics without knowledge of its internal workings. Across the platforms these methods can be accessed, no matter what your client developing a UI in C# or Java or any latest technology. It decouples the business services from the technical services, in other words the service methods having the business logic is not coupled with the specific programming language, both will react independently.

SOA Overview

A Service Oriented Architecture is based on four key abstractions.

• An Application Front End
• A Service
• A Service Repository
• A Service Bus

Application Front End: The application front end is decoupled from the services. Each service has a contract that defines what it will do and one or more interfaces to implement the contract.

A Service: it has the methods with the defined contracts and the implementation of the business logic to connect the DB or other service.

A Service Repository: The service repository provides a home for the services and the service bus provides an industry-standard mechanism for connecting to and interacting with the services.

The preceding architecture helps the businesses respond more quickly and cost effectively to the changing market conditions because all the services are decoupled from each other and from the application front end, SOA provides the desired level of interoperability in a non-proprietary open-systems environment.

Let's talk about SOA in another detailed example.

SOA: Service Oriented architecture



You could find two services named Transaction and Stock thare are hosted and being consumed by the various clients whose UI has been developed in various technologies like C#, Java, Android (Mobile App).. If the client has the knowledge of the input parameters, output parameters and return type of the method, across the platform the service will be consumed. This makes the system a loosely coupled one. In fact the idea behind the SOA is to create the loosely coupled system. The clients will not have a direct interaction with the server, instead the messages are formed out of the value of the input parameters, return parameters and the data are formatted by the SOAP.

Every development platform has the SOAP stack, so working with a service is supported in many environments. Implementing the application in this architecture will be the way to make the code and the functional behavior reusable in the future. Separation of concerns is an another advantage. When structuring the development team for a project, various sub teams can be assigned to the client and services. The UI team can completely concentrate on user interaction stuff without concern with the code dealing with the business logic and the data access.

Whereas the services team can concentrate on forming the business logics in the service's methods without concern with the user interfaces. It clearly says that the developer is no longer responsible for the code end-to end, starting from the user interface, business logic and the data access for the given requirement. So both of the teams can start their work at the same time. Another advantage here is the UI-related work can be outsourced and keeps the creation of business logic in house.

SOAP Message



The preceding is an example of how a client might format a SOAP message for requesting the stock information from the server.

Structure of the message



Simple Object Access Protocol (SOAP) is a XML specification for exchanging data as structured information in messages across the platforms. SOAP standardizes how data are exchanged on the wire. A SOAP envelope contains an optional header and a required body element.

A header can contain information needed for the underlying technical infrastructure to support the communication, not the business functionality. Whereas the body contains the functional data.

Each parameter for the service operation is present in the body in a serialized representation of data. A fault message will contain details of the exception (as appropriate) and one of the fault codes defined by the SOAP specification.

Client Request

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getProductAvailablity xmlns="http://www.soaexample.org/ProductAvailable">
      <product>Toy 0608</product>
    </getProductAvailablity>
  </soap:Body>
</soap:Envelope>

Response from the server to the client.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <getProductAvailablityResponse xmlns="http://www.soaexample.org/ProductAvailable">
         <getProductAvailablityResponseResult>
            <productName>Toy 0608 </productName>
            <productID>0608</productID>
            <description>Barbie Doll</description>
            <price currency="NIS">510.00</price>
            <inStock>true</inStock>
            <AvailablePieces>170</AvailablePieces>
         </getProductAvailablityResponseResult>
      </getProductAvailablityResponse>
   </soap:Body>
</soap:Envelope>

Summary

SOA is an architectural approach to the distributed systems to integrate flexibly with interoperability. Newer technology systems can be easily adopted into it.