tag:blogger.com,1999:blog-92035572024-03-07T07:24:39.899+00:00Mark Little's WebLogI work for Red Hat, where I lead JBoss technical direction and research/development. Prior to this I was SOA Technical Development Manager and Director of Standards. I was Chief Architect and co-founder at Arjuna Technologies, an HP spin-off (where I was a Distinguished Engineer). I've been working in the area of reliable distributed systems since the mid-80's. My PhD was on fault-tolerant distributed systems, replication and transactions. I'm also a Professor at Newcastle University and Lyon.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.comBlogger621125tag:blogger.com,1999:blog-9203557.post-45915040577208793222020-07-11T17:28:00.003+01:002020-07-11T17:28:29.286+01:00Farewell Rob ...This year has definitely been shitty for many people globally for a number of reasons. To add to that, I just heard that a long time friend of mine died the other day from pancreatic cancer. I could write about him but another friend of ours, Mike, already did and very eloquently. Therefore, I'll just link to his <a href="https://thesagedm.blogspot.com/2020/07/let-me-tell-you-story.html?showComment=1594484114173#c9142241865568519771">entry</a> and send Rob's family my condolences. I'll also toast Rob tonight along with all the good memories we share!Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-41652228295900495952020-04-06T11:46:00.000+01:002020-04-06T11:46:00.933+01:00Community driven innovation and freedom<div data-en-clipboard="true" data-pm-slice="1 1 []">
Picture this ... a world where we have an industry with open source innovation at its heart. Communities come together to tackle problems. Majority decisions are made in the open through mutual respect and often lots of discussion. Differences of opinion are a reality inside these open source communities as outside.</div>
<div>
<br /></div>
<div>
In this world if you don't like the way a community is heading then you get involved and try to persuade them to change and understand your point. If there are many more people who believe the same then they get involved too and maybe that community changes direction. But in this reality you don't complain when a decision goes against you ... you respect the choices the community makes and you have the freedom to go and try to create your own community elsewhere if that's the best option.</div>
<div>
<br /></div>
<div>
You also don't complain about a community when you've had minimal or even zero involved. You don't complain about dominance of communities by vendors or individuals if you fail to get involved or fail to get a majority of like minded people active enough for them to gain voting rights.</div>
<div>
<br /></div>
<div>
Even without voting rights or until they are obtained, influence is something which is possible because everything is discussed in the open. In this ideal world you get involved and help. You spend the time to earn the same rights as others. You expend the time and energy and do the work that is required to gain those voting rights because they are a privilege and not an automatic right. However, if something is important to you then you spend that time to earn it.</div>
<div>
<br /></div>
<div>
Sometimes I think we live in this world but then I wake up!</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-77803686357163378652020-04-06T11:44:00.000+01:002020-04-06T11:44:55.957+01:00Don't default fork MP into Jakarta EE<div data-en-clipboard="true" data-pm-slice="1 1 []">
There should be no default rule for the relationship between Jakarta EE and MicroProfile because each MicroProfile specification is often driven by a mix of different developers, vendors and communities who may not want their efforts forked. To ignore them is tantamount to a hostile take-over. The Jakarta EE communities should work with them and try to persuade them to see their point of view. However, if the MP spec community cannot be persuaded then I caution continuing with a fork. Embed and try to work together because the MP spec should still be usable within Jakarta EE. And working with the original community is a far better path to future success than trying to split efforts - anyone remember Hudson these days?</div>
<div>
<br /></div>
<div>
If no way to collaborate can be found, including simply embedding that spec into Jakarta EE, then I'd suggest that there is something fundamentally wrong with that specific MP community or those in Jakarta EE. I really can't see this ever happening though so it's not worth further consideration.</div>
<div>
<br /></div>
<div>
Then there's the notion of changing the namespace of a MP specification if it is "imported". Well I also don't think that should be a hard and fast rule either. It should be something that is worked out between the MP specification in question and the Jakarta EE community. It should also not be a reason to reject importing and collaborating with the MP community and defaulting to a hostile-like fork.</div>
<div>
<br /></div>
<div>
And that brings me to the final question: where does work on the MP specification continue, assuming it does need to continue? Well guess what? I think that's up to the MP spec community since they are the founders of their work and their future destiny. If they feel that innovation should shift entirely to Jakarta EE then go for it, with all of my support. But likewise, if they feel innovation should continue in MP and maybe they are a part of the corresponding Jakarta EE community they work to pull updates across when it makes sense. A great collaboration.</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-58603396454651108642019-09-11T17:31:00.000+01:002019-09-11T17:31:09.260+01:00That time again ... September 11thYes, it comes around <a href="http://markclittle.blogspot.com/2007/05/some-form-of-closure.html">again</a>. This year I decided to link something <a href="https://www.nps.gov/flni/learn/historyculture/edward-porter-felt.htm">more</a> for <a href="http://93memorial.com/Heros-Of-Flight-93/pages/Edward-Felt_jpg.htm">Ed</a>. My thoughts are with his family as usual. And mine.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-8296073973915562932019-05-10T18:34:00.002+01:002019-05-10T18:34:41.218+01:00Community, Jakarta EE and MicroProfileI've written a lot recently about the future of Eclipse MicroProfile and Jakarta EE recently. If you're reading this then hopefully you'll have seen those other entries (if not, scroll up?) I've taken a personal stance which may not be exactly the same as Red Hat's stance but as I've said already, this is a tricky series of connected decisions the entire community needs to make and there's no right or wrong answer. However, I wanted to write one more smaller article to just say thanks to the community for their very active involvement in the conversations. Whether through the email threads which have been kicked off, Twitter, face-to-face in various timely conference sessions, etc. it's warming to see the interest in the topic and the passion as well as commitment to the future of enterprise Java. I hope this doesn't wane as we move forward. As one of my predecessors used to say: Onward!Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-59616251209498137592019-05-07T10:33:00.006+01:002019-05-07T10:33:56.850+01:00Transitioning Jakarta EE to the jakarta namespaceNote, this is just a copy-and-paste from the original <a href="https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html">email</a> sent out by the spec committee. Placed here to try to maximise involvement.<br />
<br />
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings. The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]</span></div>
<span class="" id="docs-internal-guid-2777dbfb-7fff-e939-e443-313700ba54b1" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">As announced in the Update on Jakarta EE Rights to Java Trademarks[1] </span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">post on Friday, future modification of the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace will not be allowed. While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> would always have involved long-term legal and trademark restrictions.</span></span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyoneâs part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Other proposals should incorporate the following considerations and goals:</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">The new namespace will be </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta.*</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Even a small maintenance change to an API would require a </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> change of that entire specification. Examples include:</span></span></div>
</li>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Adding a value to an enum</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Overriding/adding a method signature</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Adding default methods in interfaces</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Compensating for Java language changes</span></div>
</li>
</ul>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Binary compatibility for existing applications in the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace from entering the ecosystem by requiring they also implement an equivalent </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> legacy API.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">There is no intention to change Jakarta EE 8 goals or timeline.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Community discussion on how to transition to the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace will conclude </span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Sunday, June 9th, 2019</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">.</span></span></div>
</li>
</ul>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.</span></div>
<h1 class="" dir="ltr" style="font-family: arial, helvetica, geneva; font-size: 28px; font-weight: bold; line-height: 1.38; margin-bottom: 6pt; margin-top: 20pt;">
<span class="" style="font-family: Arial; font-size: 20pt; font-variant-east-asian: normal; font-variant-ligatures: normal; font-weight: 400; vertical-align: baseline; white-space: pre-wrap;">Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features</span></h1>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">The heart of this proposal is to do a one-time move of API source from the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace to the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace with the primary goal of not prolonging industry cost and pain associated with the transition.</span></span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Some or all Jakarta EE APIs under </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> would move immediately into </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> as-is.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Any packages not moved from </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> could be included in Jakarta EE, but would be </span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">forever</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> frozen and never move to the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace change and immediately released.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.</span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Pros:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Easily understood rule: everything Jakarta EE 8 and before is </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">, Jakarta EE 9 and after is </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Consistent with the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> Maven groupId change.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Highest degree of flexibility and freedom of action, post-change.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.</span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Cons:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Largest upfront cost for </span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">everyone.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Specifications that may never be updated would still likely be moved.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Decision to not move a specification is permanent and therefore requires high confidence.</span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Decisions:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Which specifications, if any, would we opt not to move?</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Would we take the opportunity to prune specifications from Jakarta EE 9?</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?</span></div>
</li>
</ul>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<h1 class="" dir="ltr" style="font-family: arial, helvetica, geneva; font-size: 28px; font-weight: bold; line-height: 1.38; margin-bottom: 6pt; margin-top: 20pt;">
<span class="" style="font-family: Arial; font-size: 20pt; font-variant-east-asian: normal; font-variant-ligatures: normal; font-weight: 400; vertical-align: baseline; white-space: pre-wrap;">Proposal 2: Incremental Change in Jakarta EE 9 and beyond</span></h1>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Evolve API source from </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace over time on an as-needed basis. The most active specifications would immediately move in Jakarta EE 9. Every Jakarta EE release, starting with version 10 and beyond may involve some </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-family: Arial; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace transition.</span></span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">The most active APIs would immediately move from </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">APIs not changed or determined by the community to be unlikely to change would stay in </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Jakarta EE 9 would be a mix of </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> and </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> packaged APIs</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">If a change was needed to a </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> API post Jakarta EE 9 for any reason, that API would transition from </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Jakarta EE 10 would be a mix of </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> and </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> packaged APIs, but a different mix than Jakarta EE 9.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">At some point down the road, Jakarta EE xx, it may be decided that the migration from </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> is âdoneâ and the final APIs are moved.</span></span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Pros:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Cheaper up front cost and reduced immediate noise.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">No need to move specifications unless there is an immediately visible benefit.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Potential for less impact from API change overall.</span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Cons:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Use of restricted </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> namespace prolonged.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Frustration of âalways changingâ packages may deter application developers and become a permanent perception of the brand.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Difficulty in remembering/knowing which Jakarta EE release an API was moved. âIs Connector </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> or </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> in Jakarta EE 11?â</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Difficulty in keeping the industry in sync.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px;"><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">New implementations may find themselves having to deal with the </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">javax</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> to </span><span class="" style="font-family: "Courier New"; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">jakarta</span><span class="" style="font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"> transition, unable to avoid legacy costs and therefore decide not to enter the space.</span></span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Transitive dependencies to other specifications may make incremental change difficult or impossible.</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Restrictions on what Java SE implementation can be used for certification</span></div>
</li>
</ul>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Decisions:</span></div>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Do we start small or start large?</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Which APIs would immediately need to be changed?</span></div>
</li>
</ul>
<h1 class="" dir="ltr" style="font-family: arial, helvetica, geneva; font-size: 28px; font-weight: bold; line-height: 1.38; margin-bottom: 6pt; margin-top: 20pt;">
<span class="" style="font-family: Arial; font-size: 20pt; font-variant-east-asian: normal; font-variant-ligatures: normal; font-weight: 400; vertical-align: baseline; white-space: pre-wrap;">Out of Scope</span></h1>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">The following are very important community discussions, but do not require a decision in the time-frame allotted:</span></div>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<ul class="" style="margin-bottom: 0pt; margin-top: 0pt;">
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Roadmap or release date for any Jakarta EE.next that would contain new features</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">Specification text around backwards compatibility requirements, if any</span></div>
</li>
<li class="" dir="ltr" style="font-family: Arial; font-size: 10pt; font-variant-east-asian: normal; font-variant-ligatures: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">What profiles should be defined</span></div>
</li>
</ul>
<span class="" style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: arial, helvetica, geneva; font-size: 13.3333px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="" style="font-size: 13px;"><br class="" /></span></span>
<div class="" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;">However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.</span></div>
<div class="">
<span class="" style="font-family: Arial; font-size: 13px; font-variant-east-asian: normal; font-variant-ligatures: normal; vertical-align: baseline; white-space: pre-wrap;"><br class="" /></span></div>
<span class="" style="font-family: arial, helvetica, geneva; font-size: 13.3333px; font-variant-ligatures: normal; orphans: 2; widows: 2;"></span><br />
<div class="" style="font-family: arial, helvetica, geneva; font-size: 13.3333px; font-variant-ligatures: normal; orphans: 2; widows: 2;">
<div class="" style="font-family: Helvetica; font-variant-east-asian: normal; font-variant-ligatures: normal; font-variant-position: normal; line-break: after-white-space; line-height: normal; overflow-wrap: break-word; text-align: -webkit-auto;">
[1] <a class="" href="https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/">https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/</a></div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-53830260072125178012019-05-06T23:05:00.002+01:002019-05-06T23:05:59.756+01:00Evolving Jakarta EEIn the second of my additional blogs triggered by the recent javax announcement, let's look at another of the options I mentioned for moving forward. If we decide not to pursue the option to freeze Jakarta EE for stability and focus our combined innovative efforts on MicroProfile, but instead agree to innovate within Jakarta EE then what do we need to do to succeed with the alternative, i.e., what do we need to do to make Jakarta EE successful? Well let's first start with the understanding that to go down route we must therefore believe Jakarta EE is the best place to innovate for cloud-native enterprise Java and no place else. Splitting efforts doesn't help at this stage in the history of the ecosystem: we need the community to coalesce and collaborate on this.<br />
<br />
With that in mind we, and by that I mean existing vendors, the communities of users and contributors, partners, etc., have to get far more involved in Jakarta EE than many have with Java EE to date and particularly of late. We need evangelists, we need developers, we need testers, we need writers, we need so much more to fill in the gaps left by previous individuals or vendors who cannot be expected to put in as much time and effort as they have in the past. And critically we need this to happen in order to convince the industry that there's a groundswell of support and investment behind Jakarta EE which makes them stand up and take notice.<br />
<br />
The Eclipse Foundation needs investment too and it can't all be on the original main vendors to provide. Because Jakarta EE is now at the Eclipse Foundation this makes that kind of participation possible because there are no barriers to active involvement as perhaps there were when Java EE was in the JCP. Those old reasons (dominated by a single vendor, trademark concerns, not all things open source) go away. That's good because there's a lot going on within Jakarta EE and some of the specifications definitely should be evolved whereas others should probably be deprecated. Furthermore, new specifications need defining, implementing, testing (for compliance with a TCK) and including within subsequent releases. That's effort which has to be shared and this time the community must get involved. If the future of Jakarta EE relies solely on the same vendors and individuals as Java EE then we have failed in one of the most basic of reasons for moving to the Eclipse Foundation.<br />
<br />
There's another reason we would need to come together behind Jakarta EE innovation and that's related to the shadow the recent javax announcement has likely cast over things. No matter how positively we want to spin things there will no doubt be some tarnishing of the image which could turn people away or even convince them to leave. If we (the community) can do all of this together then any possible tarnishing of the Jakarta EE brand could well be polished away and perhaps Jakarta EE can have a bright future.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-82544958123144739192019-05-06T23:04:00.001+01:002019-05-06T23:04:30.669+01:00Why MicroProfile after javax?It wasn't my intention to write more on this topic as I want the discussions to be had in the <a href="https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev">community forums</a>. However, since writing my first article I've seen some confusion on the Twitter-verse and perhaps some FUD so I figured I'd write a couple more articles here, of which this is the first. Hopefully they help fuel the debate.<br />
<br />
Hopefully you've read at least my JBoss blog about the javax namespace problems and my personal blog outlining my preference for how we move forward from this point. Since posting them both I've read a number of people ask “Why MicroProfile?” Or “Why can’t we just innovate in Jakarta EE?” I want to try to answer those questions but recall this is still my personal opinion not that of my employer.<br />
<br />
I think what some people are missing is that I'm not arguing against innovating with Jakarta EE components. I'm discussing where to do that innovation and why. And this isn't an easy choice for our community to make. No matter what we do there are risks and I want to make sure everyone understands that there are no right or wrong answers here. As long as we make an informed decision as a community I'm sure we can move forward constructively. I'm sure some people won't agree with the decision(s) but as long as we have a good debate I hope everyone will get behind the new direction and put their feelings aside.<br />
<br />
OK so back to the original questions about why I'm suggesting we focus our innovation efforts around MicroProfile. Well think of it this way: if there was no MicroProfile and we wanted to evolve Jakarta EE today then where would we look for influence and inspiration? If “The Cloud” isn’t in your top 2 then you should probably go sit this one out. Now that leaves us with the obvious question of where do we do this work? My preference, as I've already mentioned, is MicroProfile and make Jakarta EE the stable solution for existing Java EE end users. I'm not saying this because Red Hat has a MicroProfile product, which we clearly do, but we also have an industry leading Java EE product, just in case anyone missed that! This is about developers and end users. And what they want today. In big shops and small. For their new applications. Cloud is their biggest concern and how to develop for it.<br />
<br />
Naturally we could evolve Jakarta EE towards cloud-native. That was the original remit for Jakarta EE after all. But I believe the namespace issue changes things because prior to this we were probably going to be able to get away without having to touch much of Jakarta EE, or perhaps not for some time anyway. In the meantime we'd be able to focus on those aspects of it which are needed in that particular problem space, bringing in new things which aren't there too (e.g., Istio integration). But clearly that isn't going to be possible now and we're going to have to invest some time and effort in all of the specifications.<br />
<br />
Now you can argue how much effort that will be but even if the code changes can be masked to end users, they still need to be made within the TCKs, docs etc. And of course there is the knock-on effect on training courses for Java EE 8, books etc. It will all take some time. It will likely divert the attention of many people who could well be used to help innovate. And in that time what else happens in other areas of our industry which we may miss? Is the rest of the world going to stand still? We risk stagnation and developers migrating elsewhere, which is precisely why Red Hat, IBM, TomiTribe, Payara and others created MicroProfile in the first place over three years ago. Let’s face it, Java EE innovation stagnated for quite a while. MicroProfile represents the most intense effort of innovation any of us have seen based on a select number of aspects of Java EE for many years. As a Java EE community we should all be proud of that and not see it as a threat!<br />
<br />
A threat, I hear you ask? Yes, apparently some people are now suggesting MicroProfile is a threat to the future of Jakarta EE, despite the fact the latter exists today due to a number of factors and MicroProfile is up there near the top! I'm not going to even stoop so low as to respond except to remind everyone that very few companies have as much invested in Java EE than Red Hat so anything I discuss here is not done without careful consideration. If that doesn't help then nothing willl.<br />
<br />
Anyway, back to the question at hand. The logical alternative to starting to evolve Jakarra EE towards cloud native is to jump to the end game, or somewhere on that road. And I believe that MicroProfile does precisely that for enterprise Java. Recent surveys from the Eclipse Foundation and others back up this assertion. The MicroProfile community has done a great job so far and should be congratulated.<br />
<br />
If you've looked at MicroProfile recently then you'll know it uses a few Java EE specifications, such as CDI and JAX-RS. It doesn't seem to need more than those just yet. However, if more Jakarta EE pieces need to be evolved then pull them in. Push them back to Jakarta EE if needed but don’t make that a requirement. Use the momentum that we've all built up around MicroProfile to keep driving forward. Maybe some Jakarta EE specifications need replacing completely for the cloud, e.g., transactions or messaging. Reactive is not something which can be easily applied to all of the current Jakarta EE specifications so why not just start with a much more focussed (limited specifications) approach, as MicroProfile is doing? Can you imagine the can of worms we might open if we wanted to make Spec A reactive only to find that impacts B, C and D, with other cascading impacts from them?<br />
<br />
So if the community still believes that pieces of Java EE have a role to play in cloud-native microservices, I suggest MicroProfile is already a far better starting point than where Jakarta EE is today. Now as I stated in an earlier blog post you might not agree with me and that's fine. Perhaps the reader believes there’s something else other than cloud-native microservices that people want to innovate around using Jakarta EE? Great, let's hear it and open a discussion. How many people are willing to contribute their time and maybe even money to it? If Jakarta EE is to not only survive this javax namespace issue but thrive then it needs people to stand up and be counted against GitHub commits.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com1tag:blogger.com,1999:blog-9203557.post-13346679910594148982019-05-05T09:21:00.000+01:002019-05-05T15:17:34.432+01:00To Enterprise Java and Beyond! A personal perspective.Ok so the title isn't quite what Buzz Lightyear said but cut me some slack, it's been a long day! Earlier <a href="https://planet.jboss.org/post/jakarta_ee_and_the_future">I posted</a> a blog about the results of the negotiations between Oracle and the Eclipse Foundation around IP transfer for Eclipse Jakarta EE and how they didn't go the way many of us had expected 18 months ago. The upshot of this is that the Java EE community is at a crossroads and I'm going to outline the options I see and give my own preference. Note, we are discussing these things within Red Hat now and have no firm conclusion so far, hence why this is on my personal blog. Therefore, don’t read this as a formal statement from Red Hat - it is not and these are just my own thoughts and opinions. If you know anything about Red Hat then you'll understand that even though I sit where I do in the organisation that doesn't mean I get a veto!<br />
<br />
Before I jump in I want to make something clear from the outset. Anyone who knows me knows I've been involved with Java and Java EE (J2EE) from the beginning of their history. In my own small way I like to think I've helped shape them both, whether as a specification lead or a member of the JCP EC. I may not be a Java Champion but I'm a champion of Java - see what I did there ;) ? The reason I call this out is I'm pretty sure I understand the positive influence they've both had on the industry over the years, whether through explicit efforts like application servers and the raft of specifications needed to build them for a distributed environment, or implicit because many of those same specifications are embedded and often hidden in some of our most popular frameworks or stacks. I'm not writing this from the perspective of a vendor, or because I'm on some ego trip, or even anger at the way things turned out. A few of us have known that this day was coming and it's given me a chance to try to think about the future objectively.<br />
<br />
One of the key things that Java EE has prided itself with over those years has been compatibility which has helped ensure application portability. With a few exceptions and application written against those standards ensured an application could be moved between different compliant vendor implementations. And something which is often overlooked is the backwards compatibly such that it was typically possible to easily migrate to the next revision of the specification and hence implementations. That compatibility helped a lot of developers build applications which have stood the test of time with little to no modifications. In short, they could develop their apps in the pretty safe knowledge that they'd keep working over the years until or unless there was a need to add new functionality or take into account some breaking change in the standards.<br />
<br />
Alright so with all of that said, where do the most recent announcements take us? Well put simply, if the community want to modify a Jakarta EE specification that is under the javax namespace then:<br />
<br />
<ul>
<li>The namespace needs to change from javax to something else.</li>
<li>The specification name needs to change, e.g., no more JMS (note, as my youngest son pointed out to me the other day JkMS may not be good as his generation assume JK is shorthand for joke!)</li>
<li>The TCK needs to change.</li>
<li>The RI needs to change. I know we don't have the concept of RIs in Jakarta but there are implementations in Glassfish which have need drive the specifications.</li>
</ul>
<br />
Now let's think of what that means for developers who use these specifications, either within Java EE implementations or elsewhere:<br />
<br />
<ul>
<li>Their application code needs to change.</li>
<li>Their test suites need to change.</li>
<li>Potentially any 3rd party code reliant on the specification needs to change.</li>
<li>Potentially any code reliant on the original developer code needs to change.</li>
</ul>
<br />
If you’ve ever used one of the Java EE specifications or even other specifications from other standards bodies, then you’ll know that depending upon the original reason for wanting to modify the specification, all of the above changes and necessary coordination across developers and possibly different vendors might well be worthwhile. The modifications could be that killer feature needed to catapult dependant applications to the next level or close that crucial security flaw. Changing your applications to accommodate such modifications isn’t something you might want to do from the start, especially if they appear to be working fine anyway, but any concerns can often be quickly overridden through understanding the motivation.<br />
<br />
Going back to those crossroads, one of the roads we could go down is what a few people are advocating: a Big Bang approach after Jakarta EE 8 is out to just get the whole issue around javax out of the way in one fell swoop. This would mean changing all of the specifications and take the hit with developers, communities and customers all in one go. I'm not convinced that's the right thing to do though I'm willing to listen to the community, but here's why I start from my position:<br />
<br />
<ul>
<li>It clearly breaks backwards compatibly and from the perspective of an end user that's not necessarily a good thing for all the reasons I mentioned before. Yes it "finally removes all Oracle control" as some have suggested, but I suspect most users of Java EE don't care about that, especially as they ignore it for other areas of our ecosystem like OpenJDK. So this could be an uphill struggle to convince people it's a good thing. Bad enough for one specification let alone all of them. In fact it could have the unintended affect of driving people away from Jakarta EE because if they have to change code anyway then why not look at all options, such as other frameworks, stacks or even languages.</li>
<li>We need to stop thinking about developers of Application Servers or their components and think about our end users who are not necessarily as well versed in the politics we often take for granted. A "one time hit" for us could be death by a thousand cuts for our users, communities and customers.</li>
<li>Going back to my original statement earlier about why a specification may have to change and why users may be ok with that, it all hinges on the definition of what constitutes a critical update to the specifications. Just changing the namespace doesn't count in my book (annoyance with Oracle isn't necessarily something people elsewhere care about, as I said earlier). I've heard that we should adopt Java 11 (like Java EE 8, Jakarta EE 8 only requires Java 8) and maybe suggest that we have to change the specifications somehow anyway as a result, so the namespace change is therefore forced on us and users. Well that doesn't work either because most vendors already support Java 11 without any changes to the specifications.</li>
<li>OK what about JPMS I hear you say? That's a part of Java 11 so we could take to opportunity to embrace modules for the specifications and again address the whole namespace issue at the same time. Look, I'm not going to rehash the whole Jigsaw debate from the other year but I think the jury is still well and truly out at the moment as far as JPMS is concerned so suggesting that this will do anything but alienate a large swathe of users is strange at the very least. JPMS is not a good reason to break compatibility for end users of something so mature and so well adopters as Java EE.</li>
</ul>
<br />
I cannot see any good reason (good for end users) that makes a wholesale change to the specification namespace worthy. Now that doesn't mean the community won't decide to go down that road, but if they do then they need to understand the potential potholes that are lying in wait. I've mentioned some of them and they could be so big as to derail the entire journey. Changing all of the specifications will require a lot of effort from vendors and communities to get behind the code changes, bug fixes etc. No one should be under any illusions that the developers and vendors who brought Java EE to where it is today are necessarily going to be able to commit as much to Jakarta EE in the future - the wider community is going to have to step up and fill in the gaps in effort and potentially monetary investment too. These specifications and implementations don't write themselves! One other thing to take into account: whilst the larger vendors can probably afford to make this kind of investment of time and people to change their implementations, it's entirely possible some smaller vendors won't have that luxury and that could reduce diversity.<br />
<br />
That's one of the routes from this crossroads outlined. What about another? Well the clear alternative to the wholesale change option is to do it gradually as and when meaningful modifications to the specifications are needed. That then raises the obvious question about what is the future direction for Jakarta EE? Let’s try to answer that before we venture down this other road.<br />
<br />
Those of you who have followed this adventure from the time we stood on stage at JavaOne 2017 will know that we said we wanted it to be the home of cloud native Java. That made perfect sense as we believed we could evolve the existing specifications seamlessly and eventually merge or otherwise collaborate with MicroProfile, which sprang up over a year prior to the JavaOne 2017 announcement. However, in this new world I'm no longer sure that makes sense and here's why:<br />
<br />
<ul>
<li>The use cases which drove the development of Java EE remain extremely relevant today as evidenced by size of the market. When you factor in those other frameworks and stacks which use components of Java EE (specifications and implementations), that size grows further. Those users typically want stability, compatibility and cautious evolution. But changes happen; Java EE today isn’t the same as J2EE in the beginning. That’s been fine over the last 15+ years as new specifications appeared in the javax namespace and modifications to existing specifications likewise. This is goodness. However, we have to recognise that Java EE hasn’t evolved rapidly over the years. The 18 month delay around Jakarta EE hasn’t exactly helped either. New specifications and updates to existing ones haven’t exactly been driving to a rapid release cadence release. Don't get me wrong though, that isn’t necessarily a bad thing: stability, maturity and reliability are good things after all and I believe many of today's long time users take that for granted and expect it.</li>
</ul>
<br />
<ul>
<li>Slowly evolving the stable standards and implementations as and when, helps to give users the chance to evolve at their own pace too and often only when significant changes happen. In fact it’s not rocket science to see how the old javax namespace implementations could reside alongside their updated Jakarta namespace siblings at the same time if we went this route.</li>
</ul>
Stability is the operative word then and therefore, I think we should re-evaluate our direction for Jakarta EE in light of the namespace debacle which clearly has the potential to throw that out of the window. It’s no disservice to the community and implementers to suggest that focussing on stability and existing use cases should become the priority for Jakarta EE. They represent the backbone of our industry. If something significant comes up later that requires a change to a specification then we evolve only that specification, as I mentioned above.<br />
<br />
What about new specifications though? Where do they get added? Well for now let’s assume that this route at the crossroads (this option) doesn’t preclude adding of new specifications to Jakarta EE, which would clearly have to be under a non-javax namespace, but we’ll put that topic on hold for a moment whilst we look at the final option at the crossroads where we find ourselves.<br />
<br />
I think we can all recognise that there are new use cases for new deployment environments such as the cloud or IoT which have shown that Java EE isn’t necessarily the right answer. The community and vendors saw this when we all kicked off Eclipse MicroProfile and over the 3+ years since that effort started we’ve seen a lot of activity, many more implementations than Java EE Application Servers, and a number of rapid releases annually.<br />
<br />
Whilst MicroProfile uses some Java EE specifications, it doesn’t need them all at the moment and might never. Some implementations can use Java EE Application Servers as a result of this. However, much of what has happened in MicroProfile has resulted in more non-Java EE specifications than Java EE and more implementations that don’t rely on Application Servers at all. It is a vibrant community evolving enterprise Java to be cloud-native faster than Java EE has so far been able to do. And it has a familiar feel to it as many of the same vendors and communities have become involved. Though if you look at the list of supporters and participants in the community you'll see many new names there, both big and small.<br />
<br />
As I mentioned, MicroProfile relies on a few Java EE specifications at the moment, e.g., JAX-RS and CDI. If that community needed to evolve them then it would naturally need to either change the namespace as we’ve already covered, or perhaps replace them wholesale with entirely different approaches, though that has its own pros and cons. However, because MicroProfile doesn’t rely on many Java EE specifications, and when and where it does the use cases MicroProfile has will likely be satisfied with the stable javax versions anyway, it’s probable that the impact of any namespace changes is already much more focussed, meaning users are that much less likely to want to consider jumping ship.<br />
<br />
Since the point we announced Jakarta EE and began working on it we've been asking the question about whether and how MicroProfile might merge into Jakarta EE, perhaps providing the innovation branch of it. But if the community wants to evolve Jakarta EE to cloud-native, I believe it makes more sense given the recent announcements to jump straight there and anoint MicroProfile as the place where that work continues to happen, pulling over specifications from Jakarta EE only where needed, modifying them only when there's a good reason. We don’t want to split the community and cause yet more confusion or delays and whilst some may want to continue driving Jakarta EE forward to conflict with MicroProfile, that risks fracturing the efforts and not capitalising on the momentum happening there now. Therefore, if new specifications were to be considered to be added to Jakarta EE around cloud-native, my preference would be for them to be moved to MicroProfile instead. And of course that doesn't mean they can't be taken back in to Jakarta EE if and when new releases are deemed necessary.<br />
<br />
OK so you've gotten here and you'd probably like a summary of the options as I see them so here goes:<br />
<br />
<ol>
<li>The Big Bang approach and change all of the javax namespace at Jakarta EE 9 to something else. Not my personal preference as it risks alienating a lot of end users, driving them elsewhere and possibly reducing implementation diversity.</li>
<li>Focus on stability and compatibility for Jakarta EE and evolve specifications and namespace only as and when new and significant modifications to them are needed, such as new features, bug fixes etc. New specifications can be added here too but clearly not under the javax namespace. I'm more keen on this option but the communities need to agree on the use cases as there's a possible conflict with MicroProfile.</li>
<li>Agree that MicroProfile is the place to evolve Jakarta EE specifications if they need to become more cloud-native. MicroProfile will likely look forward though and add more and more new specifications and only pull across specifications from Jakarta EE when really needed, as has been the model to date. My preference, in case it wasn't obvious.</li>
</ol>
<br />
<br />
Now maybe there are other options, such as significant reasons for why Jakarta EE should evolve in directions not covered by MicroProfile. And of course option 2 and 3 aren't necessarily mutually exclusive if we can find other meaningful use cases for evolving Jakarta EE in option 2. It’s also possible some people won’t agree with my assessments. For me those are all good and acceptable outcomes from reading this article. I’m a scientist and if new information comes to light which impacts a theory I’ve created then I’ll re-evaluate. But what I caution everyone against is making rash decisions in the heat of the moment, especially if they are fuelled with the “let’s stick it to Oracle and get this done!” That attitude won’t lead to the right outcome and we could then spend many years regretting it.<br />
<br />
The next step should be discussing this in the communities and not just the Jakarta EE community. The MicroProfile community is just as tied into the future of Jakarta EE. How we move forward with both is important to both. Let’s do this together and make the right consensus driven decision. This is a tricky time and we shouldn't rush to a decision on partial facts or worse still, anger and frustration.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com4tag:blogger.com,1999:blog-9203557.post-1438749165391372082019-03-15T14:16:00.000+00:002019-03-15T14:16:44.968+00:00Why Quarkus?<br />
<div>
One size rarely fits all. I've written about this a number of times, for instance on the topic of extended transactions. In the world of building architecture that rule applies too or we'd all be living in caves! The Red Hat/JBoss middleware developer strategy for many years has recognised this fact and we support the frameworks and associated stacks for a wide variety of developers to use when building the next generation of microservice-based applications. Because polyglot is the normal situation today it does not just focus on Java, hence why Node.js is in there. Furthermore, not all new applications will be build from scratch; there has to be a way for existing applications to evolve and similarly for existing developers to evolve their skills rather than having to start from scratch.</div>
<div>
<br /></div>
<div>
As anyone who has been in this industry long enough knows, existing investments remain with us for years (decades in many cases). We can’t just throw them out the window when something new comes along. Neither can we throw the people out the window! Therefore, appealing to so-called brownfield developers is critical because it allows them to leverage their existing skills and key knowledge which likely has built up over many years. Brownfield can include:</div>
<div>
<ul>
<li>building new services and applications which require/leverage/integrate with existing systems but where the new components are developed in some new framework or approach;</li>
<li>evolving existing systems, components and services built with mature (I hate "legacy") frameworks and stacks towards newer styles. One example of this would be the evolution of CORBA to J2EE.</li>
</ul>
</div>
<div>
So whilst it might look like adding Quarkus to the mix confuses things, it really doesn’t, or at least it shouldn’t and here’s why: there’s a spectrum of developers and applications and our approach attempts to cover the important areas of that spectrum. Specifically there's no one tool or framework right for the entire application or developer and you’ll need some or all of Quarkus (remember, it combines [<a href="https://developer.jboss.org/blogs/mark.little/2015/10/27/next-generation-frameworks-and-stacks">will combine</a>] serverless with Camel-K/Fuse, our core services on Kubernetes, such as [xPaaS] SSO, transactions, messaging, and uses Eclipse Vert.x for reactive and Eclipse MicroProfile/SmallRye), with EAP/WildFly if you need Java EE/Jakarta EE. And crucially, wherever your app is developed or deployed, they will be able to communicate and interact seamlessly as if developed with the same technology stack.</div>
<div>
<br /></div>
<div>
We’ll be talking more about how this all comes together in the coming weeks and months but another important point to remember is that we’re driving this upstream first, as we always do within JBoss/Red Hat. In fact <a href="https://thorntail.io/posts/thorntail-community-announcement-on-quarkus/">Ken Finnigan's recent blog about the future of Thorntail</a> is one of those important next steps. So if you want to get involved and help influence the technical direction please do! There are multiple entry points, i.e., you don’t need to start with Quarkus if you are more interested in Keycloak, or WildFly or Narayana (yeah!)</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-47490652985495512012018-10-30T11:50:00.002+00:002018-10-30T12:19:38.042+00:00Red Hat and IBM ... Really?I’m writing this here on my personal blog because it’s not an official statement from Red Hat and I wanted everyone to know that what I’m putting here is my honest opinion and not clouded by the fact I work for Red Hat. I’m trying to be objective here, building on my scientific background.<br />
<br />
I’ve had a couple of days to digest the news about <a href="https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-worlds-1-hybrid-cloud-provider?intcmp=701f2000000RWK2AAO">Red Hat acquiring IBM</a>. That is the way round, right? 😉 I always like to say that JBoss acquired Red Hat in 2006 too 🙂 Anyway, I’m excited by the opportunity this gives. I know many people at different levels throughout IBM and they are good people and have a great deal of respect for Red Hat in general and specifically, due to the areas where we interact, the middleware/Java teams, products and projects.<br />
<br />
Yes, maybe there are other companies who would be “better” but I can think of a lot of others who would be “worse”. I’ve been acquired six times now, including this one, so I know full well what many of my fellow Red Hatters are going through. I know that in this period of uncertainty there will be those who are worried. That’s only natural. But I’m hoping that over the coming weeks and months we’ll get more details and everyone will be able to see what working as a wholly owned subsidiary of IBM actually means if IBM want to preserve Red Hat.<br />
<br />
IBM and Red Hat have a great track record of working together in the middleware space, in areas such as Eclipse MicroProfile, Jakarta EE and Java, then there’s all the other standards work we’ve done over the years. Yes they aren’t Red Hat but then no company every could be. I’ve worked at a number of companies and I think JBoss and Red Hat are the best but when a company spends a third of its market cap to acquire another company that’s almost a merger! It’s in everyone’s interest in IBM to make it succeed and keep the great teams we have built up in Red Hat. IBM recognises what we all appreciate here: our key assets are the people and not just the code. Therefore, they need to ensure we keep those people happy and together if Red Hat is to continue to succeed. And I think <a href="https://www.aniszczyk.org/2018/10/29/red-hat-and-ibm-elephants-can-dance/">Chris</a> puts it well- IBM is no novice in the open source space.<br />
<br />
Recall that only a few years back we had hoped IBM would acquire Sun over Oracle? I have had some contact with friends and colleagues in IBM over the past few days and I can tell you they are excited by the possibility of working together. Collectively we have an opportunity to define the next phase for IBM. And I use the term “we” here because the Red Hat communities have been a key part of our success to date and just as this deal succeeds or fails by bringing the employees along, so too does it need the communities: you can’t be an open source company, big or small, without them. Red Hat works in some of the biggest upstream communities there are and I’m sure IBM understands their value lies with collaboration, trust built on relationships between people first and vendors second, and so many other factors that it’s really easy to spoil them if you aren’t careful. Again, as Chris mentions, they “get this” and I have every reason to believe that myself.<br />
<br />
I know some people outside the company have been incredibly down on the deal suggesting that IBM will kill or stifle the Red Hat culture, cause us to become unfocused or take the proverbial foot off the pedal. Sure that’s possible, but it’s unlikely because no company has ever acquired a company quite like Red Hat before. Our culture of openness is incredibly strong (didn’t Darth Vader once say “The Red Hat Culture is strong in this one” or am I thinking of something else?) I’m pretty confident to say that it won’t happen because we won’t let it happen. Remember what I said about the assets? Well many of those assets are pretty verbal when they want to be ... I’ve been on the receiving end once or twice publicly and privately 😉 Also I think some of those people trying to throw cold water on this are the usual Trolls, maybe disgruntled for other reasons, or wanting to try to pull key Red Hat folks away to other companies in the first few hours of uncertainty; not necessarily objective. But they could be right in the long run if Red Hat and IBM can’t work well together - fortunately I think we stand a much better chance of succeeding than failing, if we all stick together.<br />
<br />
I’ll finish off by trying to end some speculation I’ve seen in the media about what “lives and dies” after the acquisition. Here they’re talking about software products, clearly! Look, no one knows for sure but I do know that between the two companies we have some of the most influential open source projects and products out there with huge adoption and developer interest. It’s not as clear cut as some people are trying to make out, especially when you look at the future of cloud-native middleware. I have some thoughts on the subject of course and although I haven’t confirmed, I’m sure IBM people do too. We’ll have some good, collaborative discussions to define the way forward, taking everything I’ve already said about developers, engineers, community and customers into account. It’ll be fun and I’m hoping all interested parties, whether or not employees of either company, will participate.<br />
<br />
On a personal level, I intend to remain committed to Eclipse MicroProfile, Jakarta EE, WildFly, Thorntail, Drools, jBPM, 3scale, Fuse, Camel, A-MQ, ActiveMQ, Active MQ Artemis, OpenJDK, JCP EC and all of the countless projects and products we have today. The teams and the code are definitely something of which we should all be proud.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com1tag:blogger.com,1999:blog-9203557.post-64848266792168131752018-01-28T19:02:00.001+00:002018-01-28T19:02:55.936+00:00Eventual consistency and microservicesSince at least the early 1990's our industry and academia have dabbled with eventual consistency. I've <a href="http://markclittle.blogspot.co.uk/2008/12/eventual-consistency-and-xtp.html">written </a>and <a href="https://www.youtube.com/watch?v=CR8_m5_k4fQ">spoken </a>a bit about eventual consistency around transactions and replication as it applies to <a href="https://developer.jboss.org/blogs/mark.little/2011/08/29/why-you-need-an-enterprise-platform-for-a-paas">scaling systems</a> and also <a href="https://www.slideshare.net/soasymposium/mark-little-web-services-and-transactions">SOA </a>over the years. As <a href="https://ericnewcomer.wordpress.com/2007/06/06/response-to-gregor-on-transactions/">Eric wrote</a> many years ago, some of it even made its way into standards. Recently the industry has been looking at how eventual consistency may be required within microservices. For instance, what about <a href="https://groups.google.com/forum/#!topic/microprofile/CJirjFkM9Do">Eclipse MicroProfile and transactions</a> (yes, a favourite of mine)? It's possible some of this may make its way into Eclipse EE4J. And now Matt Klein from Lyft has written a <a href="https://medium.com/@mattklein123/embracing-eventual-consistency-in-soa-networking-32a5ee5d443d">nice piece</a> about eventual consistency and networks, which is also worth a read.<br />
<br />
Just remember: right tool for right job; just as ACID transactions aren't right for evry use case, strong consistency isn't right for every use case, and hence neither is eventual consistency right for every use case. Think, understand, consider and apply.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-60897636510157265242017-12-31T19:00:00.000+00:002017-12-31T19:00:02.023+00:00Effectiveness of Replication Strategies
<br />
<div class="page" title="Page 108">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">In [Noe 86] a simulation study for the comparison of available copies, quorum
consensus, and regeneration was carried out to determine which replication protocol was
the most efficient given a specific configuration of distributed system, and a certain set of
failure characteristics.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<div class="page" title="Page 108">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">The model was programmed in SIMULA [<a href="https://dl.acm.org/citation.cfm?id=1096934">Birwhistle 73</a>], and assumed a local area
network consisting of a number of separate computers interconnected by a
communications medium such as an Ethernet, with no communications failures. The
parameters used in the simulation, such as crash rates and node load, were obtained from
studies of existing distributed systems and from mathematical models, and all parameters
were the same for each replication protocol simulated. Crash frequency varied between </span><span style="font-family: Times; font-size: 13pt;">100 and 300 days, with repair times having a mean of 7 days. The number of replicated
resources ranged from only one copy to having three copies, and the ratio of read requests
to write requests varied from a probability of 0.3 up to 0.7, with request frequencies
varying from between 50 and 400 requests per day. The number of nodes in the system also
varied from 10 to 30. All measured results were taken over a simulated time of 2 years of </span><span style="font-family: Times; font-size: 13pt;">operation.</span><br />
<br />
<div class="page" title="Page 108">
<div class="layoutArea">
<div class="column">
<h3>
<span style="font-family: 'Helvetica'; font-size: 12.000000pt; font-weight: 700;">Simulation Results </span></h3>
<div>
<div class="page" title="Page 108">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">The quantities calculated from the results were the read and write availability of the
replicated service. The read availability was defined and calculated as the total number of </span><span style="font-family: Times; font-size: 13pt;">successful read requests divided by the total number of read requests. Write availability
was similarly defined in terms of write requests.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<div class="page" title="Page 109">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">What was found from the results was that replication provides a significant increase in
availability. However, there is little point in going beyond a maximum of two copies. Both
the Available Copies and Regeneration techniques provide a substantial increase in
availability, raising the value of read and write availability very close to 1.0 i.e., whenever a
request is performed upon a replicated resource it will be carried out successfully. There is
very little additional gain with either of these protocols in having a maximum of 3 copies of
each resource.
</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
</div>
</div>
</div>
<span style="font-family: Times; font-size: 13pt;">The Voting protocol provided less protection than either of the other protocols and
would not even be considered until a maximum of 3 copies were used. In such a case the
optimal size for a read and write quorum is 2; with a write quorum of 3 the replicated
resource performed worse than in the non-replicated case because there are three ways to
lose a single copy and destroy the write quorum.</span><br />
<span style="font-family: Times; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 109">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">Both Available Copies and Regeneration are preferable to Voting if network
partitions are rare, or if measures are added to prevent or reconcile independent updates
during partition rejoining. The read and write availability of the Available Copies
technique are the same, and remain relatively constant despite changes in the request rate </span><span style="font-family: Times; font-size: 13pt;">and the number of nodes. Regeneration can be preferable to Available Copies in an
unstable environment that suffers from high crash frequencies, with a high number of
updates and frequent reconfiguration of the network. Further, Regeneration can equal or
surpass the performance of the Available Copies technique only if enough additional
storage is supplied to allow regeneration. </span><br />
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-43048728944907193372017-12-31T18:53:00.001+00:002017-12-31T18:53:30.200+00:00Optimistic and Pessimistic Consistency Control
<br />
<div class="page" title="Page 107">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">The replication protocols described previously can all be considered </span><span style="font-family: 'Times'; font-size: 12.000000pt; font-style: italic;">pessimistic </span><span style="font-family: 'Times'; font-size: 13.000000pt;">with
regard to consistency of data in the presence of network partitions. Until a partitioned
network is reconnected, it is impossible for nodes on one side of the partition to
differentiate between being partitioned and a failure of the nodes on the other side of the
partition. As has been described in previous sections, this can have an adverse affect on
replicated groups which have also been partitioned, unless some method is provided to </span><span style="font-family: Times; font-size: 13pt;">ensure that update operations can only be performed consistently on the </span><span style="font-family: Times; font-size: 12pt; font-style: italic;">entire </span><span style="font-family: Times; font-size: 13pt;">group. Typically, these replication protocols are used in conjunction with atomic actions, and in
the event of a network partition either only one partition (in the case of Voting) or no
partition is allowed to continue to progress, meaning that any atomic actions that were
executing must be aborted to maintain consistency of state between the partitioned
replicas. They are pessimistic, using the principle that, if it is not possible to tell definitely
that replicas have failed then it is better to do nothing at all. Those protocols which can
operate correctly in the presence of a network partition (still maintain consistency of
replicas), such as Voting, typically impose an overhead on the cost of performing </span><span style="font-family: Times; font-size: 13pt;">operations on replicas (in the Voting protocol, the cost of performing a read operation is
increased because a quorum of replicas must be obtained).</span><br />
<span style="font-family: Times; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 107">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">An </span><span style="font-family: 'Times'; font-size: 12.000000pt; font-style: italic;">optimistic </span><span style="font-family: 'Times'; font-size: 13.000000pt;">consistency control scheme like those described in [<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.7025&rep=rep1&type=pdf">Davidson84</a>][<a href="http://www.vldb.org/conf/1990/P243.PDF">Abbadi 89</a>] take a different approach and allow actions to continue operating even in
the event of a partition. When the partition is eventually resolved it must be possible to
detect any conflicts that have arisen as a result of the original failure and to be able to
resolve them. These protocols assume that it is possible for committed actions to be rolled
back (i.e., un—committed). How the detection and resolution of conflicts is performed is </span><span style="font-family: Times; font-size: 13pt;">system specific e.g., in some systems it must be done manually, whereas in [<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.7025&rep=rep1&type=pdf">Davidson 84</a>] a
mechanism is described that will allow the system to automate much of the work.</span><span style="font-family: Times; font-size: 13pt;"> </span><br />
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-85602686048247451922017-12-31T08:51:00.002+00:002017-12-31T08:51:46.856+00:00JBossTS/Narayana blog - a reminderI haven't been cross-posting links to the <a href="http://jbossts.blogspot.co.uk/">JBossTS/Narayana</a> blog recently and it's well worth taking a look at the team have written a number of great articles over the year, particularly around microservices and transactions.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-76010527676318040302017-12-31T08:49:00.000+00:002017-12-31T08:49:05.980+00:00Primary Copy
<br />
<div class="page" title="Page 106">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">The Primary Copy [<a href="http://pages.cs.wisc.edu/~remzi/Classes/739/Papers/p562-alsberg.pdf">Alsberg 76</a>] mechanism is an implementation of the passive
replication strategy, where one copy of an object is designated as the primary, and the
other copies become its backups. All write operations are performed on the primary copy
first, which then propagates the update to the secondary copies before replying to the
request. Reads can be serviced by any replica since they all contain consistent copies of the
state. </span><span style="font-family: 'Times'; font-size: 12.000000pt; font-style: italic;">Any inaccessible </span><span style="font-family: 'Times'; font-size: 13.000000pt;">secondary copies are typically marked as such (perhaps to a
name-server) so that they cannot be used as either a future primary or to be read from
until they have been brought up-to-date (another method would be physically to remove
them from the replica group until they have been updated). If the Primary Copy fails then a
reassignment takes place between the remaining copies to elect a new Primary.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: Times; font-size: 13pt;">A problem arises when the Primary copy fails. If the primary site is down a
reassignment is in order. However, if the network has become partitioned a reassignment
would compromise consistency. If network partitioning has a low probability of
occurrence then the process for electing a new primary can be allowed: the secondaries
should be notified of the primary's failure and they must agree amongst themselves which
one is to become the new primary copy. If the election of a new primary takes place and the
existing primary has not actually failed (perhaps it was not able to reply to the 'are you
alive' probe-messages in time because of an overloaded node) then the protocol should
ensure that the client will only accept a reply from the newly elected primary, as the old
primary could be in an inconsistent state. The protocol described in [<a href="http://pages.cs.wisc.edu/~remzi/Classes/739/Papers/p562-alsberg.pdf">Alsberg 76</a>] tolerates
network partitions by allowing operations to continue in all partitioned segments and
relying upon some "integration" protocol to merge the states of replica groups when the
partitions are re-joined. However, such integration is not guaranteed to be resolvable.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: Times; font-size: 13pt;">If we take the case of only a fixed primary site i.e., no secondary takes over because
partitioning is possible, then a resource replicated using this strategy only increases the </span><span style="font-family: Times; font-size: 13pt; font-style: italic;">read</span><span style="font-family: Times; font-size: 13pt; font-style: italic; font-weight: 700;"> </span><span style="font-family: Times; font-size: 13pt;">availability. Its </span><span style="font-family: Times; font-size: 12pt; font-style: italic;">write </span><span style="font-family: Times; font-size: 13pt;">availability is the same as the availability of the primary site. The
other replication strategies all provide ways of increasing write availability.</span><br />
<span style="font-family: Times; font-size: 13pt;"> </span><span style="font-family: 'Times'; font-size: 13.000000pt;"> </span><br />
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-28219338573463021442017-12-31T08:45:00.001+00:002017-12-31T08:45:55.721+00:00Regeneration<br />
<div class="page" title="Page 105">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">Regeneration [<a href="http://ieeexplore.ieee.org/document/42736/">Pu 86</a>] is a similar replication scheme to Available Copies in that a
client only requires one replica to service a read request but a write must be performed by
all copies. When an update occurs, if fewer than the required number of replicas are
available then additional copies are regenerated on other operating nodes. In doing so the
system must check that there is sufficient space available on the target node for the new
replica (in terms of the volatile and stable storage that it may use) and also that a copy does
not already reside there. A write failure occurs if it is not possible to update the correct
number of replicas, and a read failure occurs if no replica is available.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: Times; font-size: 13pt;">A recovering node and replica cannot simply rejoin the system. For each replicated
resource the system must check to see whether the maximum number of replicas already
exist. If so the recovering replica is deleted. If the maximum number does not exist the
system must check one of the available replicas to determine whether the state of the
recovering replica is consistent. If the recovering replica is inconsistent (i.e. an update has
occurred since this replica failed) then it must be deleted because a new copy has already
been created to take its place but is currently unavailable.</span><span style="font-family: 'Times'; font-size: 13.000000pt;"> </span><br />
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-66216209981112269212017-12-31T08:43:00.000+00:002017-12-31T08:43:31.380+00:00Weighted Voting<br />
<div class="page" title="Page 103">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The Voting (or Quorum Consensus) replication protocol [<a href="https://www.cs.cornell.edu/courses/cs614/2003sp/papers/Gif79.pdf">Gifford 79</a>] is a replication
scheme which can operate correctly in the presence of network partitions. In this method a
non—negative weight is assigned to each replica and this weight information is available to
every client in the network. When a client wishes to read (write) the group it must first gain
access to what is known as a </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">read (write) </span><span style="font-family: "times"; font-size: 13.000000pt; font-style: italic;">quorum. </span><span style="font-family: "times"; font-size: 13.000000pt;">A quorum is any set of replicas with
(typically) more than half the total weight of all copies. A read quorum (Nr) and a write
quorum (Nw) are defined such that Nr+Nw > N (the total weight).</span><br />
<div style="text-align: center;">
<span style="font-family: "times"; font-size: 13.000000pt;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiILcE1ldhlayu-YrpDv_lOD6dSNJfMGk4sSRQb4FSpGP4SvUo_msj6wOFwJrNKHaxQ0gLNryTWT2ATksOOO6shSAEyj_3Lvnue3a-UxVivxcXWimElsCSigGfVineEa5ge79LVNw/s1600/Screen+Shot+2017-12-31+at+08.30.17.png" imageanchor="1"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiILcE1ldhlayu-YrpDv_lOD6dSNJfMGk4sSRQb4FSpGP4SvUo_msj6wOFwJrNKHaxQ0gLNryTWT2ATksOOO6shSAEyj_3Lvnue3a-UxVivxcXWimElsCSigGfVineEa5ge79LVNw/s320/Screen+Shot+2017-12-31+at+08.30.17.png" width="320" /></a> </span></div>
<div style="text-align: left;">
</div>
<div class="page" title="Page 103">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">A read operation requires the access of any Nr copies (only data from up—to—date
replicas should be used), and a write operation requires N up—to—date copies (so updates
are not applied to obsolete replicas). The number of inaccessible copies tolerated by a
read is N-Nr, and for a write operation it is N—Nw. The purpose of having quora is to
ensure that read and write operations have at least one copy of an object in common. If the
network partitions then voting allows access only from the majority partition if one exists.</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13pt;">Associated with each replica is a timestamp or update number which clients can use to
determine which replicas are up—to—date. If Nw ≠ N then a read quorum is required to </span><span style="font-family: "times"; font-size: 13pt;">obtain the most up-to-date version of this number. If Nw = N then every functioning copy
must contain the same value because every write operation has been performed on every
replica in the group. This update number is used by clients to ensure that they only read
data from up-to-date replicas, even though they may acquire access to out-of-date
replicas in their read quorum.</span><br />
<div class="page" title="Page 104">
<div class="layoutArea">
<div class="column">
<br />
<div class="page" title="Page 104">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The write operation is a two-phase, atomic operation, because either the states of Nw copies are modified or none of them are changed (to ensure that subsequent read and
write quorum overlap and that a majority of the replicas are consistent). If a write quorum
cannot be obtained the transaction must be aborted. However, a separate transaction can
be run to copy the state of a current replica to an out-of-date replica. It is always legal to
copy the contents of replicas in this way.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">The weights assigned to replicas should be based on their relative importance to the
system e.g., a printer spooler which resides on a very fast node would be considered better
for throughput than one which resides on a slower node and would therefore be assigned a
higher weight than a replica on a slower node. A replica with higher weight is more likely
to be in the quorum component.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">A major problem with this protocol is that read operations require a quorum, even if
there is a local copy of the object. This can prove inconvenient (and slow) if an object
wishes to carry out many read operations on that object in a short space of time. There is
also the problem of fault tolerance: many copies of an object must be created to be able to
tolerate only a few failures e.g., we require five copies just to be able to tolerate two
crashes. </span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<br />
<div class="page" title="Page 104">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">Note that to cut down on the storage requirements Witnesses [<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.146.3429&rep=rep1&type=pdf">Paris 86</a>] can be used in
place of actual replicas. A witness only maintains the current version number of the data.
They can take part in quora, but there must be at least one "real" replica in a quorum.
Other replication protocols based on the Voting protocol also exist [<a href="http://www.vldb.org/conf/1990/P243.PDF">Abbadi 90</a>][<a href="http://ieeexplore.ieee.org/document/21724/">Jajodia89</a>][<a href="http://ieeexplore.ieee.org/document/21731/">Davcev 89</a>]. They address issues such as the need to acquire a quorum for a read </span><span style="font-family: "times"; font-size: 13pt;">the responses of "true" copies. A write can only succeed if a write quorum contains at least
one non-ghost copy.</span><br />
<br />
<span style="font-family: "times"; font-size: 13pt;">Because of the way in which ghosts are created and used, a ghost is used to ensure that a
particular non-ghost copy has failed due to a node crash and not to a segment partition. If
it is possible to create a ghost then the segment has not been partitioned and only the node
has failed. In Available Copies when a replica does not respond it is simply assumed that it
is because of node failure, which can result in inconsistencies if the copy was partitioned.
When the node on which the non-ghost copy originally resided is re-booted it is possible
to convert the ghost copy back into its live version.</span><span style="font-family: "times"; font-size: 13.000000pt;"> </span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-2127287270442405112017-12-22T13:18:00.001+00:002017-12-22T13:19:50.550+00:00Available Copies<br />
<div class="page" title="Page 100">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">In the Available Copies [<a href="https://www.amazon.co.uk/Concurrency-Control-Recovery-Data-Systems/dp/0201107155">Bernstein 87</a>] replication protocol, a user of a replicated
service reads from one replica and writes </span><span style="font-family: "times"; font-size: 12pt;">to all available replicas. Prior to the execution of </span><span style="font-family: "times"; font-size: 13pt;">an action, each client determines how many replicas of the service there are available, and
where they are, (this information may be stored in a naming service and is accessed before
each atomic action is performed). Whenever a client detects a failure of a replica it must
update the naming service </span><span style="font-family: "times"; font-size: 12pt; font-style: italic;">(name-server) </span><span style="font-family: "times"; font-size: 13pt;">view of the replicated object by performing a
</span><span style="font-family: "times"; font-size: 12pt; font-style: italic;">delete </span><span style="font-family: "times"; font-size: 13pt;">operation for the failed copy. All copies of the name-server, if it too is replicated,
must be updated atomically.</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 101">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">When a write operation is performed all copies are written to and they must all reply to
this request within a specified time (it is assumed that it is always possible to communicate
with non-faulty replicas). Locks must be acquired on all of the functioning replicas before
the operations can be performed, and if conflicts between clients occur then some replicas
will not be locked on behalf of a client, and the client will be informed, at which point the
calling action is aborted. Using this locking policy and the serialisability property of the
actions within which operations occur, it is possible to ensure that all replicas execute the </span><span style="font-family: "times"; font-size: 13pt;">operations in identical order. </span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 101">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">If all replicas reply to a write operation then the action may continue. However, if only
a subset reply the action must ensure that the silent members have in fact failed, If the
silent replicas subsequently reply then the action must abort and try again (this is because
the states of the replicas may have diverged). However, if the silent copies have actually
failed then the action can still commit since all available copies are in a consistent state.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">Whenever a new copy is created (or recovers from a failure) it must be brought
up-to-date before the name-server is informed of the recovery (before a client can make
use of the replica). When this is done the copy can take requests from clients along with the
other members of the group. The updating of recovered replicas can be done
automatically if an out-of-date replica intercepts/receives a write request from a current
transaction, as has been mentioned previously.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">Consider the history of events shown in the diagram below, where T</span><span style="font-family: "times";"><span style="font-size: x-small;">1 </span></span><span style="font-family: "times"; font-size: 13.000000pt;">and T</span><span style="font-family: "times";"><span style="font-size: x-small;">2</span></span><span style="font-family: "times"; font-size: 13.000000pt;"> are
different transactions operating on two replica groups whose members are xl, x2 and </span><span style="font-family: "times"; font-size: 13pt;">yl, y2. Assume that T</span><span style="font-family: "times";"><span style="font-size: x-small;">1</span></span><span style="font-family: "times"; font-size: 13pt;"> and T</span><span style="font-family: "times";"><span style="font-size: x-small;">2</span></span><span style="font-family: "times"; font-size: 13pt;"> are using a "read—one copy, write—all—available copies"
scheme and that there are initially two copies of objects x and y which they both wish to
access. The execution of events is as shown, with time increasing down the y—axis.</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 102">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">If we examine the above history, it is clearly not 1SR i.e., neither the serial execution
T</span><span style="font-family: "times";"><span style="font-size: x-small;">1</span></span><span style="font-family: "times"; font-size: 13.000000pt;">;T</span><span style="font-family: "times";"><span style="font-size: x-small;">2</span></span><span style="font-family: "times"; font-size: 13.000000pt;"> nor T</span><span style="font-family: "times";"><span style="font-size: x-small;">2</span></span><span style="font-family: "times"; font-size: 13.000000pt;">;T</span><span style="font-family: "times";"><span style="font-size: x-small;">1</span></span><span style="font-family: "times"; font-size: 13.000000pt;"> are consistent with the above history. Thus, the idea of "read—one copy,
write—all—available copies" by itself cannot guarantee 1SR. It is necessary to execute a
validation protocol before the transaction can commit to ensure correctness. In Available
Copies this takes the form of ensuring that every copy that was accessed is still available at
commit time, and every replica that was unavailable is still unavailable, otherwise the
action must abort. </span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<br />
<div style="text-align: center;">
<span style="font-family: "times"; font-size: 13.000000pt;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj47XLXl1rzoEvd7QjsfN9FGilwwTwMSFEWCuycI5UoosADXXJwG1ODNFRFzPEqiKHR9Hl0NCFwzCrO6k75x22PH3o5tv2t5OwWEd0x4kpj0lrTt9_B3WzJrB4XV-x5j9uuO9id_w/s1600/Screen+Shot+2017-12-22+at+13.09.07.png" imageanchor="1"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj47XLXl1rzoEvd7QjsfN9FGilwwTwMSFEWCuycI5UoosADXXJwG1ODNFRFzPEqiKHR9Hl0NCFwzCrO6k75x22PH3o5tv2t5OwWEd0x4kpj0lrTt9_B3WzJrB4XV-x5j9uuO9id_w/s400/Screen+Shot+2017-12-22+at+13.09.07.png" /></a></span></div>
<div style="text-align: left;">
</div>
<div class="page" title="Page 102">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">Because of the assumption made by Available Copies that all functional replicas can
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;">always be contacted, this means that this protocol cannot be used in the presence of
network partitions. Anode which is partitioned cannot be distinguished from a failed node
until it has been reconnected. If the replication protocol assumes that all nodes which are
unavailable have failed when in fact some have only been partitioned, inconsistencies can
result in the replicas. As such, if partitions can occur then the
replication protocol must be sufficiently sophisticated that it can ensure consistent
behaviour despite such failures. </span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-62839409193780399022017-12-22T13:06:00.000+00:002017-12-22T13:06:20.516+00:00Data Replication in Atomic Action Systems
<br />
<div class="page" title="Page 99">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">Data replication techniques for atomic action systems to maintain </span><span style="font-family: 'Times'; font-size: 13.000000pt; font-style: italic;">one-copy
serialisability (1SR) </span><span style="font-family: 'Times'; font-size: 13.000000pt;">have been extensively studied (most notably with regard to replicating
databases). When designing a replication protocol it is natural to examine those protocols
(and systems which use them) that already exist, to determine whether they have any
relevance.</span><br />
<br />
<ul>
<li><span style="font-family: Times; font-size: 13pt;">Definition: If the effect of a group of atomic actions executing on a replicated object is
equivalent to running those same atomic actions on a single copy of the object
then the overall execution is said to be 1SR.</span></li>
<li><span style="font-family: Times;"><span style="font-size: 17.33333396911621px;"><br /></span></span></li>
<li><span style="font-family: Times; font-size: 13pt;">Definition: A </span><span style="font-family: Times; font-size: 13pt; font-style: italic;">replica consistency protocol </span><span style="font-family: Times; font-size: 13pt;">is one which ensures 1SR.</span></li>
</ul>
<br />
<span style="font-family: Times; font-size: 13pt;">Because most replication protocols have been developed for use in database
environments it is important to understand the differences between the way in which
operations function in a database system and the way in which similar operations would
function in an object-oriented environment. These differences are important as they
affect the way in which the replication protocols function.</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: 'Times'; font-size: 13.000000pt;">In a database system, which performs operations on data structures, a read operation is
typically implemented as a "read entire data structure", and a write operation is in fact a </span><span style="font-family: Times; font-size: 13pt;">"read entire data structure, update state locally to the invoker, then write entire new data
state back". In this way, a single write operation can also update (or re-initialise) the state
of an out-of-date data structure.</span><br />
<span style="font-family: Times; font-size: 13pt;"><br /></span>
<div class="page" title="Page 100">
<div class="layoutArea">
<div class="column">
<span style="font-family: 'Times'; font-size: 13.000000pt;">In an object-oriented system, the read operation is typically implemented as "read a
specific data value". Similarly, the write is "perform some operation which will modify the
state of the object". The object simply exports an interface with certain operations through
which it is possible to manipulate the object state. Some of these operations may update
the state of the object, whilst others will simply leave it unchanged. A write operation in
this case may only modify a subset of an object's state, and so cannot be guaranteed to
perform an update as in a database system.
</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: 'Times'; font-size: 13.000000pt;">In a database system, the fact that a single write operation can update the entire state
of a replica is used in replication protocols such </span><span style="font-family: 'Times'; font-size: 12.000000pt; font-style: italic;">as Available Copies. </span><span style="font-family: 'Times'; font-size: 13.000000pt;">If these protocols are
to be used in an object-oriented system then they will require explicit update protocols.
</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: 'Times'; font-size: 13.000000pt;">Finally, in a database system the invoker of a given operation knows whether that
operation is state modifying or not i.e., it knows which type of lock </span><span style="font-family: 'Helvetica'; font-size: 13.000000pt;">will </span><span style="font-family: 'Times'; font-size: 13.000000pt;">be required.
However, in an object-oriented system users of a given object only see the exported
interface and see nothing of the implementation, and therefore do not know whether a
given operation </span><span style="font-family: 'Helvetica'; font-size: 13.000000pt;">will </span><span style="font-family: 'Times'; font-size: 13.000000pt;">modify the state of the object. This difference is important as many of
the replication protocols to be described implicitly assume that clients have this type of
knowledge (it is used to ensure that read operations can be executed faster than write
operations).</span><br />
<span style="font-family: 'Times'; font-size: 13.000000pt;"><br /></span>
<span style="font-family: 'Times'; font-size: 13.000000pt;">In the next few entries we </span><span style="font-family: Times; font-size: 13pt;">shall examine some of the replication protocols which have been proposed for
managing replicated data.</span><br />
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-24641252969786298082017-12-20T09:03:00.001+00:002017-12-20T09:04:29.456+00:00Replication and Atomic Actions<br />
<div class="page" title="Page 95">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">Replication can be integrated into atomic actions in two ways: </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">replicas within actions,
</span><span style="font-family: "times"; font-size: 13.000000pt;">and </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">replicated actions. </span><span style="font-family: "times"; font-size: 13.000000pt;">These two methods are substantially different from each other and
</span><span style="font-family: "times"; font-size: 13pt;">yet attempt to solve the</span><span style="font-family: "times"; font-size: 13.000000pt; font-weight: 700;"> </span><span style="font-family: "times"; font-size: 13.000000pt;">same problem: to ensure (with a high degree of probability) that an
action can commit despite a finite number of component failures.</span><br />
<br />
<div class="page" title="Page 95">
<div class="layoutArea">
<div class="column">
<h3>
<span style="font-family: "helvetica"; font-size: 14.000000pt; font-weight: 700;">Replicas within Actions</span></h3>
<div>
<div class="page" title="Page 95">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13pt;">Of the two methods of combining replication</span><span style="font-family: "times"; font-size: 13.000000pt; font-weight: 700;"> </span><span style="font-family: "times"; font-size: 13.000000pt;">with atomic actions, this method is the
most intuitive: each non-replicated object is replaced by a replica group. Whenever an
action issues a request on the object this is translated into a request on the entire replica
group (how the requests are interpreted depends upon the replica consistency protocol).
Failures of replicas within a given replica group are handled by the replication protocol in </span><span style="font-family: "times"; font-size: 13pt;">an effort to mask them until a sufficient number of failures have occurred which makes
masking impossible, and in this case the replica group fails. When an action comes to
commit, the replication protocol dictates the minimum number of replicas which must be
functioning in any given replica group for that group to be considered operational and
allow the action to commit.</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 96">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">Problems which arise from this method have already been outlined in earlier entries. The replication protocol must be able to deal with multiple messages from
both replicated client groups as well as replicated server groups; the majority of
replication protocols assume that replicated objects within the same replica group are
deterministic; problems can occur in maintaining consistency between replicas when local
asynchronous events can occur such as RPC timeouts.</span><br />
<span style="font-family: "helvetica"; font-size: 14pt; font-weight: 700;"><br /></span>
<br />
<h3>
<span style="font-family: "helvetica"; font-size: 14pt; font-weight: 700;">Replicated Actions </span></h3>
<br />
<div class="page" title="Page 96">
<div class="layoutArea">
<div class="column">
<div>
<div class="page" title="Page 96">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The idea behind Replicated Actions [<a href="https://link.springer.com/article/10.1007/BF01786632">Ahamad 87</a>][<a href="http://ieeexplore.ieee.org/document/37979/">Ng 89</a>] is to take an atomic action
written for a non-replicated system and replicate the entire action to achieve availability.
In this scheme the unit of replication is the action along with non-replicated objects used
within it. In the Clouds distributed system [<a href="https://link.springer.com/article/10.1007/BF01786632">Ahamad 87</a>] the replicated actions are called
PETS (Parallel Execution Threads). By replicating the action N times (creating N PETS)
and hence by also replicating the objects which the action uses, the probability of at least
one action being able to commit successfully is increased. Although the actions and
objects are replicated, each action only ever communicates with one replica from a given
object-replica group and does not know about either the other replicas or the other
actions until it comes to commit. Subsequently, if this replica fails, so too does the action
(as is the case in a non-replicated system).</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13pt;">Because each action only uses one replica in a given group and each replica only
receives messages from this one action, the replicas need not be deterministic, and there is </span><span style="font-family: "times"; font-size: 13pt;">no need to devise some protocol for dealing with multiple requests (or replies) from a
client (server) group. When the replicated actions commit, it is necessary to ensure that
only one action does so (to maintain consistency between the replicated objects). To do
this, typically the first action to commit (the fastest) as part of its commit protocol copies
the states of the objects it has used to those replicas it did not use (i.e. the replicas used by
the other actions) and causes the other actions to abort. This is done atomically, so that if
this atomic action should fail then the next replicated action which commits will proceed as
though it had finished first.</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimVU-3IW37BoWJtjZbt0dh05Yy1YVPaHfspHhA9rqQHEO9nWEb9JLTOJoygJD-AT9rdKcT8RYG7dsd72_sAhKCOLt6i8XpKZ0crQmr6pJ80y2Ja_E7a33vfeHtEZQhR8g9nS_f_Q/s1600/Screen+Shot+2017-12-20+at+08.42.15.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimVU-3IW37BoWJtjZbt0dh05Yy1YVPaHfspHhA9rqQHEO9nWEb9JLTOJoygJD-AT9rdKcT8RYG7dsd72_sAhKCOLt6i8XpKZ0crQmr6pJ80y2Ja_E7a33vfeHtEZQhR8g9nS_f_Q/s400/Screen+Shot+2017-12-20+at+08.42.15.png" width="321" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="page" title="Page 97">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The figure above shows the state of the objects A, B, C, and D which are replicated three
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;">times, just as the replicated actions, which are also replicated three times, α, β, and ε,
begin commit processing. The execution paths of these actions is indicated by the lines.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt; vertical-align: 1.000000pt;">When actions α and β come to commit they will be unable to do so because the object D (which α used) and C (which β used) have failed, making commit impossible. However, action ε will be able to commit, and will then update the states of all remaining functioning
replicas. Failed replicas must be updated before they can be reused.</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<span style="font-family: "times"; font-size: 13pt;">Obviously the choice of which replicas the actions should use is important e.g. in</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;">In the figure, if action ε had used the same copy of object D as action then the failure of this
object would have caused the two actions to have failed instead of one. In some systems
[<a href="https://link.springer.com/article/10.1007/BF01786632">Ahamad 87</a>] the choice of which replica a particular action uses is made randomly
because they make the assumption that with a sufficient number of object replicas the
chances of two actions using the same copy are small. However, in [<a href="http://ieeexplore.ieee.org/document/37979/">Ng 89</a>] they propose a
different approach by using information about the nature of the distributed system
(reliability of nodes, probability of network partitions occurring) to come up with an
optimal route for each action to take when using replicated objects. This route attempts to
minimize the object overlap between replicated actions and minimize the number of
different nodes that an action visits during the course of its execution.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">The advantage of using replicated actions as opposed to using replicas within an action
are the same advantages obtained from using a passive replication protocol as opposed to
using an active replication protocol: there is no need to ensure that all copies of the same
object are deterministic since the action which commits will impose its view of the state of
the object on all other copies, and each replica will receive a reduced number of repeated
requests from replicated clients (reduced to only one message if each action makes use of a
different replica).
</span></div>
</div>
</div>
<span style="font-family: "times"; font-size: 13pt;">However, the scheme also suffers from the problems inherent with a passive
replication scheme: checkpointing of state across a network can be a time consuming,
expensive operation. If we assume failures to be rare (as would be the case) then this
scheme will cause large numbers of actions to abort. The action which commits first will
overwrite the states of the other replicas, effectively removing the knowledge that the
other actions ever ran. In some applications it may prove more of an overhead to </span><span style="font-family: "times"; font-size: 13pt;">checkpoint the state of one action in this way rather than allowing all functioning actions
simply to commit.</span></div>
</div>
</div>
<br /></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-9816201882204508202017-12-18T07:52:00.000+00:002017-12-18T07:53:59.042+00:00An overview of some existing distributed systems (of the time)<br />
<div class="page" title="Page 89">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">Existing distributed systems which make use of multicast communication can be
categorised as using either one—to—many communication (one client interacting with a
replica group) or many—to—many communication (replica groups interacting with replica
groups). We shall now look at a number of the popular protocols and show how they have </span><span style="font-family: "times"; font-size: 13pt;">approached the problems of maintaining replica consistency to both </span><span style="font-family: "times"; font-size: 12pt; font-style: italic;">external </span><span style="font-family: "times"; font-size: 13pt;">and </span><span style="font-family: "times"; font-size: 12pt; font-style: italic;">internal
</span><span style="font-family: "times"; font-size: 13pt;">events.</span><span style="font-family: "helvetica"; font-size: 14pt;"><br /></span><br />
<span style="font-family: "times"; font-size: 13pt;"></span><br />
<h2>
<span style="font-family: "times"; font-size: 15pt;">One-to-Many Communication </span></h2>
<h3>
<span style="font-family: "times"; font-size: 13pt;">The V System</span></h3>
<div>
<div class="page" title="Page 90">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The V System [<a href="https://dl.acm.org/citation.cfm?id=802061">Cheriton 84</a>][<a href="https://dl.acm.org/citation.cfm?id=214439">Cheriton 85</a>] </span><span style="font-family: "times"; font-size: 13.000000pt;">makes use of what they term one-to-many
</span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">communication transactions, </span><span style="font-family: "times"; font-size: 13.000000pt;">where the start of a transaction marks the end of the previous
transaction (any outstanding messages associated with the old transaction are destroyed
without being processed). Each group member has a finite message buffer into which
replies are queued provided they arrive before the start of the next send transaction. </span><span style="font-family: "times"; font-size: 13pt;">Although a reliable communication protocol is not used, the assumption is made that by
making use of retransmissions is it possible to ensure (with a high probability) that
messages are delivered if the sender and receiver remain operational. A further
assumption is that at least one operational group member receives and replies to a
message.</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">The designers of the V System recognized the possibility of message loss due to
message buffer overflow, and their solution was to make use of larger buffers and to
modify the kernel to introduce a random delay when replying to a group send, thereby
reducing the number of messages in a queue at any time. This imposes a consistent
overhead on all group replies but still does not ensure that buffer overflow will never occur
(if the number of different groups interacting with each other increases then even with this </span><span style="font-family: "times"; font-size: 13pt;">delay it is still probable that the finite sized message queues will overflow).</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">When servers reply to a client they do so on a many-to--one basis i.e., all servers which
received a request from a particular client will attempt to reply to that client (and not to
any replica group the client may be a member of). This means that there is the possibility of
members of the same group taking different actions as a result of local events such as
timeouts (resul</span><span style="font-family: "times"; font-size: 13pt;">ting in state divergence), because the servers replied to some, but not all, </span><span style="font-family: "times"; font-size: 13pt;">clients on time.</span><br />
<br />
<div class="page" title="Page 91">
<div class="layoutArea">
<div class="column">
<h3>
<span style="font-family: "helvetica"; font-size: 12.000000pt; font-weight: 700;">The Andrew System </span></h3>
</div>
</div>
</div>
<div class="page" title="Page 90">
<div class="layoutArea">
<div class="column">
<div class="page" title="Page 91">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">The Andrew System [<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=48864">Satyanarayanan 90</a>]</span><span style="font-family: "times"; font-size: 13pt;"> assumes that the communication system is
reliable in much the same manner as the V System i.e., given a sufficient number of retries
then any operational server can always be contacted. Communication is one-to-many and
the termination conditions for a particular client-server interaction is set on a per call
basis (depending on the application). The designers recognized that calls between remote
processes can take an indeterminate amount of time and so if a client times out it sends an
"are you alive" message to any server replica which has not responded and if a reply is
returned then it continues to wait. However, because servers reply on a many-to-one
basis, state divergence between replicated clients can still occur: if only one client receives </span><span style="font-family: "times"; font-size: 13pt;">a reply sent before all servers fail, then the replicated clients may take different actions.</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
</div>
</div>
</div>
<span style="font-family: "times"; font-size: 13pt;">It was recognized that messages might be lost by processes because of message buffer
overflow, but in Andrew it is assumed that such loses will be detected by retries. This
implicitly relies on the servers keeping the last transmitted replies to every client, but
could still result in state divergence if, for example, a server group is seen to have failed by
one replicated client when it retries a request, when in fact all other members of the client
group received the reply before the failure.</span><span style="font-family: "times"; font-size: 13.000000pt;"> </span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<div class="page" title="Page 91">
<div class="layoutArea">
<div class="column">
<h2>
<span style="font-family: "times"; font-size: 15.000000pt; font-weight: 700;">Many-to-Many Communication </span></h2>
</div>
</div>
</div>
</div>
</div>
</div>
<h3>
<span style="font-family: "helvetica"; font-size: 12pt; font-weight: 700;">The Circus System</span></h3>
<span style="font-family: "times"; font-size: 13pt;">The Circus System [<a href="https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/CSD-84-196.pdf">Cooper 84b</a>] (and Multi-Functions [Banatre 86b] in Gothic
[Banatre 86a]) makes use of many-to-many communication, with both client and server
groups. As with the V System they assume that with a sufficient number of transmission
retries it is possible to deliver messages to all operational members of a group. Thus, if a
call eventually times out (after retrying a <i>sufficient</i> number of times) a sender can assume
that the receiver(s) has failed. Each member of a group has a message queue which is
assumed to be infinite in size (if this assumption cannot be made then the designers of </span><span style="font-family: "times"; font-size: 13pt;">Circus assume that retransmissions of requests and replies can account for losses due to
buffer overflow).</span><br />
<span style="font-family: "times"; font-size: 13pt;"><br /></span>
<br />
<div class="page" title="Page 92">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">Throughout the description of Circus the assumption is made that the members of a
group are detenninistic (given the same set of messages in the same order and the same
starting state then they will all arrive at the same next state). Client groups' members
operate as though they were not replicated and do not know that they are members of a
replica group. No mention is made of how this determinism of group members extends to
asynchronous local events such as timeouts.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
</div>
</div>
</div>
<span style="font-family: "times"; font-size: 13pt;">Despite the assumptions made by the designers, both the problem of message buffer
overflow, and local timeouts, can occur in the Circus system, leading to replica state
divergence.</span><span style="font-family: "times"; font-size: 13pt;"> </span><span style="font-family: "times"; font-size: 13.000000pt;"> </span></div>
</div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-18614262757199554272017-12-18T07:30:00.004+00:002017-12-18T07:30:57.273+00:00rel/RELFollowing on from the last entry I did the initial <a href="http://iopscience.iop.org/article/10.1088/0967-1846/1/6/001/meta">implementation of red/REL</a> as part of my PhD and that document includes an overview of the protocol as well as some performance figures and proposed optimisations to the protocol. For now I won't cover that here as there's a good paper in the previous reference to read, or the PhD of course. However, maybe I'll come back to this later.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-72015656076097586712017-12-17T09:29:00.001+00:002017-12-17T09:29:46.696+00:00Multicasts and Replication<br />
<div class="page" title="Page 66">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;">In the previous entries we have discussed what delivery properties can be provided by
the communication subsystem, and how they can be implemented. We shall now discuss
how such communications primitives can be used in a replication scheme to aid in
maintaining replica consistency.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">Group invocations can be implemented as replicated RPCs by replacing the
one-to-one communication of </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">send_request </span><span style="font-family: "times"; font-size: 13.000000pt;">and </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">send_result </span><span style="font-family: "times"; font-size: 13.000000pt;">in the figure below (which we saw in an earlier entry too) with
one-to-many communication. </span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp0m6pVhNO_52X9BgX7yF0mQvmbXkO3W4JookT3zOCKkCLRR6qERPC2vCU08J6jDDVWv9bOmG3krvAlf1WkrpxAnHHEtHuGxeToa9HvrjNFva4ExZl0M7RzVHX3kO_GSAnzEz5MA/s1600/Screen+Shot+2017-12-17+at+09.26.22.png" imageanchor="1"><img border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp0m6pVhNO_52X9BgX7yF0mQvmbXkO3W4JookT3zOCKkCLRR6qERPC2vCU08J6jDDVWv9bOmG3krvAlf1WkrpxAnHHEtHuGxeToa9HvrjNFva4ExZl0M7RzVHX3kO_GSAnzEz5MA/s640/Screen+Shot+2017-12-17+at+09.26.22.png" width="640" /></a></span><br />
<br />
<span style="font-family: "times"; font-size: 13.000000pt;">Every non-faulty member of a client group sends the
request message to every non-faulty member of the server group, which in turn send a
reply back. If multiple client groups invoke methods on the same replicated server group
then it must be ensured that concurrent invocations are executed in an identical order at
all of the correctly functioning replicas, otherwise the states of the replicas may diverge. In
order to ensure this property, the objects must not only be deterministic in nature, but all
correctly functioning replicas must receive the same sets of messages in the same order
i.e., a totally ordered multicast must be employed.
</span><br />
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">The State Machine conditions Cl and C2 can both be met by making use of totally
ordered multicasts to deliver all messages transmitted by clients and servers. However,
such total ordering of messages may be unnecessary for all interactions: if two,
non-conflicting, non-related messages are received at members of the same replica group
(e.g., two unrelated electronic mail messages from different users) then they need not be
ordered consistently at these destinations. If they were related in some manner (e.g., from
the same user) then they could be ordered consistently. Application level ordering can be
achieved more efficiently as cheaper, reliable broadcast protocols can be used to deliver
messages for which ordering is unimportant, resorting to the more complex order
preserving protocols only where necessary. Since such protocols typically need more </span><span style="font-family: "times"; font-size: 13pt;">rounds of messages to be transmitted, the reduction in their use can be beneficial to the
system as a whole, whilst maintaining overall replica consistency.</span><br />
<div class="page" title="Page 67">
<div class="layoutArea">
<div class="column">
<span style="font-family: "times"; font-size: 13.000000pt;"><br /></span>
<span style="font-family: "times"; font-size: 13.000000pt;">One method of achieving such application level ordering would be to transmit
messages using </span><span style="font-family: "times"; font-size: 12.000000pt; font-style: italic;">unordered atomic multicasts </span><span style="font-family: "times"; font-size: 13.000000pt;">(since it is still important that the messages are
received by all functioning replicas) which only guarantee delivery to all functioning
replicas but make no guarantee of the order (described in a previous entry), and then to
impose ordering on top of this i.e., at a level above the communication layer. If atomic
actions are used in the system then we can make use of their properties to impose the
ordering on message execution that we require i.e., the order shall be equivalent to the
serialization order imposed by atomic actions. This has the advantage that operations
from different clients which do not conflict (e.g., multiple read operations) can be
executed in a different order at each replica. Atomic actions will ensure that multiple
accesses from different clients to the same resource will be allowed only if such interaction
is serialisable.</span></div>
</div>
</div>
</div>
</div>
</div>
Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-44759883081060680702017-12-17T09:20:00.002+00:002017-12-17T09:20:54.341+00:00Failed on historical bloggingWhere has the time gone?! Around a year ago I said I would <a href="http://markclittle.blogspot.co.uk/2016/12/some-historical-blogging.html">blog a bit from my PhD</a> and though I did do a few entries I haven't been able to do anything since January! Looking back it's a combination of work, family commitments and writing a book with some of my friends, but I didn't realise they'd soaked up so much of my time. Oh well, there are a few days left in 2017 so let me see what I can do to try to catch up a bit.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0