Editing Service-oriented architecture (section)

== Patterns ==

Each SOA building block can play any of the three roles:

; Service provider
: It creates a web service and provides its information to the service registry. Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance: security or easy availability, what price to offer the service for and many more''.'' The provider also has to decide what category the service should be listed in for a given broker service<ref>{{cite book|chapter=Exploring Cloud Service Brokering from an Interface Perspective|last1=Duan |first1=Yucong |title=2014 IEEE International Conference on Web Services|pages=329–336|last2=Narendra |first2= Nanjangud |last3=Du |first3=Wencai |last4=Wang |first4=Yongzhi |last5=Zhou|first5=Nianjun|publisher=[[IEEE]]|doi=10.1109/ICWS.2014.55|year=2014|isbn=978-1-4799-5054-6|s2cid=17957063 }}</ref> and what sort of trading partner agreements are required to use the service.
; Service broker, service registry or service repository
: Its main functionality is to make information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker. Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public. [[UDDI]] was an early, no longer actively supported attempt to provide [[Web Services Discovery|Web services discovery]].
; Service requester/consumer
: It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.

The service consumer–provider relationship is governed by a [[standardized service contract]],<ref>{{cite book |chapter=A Survey on Service Contract |last1=Duan |first1=Yucong |title=2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing |pages=805–810 |publisher=[[IEEE]]|doi=10.1109/SNPD.2012.22 |year=2012 |isbn=978-1-4673-2120-4 |s2cid=1837914 }}</ref> which has a business part, a functional part and a technical part.

[[Service composability principle|Service composition patterns]] have two broad, high-level architectural styles: [[Service choreography#Service choreography and service orchestration|choreography and orchestration]]. Lower level enterprise integration patterns that are not bound to a particular architectural style continue to be relevant and eligible in SOA design.<ref name="ieeesweip">{{Cite journal | doi = 10.1109/MS.2016.11 | title = A Decade of Enterprise Integration Patterns | journal = IEEE Software | volume = 33 | issue = 1 | pages =  13–19 | year = 2016 | last1 = Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf | doi-access = free }}</ref><ref>{{Cite book | last=Rotem-Gal-Oz | first=Arnon | title= SOA Patterns | publisher= Manning Publications | year=2012 | isbn=978-1933988269 }}</ref><ref>{{cite journal |doi=10.1016/j.cose.2011.03.005 |citeseerx=10.1.1.390.3652|url=http://soadecisions.org/download/ComplianceByDesign-AAM.pdf|title=Compliance by design – Bridging the chasm between auditors and IT architects|year=2011|last1=Julisch|first1=Klaus|last2=Suter|first2=Christophe|last3=Woitalla|first3=Thomas|last4=Zimmermann|first4=Olaf|journal=Computers & Security|volume=30|issue=6–7|pages=410–426}}</ref>