Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
- Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
- Is self-contained
- May be composed of other services
- Is a “black box” to consumers of the service
SOA Architectural Style
An architectural style is the combination of distinctive features in which architecture is performed or expressed.
The SOA architectural style has the following distinctive features:
- It is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.
- Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
- It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.
- Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.
- It requires strong governance of service representation and implementation.
- It requires a “Litmus Test”, which determines a “good service”.
SOA is a collection of software components which are communicating with each other through a communication protocol such as REST, SOAP, RPC, etc referred to as services. SOA is a new term for componentization of software pieces through service. In SOA we have service provider and service consumer. The middleware in the picture above is an enterprise service bus which routes, transform, translate, and connect components in the service provider with consumers through a communication protocol. There are also bunch of other components on the side such as security and management services which manages the routing and communication between consumers and providers.
SOA is built if three components:
- Service Provider
- Service Consumer
- Service Manager (Enterprise Service Bus)
Flow of SOA:
SOA is a particular construction technique that can be used to build enterprise IT. SOA could have a similar impact on IT architecture. It does not increase the size of IT systems, but it does increase their interoperability. The principle of service-orientation can apply throughout the enterprise architecture, but is most commonly applied to the organization of the software that supports the enterprise’s business operations. With SOA, this software is organized as a set of software services. The services are supported by an infrastructure that, together with the services, improves information flow within the enterprise and between the enterprise and external enterprises.
ESB Enterprise Service Bus:
An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time. Point-to-point integration results in custom integration code being spread among applications with no central way to monitor or troubleshoot. This is often referred to as “spaghetti code” and does not scale because it creates tight dependencies between applications.
Increasing organizational agility by reducing time to market for new initiatives is one of the most common reasons that companies implement an ESB as the backbone of their IT infrastructure. An ESB architecture facilitates this by providing a simple, well defined, “pluggable” system that scales really well. Additionally, an ESB provides a way to leverage your existing systems and expose them to new applications using its communication and transformation capabilities.
ESB architecture maps to five core integration principles:
- Orchestration: Composing several existing fine-grained components into a single higher order composite service. This can be done to achieve appropriate “granularity” of services and promote reuse and manageability of the underlying components.
- Transformation: Data transformation between canonical data formats and specific data formats required by each ESB connector. An example of this would be transforming between CSV, Cobol copybook or EDI formats to either SOAP/XML or JSON. Canoncial data formats can greatly simplify the transformation requirements associated with a large ESB implementation where there are many consumers and providers, each with their own data formats and definitions.
- Transportation: Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC). Note: Mule treats databases like another “service” by making JDBC just another transport (or endpoint) where data can be accessed.
- Mediation: Providing multiple interfaces for the purpose of a) supporting multiple versions of a service for backwards compatibility or alternatively, b) to allow for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (flat file) and one standards compliant (SOAP/XML) interface.
- Non-functional consistency: For a typical ESB initiative, this can include consistency around the way security and monitoring policies are applied and implemented. Additionally the goals of scalability and availability can be achieved by using multiple instances of an ESB to provide increased throughput (scalability) and eliminate single-points-of-failure (SPOFs), which is the key objective for highly available systems.
Componentization through services:
Breaking down into interchangeable pieces. For many years, software innovators have been trying to make software more like computer hardware, which is assembled from cheap, mass-produced components that connect together using standard interfaces. Component-based development (CBD) uses this approach to assemble software from reusable components within frameworks such as CORBA, Sun’s Enterprise Java Beans (EJBs) and Microsoft COM. Today’s service oriented architectures, based on web services, go a step further by encapsulating components in a standards-based service interface, which allows components to be reused outside their native framework. Componentization is not limited to software; through the use of subcontracting and outsourcing, it can also apply to business organizations and processes.
Microservice architecture is a subset of SOA which focuses on componentizing monolith applications into pieces using services. In many cases SOA helps resolving the macaroni style of communication between DB and middleware component in the left picture above to a nicely organized service oriented component chart in the right.