Service-Oriented Architecture (SOA)

From GM-RKB
Jump to navigation Jump to search

A Service-Oriented Architecture (SOA) is an information system architecture where services are provided to the other components by application components through a communication protocols over a network.

References

2023

2022

  • (Wikipedia, 2022) ⇒ https://en.wikipedia.org/wiki/Service-oriented_architecture Retrieved:2022-8-18.
    • In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service has four properties according to one of many definitions of SOA: # It logically represents a repeatable business activity with a specified outcome. # It is self-contained.
      1. It is a black box for its consumers, meaning the consumer does not have to be aware of the service's inner workings.
      2. It may be composed of other services. Different services can be used in conjunction as a service mesh to provide the functionality of a large software application, a principle SOA shares with modular programming. Service-oriented architecture integrates distributed, separately maintained and deployed software components. It is enabled by technologies and standards that facilitate components' communication and cooperation over a network, especially over an IP network.
    • SOA is related to the idea of an API (application programming interface), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software. An API can be thought of as the service, and the SOA the architecture that allows the service to operate.


2017b

Standardized service contract
Services adhere to a standard communications agreements, as defined collectively by one or more service-description documents within a given set of services.
Service reference autonomy (an aspect of loose coupling)
The relationship between services is minimized to the level that they are only aware of their existence.
Service location transparency (an aspect of loose coupling)
Services can be called from anywhere within the network that it is located no matter where it is present.
Service longevity
Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.
Service abstraction
The services act as black boxes, that is their inner logic is hidden from the consumers.
Service autonomy
Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
Service statelessness
Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
Service granularity
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
Service normalization
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done, These are the cases where performance optimization, access, and aggregation are required.[3]
Service composability
Services can be used to compose other services.
Service discovery
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Service reusability
Logic is divided into various services, to promote reuse of code.
Service encapsulation
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.

2017c

  1. ↑ Yvonne Balzer Improve your SOA project plans, IBM, July 16, 2004
  2. ↑ Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles
  3. ↑ Tony Shan (2004). "Building a service-oriented e Banking platform". IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004. pp. 237–244. doi:10.1109/SCC.2004.1358011. ISBN 0-7695-2225-4. 2004
Retrieved from "http://www.gabormelli.com/RKB/index.php?title=Service-Oriented_Architecture_(SOA)&oldid=785668"