Baraap Technologies
Home Practice Areas Industries Careers Partners About UsContact Us

Services Oriented Architecture

What is a SOA?

There are numerous ways to define what Services Oriented Architecture (SOA) truly means. We have taken the definition part of SOA very seriously and have found that the following definition best describes SOA:

"The policies, practices and frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity level relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.”

It is important to note that SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which one ensures the right services are provided and consumed.

Why SOA?

Why should SOA interest you? By starting a SOA initiative, you are preparing your organization for the ability to integrate systems across departments and agencies using open standards.

Service-oriented architectures are an important new paradigm that supports modularized implementation of solutions within a middle tier. These architectures are particularly applicable when multiple applications running on varied technologies and platforms have to communicate with each other.

Baraap's OpenSOATM Blueprint

Baraap's objective in system development is to deliver agile systems in support of the business; not Service Orientation (SO). SO is the approach by which we can enable business and technology agility. The concept of micro-architectures working together enable technical agility. The micro-architecture concept is the guiding principle behind our OpenSOATM Blueprint.

Baraap defines three micro-architectures in the OpenSOATM:

Application Architecture
This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.

Service Architecture
This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture.

Component Architecture
This describes the various environments supporting the implemented applications, the business objects and their implementations.


These architectures can be viewed from either the consumer or provider perspective. Key to the architecture is that the consumer of a service should not be interested in the implementation detail of the service just the service provided. The implementation architecture could vary from provider to provider yet still deliver the same service. Similarly the provider should not be interested in the application that the service is consumed in. New unforeseen applications will reuse the same set of services.

The consumer is focused on their application architecture, the services used, but not the detail of the component architecture. They are interested at some level of detail in the general business objects that are of mutual interest, for example provider and consumer need to share a view of what an order is. But the consumer does not need to know how the order component and database are implemented.

Similarly, the provider is focused on the component architecture, the service architecture, but not on the application architecture Again, they both need to understand certain information about the basic applications, for example to be able to set any sequencing rules and pre and post conditions. But the provider is not interested in every detail of the consuming application.

What is the "Open" in the OpenSOATM Blueprint?

The "Open" in our SOA Blueprint is related to the Component Architecture. With Baraap's OpenSOATM Blueprint, it does not matter how or what platform you build the component architecture. These components can be Java based, .NET based, Oracle PL/SQL based, etc. As long as the Service Architecture provides a common interface and management infrastruture, you can use the technology of your choice or use the existing technologies you have in-house to build the component tier. We understand that this is a fundamental tenet of a properly implemented SOA, but we have recognized that some product vendors are pushing SOA based on their product suite. Since we are independent of all product vendors, we can faithfully offer a true SOA blueprint that is open and extensible using our OpenSOATMinitiative.

Getting Started with OpenSOATM

Service-oriented architectures aren't implemented overnight. Organizations must first gear up and work towards the progressive construction of the components and services involved. A road map and company-specific standards are key prerequisites ensuring a systematic implementation of a SOA. Baraap can help you jump start your SOA initiative by getting involved with you at the very beginning. Here are three high-level questions to help you start planning an enterprise service portfolio:

1. Service-oriented analysis: What services should you build to support the business priorities of the organization?

2. Service design: How should each service be built?

3. Service management: What infrastructure services should be deployed to support the business services, and what support is needed to understand and address exceptions?

Baraap OpenSOATM - A Great Start

Do you think we know what we are talking about? Baraap can help you jump start your SOA initiative by getting involved with you at the very beginning. Contact Us Now!