Service orientation is a design paradigm for computer software in the form of services. Applying service-orientation results in units of software partitioned into operational capabilities, each designed to solve an individual concern. These units qualify as services.
SERVICE-ORIENTED ARCHITECTURE (SOA)
Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications.
Service-oriented modeling is the discipline of modeling business and software systems, for the purpose of designing and specifying service-oriented business systems within a variety of architectural styles, such as enterprise architecture, application architecture, service-oriented architecture, and cloud computing.
A service is classified by its contextual and structural attributes:
- Atomic service:
- an indivisible software component that is too granular and executes fewer business or technical functionalities.
- Examples: customer address service and checking account balance service.
- Composite service:
- Aggregates smaller and fine-grained services to form a network of interacting services.
- Also called as service composition.
- Examples: customer checking service that aggregates smaller checking account and savings account services.
- Service cluster:
- Collection of distributed and related services that are gathered because of their mutual business or technological commonalities.
- Examples: A Mutual Funds service cluster that is composed of related and distributed mutual funds services.
- Cloud of Services:
- Collection of services that are delivered by a cloud computing implementation. These services can be classified as SaaS, PaaS, IaaS, and more.
RELATION BETWEEN SOA, SOAP AND MICROSERVICES
SOAP web services were the primary means of achieving Service Oriented Architecture (SOA) sometime back. However, microservices and RESTful services are becoming the way organizations are structuring their services. In fact, microservices can be considered a special case implementation of SOA.
In general, choreography is the art or practice of designing sequences of movements of physical bodies (or their depictions) in which motion, form, or both are specified.
With respect to SOA, choreography can be considered as a collaboration between service providers among each other and also with their users, to achieve a common goal. Here, service composition is achieved through a decentralized approach, unlike in orchestration.
Read more @ https://en.wikipedia.org/wiki/Choreography.
Orchestration is a centralized approach for service coordination, with an orchestration engine doing the coordination between tasks.
It can be considered as the behavior a service provider does internally to realize a service. Or in other words, the relationship between all the participating services are described by a single endpoint (i.e., the composite service).
Orchestration also provides centralized management of the resource pool, including billing, metering, and chargeback for consumption.
ORCHESTRATION VS. CHOREOGRAPHY
While orchestration can be considered as a local view from the perspective of one participant, choreography can be considered as the coordination from a global multi-participant perspective, albeit without a central controller.
In orchestration, a central service often controls other services. This may lead to these other services getting drained of responsibilities often acting as mere database wrappers and the controlling service getting turned into a God class. In choreography, each actor (service) know only its part, and may not know at all about others; a service may publish an event or message and other interested services can listen to it and do their part, so that the publishing service may not even know about others.
Service-oriented Design: A Multi-viewpoint Approach.
Dijkman, Remco & Dumas, Marlon (2004) Service-oriented Design: A Multi-viewpoint Approach. International Journal of Cooperative Information Systems, 13(4), pp. 337-378.
Available @ http://eprints.qut.edu.au/622/