What is SOA

Why SOA

To enjoy the full benefits of BPM, business processes must integrate with existing applications and systems. They require access to the functions that are locked in application silos. Today’s IT organization is complex, consisting of many different applications and systems. They’re built using different technologies, on various middleware, utilizing multiple databases and running on many platforms. Hard-coding point-to-point integration with those applications is not a good solution as it creates tight coupling with the application and makes the process brittle and inflexible. That may be expensive to change and may, therefore, defeat the entire purpose of BPM.

SOA Definition

This is where Service Oriented Architecture (SOA) comes into play. It provides the technical ability to create a process independence. The goal of SOA is to expose an organization’s IT assets as reusable services that can communicate and integrate more easily. SOA’s aim is to provide a common communication framework to organize and describe capabilities, usage policies and service provider locations without exposing implementation details. It allows organizations to link new services or upgrade existing services in a granular manner when they have new business requirements.

Service-oriented architecture (SOA) is a software design (process) and architecture based on discrete pieces of software providing application functionality as services to other applications. This is known as service-orientation. It is independent of any vendor, product or technology.

A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by all software applications to provide the complete functionality of a large software application. SOA makes it easy for computers connected over a network to cooperate. Every computer can run a random number of services, and each service is built in a way that ensures it can exchange information with any other service in the network. This should happen without human interaction and without any need to make changes to the underlying program itself.

Service Oriented Design Principles

• Service Contract Standardization

The standardization of the service contract is probably the most important design principle. A service exposes its functionality and purpose via its contract. When defining this contract, organisations should take special care about the granularity of the exposed operations, naming conventions, and policy attachments.

Indeed, standardizing the service contracts will allow services of the same service inventory to be understood more easily, to be designed consistently, as well as to be governed in a consistent way.

Therefore the application of this design principle will require:

• • • Naming conventions;
    • Design standards (e.g. how to define fault handling on service contract level);
    • “Contract first” design: defining the contract  before the implementation;
    • Standardization and centralization of service policies;
    • Versioning standards;
    • SLA (Service Level Agreement) definitions

• Service Loose Coupling

This principle focuses on limiting the dependency between the service contract, the service logic and the service’s consumers. It allows service producers and consumers to evolve over time with limited impact on each other.

In other words, a service implementation should be able to evolve independently of the contract. It should also ensure interoperability with the service consumers relying on the functionality of the service.

To enforce this principle, a designer should:

• • • Make sure no implementation or technology details are reflected in the contract;
    • Design the contract first to ensure technology and implementation abstraction at the service contract level.

• Service Abstraction

Basically, this principle focuses on the need for the contract to hide the implementation details such as the used technology and logic, enforcing the service loose coupling design principle. Respecting this pattern will allow one to change or replace the technology and logic without impacting the contract.

However, other types of abstraction are also considered in this principle. There is a functional abstraction (what operations will be made public or hidden for the end user) and logical abstraction (good design is to avoid operation invocation sequences in order to fulfill some logic).

• Service Reusability

To achieve the SOA goal of increased agility, designing and implementing reusable services is a must.

Moreover, in a well-designed SOA, most of the services in a service inventory are reusable business agnostic services.

Here are some of the design characteristics of reusable service:

• • • The service should have a generic contract to be flexible enough to accept a larger range of messages, so don’t make the messages type too specific;
    • The logic should be as business agnostic and as generic as possible to allow different types of consumers to consume the service.

This principle will require a solid version control system to allow the service to evolve without impacting the actual consumers.

• Service Autonomy

Service reuse is an important aspect of service-oriented computing. This means they should be fully reliable in order to be reusable. To enforce its reliability, the service needs to have maximum control over its service logic and underlying resources. This means, the service should depend as less as possible on external resources like share logic or data. To enforce service autonomy, the service contract’s functional boundaries should be well defined. Also important is the deployment of services to be in an environment in which they have a great control.

• Service Statelessness

In an SOA, services and especially reusable services should be scalable. This means they should free up the consumed resources whenever possible to allow the service to handle maximum requests in a reliable way. In this context, state management should not be handled by the service itself but delegated to external architectural components comprised by the SOA middleware.

• Service Discoverability

To increase service reusability and to avoid redundant service functionalities, services should be discoverable, meaning they are documented and searchable by designers and architects. Definitely the best tool for service discoverability is a service registry, as it allows to publish and document service contracts as well as to discover services.

• Service Composability

For services to be reusable and be active participants in a service composition, their contract should be designed in such a way that they are easily composable. The contract needs to be flexible enough as described in the service reusability principle.  Moreover, to achieve this, its runtime environment should be highly scalable and support the statelessness principle.

Certainly reaching a right balance between the actual principle, the impact of the actual principle on other principles and a trade-off between good design and performance, development time, etc. is the key to successful implementing of the Service Oriented Design Principles.

Service Types

• Business Process Service

• Business Activity Service

• Data Service

• Decision Service

• Connectivity Service

• Infrastructure Service

In one of our next articles, we will present in more details each of the Service Types.