Wikipedia - User contributions [en]

User talk:Biniljava

2019-07-31T08:28:34Z

Biniljava: Appeal to unblock account

[[File:Information orange.svg|25px|alt=Information icon]] Please do not add promotional material to Wikipedia. While [[Wikipedia:Neutral point of view|objective prose]] about beliefs, organisations, people, products or services ''is'' acceptable, Wikipedia is not [[Wikipedia:What Wikipedia is not#Wikipedia is not a soapbox|a vehicle for soapboxing, advertising or promotion]]. Thank you.[[Category:User talk pages with Uw-advert2 notices|{{PAGENAME}}]] [[User:Mean as custard|Mean as custard]] ([[User talk:Mean as custard|talk]]) 07:53, 11 April 2019 (UTC)

<div class="user-block" style="min-height: 40px">[[File:Stop x nuvola.svg|40px|left|alt=Stop icon]]<div style="margin-left:45px">You have been '''[[WP:Blocking policy|blocked]]''' '''[[Wikipedia:Blocking_policy#Indefinite_blocks|indefinitely]]''' from editing for [[Wikipedia:Spam|advertising or promotion]]. From your [[Special:Contributions/Biniljava|contributions]], this seems to be your only purpose. </div><div style="margin-left:45px">If you think there are good reasons for being unblocked, please read the [[WP:Guide to appealing blocks|guide to appealing blocks]], then add the following text below the block notice on your talk page: {{tlx|unblock|2=reason=''The material I have linked is https://link.springer.com/content/pdf/bfm%3A978-1-4842-4501-9%2F1.pdf , I have done that under the impression that this content will fall within the "more info" category. However, now I understand how wikipedia classify that, and I am now aware that wikipedia doesn't encourage even such items. I can abide by wikipedia guideline. Great if you can unblock my account.''}}. </div></div>[[Category:Wikipedians who are indefinitely blocked for advertising|{{PAGENAME}}]]

CAP theorem

2019-07-24T11:06:14Z

Biniljava: /* Added an external link as reference */

In [[theoretical computer science]], the '''CAP theorem''', also named '''Brewer's theorem''' after computer scientist [[Eric Brewer (scientist)|Eric Brewer]], states that it is impossible for a [[distributed data store]] to simultaneously provide more than two out of the following three guarantees:<ref name="Gilbert Lynch">Seth Gilbert and Nancy Lynch, [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970 "Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services"], ''ACM SIGACT News'', Volume 33 Issue 2 (2002), pg. 51–59. {{doi|10.1145/564585.564601}}.</ref><ref>[http://www.julianbrowne.com/article/viewer/brewers-cap-theorem "Brewer's CAP Theorem"], julianbrowne.com, Retrieved 02-Mar-2010</ref><ref>[http://www.royans.net/wp/2010/02/14/brewers-cap-theorem-on-distributed-systems/ "Brewers CAP theorem on distributed systems"], royans.net</ref>

* ''[[Consistency (database systems)|Consistency]]'': Every read receives the most recent write or an error
* ''[[Availability]]'': Every request receives a (non-error) response – without the guarantee that it contains the most recent write
* ''[[Network partitioning|Partition tolerance]]'': The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

In particular, the CAP theorem implies that in the presence of a network partition, one has to choose between consistency and availability. Note that consistency as defined in the CAP theorem is quite different from the consistency guaranteed in [[ACID]] [[database transaction]]s<ref>{{cite web |last1=Liochon |first1=Nicolas |title=The confusing CAP and ACID wording |url=http://blog.thislongrun.com/2015/03/the-confusing-cap-and-acid-wording.html |website=This long run |accessdate=1 February 2019}}</ref>.

== Explanation ==
No distributed system is safe from network failures, thus [[network partitioning]] generally has to be tolerated. In the presence of a partition, one is then left with two options: consistency or [[availability]]. When choosing consistency over availability, the system will return an error or a time-out if particular information cannot be guaranteed to be up to date due to network partitioning. When choosing availability over consistency, the system will always process the query and try to return the most recent available version of the information, even if it cannot guarantee it is up to date due to network partitioning.

In the absence of network failure – that is, when the distributed system is running normally – both availability and consistency can be satisfied.

CAP is frequently misunderstood as if one has to choose to abandon one of the three guarantees at all times. In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made.<ref>{{Cite web|url=https://dzone.com/articles/better-explaining-cap-theorem|title=Better explaining the CAP Theorem – DZone Big Data|website=dzone.com|access-date=2016-09-02}}</ref><ref>{{Cite web|url=http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html|title=DBMS Musings: Problems with CAP, and Yahoo's little known NoSQL system|last=Abadi|first=Daniel|date=2010-04-23|website=DBMS Musings|access-date=2018-01-23}}</ref>

Database systems designed with traditional [[ACID]] guarantees in mind such as [[Relational database management system|RDBMS]] choose consistency over availability, whereas systems designed around the [[Eventual consistency|BASE]] philosophy, common in the [[NoSQL]] movement for example, choose availability over consistency.<ref name="Brewer2012" />

The [[PACELC theorem]] builds on CAP by stating that even in the absence of partitioning, another trade-off between latency and consistency occurs.

== History ==

According to [[University of California, Berkeley]] computer scientist [[Eric Brewer (scientist)|Eric Brewer]], the theorem first appeared in autumn 1998.<ref name="Brewer2012">Eric Brewer, [http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed "CAP twelve years later: How the 'rules' have changed"], ''Computer'', Volume 45, Issue 2 (2012), pg. 23–29. {{doi|10.1109/MC.2012.37}}.</ref> It was published as the CAP principle in 1999<ref name="Brewer1999">Armando Fox and Eric Brewer, "Harvest, Yield and Scalable Tolerant Systems", ''Proc. 7th Workshop Hot Topics in Operating Systems (HotOS 99)'', IEEE CS, 1999, pg. 174–178. {{DOI|10.1109/HOTOS.1999.798396}}</ref> and presented as a [[conjecture]] by Brewer at the 2000 [[Symposium on Principles of Distributed Computing]] (PODC).<ref name="Brewer2000">Eric Brewer, [http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf "Towards Robust Distributed Systems"]</ref> In 2002, [[Seth Gilbert]] and [[Nancy Lynch]] of [[MIT]] published a formal proof of Brewer's conjecture, rendering it a [[theorem]].<ref name="Gilbert Lynch"/>

In 2012, Brewer clarified some of his positions, including why the often-used "two out of three" concept can be misleading or misapplied, and the different definition of consistency used in CAP relative to the one used in [[ACID]].<ref name="Brewer2012" />

A similar theorem stating the trade-off between consistency and availability in distributed systems was published by Birman and Friedman in 1996.<ref>Ken Birman and Roy Friedman, "[https://ecommons.cornell.edu/handle/1813/7235 Trading Consistency for Availability in Distributed Systems]", April 1996. {{hdl|1813/7235}}.</ref> The result of Birman and Friedman restricted this lower bound to non-commuting operations.

== See also ==
* [[PACELC theorem]]
* [[Consistency model]]
* [[Fallacies of distributed computing]]
* [[Paxos (computer science)]]
* [[Project management triangle]]
* [[Raft (computer science)]]
* [[Trilemma]]

== References ==
{{reflist}}

== External links ==
* [http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed CAP Twelve Years Later: How the "Rules" Have Changed] Brewer's 2012 article on CRDTs (conflict free replicated data types).
* [https://research.google.com/pubs/pub45855.html Spanner, TrueTime and the CAP Theorem]
* [https://link.springer.com/content/pdf/bfm%3A978-1-4842-4501-9%2F1.pdf Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns. Apress. ISBN 978-1484245002.] Chapter 11. Events, Eventuality, and Consistency. Page 333: CAP Pyramid).

{{DEFAULTSORT:Cap Theorem}}
[[Category:Distributed computing]]
{{bots|deny=tagbot}}

Command–query separation

2019-07-23T06:17:29Z

Biniljava: /* Added new External link as reference */

{{refimprove|date=February 2008}}
'''Command–query separation''' ('''CQS''') is a principle of [[Imperative programming|imperative]] [[computer programming]]. It was devised by [[Bertrand Meyer]] as part of his pioneering work on the [[Eiffel (programming language)|Eiffel programming language]].

It states that every [[Method (computer science)|method]] should either be a ''command'' that performs an action, or a ''query'' that returns data to the caller, but not both. In other words, ''Asking a question should not change the answer''.<ref>{{cite web |last=Meyer|first=Bertrand|title=Eiffel: a language for software engineering|url=http://laser.inf.ethz.ch/2012/slides/Meyer/eiffel_laser_2012.pdf|page=22|accessdate=16 December 2014}}</ref> More formally, methods should return a value only if they are [[Referential transparency (computer science)|referentially transparent]] and hence possess no [[Side effect (computer science)|side effect]]s.

==Connection with design by contract==
Command–query separation is particularly well suited to a [[design by contract]] (DbC) methodology, in which the design of a [[Computer program|program]] is expressed as [[Assertion (software development)|assert]]ions embedded in the [[source code]], describing the [[State (computer science)|state]] of the program at certain critical times. In DbC, assertions are considered design annotations – not program logic – and as such, their execution should not affect the program state. CQS is beneficial to DbC because any value-returning method (any query) can be called by any assertion without fear of modifying program state.

In theoretical terms, this establishes a measure of sanity, whereby one can reason about a program's state without simultaneously modifying that state. In practical terms, CQS allows all assertion checks to be bypassed in a working system to improve its performance without inadvertently modifying its behaviour. CQS may also prevent the occurrence of certain kinds of [[heisenbug]]s.

==Broader impact on software engineering==
Even beyond the connection with design by contract, CQS is considered by its adherents to have a simplifying effect on a program, making its states (via queries) and state changes (via commands) more comprehensible.{{citation needed|date=December 2014}}

CQS is well-suited to the [[object-oriented programming|object-oriented]] methodology, but can also be applied outside of object-oriented programming. Since the separation of side effects and return values is not inherently object-oriented, CQS can be profitably applied to any programming paradigm that requires reasoning about side effects.{{citation needed|date=December 2014}}

==Other Architectural Patterns==
* As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI.
* CQRS fits well with event-based programming models. It's common to see a CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of Event Sourcing.
* Having separate models raises questions about how hard is to keep those models consistent, which raises the likelihood of using eventual consistency.
* For many domains, much of the logic requiredis needed when you're updating, so it may make sense to use Eager Read Derivation to simplify your query-side models.
* If the write model generates events for all updates, you can structure read models as Event Posters, allowing them to be Memory Images and thus avoiding a lot of database interactions.
* CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design. <ref>{{cite web|url=https://www.ukad-group.com/blog/what-is-cqrs-and-when-to-use-it/|title=What is CQRS|accessdate=2019-06-27 |publisher=What is CQRS}}</ref>

==Command query responsibility segregation==
Command query responsibility segregation (CQRS) applies the CQS principle by using separate ''Query'' and ''Command'' objects to ''retrieve'' and ''modify'' data, respectively.<ref>{{cite web|last=Young|first=Greg|title=CQRS Documents|url=http://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf|accessdate=2012-12-28}}</ref><ref>{{cite web|last=Fowler|first=Martin|title=CQRS|url=http://martinfowler.com/bliki/CQRS.html|accessdate=2011-07-14}}</ref>

123

==See also==
*[[Fluent interface]]

==References==
{{Reflist}}

==Further reading==
*{{cite book
| first = Bertrand
| last = Meyer
| authorlink = Bertrand Meyer
| origyear = 1988
| date = September 1994
| title = Object-oriented Software Construction
| publisher = Prentice Hall
| isbn = 0-13-629049-3
}}

==External links==
*[http://martinfowler.com/bliki/CommandQuerySeparation.html Explanation on Martin Fowler's Bliki]
*[https://cqrsjourney.github.com CQRS Journey by Microsoft patterns & practices]
*[https://groups.google.com/group/dddcqrs DDD/CQRS/Event Sourcing List]
*[http://www.cqrs.nu The CQRS Frequently Asked Questions]
*[http://www.h-online.com/developer/features/CQRS-an-architecture-precept-based-on-segregation-of-commands-and-queries-1803276.html CQRS - a new architecture precept based on segregation of commands and queries]
*[https://link.springer.com/content/pdf/bfm%3A978-1-4842-4501-9%2F1.pdf Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns. Chapter 5 : Essential Patterns for Microservices: Apress. ISBN 978-1484245002.]

{{DEFAULTSORT:Command-query separation}}
[[Category:Programming principles]]
[[Category:Object-oriented programming]]

Distributed transaction

2019-07-22T06:17:49Z

Biniljava: /* Added new Reference material */

A '''distributed transaction''' is a [[database transaction]] in which two or more network hosts are involved. Usually, hosts provide '''transactional resources''', while the '''transaction manager''' is responsible for creating and managing a global transaction that encompasses all operations against such resources. Distributed transactions, as any other [[Database transaction|transactions]], must have all four [[ACID|ACID (atomicity, consistency, isolation, durability)]] properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).

Open Group, a vendor consortium, proposed the [[X/Open XA|X/Open Distributed Transaction Processing (DTP) Model]] (X/Open XA), which became a de facto standard for behavior of transaction model components.

Databases are common transactional resources and, often, transactions span a couple of such databases. In this case, a distributed transaction can be seen as a [[database transaction]] that must be [[Synchronization|synchronized]] (or provide [[ACID]] properties) among multiple participating [[database]]s which are [[distributed computing|distributed]] among different physical locations. The [[isolation (computer science)|isolation]] property (the I of ACID) poses a special challenge for multi database transactions, since the (global) [[serializability]] property could be violated, even if each database provides it (see also [[global serializability]]). In practice most commercial database systems use [[Two phase locking#Strong_strict_two-phase_locking|strong strict two phase locking (SS2PL)]] for [[concurrency control]], which ensures global serializability, if all the participating databases employ it. (see also [[commitment ordering]] for multidatabases.)

A common [[algorithm]] for ensuring [[correctness (computer science)|correct]] completion of a distributed transaction is the [[two-phase commit]] (2PC). This algorithm is usually applied for updates able to [[commit (data management)|commit]] in a short period of time, ranging from couple of milliseconds to couple of minutes.

There are also long-lived distributed transactions, for example a transaction to book a trip, which consists of booking a flight, a rental car and a hotel. Since booking the flight might take up to a day to get a confirmation, two-phase commit is not applicable here, it will lock the resources for this long. In this case more sophisticated techniques that involve multiple undo levels are used. The way you can undo the hotel booking by calling a desk and cancelling the reservation, a system can be designed to undo certain operations (unless they are irreversibly finished).

In practice, long-lived distributed transactions are implemented in systems based on [[Web Services]]. Usually these transactions utilize principles of [[compensating transaction]]s, Optimism and Isolation Without Locking. X/Open standard does not cover long-lived DTP.

Several modern technologies, including [[Enterprise Java Beans]] (EJBs) and [[Microsoft Transaction Server]] (MTS) fully support distributed transaction standards.

==See also==
* [[Java Transaction API|Java Transaction API (JTA)]]
* [[Enduro/X|Enduro/X Open source X/Open XA and XATMI implementation]]

==References==
* {{cite web | title=Web-Services Transactions | work=Web-Services Transactions | url=http://xml.sys-con.com/read/43755.htm | accessdate=May 2, 2005 }}
* {{cite web | title=Nuts And Bolts Of Transaction Processing | work=Article about Transaction Management | url=http://comet.lehman.cuny.edu/cocchi/CIS256/StudentReading/TransactionProcessing.doc
| accessdate=May 3, 2005 }}
* {{cite web | title=A Detailed Comparison of Enterprise JavaBeans (EJB) & The Microsoft Transaction Server (MTS) Models
| url=http://gsraj.tripod.com/misc/ejbmtscomp.html }}
* {{cite web | title=Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns. Chapter 13. Distributed Transactions: Apress. ISBN 978-1484245002. | url=https://link.springer.com/content/pdf/bfm%3A978-1-4842-4501-9%2F1.pdf }}

==Further reading==
* Gerhard Weikum, Gottfried Vossen, ''Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery'', Morgan Kaufmann, 2002, {{ISBN|1-55860-508-8}}

{{DEFAULTSORT:Distributed Transaction}}
[[Category:Data management]]
[[Category:Transaction processing]]

Microservices

2019-07-17T03:51:42Z

Biniljava: /* Added a new Reference Material */

{{unreliable sources|date=October 2018}}

'''Microservices''' are a [[software development]] technique—a variant of the [[service-oriented architecture]] (SOA) architectural style that structures an [[application (computing)|application]] as a collection of [[Coupling (computer programming)|loosely coupled]] services. In a microservices architecture, services are [[Service granularity principle|fine-grained]] and the [[protocol (computing)|protocol]]s are lightweight. The benefit of decomposing an application into different smaller services is that it improves [[Modular programming|modularity]]. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.<ref name="Micro_Chen">{{cite conference

|url= https://www.researchgate.net/publication/323944215
|title= Microservices: Architecting for Continuous Delivery and DevOps
|first= Lianping |last= Chen
|date= 2018
|conference= The IEEE International Conference on Software Architecture (ICSA 2018)
|conferenceurl= http://icsa-conferences.org/2018/
|publisher= IEEE
}}
</ref> It parallelizes [[software development|development]] by enabling small autonomous teams to develop, [[software deployment|deploy]] and scale their respective services independently.<ref>{{Cite web|url=http://microservices.io/patterns/microservices.html|title=Microservice architecture pattern|last=Richardson|first=Chris|date=|website=microservices.io|archive-url=|archive-date=|dead-url=|access-date=2017-03-19}}</ref> It also allows the architecture of an individual service to emerge through continuous [[refactoring]].<ref name="Ach_Chen">{{cite conference
|title= Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development
|first= Lianping |last= Chen
|first2= Muhammad|last2= Ali Babar|date= 2014
|conference= The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)
|conferenceurl= https://web.archive.org/web/20140730053f454/http://wicsa2014.org/
|publisher= IEEE
|doi = 10.1109/WICSA.2014.45}}
</ref> Microservice-based architectures enable [[continuous delivery]] and deployment.<ref>{{Cite journal|last=Balalaie|first=Armin|last2=Heydarnoori|first2=Abbas|last3=Jamshidi|first3=Pooyan|date=May 2016|title=Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|journal=IEEE Software|volume=33|issue=3|pages=42–52|doi=10.1109/ms.2016.64|issn=0740-7459|hdl=10044/1/40557}}</ref>

== Introduction ==
Even though there is no official definition of what microservices are, a consensus view has evolved over time, in the industry. Some of the defining characteristics that are frequently cited include:
* Per [[Martin Fowler (software engineer)|Martin Fowler]] and other experts, services in a microservice architecture (MSA) are often [[Process (computing)|processes]] that communicate over a [[Computer network|network]] to fulfill a goal using technology-agnostic [[Communications protocol|protocols]] such as HTTP.<ref name="martinfowler">{{cite web|url=http://martinfowler.com/articles/microservices.html|title=Microservices|author=Martin Fowler|archive-url=https://web.archive.org/web/20180214171522/https://martinfowler.com/articles/microservices.html|archive-date=14 February 2018|dead-url=no}}</ref><ref>{{cite book|title=Building Microservices|last=Newman|first=Sam|publisher=O'Reilly Media|isbn=978-1491950357|date=2015-02-20}}</ref><ref>{{cite book|url=http://microservices-book.com|title=Microservices: Flexible Software Architectures|isbn=978-0134602417|last1=Wolff|first1=Eberhard|date=2016-10-12}}</ref>
* Services in a microservice architecture are independently deployable.<ref name="NMMA16">Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016</ref><ref name="Micro_Chen"/>
* Services are organized around fine-grained business capabilities. The granularity of the microservice is important - because this is key to how this approach is different from [[Service-oriented architecture|SOA.]]
* Services can be implemented using different [[programming language]]s, [[database]]s, hardware and software environment, depending on what fits best.<ref name="Micro_Chen"/> This does not mean that a single microservice is written in a patchwork of programming languages. While it is almost certainly the case that different components that the service is composed of will require different languages or APIs (example, the web server layer may be in Java or Javascript, but the database may use SQL to communicate to an RDBMS), this is really reflective of a comparison to the monolithic architecture style. If a monolithic application were to be re-implemented as a set of microservices, then the individual services could pick their own implementation languages. So one microservice could pick Java for the web layer, and another microservice could pick a [[Node.js]]-based implementation, but within each microservice component, the implementation language would be uniform.
* Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and [[Build automation|built]] and [[Application release automation|released with automated processes]].<ref name="NMMA16" />

A microservice is ''not'' a layer within a monolithic application (example, the web controller, or the backend-for-frontend<ref>{{cite web |title=Backends For Frontends Pattern |url=https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends |website=Microsoft Azure Cloud Design Patterns |publisher=Microsoft}}</ref>). Rather it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategy perspective, microservices architecture essentially follows the [[Unix philosophy]] of "Do one thing and do it well".<ref>{{cite book|asin= B00VJ3NP4A|title= Microservices: Patterns and Applications|author= Lucas Krause}}</ref> [[Martin Fowler (software engineer)|Martin Fowler]] describes a microservices-based architecture as having the following properties:<ref name="martinfowler"/>
* Naturally enforces a [[Modular programming|modular]] structure.<ref>[https://www.forbes.com/sites/oracle/2019/01/07/grails-founder-what-java-developers-dont-know-about-memory-can-cost-them-money-in-the-cloud/#3e7ab84a44e1 Grails Founder: What Java Developers Don’t Know About Memory Can Cost Them Money in the Cloud] ''[[Forbes]]'' Retrieve 9 January 2019</ref>
* Lends itself to a [[continuous delivery]] software development process. A change to a small part of the application only requires rebuilding and redeploying only one or a small number of services.<ref>[https://docs.microsoft.com/en-us/azure/architecture/microservices/ci-cd Designing microservices: Continuous integration] ''[[Microsoft]]'' Retrieved 9 January 2018</ref>
* Adheres to principles such as [[Service granularity principle|fine-grained]] [[software interface|interface]]s (to independently deployable services), business-driven development (e.g. [[domain-driven design]]).<ref>Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. {{ISBN|978-0-596-52955-0}}.</ref>

It is quite common for such an architectural style to be adopted for [[cloud application|cloud-native applications]], and applications using lightweight [[operating-system-level virtualization|container]] deployment. As explained<ref>{{cite web|url=https://martinfowler.com/bliki/MicroservicePrerequisites.html|title=Microservice Prerequisites|author=Martin Fowler|author-link=Martin Fowler (software engineer)}}</ref> by Martin Fowler, because of the large number (when compared to monolithic application implementations) of services, decentralized continuous delivery and [[DevOps]] with holistic service monitoring are necessary to effectively develop, maintain, and operate such applications. A consequence of (and rationale for) following this approach is that the individual microservices can be individually scaled. In the monolithic approach, an application supporting three functions would have to be scaled in its entirety even if only one of these functions had a resource constraint.<ref>{{cite book |last1=Richardson |first1=Chris |title=Microservice Patterns |date=November 2018 |publisher=Manning Publications |location=Chapter 1, section 1.4.1 Scale cube and microservices |isbn=9781617294549}}</ref> With microservices, only the microservice supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits.

== History ==
A workshop of software architects held near Venice in May 2011 used the term "microservice" to describe what the participants saw as a common architectural style that many of them had been recently exploring {{citation needed|date=November 2018}}. In May 2012, the same group decided on "microservices" as the most appropriate name. James Lewis presented some of those ideas as a [[case study]] in March 2012 at 33rd Degree in Kraków in Microservices - Java, the Unix Way, as did Fred George about the same time. [[Adrian Cockcroft]] at Netflix, describing this approach as "fine grained SOA", pioneered the style at web scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher and Graham Tackley.<ref>
{{cite web
|author= James Lewis and Martin Fowler
|title= Microservices
|url= http://martinfowler.com/articles/microservices.html
}}
</ref>

Dr. Peter Rodgers introduced the term "Micro-[[web service|Web-Services]]" during a presentation at the Web Services Edge conference in 2005. On slide #4 of the conference presentation, he states that "[[Software component]]s are Micro-Web-Services".<ref>{{cite web|last1=Rodgers|first1=Peter|title=Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity Web Services Edge 2005 East: CS-3|url=http://www.cloudcomputingexpo.com/node/80883|website=CloudComputingExpo 2005|publisher=SYS-CON TV|accessdate=3 July 2017}}</ref> Juval Löwy had similar precursor ideas about classes being [[Granularity#Computing|granular]] services, as the next evolution of [[Microsoft]] architecture.<ref>{{cite web|last1=Löwy|first1=Juval|title=Every Class a WCF Service|url=https://channel9.msdn.com/Shows/ARCast.TV/ARCastTV-Every-Class-a-WCF-Service-with-Juval-Lowy|website= Channel9, ARCast.TV|date=October 2007}}</ref><ref>{{cite book |author= Löwy, Juval |title= Programming WCF Services 1st Edition |pages= 543–553|date= 2007}}</ref><ref>{{cite web|last1=Löwy|first1=Juval|title=Every Class As a Service|url=https://www.youtube.com/watch?v=w-Hxc6uWCPg|website=Microsoft TechEd Conference, SOA206|archiveurl=https://blogs.msdn.microsoft.com/drnick/2009/04/29/wcf-at-teched-2009/|archive-date= 2010|date=May 2009}}</ref> "Services are composed using [[Pipeline (Unix)|Unix-like pipelines]] (the [[WWW|Web]] meets Unix = true [[Loose coupling|loose-coupling]]). Services can call services (+multiple language run-times). Complex service-assemblies are abstracted behind simple [[URI]] interfaces. Any service, at any granularity, can be exposed." He described how a well-designed service platform "applies the underlying architectural principles of the [[WWW|Web]] and Web services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity by providing a platform to apply service-oriented architecture throughout your application environment".<ref>{{cite web|last1= Rodgers|first1= Peter|title= Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity|url= http://www.cloudcomputingexpo.com/node/80883|website= CloudComputingExpo|publisher= SYS-CON Media|accessdate= 19 August 2015}}</ref> The design, which originated in a research project at [[Hewlett Packard Labs]], aims to make code less brittle and to make large-scale, complex software systems [[Robustness (computer science)|robust]] to change.<ref>{{cite web|last1= Russell|first1= Perry|last2=Rodgers|first2= Peter|last3= Sellman|first3= Royston|title= Architecture and Design of an XML Application Platform|url= http://www.hpl.hp.com/techreports/2004/HPL-2004-23.html|website= HP Technical Reports|accessdate= 20 August 2015|pages= 62|date= 2004}}</ref> To make "Micro-Web-Services" work, one has to question and analyze the foundations of architectural styles (such as [[Service-oriented architecture|SOA]]) and the role of messaging between software components in order to arrive at a new general computing abstraction.<ref>{{cite journal|last1= Hitchens|first1= Ron|editor1-last= Swaine|editor1-first= Michael|title= Your Object Model Sucks|journal= PragPub Magazine|date= Dec 2014|page= 15}}</ref> In this case, one can think of [[resource-oriented computing]] (ROC) as a generalized form of the Web abstraction. If in the Unix abstraction "[[everything is a file]]", in ROC, everything is a "Micro-Web-Service". It can contain information, code or the results of computations so that a service can be either a consumer or producer in a symmetrical and evolving architecture.

Microservices is a specialization of an implementation approach for [[service-oriented architecture]]s (SOA) used to build flexible, independently deployable [[distributed software|software systems]].<ref name="ieeeswi2">{{Cite journal|year=2017|title=Microservices in Practice, Part 1: Reality Check and Service Design|journal=IEEE Software|volume=34|issue=1|pages=91–98|doi=10.1109/MS.2017.24|last1=Pautasso|first1=Cesare}}</ref> The microservices approach is a first realisation of SOA that followed the introduction of [[DevOps]] and is becoming more popular for building [[Continuous deployment|continuously deployed]] systems.<ref>{{cite web|url=https://www.javacodegeeks.com/2014/12/continuous-deployment-strategies.html|title=Continuous Deployment: Strategies|date=|author=|work=javacodegeeks.com|accessdate=28 December 2016}}</ref>

== Service Granularity ==
A key step in defining a microservice architecture is figuring out how big an individual microservice has to be. There is no consensus or litmus test for this, as the right answer depends on the business and organizational context. [[Amazon (company)|Amazon]]'s policy is that the team implementing a microservice should be small enough that they can be fed by two pizzas.<ref name="martinfowler"/> Many organizations choose smaller "squads" - typically 6 to 8 developers. But the key decision hinges around how "clean" the service boundary can be.

On the opposite side of the spectrum, it is considered a bad practice to make the service too small, as then the runtime overhead and the operational complexity can overwhelm the benefits of the approach. When things get too fine-grained, alternative approaches must be considered - such as packaging the function as a library, or by placing the function into other microservices.{{citation needed|date=January 2019}}

== Linguistic approach ==
A linguistic approach to the development of microservices<ref name="jolie-2">{{cite web|url=http://claudioguidi.blogspot.it/2017/03/what-microservice-from-linguisitc.html|title=What is a microservice? (from a linguistic point of view) |author=Claudio Guidi|date=2017-03-29 }}</ref> focuses on selecting a programming language that can easily represent a microservice as a single software artifact. When effective, the gap between architecting a project and deploying it can be minimized.{{citation needed|date=October 2018}}

One language intended to fill this role is [[Jolie (programming language)|Jolie]].<ref name="jolie-1">{{cite web|url=http://www.jolie-lang.org/vision.html|title=Vision of microservices revolution |author=Jolie Team}}</ref><ref name="jolie-3">{{cite web|url=https://fmontesi.github.io/2015/02/06/programming-microservices-with-jolie.html|title = Programming Microservices with Jolie - Part 1: Data formats, Proxies, and Workflows.|author=Fabrizio Montesi}}</ref>

== Technologies ==

Computer microservices can be implemented in different programming languages and might use different infrastructures. Therefore the most important technology choices are the way microservices communicate with each other (synchronous, asynchronous, UI integration) and the protocols used for the communication (REST, messaging, ...). In a traditional system most technology choices like the programming language impact the whole systems. Therefore the approach for choosing technologies is quite different.<ref>{{cite book|url=http://practical-microservices.com|title=Microservices - A Practical Guide|isbn=978-1717075901|last1=Wolff|first1=Eberhard|date=2018-04-15}}</ref>

The [[Eclipse Foundation]] has published a specification for developing microservices, Eclipse MicroProfile.<ref>{{cite web|url=https://projects.eclipse.org/projects/technology.microprofile|title=Eclipse MicroProfile|first=Stephanie|last=Swart|date=14 December 2016|website=projects.eclipse.org}}</ref>

== Service mesh ==

In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as [[Kubernetes]].
The service proxies are responsible for communication with other service instances and can support capabilities such as service (instance) discovery, load balancing, authentication and authorization, secure communications, and others.

In a service mesh, the service instances and their sidecar proxies are said to make up the data plane, which includes not only data management but also request processing and response. The service mesh also includes a control plane for managing the interaction between services, mediated by their sidecar proxies. There are several options for service mesh architecture: [[Istio]] (a joint project among Google, IBM, and Lyft), [[Linux_Foundation#Linkerd|Linkerd]] (CNCF project led by [[Buoyant]]<ref>{{cite web |title=What's a service mesh? |url=https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ |website=Buoyant |publisher=Buoyant |accessdate=5 December 2018|date=2017-04-25 }}</ref>) and others.

== Criticism ==
The microservices approach is subject to criticism for a number of issues:
* Services form information barriers.<ref name= "infoq-1">{{cite web|url= http://www.infoq.com/news/2014/08/failing-microservices|title=Experiences from Failing with Microservices| first =Jan | last = Stenberg|date=11 August 2014}}</ref>
* Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process [[function call|calls]] within a [[monolithic system|monolithic]] service process.<ref name= "martinfowler" />
* [[Software testing|Testing]] and [[Software deployment|deployment]] are more complicated.<ref name= "infoqbook" />
* Moving responsibilities between services is more difficult.<ref name= "Micro_Chen"/> It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure.<ref name= "martinfowler" />
* Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.<ref>{{cite web |url= https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/ |title=How small should your microservice be? |last=Tilkov |first=Stefan |date= 17 November 2014 |website= Innoq |access-date=4 January 2017}}</ref>
* Two-phased commits are regarded as an anti-pattern in microservices-based architectures as this results in a tighter coupling of all the participants within the transaction. However, lack of this technology causes awkward dances which have to be implemented by all the transaction participants in order to maintain data consistency.<ref>{{cite book |last1= Richardson |first1= Chris |title= Microservice Patterns |date= November 2018 |publisher= Manning Publications |location=Chapter 4. Managing transactions with sagas|isbn= 978-1-61729454-9}}</ref>
* Development and support of many services is more challenging if they are built with different tools and technologies - this is especially a problem if engineers move between projects frequently.

===Cognitive load===
The architecture introduces additional complexity and new problems to deal with, such as [[network latency]], [[message format]]s, [[Load balancing (computing)|load balancing]] and [[fault tolerance]].<ref name= "ieeeswmsip2">{{Cite journal|year= 2017|title= Microservices in Practice, Part 2: Service Integration and Sustainability |journal= IEEE Software |volume=34|issue=2|pages= 97–104|doi=10.1109/MS.2017.56 |last1=Pautasso|first1= Cesare}}</ref><ref name= "infoqbook">{{cite web|url= http://www.infoq.com/presentations/microservices-pass-spring-cloud-foundry|title=Developing Microservices for PaaS with Spring and Cloud Foundry}}</ref> All of these problems have to be addressed at scale.

The complexity of a [[monolithic application]] doesn't disappear if it gets re-implemented as a set of microservice applications. Some of the complexity gets translated into operational complexity.<ref>{{cite web|author-link = Martin Fowler (software engineer)| first = Martin | last = Fowler |url= https://www.martinfowler.com/articles/microservice-trade-offs.html#ops |title=Microservice Trade-Offs}}</ref> Other places where the complexity manifests itself is in the increased network traffic and resulting slower performance. Also, an application made up of any number of microservices has a larger number of interface points to access its respective [[software ecosystem|ecosystem]], which increases the architectural complexity.<ref>{{cite news|title= BRASS Building Resource Adaptive Software Systems |agency= DARPA |publisher=U.S. Government |date= April 7, 2015}} "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented [[application programming interface]]s (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with."</ref> Various organizing principles (such as [[HATEOAS]], interface and data model documentation captured via [[Swagger (software)|Swagger]], etc.) have been applied to reduce the impact of such additional complexity.

== A comparison of platforms ==
Prior to Kubernetes and its ecosystem of tools being developed, implementing a [[microservice]] architecture was hard because of the lack of popular frameworks. There are many concerns (see table below) that any microservice architecture needs to address. [[Netflix]] developed a microservice framework to support their internal applications, and then open-sourced<ref>{{Citation | publisher = Git Hub | url = https://netflix.github.io/ | title = Netflix OSS}}</ref> many portions of that framework. Many of these tools have been popularized via the [[Spring Framework]] – they have been re-implemented as Spring-based tools under the umbrella of the Spring Cloud<ref>{{Citation | url = http://spring.io/projects/spring-cloud | publisher = Spring | title = Cloud}}</ref> project. The table below shows a comparison of an implementing feature from the Kubernetes ecosystem with an equivalent from the Spring Cloud world.<ref>{{Citation | work = Developers | publisher = Red hat | date = 2016-12-09 | url = https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/ | title = Spring Cloud for Microservices Compared to Kubernetes}}</ref> One noteworthy aspect of the Spring Cloud ecosystem is that they are all Java-based technologies, whereas Kubernetes is a polyglot runtime platform.

{| class="wikitable" style="font-size: 85%; text-align: left; width: auto;"
|-
! Microservices concern
! Spring Cloud & Netflix OSS
! Kubernetes
|-
| Configuration management: configuration for a microservice application needs to be externalized from the code and be retrievable via a simple service call.
| Spring Config Server, Netflix Archaius both support a Git-repository--based location for configuration. Archaius supports data typing of configuration.
| Kubernetes ConfigMaps exposes the configuration stored in etcd via services. Kubernetes Secrets supports the service-based secure deployment and usage of sensitive configuration information (such as passwords, certificates, etc.).
|-
| [[Service discovery]]: maintain a list of service instances that are available for work within a microservice domain.
| Spring Cloud Eureka allows clients to register to it, maintains a heartbeat with registered clients, and maps service names to hostnames for clients that look up services by service name.
| Kubernetes Services provide deployment-time registration of instances of services that are internally available within the cluster. Ingress is a mechanism whereby a service can be exposed to clients outside the cluster.
|-
| Load balancing: The key to scaling a distributed system is being able to run more than one instance of a component. Load has to be then distributed across those instances via a load balancer.
| Spring Cloud Ribbon provides the ability for service clients to load balance across instances of the service.
| Kubernetes Service provides the ability for the service to be load-balanced across service instances. This is not the equivalent of what Ribbon provides.
|-
| API gateway: The granularity of APIs provided by microservices is often different than what a service client needs. API Gateways implement facades and provide additional services like proxying, and protocol translation, and other management functions.
| Spring Cloud Zuul provides configuration-based API facades
| Kubernetes Service and Ingress resources, Istio, Ambassador are solutions that provide both north-south (traffic into and out of data center) as well as east-west (traffic across data centers or clouds or regions) API gateway functions.
|-
| Security concerns: Many security concerns are pushed to the API gateway implementation. With distributed microservice applications, it makes sense to not reinvent the security wheel and allow for policy definition and implementation in components that are shared by all services.
| Spring Cloud Security addresses many security concerns through Spring Cloud Zuul
| The Kubernetes ecosystem provides service meshes like Istio, which are capable of providing security through their API gateway mechanisms.
|-
| Centralized logging: It is important to have a centralized log gathering and analysis infrastructure to manage a plethora of services – many of which are operating in a distributed fashion.
| ELK Stack ([[Elasticsearch]], LogStash, [[Kibana]])
| EFK Stack ([[Elasticsearch]], [[Fluentd]], [[Kibana]])
|-
| Centralized metrics: A centralized area where the health and performance of the individual and overall system is essential to proper operations.
| Spring Spectator & Atlas
| Heapster, Prometheus, & Grafana
|-
| Distributed tracing: Per-process logging and metric monitoring have their place, but neither can reconstruct the complex paths that transactions take as they propagate across a distributed system. Distributed tracing is an essential tool for a microservices platform.
| Spring Cloud Sleuth
| Hawkular
|-
| Resilience and fault tolerance: Distributed systems must be capable of auto-routing around failures, and be capable of routing requests to the service instance that will provide an optimum response.
| Spring Hystrix, Turbine, & Ribbon
| Health check, [[#Service mesh|service meshes]] (example: Istio)<ref>{{Citation | publisher = Kubernetes | date = May 2017 | url = https://kubernetes.io/blog/2017/05/managing-microservices-with-istio-service-mesh/ | title = Managing microservices with the Istio service mesh}}</ref>
|-
| Autoscaling and self-healing: Distributed systems respond to higher load by scaling horizontally: the platform must detect and auto-respond to such conditions. Furthermore, the system needs to detect failures and attempt auto-restarts without operator input.
| -
| Health check, self-healing and auto-scaling
|-
| Packaging, deployment and scheduling: Large-scale systems require robust package management, and deployment systems to manage rolling or blue-green deployments, and rollbacks if necessary. A scheduler helps determine which particular execution node a new set of services can be deployed to based on current conditions.
| Spring Boot, Apache Maven. The Spring Cloud system does not have a true scheduler.
| Docker, Rkt, Kubernetes Scheduler & Deployment, Helm<ref>{{Citation | url = https://helm.sh/ | publisher = Helm | title = The Kubernetes Package Manager}}</ref>
|-
| Job management: scheduled computations disconnected from any individual user requests
| Spring Batch
| Kubernetes Jobs and Scheduled Jobs
|-
| Singleton application: run specific services as a single instance of it within the entire system
| Spring Cloud Cluster
| Kubernetes Pods
|}

== Implementations ==
* [https://www.mulesoft.com/integration-solutions/api/microservices Mulesoft]
* Thorntail by [[Red Hat]]
* Helidon by [[Oracle Corporation|Oracle]]
* Meecrowave by [[The Apache Software Foundation|Apache]]

== See also ==
* [[Conway's law]]
* [[Cross-cutting concern]]
* [[DevOps]]
* [[Fallacies of distributed computing]]
* [[gRPC]]
* [[Microkernel]]
* [[Representational state transfer]] (REST)
* [[Service-oriented architecture]] (SOA)
* [[Unix philosophy]]
* [[Self-contained system (software)]]
* [[Serverless computing]]
* [[Web-oriented architecture]] (WOA)

== References ==
{{reflist|30em}}
44. Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud. Apress. ISBN-10: 1484245008. ISBN-13: 978-1484245002.

== Further reading ==
* S. Newman, Building Microservices – Designing Fine-Grained Systems, O'Reilly, 2015 {{isbn|978-1491950357}}
* I. Nadareishvili et al., [https://www.ca.com/content/dam/ca/us/files/ebook/microservice-architecture-aligning-principles-practices-and-culture.pdf Microservices Architecture – Aligning Principles, Practices and Culture], O’Reilly, 2016, {{isbn|978-1-491-95979-4}}
* SEI SATURN 2015 microservices workshop, https://github.com/michaelkeeling/SATURN2015-Microservices-Workshop
* Wijesuriya, Viraj Brian (2016-08-29) ''[http://www.slideshare.net/tyrantbrian/microservice-architecture-65505794 Microservice Architecture, Lecture Notes]'' - University of Colombo School of Computing, Sri Lanka
* Asanka Abeysinghe (2018-07-24) ''[https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md Cell-based Archtecture]'' - WSO2, Inc

[[Category:Architectural pattern (computer science)]]
[[Category:Service-oriented (business computing)]]

Long-running transaction

2019-04-11T06:54:04Z

Biniljava: /* References */ Added link to a new book

{{More sources|date=October 2015}}
'''Long-running transactions''' (also known as the '''saga interaction pattern'''<ref>{{cite book |last=Rotem-Gal-Oz |first= Arnon |date=September 24, 2012 |title=SOA Patterns |edition=1st |chapter=5.4 Saga |chapterurl=http://www.rgoarchitects.com/Files/SOAPatterns/Saga.pdf |publisher=Manning Publications |isbn=1933988266}}</ref>) are computer [[database transaction]]s that avoid [[lock (computer science)|locks]] on non-local resources, use compensation to handle failures, potentially aggregate smaller [[ACID]] transactions (also referred to as [[atomic transaction]]s), and typically use a coordinator to complete or abort the transaction. In contrast to [[rollback (data management)|rollback]] in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. For example, the compensating action for making a hotel reservation is canceling that reservation, possibly with a penalty.

A number of protocols have been specified for long-running transactions using Web services within business processes. OASIS Business Transaction Processing<ref>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=business-transaction</ref> and WS-CAF<ref>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf</ref> are examples. These protocols use a coordinator to mediate the successful completion or use of compensation in a long-running transaction.

==See also==
*[[Optimistic concurrency control]]
*[[Long-lived transaction]]

==References==
{{Reflist}}

[[Category:Data management]]
[[Category:Transaction processing]]
4. Christudas, Binildas (October 2019). [https://www.amazon.com/Practical-Microservices-Architectural-Patterns-Event-Based/dp/1484245008 Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud]: Apress Publications. ISBN-10: 1484245008, ISBN-13: 978-1484245002, Language: English; Chapter 15

Command–query separation

2019-04-11T06:18:30Z

Biniljava: /* References */

{{refimprove|date=February 2008}}
'''Command–query separation''' ('''CQS''') is a principle of [[Imperative programming|imperative]] [[computer programming]]. It was devised by [[Bertrand Meyer]] as part of his pioneering work on the [[Eiffel (programming language)|Eiffel programming language]].

It states that every [[Method (computer science)|method]] should either be a ''command'' that performs an action, or a ''query'' that returns data to the caller, but not both. In other words, ''Asking a question should not change the answer''.<ref>{{cite web |last=Meyer|first=Bertrand|title=Eiffel: a language for software engineering|url=http://laser.inf.ethz.ch/2012/slides/Meyer/eiffel_laser_2012.pdf|page=22|accessdate=16 December 2014}}</ref> More formally, methods should return a value only if they are [[Referential transparency (computer science)|referentially transparent]] and hence possess no [[Side effect (computer science)|side effect]]s.

==Connection with design by contract==
Command–query separation is particularly well suited to a [[design by contract]] (DbC) methodology, in which the design of a [[Computer program|program]] is expressed as [[Assertion (software development)|assert]]ions embedded in the [[source code]], describing the [[State (computer science)|state]] of the program at certain critical times. In DbC, assertions are considered design annotations – not program logic – and as such, their execution should not affect the program state. CQS is beneficial to DbC because any value-returning method (any query) can be called by any assertion without fear of modifying program state.

In theoretical terms, this establishes a measure of sanity, whereby one can reason about a program's state without simultaneously modifying that state. In practical terms, CQS allows all assertion checks to be bypassed in a working system to improve its performance without inadvertently modifying its behaviour. CQS may also prevent the occurrence of certain kinds of [[heisenbug]]s.

==Broader impact on software engineering==
Even beyond the connection with design by contract, CQS is considered by its adherents to have a simplifying effect on a program, making its states (via queries) and state changes (via commands) more comprehensible.{{citation needed|date=December 2014}}

CQS is well-suited to the [[object-oriented programming|object-oriented]] methodology, but can also be applied outside of object-oriented programming. Since the separation of side effects and return values is not inherently object-oriented, CQS can be profitably applied to any programming paradigm that requires reasoning about side effects.{{citation needed|date=December 2014}}

==Command query responsibility segregation==
Command query responsibility segregation (CQRS) applies the CQS principle by using separate ''Query'' and ''Command'' objects to ''retrieve'' and ''modify'' data, respectively.<ref>{{cite web|last=Young|first=Greg|title=CQRS Documents|url=http://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf|accessdate=2012-12-28}}</ref><ref>{{cite web|last=Fowler|first=Martin|title=CQRS|url=http://martinfowler.com/bliki/CQRS.html|accessdate=2011-07-14}}</ref>

==Drawbacks==
CQS can make it more difficult to implement [[Reentrant (subroutine)|reentrant]] and [[Multithreading (software)|multithreaded]] software correctly. This usually occurs when a non-thread-safe pattern is used to implement the command–query separation.

Here is a simple example of a pattern that breaks CQS principles but is useful for multi-threaded software. It breaks CQS principles because the function both mutates state and returns it:
<source lang="java">
private int x;
public int increment_and_return_x() {
lock x; // by some mechanism
x = x + 1;
int x_copy = x;
unlock x; // by some mechanism
return x_copy;
}
</source>

Here is a CQS-compliant pattern. However, it is safely usable only in single-threaded applications. In a multithreaded program, there is a race condition in the caller, between where <code>increment()</code> and <code>value()</code> would be called:
<source lang="java">
private int x;
public int value() {
return x;
}
void increment() {
x = x + 1;
}
</source>

Even in single-threaded programs, it is sometimes arguably significantly more convenient to have a method that is a combined query and command. [[Martin Fowler (software engineer)|Martin Fowler]] cites the <code>pop()</code> method of a [[Stack (abstract data type)|stack]] as an example.<ref>{{cite web|last=Fowler|first=Martin|title=CommandQuerySeparation|url=http://martinfowler.com/bliki/CommandQuerySeparation.html|accessdate=5 December 2005}}</ref>

==See also==
*[[Fluent interface]]

==References==
{{Reflist}}
2. Christudas, Binildas (October 2019). [https://www.amazon.com/Practical-Microservices-Architectural-Patterns-Event-Based/dp/1484245008 Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud]: Apress Publications. ISBN-10: 1484245008, ISBN-13: 978-1484245002, Language: English

==Further reading==
*{{cite book
| first = Bertrand
| last = Meyer
| authorlink = Bertrand Meyer
| origyear = 1988
| date = September 1994
| title = Object-oriented Software Construction
| publisher = Prentice Hall
| isbn = 0-13-629049-3
}}

==External links==
*[http://martinfowler.com/bliki/CommandQuerySeparation.html Explanation on Martin Fowler's Bliki]
*[https://cqrsjourney.github.com CQRS Journey by Microsoft patterns & practices]
*[https://groups.google.com/group/dddcqrs DDD/CQRS/Event Sourcing List]
*[http://www.cqrs.nu The CQRS Frequently Asked Questions]
*[http://www.h-online.com/developer/features/CQRS-an-architecture-precept-based-on-segregation-of-commands-and-queries-1803276.html CQRS - a new architecture precept based on segregation of commands and queries]

{{DEFAULTSORT:Command-query separation}}
[[Category:Programming principles]]
[[Category:Object-oriented programming]]

Jakarta Transactions

2019-04-11T06:15:08Z

Biniljava: /* References */ Added link to a new book

The '''Java Transaction API''' ('''JTA'''), one of the [[Java EE|Java Enterprise Edition]] (Java EE) [[Application programming interface|API]]s, enables [[distributed transaction]]s to be done across multiple [[X/Open XA]] resources in a [[Java (programming language)|Java]] environment. JTA is a specification developed under the [[Java Community Process]] as JSR 907. JTA provides for:

*demarcation{{Clarify|date=May 2012}} of transaction boundaries
*[[X/Open XA]] API allowing resources to participate in transactions.

==X/Open XA architecture==

In the X/Open XA architecture, a transaction manager or [[transaction processing monitor]] (TP monitor) coordinates the transactions across multiple resources such as databases and message queues. Each resource has its own resource manager. The resource manager typically has its own API for manipulating the resource, for example the [[Java Database Connectivity|JDBC]] API to work with relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, [[Commit (data management)|commit]] or [[Rollback (data management)|roll back]] the transactions. The application also communicates with the individual resources using their own API to modify the resource.

==JTA implementation of the X/Open XA architecture==
The JTA API consists of classes in two [[Java package]]s:
* {{Javadoc:EE|package=javax.transaction|javax/transaction}}
* {{Javadoc:EE|package=javax.transaction.xa|javax/transaction/xa}}

The JTA is modelled on the X/Open XA architecture, but it defines two different APIs for demarcating transaction boundaries. It distinguishes between an [[application server]] such as an [[Enterprise JavaBean|EJB]] server and an application component. It provides an interface, {{Javadoc:EE|package=javax.transaction|javax/transaction|TransactionManager}}, that is used by the application server itself to begin, commit and roll back the transactions. It provides a different interface, the {{Javadoc:EE|package=javax.transaction|javax/transaction|UserTransaction}}, that is used by general client code such as a servlet or an EJB to manage the transactions.

The JTA architecture requires that each resource manager must implement the {{Javadoc:EE|package=javax.transaction.xa|javax/transaction/xa|XAResource}} interface in order to be managed by the TP monitor. As stated previously, each resource will have its own specific API, for instance:
* relational databases use JDBC
* messaging services use [[Java Message Service|JMS]]
* generalized EIS ([[Enterprise Information System]]) resources {{Clarify|date=May 2012}} use [[Java EE Connector Architecture|Java EE Connector API]].

==Java Transaction API==
The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.

===UserTransaction interface===
The {{Javadoc:EE|package=javax.transaction|javax/transaction|UserTransaction}} interface provides the application the
ability to control transaction boundaries programmatically. This interface may be used
by Java client programs or EJB beans.

The {{Javadoc:EE|javax/transaction|UserTransaction|begin()}} method starts a global transaction and associates the
transaction with the calling thread. The transaction-to-thread association is managed
transparently by the Transaction Manager.

Support for nested transactions is not required. The UserTransaction.begin method
throws the NotSupportedException when the calling thread is already associated
with a transaction and the transaction manager implementation does not support nested
transactions.

Transaction context propagation between application programs is provided by the
underlying transaction manager implementations on the client and server machines.
The transaction context format used for propagation is protocol dependent and must be
negotiated between the client and server hosts. For example, if the transaction manager
is an implementation of the [[Java transaction service|JTS]] specification, it will use the transaction context
propagation format as specified in the CORBA OTS 1.1 specification. Transaction
propagation is transparent to application programs.

===@Transactional annotation===
The {{Javadoc:EE|package=javax.transaction|javax/transaction|Transactional}} annotation provides the application the
ability to control transaction boundaries declaratively. This annotation can be applied to any class that the Java EE specification
defines as a managed bean (which includes CDI managed beans).

The code sample below illustrates the usage of @Transactional in a request scoped CDI managed bean:

<source lang="java">
@RequestScoped
public class ExampleBean {

@Transactional
public void foo() { // A transaction is active here

// Do work

} // After the method returns transaction is committed or rolled back
}
</source>

Transactional behavior can be configured via an attribute on the annotation. The available options closely mirror those of the [[EJB#Transactions|EJB]] specification.

===@TransactionScoped annotation===
The {{Javadoc:EE|package=javax.transaction|javax/transaction|TransactionScoped}} annotation provides the application the
ability to declare that the scope during which a bean lives is tied to the time a given transaction is active.

The code sample below illustrates the usage of @TransactionScoped in a request scoped CDI managed bean:

<source lang="java">

@TransactionScoped
public class TxScopedBean {
public int number;

public int getNumber() {return number;}
public void setNumber(int number) {this.number = number;}
}

@RequestScoped
public class ExampleBean {

@Inject
private TxScopedBean txScopedBean;

@Transactional
public void foo() {
txScopedBean.setNumber(1);
}

@Transactional
public void bar() {
System.out.print(tXscopedBean.getNumber());
}
}
</source>

If method ''foo()'' is first called on a managed instance of ExampleBean and then subsequently method ''bar()'' is called, the number printed will be 0 and not 1. This is because each method had its own transaction and therefore its own instance of TxScopedBean. The number 1 that was set during the call to ''foo()'' will therefore not be seen during the call to ''bar()''.

==UserTransaction support in EJB server==
[[EJB]] servers are required to support the UserTransaction interface for use by EJB
beans with the BEAN value in the {{Javadoc:EE|package=javax.ejb|javax/ejb|TransactionManagement}} annotation (this is called bean-managed transactions or BMT). The UserTransaction
interface is exposed to EJB components through either the EJBContext interface using the
getUserTransaction method, or directly via injection using the general <code>@Resource</code> annotation. Thus, an EJB application does not interface with the
Transaction Manager directly for transaction demarcation; instead, the EJB bean relies
on the EJB server to provide support for all of its transaction work as defined in the
Enterprise JavaBeans Specification. (The underlying interaction between the EJB
Server and the TM is transparent to the application; the burden of implementing transaction management is on the EJB container and server provider.<ref>[http://cds-esd.sun.com/ESD24/JSCDL/ejb/3.0-fr/ejb-3_0-fr-spec-ejbcore.pdf?AuthParam=1269290256_bf79870723e592b88232b28f0bc403bc&TicketId=B%2Fw2nRyGS1lMTR1LO1BbkAHl&GroupName=CDS&FilePath=/ESD24/JSCDL/ejb/3.0-fr/ejb-3_0-fr-spec-ejbcore.pdf&File=ejb-3_0-fr-spec-ejbcore.pdf JSR 220: Enterprise JavaBeans,Version 3.0, EJB 3.0 Expert Group, Sun Microsystems, 2006]{{dead link|date=July 2017 |bot=InternetArchiveBot |fix-attempted=yes }}</ref>)

The code sample below illustrates the usage of UserTransaction via bean-managed transactions in an EJB session bean:

<source lang="java">
@Stateless
@TransactionManagement(BEAN)
public class ExampleBean {

@Resource
private UserTransaction utx;

public void foo() {
// start a transaction
utx.begin();

// Do work

// Commit it
utx.commit();
}
}
</source>

Alternatively, the UserTransaction can be obtained from the SessionContext:

<source lang="java">
@Stateless
@TransactionManagement(BEAN)
public class ExampleBean {

@Resource
private SessionContext ctx;

public void foo() {
UserTransaction utx = ctx.getUserTransaction();

// start a transaction
utx.begin();

// Do work

// Commit it
utx.commit();
}
}
</source>

Note though that in the example above if the <code>@TransactionManagement(BEAN)</code> annotation is omitted, a JTA transaction is automatically started whenever <code>foo()</code> is called and is automatically committed or rolled back when <code>foo()</code> is exited. Making use of a UserTransaction is thus not necessary in EJB programming, but might be needed for very specialized code.

==UserTransaction support in JNDI==
The UserTransaction should be available under <code>java:comp/UserTransaction</code> (if a JTA implementation is installed in the environment).

==See also==
{{Portal|Java (programming language)}}
* [[Java transaction service]]

==References==
{{Reflist}}
2. Christudas, Binildas (October 2019). [https://www.amazon.com/Practical-Microservices-Architectural-Patterns-Event-Based/dp/1484245008 Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud]: Apress Publications. ISBN-10: 1484245008, ISBN-13: 978-1484245002, Language: English; Chapter 13, Chapter 14 and Chapter 15

==External links==
* [http://www.oracle.com/technetwork/java/javaee/jta/index.html JTA specifications]
* [http://www.jcp.org/en/jsr/detail?id=907 JSR 907]
* [https://www.atomikos.com Atomikos transaction manager website]
* [http://narayana.io/ Narayana transaction manager website]
* [https://github.com/bitronix/btm Bitronix transaction manager website]

{{Java EE 7}}

{{DEFAULTSORT:Java Transaction Api}}
[[Category:Java enterprise platform|Transaction API]]
[[Category:Java specification requests|Transaction API]]
[[Category:Java APIs]]
[[Category:Articles with example Java code]]

Microservices

2019-04-11T06:08:31Z

Biniljava: /* References */ Added link to a new book

{{Multiple issues|
{{unreliable sources|date=October 2018}}
{{Advert |date=March 2019}}
}}

'''Microservices''' are a [[software development]] technique—a variant of the [[service-oriented architecture]] (SOA) architectural style that structures an [[application (computing)|application]] as a collection of [[Coupling (computer programming)|loosely coupled]] services. In a microservices architecture, services are [[Service granularity principle|fine-grained]] and the [[protocol (computing)|protocol]]s are lightweight. The benefit of decomposing an application into different smaller services is that it improves [[Modular programming|modularity]]. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.<ref name="Micro_Chen">{{cite conference

|url= https://www.researchgate.net/publication/323944215_Microservices_Architecting_for_Continuous_Delivery_and_DevOps
|title= Microservices: Architecting for Continuous Delivery and DevOps
|first= Lianping |last= Chen
|date= 2018
|conference= The IEEE International Conference on Software Architecture (ICSA 2018)
|conferenceurl= http://icsa-conferences.org/2018/
|publisher= IEEE
}}
</ref> It parallelizes [[software development|development]] by enabling small autonomous teams to develop, [[software deployment|deploy]] and scale their respective services independently.<ref>{{Cite web|url=http://microservices.io/patterns/microservices.html|title=Microservice architecture pattern|last=Richardson|first=Chris|date=|website=microservices.io|archive-url=|archive-date=|dead-url=|access-date=2017-03-19}}</ref> It also allows the architecture of an individual service to emerge through continuous [[refactoring]].<ref name="Ach_Chen">{{cite conference
|title= Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development
|first= Lianping |last= Chen
|first2= Muhammad|last2= Ali Babar|date= 2014
|conference= The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)
|conferenceurl= https://web.archive.org/web/20140730053f454/http://wicsa2014.org/
|publisher= IEEE
|doi = 10.1109/WICSA.2014.45}}
</ref> Microservices-based architectures enable [[continuous delivery]] and deployment.<ref>{{Cite journal|last=Balalaie|first=Armin|last2=Heydarnoori|first2=Abbas|last3=Jamshidi|first3=Pooyan|date=May 2016|title=Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|journal=IEEE Software|volume=33|issue=3|pages=42–52|doi=10.1109/ms.2016.64|issn=0740-7459|hdl=10044/1/40557}}</ref>

== Introduction ==
Even though there is no official definition of what microservices are, a consensus view has evolved over time, in the industry. Some of the defining characteristics that are frequently cited include:
* Per [[Martin Fowler (software engineer)|Martin Fowler]] software engineer and other experts, services in a microservice architecture (MSA) are often [[Process (computing)|processes]] that communicate over a [[Computer network|network]] to fulfill a goal using technology-agnostic [[Communications protocol|protocols]] such as HTTP.<ref name="martinfowler">{{cite web|url=http://martinfowler.com/articles/microservices.html|title=Microservices|author=Martin Fowler|archive-url=https://web.archive.org/web/20180214171522/https://martinfowler.com/articles/microservices.html|archive-date=14 February 2018|dead-url=no}}</ref><ref>{{cite book|title=Building Microservices|last=Newman|first=Sam|publisher=O'Reilly Media|isbn=978-1491950357|date=2015-02-20}}</ref><ref>{{cite book|url=http://microservices-book.com|title=Microservices: Flexible Software Architectures|isbn=978-0134602417|last1=Wolff|first1=Eberhard|date=2016-10-12}}</ref>
* Services in a microservice architecture are independently deployable.<ref name="NMMA16">Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016</ref><ref name="Micro_Chen"/>
* Services are organized around fine-grained business capabilities. The granularity of the Microservice is important - because this is key to how this approach is different from [[Service-oriented architecture|SOA.]]
* Services can be implemented using different [[programming language]]s, [[database]]s, hardware and software environment, depending on what fits best.<ref name="Micro_Chen"/> This does not mean that a single microservice is written in a patchwork of programming languages. While it is almost certainly the case that different components that the service is composed of, will require different languages or APIs (example, the web server layer may be in Java or Javascript, but the database may use SQL to communicate to an RDBMS), this is really reflective of a comparison to the monolithic architecture style. If a monolithic application were to be re-implemented as a set of microservices, then the individual services could pick their own implementing languages. So one microservice could pick Java for the web layer, and another microservice could pick a [[Node.js]] based implementation, but within each microservice component, the implementing language would be uniform.
* Services are small in size, messaging enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and [[Build automation|built]] and [[Application release automation|released with automated processes]].<ref name="NMMA16" />

A Microservice is ''not'' a layer within a monolithic application (example, the web controller, or the backend-for-frontend<ref>{{cite web |title=Backends For Frontends Pattern |url=https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends |website=Microsoft Azure Cloud Design Patterns |publisher=Microsoft}}</ref>). Rather it is a self-contained piece of business function with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategy perspective, microservices architecture essentially follow to the [[Unix philosophy]] of "Do one thing and do it well".<ref>{{cite book|asin= B00VJ3NP4A|title= Microservices: Patterns and Applications|author= Lucas Krause}}</ref> [[Martin Fowler (software engineer)|Martin Fowler]] describes a microservices-based architecture as having the following properties:<ref name="martinfowler"/>
* Naturally enforces a [[Modular programming|modular]] structure.<ref>[https://www.forbes.com/sites/oracle/2019/01/07/grails-founder-what-java-developers-dont-know-about-memory-can-cost-them-money-in-the-cloud/#3e7ab84a44e1 Grails Founder: What Java Developers Don’t Know About Memory Can Cost Them Money in the Cloud] ''[[Forbes]]'' Retrieve 9 January 2019</ref>
* Lends itself to a [[continuous delivery]] software development process. A change to a small part of the application only requires rebuilding and redeploying only one or a small number of services.<ref>[https://docs.microsoft.com/en-us/azure/architecture/microservices/ci-cd Designing microservices: Continuous integration] ''[[Microsoft]]'' Retrieved 9 January 2018</ref>
* Adheres to principles such as [[Service granularity principle|fine-grained]] [[software interface|interface]]s (to independently deployable services), business-driven development (e.g. [[domain-driven design]]).<ref>Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. {{ISBN|978-0-596-52955-0}}.</ref>

It is quite common for such an architectural style to be adopted for [[cloud application|cloud-native applications]], and applications using lightweight [[operating-system-level virtualization|container]] deployment. As explained<ref>{{cite web|url=https://martinfowler.com/bliki/MicroservicePrerequisites.html|title=Microservice Prerequisites|author=[[Martin Fowler (software engineer)|Martin Fowler]]}}</ref> by Martin Fowler, because of the large number (when compared to monolithic application implementations) of services, decentralized continuous delivery, and [[DevOps]] with holistic service monitoring are necessary to effectively develop, maintain, and operate such applications. A consequence of (and rationale for) following this approach is that the individual microservices can be individually scaled. In the monolithic approach, an application supporting three functions would have to be scaled in its entirety even if only one of these functions had a resource constraint.<ref>{{cite book |last1=Richardson |first1=Chris |title=Microservice Patterns |date=November 2018 |publisher=Manning Publications |location=Chapter 1, section 1.4.1 Scale cube and microservices |isbn=9781617294549}}</ref> With microservices, only the Microservice supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits.

== History ==
A workshop of software architects held near Venice in May 2011 used the term "microservice" to describe what the participants saw as a common architectural style that many of them had been recently exploring {{citation needed|date=November 2018}}. In May 2012, the same group decided on "microservices" as the most appropriate name. James Lewis presented some of those ideas as a [[case study]] in March 2012 at 33rd Degree in Kraków in Microservices - Java, the Unix Way, as did Fred George about the same time. [[Adrian Cockcroft]] at Netflix, describing this approach as "fine grained SOA", pioneered the style at web scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher and Graham Tackley.<ref>
{{cite web
|author= James Lewis and Martin Fowler
|title= Microservices
|url= http://martinfowler.com/articles/microservices.html
}}
</ref>

Dr. Peter Rodgers introduced the term "Micro-[[web service|Web-Services]]" during a presentation at the Web Services Edge conference in 2005. On slide #4 of the conference presentation, he states that "[[Software component]]s are Micro-Web-Services".<ref>{{cite web|last1=Rodgers|first1=Peter|title=Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity Web Services Edge 2005 East: CS-3|url=http://www.cloudcomputingexpo.com/node/80883|website=CloudComputingExpo 2005|publisher=SYS-CON TV|accessdate=3 July 2017}}</ref> Juval Löwy had similar precursor ideas about classes being [[Granularity#Computing|granular]] services, as the next evolution of [[Microsoft]] architecture.<ref>{{cite web|last1=Löwy|first1=Juval|title=Every Class a WCF Service|url=https://channel9.msdn.com/Shows/ARCast.TV/ARCastTV-Every-Class-a-WCF-Service-with-Juval-Lowy|website= Channel9, ARCast.TV|date=October 2007}}</ref><ref>{{cite book |author= Löwy, Juval |title= Programming WCF Services 1st Edition |pages= 543–553|date= 2007}}</ref><ref>{{cite web|last1=Löwy|first1=Juval|title=Every Class As a Service|url=https://www.youtube.com/watch?v=w-Hxc6uWCPg|website=Microsoft TechEd Conference, SOA206|archiveurl=https://blogs.msdn.microsoft.com/drnick/2009/04/29/wcf-at-teched-2009/|archive-date= 2010|date=May 2009}}</ref> "Services are composed using [[Pipeline (Unix)|Unix-like pipelines]] (the [[WWW|Web]] meets Unix = true [[Loose coupling|loose-coupling]]). Services can call services (+multiple language run-times). Complex service-assemblies are abstracted behind simple [[URI]] interfaces. Any service, at any granularity, can be exposed." He described how a well-designed service platform "applies the underlying architectural principles of the [[WWW|Web]] and Web services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity by providing a platform to apply service-oriented architecture throughout your application environment".<ref>{{cite web|last1= Rodgers|first1= Peter|title= Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity|url= http://www.cloudcomputingexpo.com/node/80883|website= CloudComputingExpo|publisher= SYS-CON Media|accessdate= 19 August 2015}}</ref> The design, which originated in a research project at [[Hewlett Packard Labs]], aims to make code less brittle and to make large-scale, complex software systems [[Robustness (computer science)|robust]] to change.<ref>{{cite web|last1= Russell|first1= Perry|last2=Rodgers|first2= Peter|last3= Sellman|first3= Royston|title= Architecture and Design of an XML Application Platform|url= http://www.hpl.hp.com/techreports/2004/HPL-2004-23.html|website= HP Technical Reports|accessdate= 20 August 2015|pages= 62|date= 2004}}</ref> To make "Micro-Web-Services" work, one has to question and analyze the foundations of architectural styles (such as [[Service-oriented architecture|SOA]]) and the role of messaging between software components in order to arrive at a new general computing abstraction.<ref>{{cite journal|last1= Hitchens|first1= Ron|editor1-last= Swaine|editor1-first= Michael|title= Your Object Model Sucks|journal= PragPub Magazine|date= Dec 2014|page= 15}}</ref> In this case, one can think of [[resource-oriented computing]] (ROC) as a generalized form of the Web abstraction. If in the Unix abstraction "[[everything is a file]]", in ROC, everything is a "Micro-Web-Service". It can contain information, code or the results of computations so that a service can be either a consumer or producer in a symmetrical and evolving architecture.

'''Microservices''' is a specialization of an implementation approach for [[service-oriented architecture]]s (SOA) used to build flexible, independently deployable [[distributed software|software systems]].<ref name="ieeeswi2">{{Cite journal|year=2017|title=Microservices in Practice, Part 1: Reality Check and Service Design|url=http://ieeexplore.ieee.org/document/7819415/|journal=IEEE Software|volume=34|issue=1|pages=91–98|doi=10.1109/MS.2017.24|last1=Pautasso|first1=Cesare}}</ref> The microservices approach is a first realisation of SOA that followed the introduction of [[DevOps]] and is becoming more popular for building [[Continuous deployment|continuously deployed]] systems.<ref>{{cite web|url=https://www.javacodegeeks.com/2014/12/continuous-deployment-strategies.html|title=Continuous Deployment: Strategies|date=|author=|work=javacodegeeks.com|accessdate=28 December 2016}}</ref>

== Service Granularity ==
A key step in defining a Microservice architecture is figuring out how big an individual Microservice has to be. There is no consensus or litmus test for this, as the right answer depends on the business and organizational context. [[Amazon (company)|Amazon]]'s policy is that the team implementing a microservice should be small enough that they can be fed by two-pizzas.<ref name="martinfowler"/> Many organizations choose smaller "squads" - typically 6 to 8 developers. But the key decision hinges around how "clean" the service boundary can be.

On the opposite side of the spectrum, it is considered a bad practice to make the service too small, as then the runtime overhead and the operational complexity can overwhelm the benefits of the approach. When things get too fine-grained, alternative approaches must be considered - such as packaging the function as a library, or by placing the function into other Microservices.{{citation needed|date=January 2019}}

== Linguistic approach ==
A linguistic approach to the development of microservices<ref name="jolie-2">{{cite web|url=http://claudioguidi.blogspot.it/2017/03/what-microservice-from-linguisitc.html|title=What is a microservice? (from a linguistic point of view) |author=Claudio Guidi|date=2017-03-29 }}</ref> focuses on selecting a programming language that can easily represent a microservice as a single software artifact. When effective, the gap between architecting a project and deploying it can be minimized.{{citation needed|date=October 2018}}

One language intended to fill this role is [[Jolie (programming language)|Jolie]].<ref name="jolie-1">{{cite web|url=http://www.jolie-lang.org/vision.html|title=Vision of microservices revolution |author=Jolie Team}}</ref><ref name="jolie-3">{{cite web|url=https://fmontesi.github.io/2015/02/06/programming-microservices-with-jolie.html|title = Programming Microservices with Jolie - Part 1: Data formats, Proxies, and Workflows.|author=Fabrizio Montesi}}</ref>

== Technologies ==

Computer microservices can be implemented in different programming languages and might use different infrastructures. Therefore the most important technology choices are the way microservices communicate with each other (synchronous, asynchronous, UI integration) and the protocols used for the communication (REST, messaging, ...). In a traditional system most technology choices like the programming language impact the whole systems. Therefore the approach for choosing technologies is quite different.<ref>{{cite book|url=http://practical-microservices.com|title=Microservices - A Practical Guide|isbn=978-1717075901|last1=Wolff|first1=Eberhard|date=2018-04-15}}</ref>

The [[Eclipse Foundation]] has published a specification for developing microservices, Eclipse MicroProfile.<ref>{{cite web|url=https://projects.eclipse.org/projects/technology.microprofile|title=Eclipse MicroProfile|first=Stephanie|last=Swart|date=14 December 2016|website=projects.eclipse.org}}</ref>

== Service Mesh ==

In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as [[Kubernetes]].
The service proxies are responsible for communication with other service instances and can support capabilities such as service (instance) discovery, load balancing, authentication and authorization, secure communications, and others.

In a service mesh, the service instances and their sidecar proxy are said to make up the data plane, which includes not only data management but also request processing and response. The service mesh also includes a control plane for managing the interaction between services, mediated by their sidecar proxies. There are several options for service mesh architecture: Istio (a joint project among Google, IBM, and Lyft), Buoyant<ref>{{cite web |title=What's a service mesh? |url=https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ |website=Buoyant |publisher=Buoyant |accessdate=5 December 2018|date=2017-04-25 }}</ref> & others

== Criticism ==
The microservices approach is subject to criticism for a number of issues:
* Services form information barriers.<ref name= "infoq-1">{{cite web|url= http://www.infoq.com/news/2014/08/failing-microservices|title=Experiences from Failing with Microservices| first =Jan | last = Stenberg|date=11 August 2014}}</ref>
* Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process [[function call|calls]] within a [[monolithic system|monolithic]] service process.<ref name= "martinfowler" />
* [[Software testing|Testing]] and [[Software deployment|deployment]] are more complicated.<ref name= "infoqbook" />
* Moving responsibilities between services is more difficult.<ref name= "Micro_Chen"/> It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure.<ref name= "martinfowler" />
* Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.<ref>{{cite web |url= https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/ |title=How small should your microservice be? |last=Tilkov |first=Stefan |date= 17 November 2014 |website= Innoq |access-date=4 January 2017}}</ref>
* Two-phased commits are regarded as an anti-pattern in microservices based architectures as this results in a tighter coupling of all the participants within the transaction. However, lack of this technology causes awkward dances which have to be implemented by all the transaction participants in order to maintain data consistency.<ref>{{cite book |last1= Richardson |first1= Chris |title= Microservice Patterns |date= November 2018 |publisher= Manning Publications |location=Chapter 4. Managing transactions with sagas|isbn= 978-1-61729454-9}}</ref>
* Development and support of many services is more challenging if they are built with different tools and technologies - this is especially a problem if engineers move between projects frequently.

===Cognitive load===
The architecture introduces additional complexity and new problems to deal with, such as [[network latency]], [[message format]]s, [[Load balancing (computing)|load balancing]] and [[fault tolerance]].<ref name= "ieeeswmsip2">{{Cite journal|year= 2017|title= Microservices in Practice, Part 2: Service Integration and Sustainability |url= http://ieeexplore.ieee.org/document/7888407/ |journal= IEEE Software |volume=34|issue=2|pages= 97–104|doi=10.1109/MS.2017.56 |last1=Pautasso|first1= Cesare}}</ref><ref name= "infoqbook">{{cite web|url= http://www.infoq.com/presentations/microservices-pass-spring-cloud-foundry|title=Developing Microservices for PaaS with Spring and Cloud Foundry}}</ref> All of these problems have to be addressed at scale.

The complexity of a [[monolithic application]] doesn't disappear if it gets re-implemented as a set of microservice applications. Some of the complexity gets translated into operational complexity.<ref>{{cite web|author-link = Martin Fowler (software engineer)| first = Martin | last = Fowler |url= https://www.martinfowler.com/articles/microservice-trade-offs.html#ops |title=Microservice Trade-Offs}}</ref> Other places where the complexity manifests itself is in the increased network traffic and resulting slower performance. Also, an application made up of any number of microservices has a larger number of interface points to access its respective [[software ecosystem|ecosystem]], which increases the architectural complexity.<ref>{{cite news|title= BRASS Building Resource Adaptive Software Systems |agency= DARPA |publisher=U.S. Government |date= April 7, 2015}} "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented [[application programming interface]]s (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with."</ref> Various organizing principles (such as [[HATEOAS]], interface and data model documentation captured via [[Swagger (software)|Swagger]], etc) have been applied to reduce the impact of such additional complexity.

== A comparison of platforms ==
Prior to Kubernetes and its ecosystem of tools being developed, implementing a [[microservice]] architecture was hard because of the lack of popular frameworks. There are many concerns (see table below) that any microservice architecture needs to address. [[Netflix]] developed a microservice framework to support their internal applications, and then open-sourced<ref>{{Citation | publisher = Git Hub | URL = https://netflix.github.io/ | title = Netflix OSS}}.</ref> many portions of that framework. Many of these tools have been popularized via the [[Spring Framework]] – they have been re-implemented as Spring-based tools under the umbrella of the Spring Cloud<ref>{{Citation | URL = http://spring.io/projects/spring-cloud | publisher = Spring | title = Cloud}}.</ref> project. The table,<ref>{{Citation | work = Developers | publisher = Red hat | date = 2016-12-09 | URL = https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/ | title = Spring Cloud for Microservices Compared to Kubernetes}}.</ref> below, shows a comparison of an implementing feature from the Kubernetes ecosystem with an equivalent from the Spring Cloud world. One noteworthy aspect of the Spring Cloud ecosystem is that they are all Java based technologies, whereas Kubernetes is a polyglot runtime platform.

{| class="wikitable" style="font-size: 85%; text-align: left; width: auto;"
|-
! Microservices concern
! Spring Cloud & Netflix OSS
! Kubernetes
|-
| Configuration Management – Configuration for a microservice application needs to be externalized from the code and be retrievable via a simple service call.
| Spring Config Server, Netflix Archaius both support a git-repository based location for configuration. Archaius supports data typing of configuration.
| Kubernetes ConfigMaps exposes the configuration stored in etcd via services. Kubernetes secrets supports the service-based secure deployment and usage of sensitive configuration information (such as passwords, certificates, etc.).
|-
| Service Discovery – maintain a list of service instances that are available for work within a microservice domain.
| Spring Cloud Eureka allows clients to register to it, maintains a heartbeat with registered clients, and maps service names to hostnames for clients that look up services by service name.
| Kubernetes Services provide deployment time registration of instances of services that are internally available within the cluster. Ingress is a mechanism whereby a service can be exposed to clients outside the cluster.
|-
| Load Balancing: The key to scaling a distributed system is being able to run more than one instance of a component. Load has to be then distributed across those instances via a load balancer.
| Spring Cloud Ribbon provides the ability for service clients to load balance across instances of the service.
| Kubernetes Service provides the ability for the service to be load balanced across service instances. This is not the equivalent of what Ribbon provides.
|-
| API Gateway: The granularity of APIs provided by microservices is often different than what a service client needs. API Gateways implement facades and provide additional services like proxying, and protocol translation, and other management functions.
| Spring Cloud Zuul provides configuration based API facades
| Kubernetes Service & Ingress resources, Istio, Ambassador are solutions that provide both north-south (traffic into and out of data center) as well as east-west (traffic across data centers or clouds or regions) API gateway functions.
|-
| Security Concerns: many security concerns are pushed to the API gateway implementation. With distributed microservice applications, it makes sense to not reinvent the security wheel and allow for policy definition and implementation in components that are shared by all services.
| Spring Cloud Security addresses many security concerns through Spring Cloud Zuul
| The Kubernetes ecosystem provides service meshes like Istio, which are capable of providing security through their API gateway mechanims.
|-
| Centralized Logging – it is important to have a centralized log gathering and analysis infrastructure to manage a plethora of services - many of which are operating in a distributed fashion.
| ELK Stack ([[Elasticsearch]], LogStash, [[Kibana]])
| EFK Stack ([[Elasticsearch]], [[Fluentd]], [[Kibana]])
|-
| Centralized Metrics – a centralized area where the health and performance of the individual and overall system is essential to proper operations.
| Spring Spectator & Atlas
| Heapster, Prometheus, & Grafana
|-
| Distributed Tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the complex paths that transactions take as they propagate across a distributed system. Distributed tracing is an essential tool for a microservices platform.
| Spring Cloud Sleuth
| Hawkular
|-
| Resilience & Fault Tolerance – distributed systems must be capable of auto-routing around failures, and be capable of routing requests to the service instance that will provide an optimum response.
| Spring Hystrix, Turbine, & Ribbon
| Health check, [[Microservices#Service Mesh|service meshes]] (example: Istio<ref>{{Citation | publisher = Kubernetes | date = May 2017 | URL = https://kubernetes.io/blog/2017/05/managing-microservices-with-istio-service-mesh/ | title = Managing microservices with the Istio service mesh}}.</ref>)
|-
| Autoscaling & Self-healing: Distributed systems respond to higher load by scaling horizontally: the platform must detect and auto-respond to such conditions. Furthermore, the system needs to detect failures and attempt auto-restarts without operator input.
| -
| Health check, self-healing, & auto-scaling
|-
| Packaging, Deployment, & Scheduling – large-scale systems require a robust package management, and deployment system to manage rolling or blue-green deployments, and rollbacks if necessary. A scheduler helps determine which particular execution node a new set of services can be deployed to based on current conditions.
| Spring Boot, Apache Maven. The Spring Cloud system does not have a true Scheduler
| Docker, Rkt, Kubernetes Scheduler & Deployment, Helm<ref>{{Citation | URL = https://helm.sh/ | publisher = Helm | title = The Kubernetes Package Manager}}.</ref>
|-
| Job Management – scheduled computations disconnected from any individual user requests
| Spring Batch
| Kubernetes Jobs & Scheduled Jobs
|-
| Singleton Application – run specific services as a single instance of it within the entire system
| Spring Cloud Cluster
| Kubernetes Pods
|}

== Implementations ==
* Thorntail by [[Red Hat]]
* Helidon by [[Oracle Corporation|Oracle]]
* Meecrowave by [[The Apache Software Foundation|Apache]]

== See also ==
* [[Conway's law]]
* [[Cross-cutting concern]]
* [[DevOps]]
* [[Fallacies of distributed computing]]
* [[gRPC]]
* [[Microkernel]]
* [[Representational state transfer]] (REST)
* [[Service-oriented architecture]] (SOA)
* [[Unix philosophy]]
* [[Self-contained Systems]]
* [[Serverless computing]]
* [[Web-oriented architecture]] (WOA)

== References ==
{{reflist|30em}}
44. Christudas, Binildas (October 2019). [https://www.amazon.com/Practical-Microservices-Architectural-Patterns-Event-Based/dp/1484245008 Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud]: Apress Publications. ISBN-10: 1484245008, ISBN-13: 978-1484245002, Language: English

== Further reading ==
* S. Newman, Building Microservices – Designing Fine-Grained Systems, O'Reilly, 2015 {{isbn|978-1491950357}}
* I. Nadareishvili et al., [http://transform.ca.com/rs/117-QWV-692/images/CA%20Technologies%20-%20OReilly%20Microservice%20Architecture%20eBook.pdf Microservices Architecture – Aligning Principles, Practices and Culture], O’Reilly, 2016, {{isbn|978-1-491-95979-4}}
* SEI SATURN 2015 microservices workshop, https://github.com/michaelkeeling/SATURN2015-Microservices-Workshop
* Wijesuriya, Viraj Brian (2016-08-29) ''[http://www.slideshare.net/tyrantbrian/microservice-architecture-65505794 Microservice Architecture, Lecture Notes]'' - University of Colombo School of Computing, Sri Lanka

[[Category:Architectural pattern (computer science)]]
[[Category:Service-oriented (business computing)]]