Editing Service-oriented architecture (section)

== Principles ==
{{list|date=July 2024}}
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles.  Some of these<ref>Yvonne Balzer [http://www-128.ibm.com/developerworks/webservices/library/ws-improvesoa/ Improve your SOA project plans], ''IBM'', July 16, 2004</ref><ref>{{cite web |url= http://msdn.microsoft.com/en-us/library/bb972954.aspx |title=Principles of Service Oriented Design |author=Microsoft Windows Communication Foundation team |work=msdn.microsoft.com |year=2012 |access-date=September 3, 2012}}</ref><ref name="Terl">Principles by [[Thomas Erl]] of SOA Systems Inc. [http://soaprinciples.com eight specific service-orientation principles]</ref>
include the following:
; [[Standardized service contract]]<ref>{{cite web | title=4.4 Guidelines for Using Web Service Contract Technologies - Anatomy of a Web Service Contract | website=InformIT | date=2021-06-11 | url=http://www.informit.com/articles/article.aspx?p=1250898&seqNum=4 | ref={{sfnref | InformIT | 2021}} | access-date=2021-09-09}}</ref>
: Services adhere to a standard communications agreement, 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 principle|Service autonomy]]
: Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
; [[Service statelessness principle|Service statelessness]]
: Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
; [[Service granularity principle|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.<ref>{{cite book|author=Tony Shan|title=IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004 |doi=10.1109/SCC.2004.1358011 |pages=237–244|year=2004|chapter=Building a service-oriented eBanking platform |isbn=978-0-7695-2225-8 |s2cid=13156128 }}2004</ref>
; [[Service composability principle|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 principle|Service reusability]]
: Logic is divided into various services, to promote reuse of code.
; Service [[Encapsulation (computer science)|encapsulation]]
: Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.