tag:blogger.com,1999:blog-136390212024-03-05T04:05:47.481-08:00The Wisdom of Ganeshprasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.comBlogger217125tag:blogger.com,1999:blog-13639021.post-53731894831677616952023-10-17T07:10:00.006-07:002023-10-25T05:47:16.817-07:00Targeting A Better Life Above The Service Tier<p style="text-align: justify;">
In 2007, <a href="https://www.linkedin.com/in/rajat-taneja-a02a05/" target="_blank" rel="nofollow">Rajat Taneja</a>, <a href="https://www.linkedin.com/in/vikrant-todankar/" target="_blank" rel="nofollow">Vikrant Todankar</a> and <a href="https://www.linkedin.com/in/ganeshcprasad/" target="_blank" rel="nofollow">I</a> co-wrote a white paper called <a href="https://bit.ly/3ZXk2im" target="_blank" rel="nofollow">Life above the Service Tier</a>. This was back when web applications were built using server-side frameworks. Our paper decried these frameworks as representing anti-patterns, and recommended that web applications ought to run independently within client devices (such as mobile phones and desktops), and only make service calls to the back-end.
</p>
<p style="text-align: justify;">
We called this architecture SOFEA, for Service-Oriented Front-End Architecture.
</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCoAzmz_KTmf_1axCCdO7HmbtEmpJtVQf6nhlIj_lpDEgA-He-OPVC5f2Z_aEuErH_vFhSLu1IFOyQgOWsTmF3FW532QJOnVXGyWNONobZU8e9K25q1uT1dgJr4VyQy_e0W6EFhoYLIvOXfn-Fr5F27kPf1jk5-435tdv5wHQwz543IOe53UgnEA/s963/life-above-the-service-tier-cover-large.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" height="600" data-original-height="963" data-original-width="708" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCoAzmz_KTmf_1axCCdO7HmbtEmpJtVQf6nhlIj_lpDEgA-He-OPVC5f2Z_aEuErH_vFhSLu1IFOyQgOWsTmF3FW532QJOnVXGyWNONobZU8e9K25q1uT1dgJr4VyQy_e0W6EFhoYLIvOXfn-Fr5F27kPf1jk5-435tdv5wHQwz543IOe53UgnEA/s600/life-above-the-service-tier-cover-large.png"/></a></div>
<p style="text-align: justify;">
The core principle of SOFEA was to decouple the three orthogonal concerns of Application Download, Presentation Flow, and Data Interchange, which were tightly coupled in server-based frameworks.
</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcv48ne2obz_udlbiUSb0ciZh_QfrMVF2Aq7ud4G-UO5IwMJwRyxC9qlisSvUnGBD22ZlXPe6A_b4JP2x3Cz81nfg7ejKM1QL5J7x9FKa_k75kXuwSPrMKw88YTQkr0cOeMupX7YWb9Pvlw18Ka_a2bITy0GxVa65nKeghUuSvnCPFVf1b9lQVOA/s1028/sofea-diagram.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="600" data-original-height="700" data-original-width="1028" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcv48ne2obz_udlbiUSb0ciZh_QfrMVF2Aq7ud4G-UO5IwMJwRyxC9qlisSvUnGBD22ZlXPe6A_b4JP2x3Cz81nfg7ejKM1QL5J7x9FKa_k75kXuwSPrMKw88YTQkr0cOeMupX7YWb9Pvlw18Ka_a2bITy0GxVa65nKeghUuSvnCPFVf1b9lQVOA/s600/sofea-diagram.png"/></a></div>
<p style="text-align: justify;">
This recommendation seemed revolutionary at the time, as witnessed by <a href="https://www.google.com/search?q=sofea+web+framework&oq=sofea+web+framework" target="_blank" rel="nofollow">the many blog posts and comments that it received</a>. However, when we fast-forward 16 years to today, SOFEA is in fact the way the vast majority of web applications are being built. All the popular web frameworks, such as <a href="https://angular.io/" target="_blank" rel="nofollow">Angular</a>, <a href="https://react.dev/" target="_blank" rel="nofollow">React</a>, <a href="https://vuejs.org/" target="_blank" rel="nofollow">Vue</a>, and <a href="https://svelte.dev/" target="_blank" rel="nofollow">Svelte</a>, are SOFEA-based.
</p>
<p style="text-align: justify;">
Everyone should have lived happily thereafter, but the main problem being faced by development shops today is that these web frameworks are too complex and heavyweight. It takes months or years to acquire true expertise in any of them. Full Stack developers are hard to come by, because both the back-end and the front-end require in-depth skills. This has made it costly and time-consuming not only to build applications, but also to maintain them over their lifetime.
</p>
<p style="text-align: justify;">
Rajat, Vikrant and I discussed this once again, and we were joined by another friend, <a href="https://www.linkedin.com/in/subbu-balakrishnan-7a44825/" target="_blank" rel="nofollow">Subbu Balakrishnan</a>.
</p>
<p style="text-align: justify;">
The time seemed ripe to release an update to the SOFEA paper, this time recommending a simpler architecture for the front-end. We have been tracking developments in the industry over the past 16 years, and have detected some paradigm shifts taking place, which the most popular web frameworks have not taken advantage of. Other frameworks have leapfrogged them, but aren't as well-known, or as comprehensive.
</p>
<p style="text-align: justify;">
Here's our high-level view of industry trends.
</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGroDL5Wlexu-DHHqOb0NHs4yp6mNA1XW9vB6dtzeX_BiGHB_fFQo5UO4tbTGw0N0JsnP7MRzLVu3My4kEZkCR3ZXKznWx5JdryCfZuwlnTZOGJmlp-S_8-ae5qF4I_2lDzCjFiiIwTfXV4TEUhDm9u54IVjmRWF-vu76pf17g_l6yZ7mzzPU6og/s1736/diagram-brief-history.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="600" data-original-height="852" data-original-width="1736" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGroDL5Wlexu-DHHqOb0NHs4yp6mNA1XW9vB6dtzeX_BiGHB_fFQo5UO4tbTGw0N0JsnP7MRzLVu3My4kEZkCR3ZXKznWx5JdryCfZuwlnTZOGJmlp-S_8-ae5qF4I_2lDzCjFiiIwTfXV4TEUhDm9u54IVjmRWF-vu76pf17g_l6yZ7mzzPU6og/s600/diagram-brief-history.png"/></a></div>
<p style="text-align: justify;">
What we have come up with is a new architectural style, a successor to SOFEA that we call BUCAREST (for Browser-based Unified Client Architecture (using) REST). <b><i>This is not just a theoretical concept, but practically implementable using frameworks that are available today.</i></b> While no single framework today can implement BUCAREST in its entirety, a combination of frameworks used in alignment with the patterns we describe will do the job just fine.
</p>
<p style="text-align: justify;">
The two frameworks we have identified are <a href="https://alpinejs.dev/" target="_blank" rel="nofollow">Alpine.js</a> and <a href="https://htmx.org/" target="_blank" rel="nofollow">HTMX</a>.
</p>
<p style="text-align: justify;">
The diagram describing this architecture is here:
</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqWYejnd1r6KE9Z8Men0hXSoF1mBjVAs3pVOicacpQRpOTsNCz9GwR6e1zgVq7nHOHO-e8BmpFATSG8lcYo-MAPpNCzk1GEFixCtKTBjM8vWlAikXtaMvyIpvjPeiVKlRfhbAHOAarDhQ762eyHRPYQKpBqufeBtTARvTqwDANmTttOlh0JmEROQ/s1499/diagram-bucarest-0-overview.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="600" data-original-height="939" data-original-width="1499" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqWYejnd1r6KE9Z8Men0hXSoF1mBjVAs3pVOicacpQRpOTsNCz9GwR6e1zgVq7nHOHO-e8BmpFATSG8lcYo-MAPpNCzk1GEFixCtKTBjM8vWlAikXtaMvyIpvjPeiVKlRfhbAHOAarDhQ762eyHRPYQKpBqufeBtTARvTqwDANmTttOlh0JmEROQ/s600/diagram-bucarest-0-overview.png"/></a></div>
<p style="text-align: justify;">
This new white paper, which describes BUCAREST in detail and explains how to use it to build web applications in a much simpler way, is called <a href="https://bit.ly/3tDztA7" target="_blank" rel="nofollow">Targeting a Better Life above the Service Tier</a>.
</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOFnQa7Tlyfdtf_Iyq9sxyb7UFmHIUZShEiiKpGxYCblVnFz-fmrGKNOeVKkoXpFqtoUvCb-Dn67Xq9w5Ep6NCeNIaosaUcQkjsb7VNIMrae8GJjosba2q3LEPiqzsHAhzY4tZlrJr6rwDbovje_cCpMZL5vIUmZ9GgvxvuOv8BmnLK3-_-aIKfg/s762/targeting-a-better-life-above-the-service-tier-cover.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" height="600" data-original-height="762" data-original-width="559" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOFnQa7Tlyfdtf_Iyq9sxyb7UFmHIUZShEiiKpGxYCblVnFz-fmrGKNOeVKkoXpFqtoUvCb-Dn67Xq9w5Ep6NCeNIaosaUcQkjsb7VNIMrae8GJjosba2q3LEPiqzsHAhzY4tZlrJr6rwDbovje_cCpMZL5vIUmZ9GgvxvuOv8BmnLK3-_-aIKfg/s600/targeting-a-better-life-above-the-service-tier-cover.png"/></a></div>
<p style="text-align: justify;">
We hope the BUCAREST style will greatly simplify web development in the coming years. Thanks to its simplicity, it should also be possible for those who have considered themselves back-end developers to venture into front-end developent too. We daresay there will be more "Full Stack" developers in the years to come.
</p>
<p style="text-align: justify;">
<a href="https://bit.ly/3tDztA7" target="_blank" rel="nofollow">Download our white paper</a>, have a read and tell us what you think!
</p>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-32919439943974017172019-10-20T07:00:00.003-07:002019-10-20T07:24:37.730-07:00How To Understand Systems - My Secret Superpower<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
In Poul Anderson's SF story "The Problem of Pain", there is the following quote:</div>
<div style="text-align: justify;">
<br /></div>
<blockquote class="tr_bq" style="text-align: justify;">
The primitive faiths see God or the gods, as power; the higher ones see Him as justice; the highest see Him as love.</blockquote>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There is also the quote attributed to Eleanor Roosevelt:</div>
<div style="text-align: justify;">
<br /></div>
<blockquote class="tr_bq" style="text-align: justify;">
Great minds discuss ideas; average minds discuss events; small minds discuss people.</blockquote>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The common thread through both of these quotes is that there is a lower and a higher way to think, with some intermediate level too.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Over my 32-year IT career, I have come across three ways by which people tend to understand systems, and I would express my findings in an analogous manner:</div>
<div style="text-align: justify;">
<br /></div>
<blockquote class="tr_bq" style="text-align: justify;">
The shallowest understanding of systems comes from a study of user interfaces; an intermediate level of understanding comes from a study of processes; the deepest level of understanding comes from a study of data.</blockquote>
<div style="text-align: justify;">
Let me elaborate.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There are many people who work in the IT industry, and not all of them have undergone rigorous study or qualification in IT disciplines. Many have just drifted into it from other functions, and they often believe they can make a contribution based on their understanding of the field and of the software systems they are familiar with. Yet a lot of them exaggerate their competence, because one cannot understand IT systems by a superficial understanding of how they seem to work. There is a lot more to it than this.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The most common misunderstanding is seen in clerical-level operations staff who have only experienced IT systems as users. All they know of a system is its user interface. They see the system as a series of screens, with fields and buttons on each. If asked to describe the system, they will proceed to describe what a user will do on each screen - "Fill up this field, check this box, select a value from this dropdown, then click 'Next'. On the next screen, select this value, select from one of the radio buttons, then click 'Submit'."</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Clearly, this level of understanding is superficial, and often misleading, when it comes to determining how to improve or extend a system to do something more.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Senior operations professionals and business people tend to understand systems a lot better than the clerical-level staff who have only experienced a system through its screens. They know what processes and process steps are being represented by those screens. This insight could result in suggestions for improvement of the system in various ways, since processes could be optimised over time. But processes too are limited in the insight they can provide into a system's design.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Many developers too are stuck at the level of understanding systems through process logic alone.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The ultimate level of insight into a system's design comes from an understanding of its data model. What entities are represented in the system? How are they related to each other? What constraints govern those relationships? In formal practice, this is known as Entity-Relationship Modelling.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The actual data stored in these data structures forms a secondary source of important information. The relative volumes of data in different data structures provide valuable information of their own, and usage patterns provide another dimension.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I identify most as a data analyst. When people describe systems to me, I mentally draw Entity-Relationship Diagrams. This has now become second nature to me. Unless I understand the entities in a system and their relationships, I'm not comfortable that I understand anything at all. As processes are explained to me, my understanding of them is formed in terms of the data entities being populated, updated, relationships established, etc. In other words, <i>I see processes in terms of their effects on data</i>. And when I see screens, I can see them as manifestations of process steps, just as business people can.<br />
<br /></div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOJx73GhQ4KcXf2zcj1tdamHsTUGK395cipyrPXzYDQGRALiYcGJXzhPVnymffjE60sSRRhN9fUg32F5c8yDBAq_dzjihZtY8ZDcraZ5f5Q778I4NyVp3uoNXfmgL49kHYLqmIfg/s1600/superpower-3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="638" data-original-width="1600" height="158" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOJx73GhQ4KcXf2zcj1tdamHsTUGK395cipyrPXzYDQGRALiYcGJXzhPVnymffjE60sSRRhN9fUg32F5c8yDBAq_dzjihZtY8ZDcraZ5f5Q778I4NyVp3uoNXfmgL49kHYLqmIfg/s400/superpower-3.jpg" width="400" /></a></div>
</div>
<div style="text-align: center;">
<i>Three ways of understanding systems, from the lowest (most superficial and least effective) to the highest (most insightful and effective) - Click to expand</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i><b>My focus on data is my secret superpower.</b></i> It has helped me whenever I have been called in to consult on a problem. I have been able to diagnose problems within hours, sometimes within the first hour, where others have been stumped for days. I have been able to propose innovative and elegant approaches to enhance the capability of systems, without the elaborate and expensive projects proposed by others. When you can see data first and foremost, a process as something that changes data, and a screen as simply representing a step in a process, you can understand a system in its entirety. Your depth of vision is then so great, and your insights so profound, as to amaze coworkers who have not been similarly trained.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Yet it is not magic. It is very simple science. The focus on data - data modelling, data design - is fundamentally important to an IT professional. Alas, it is not more widely taught in the IT industry.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-13531475863051627062018-03-18T23:20:00.000-07:002018-03-18T23:20:10.810-07:00The Difference Between Knowledge And Wisdom<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I realised today that I have become wise. I'm writing this out of a sense of amusement rather than vanity.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I had a discussion with a client about some changes she wanted made on an application. I realised even as she was speaking what changes I would need to make to the underlying database in order to display the results she wanted on the screen. After that conversation, I sat down to write out the SQL script that would make the required changes to the database.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
But I didn't run it.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
And at that moment, I realised the difference between knowledge and wisdom.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Knowledge refers to the capacity to understand how to implement something.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Wisdom is the meta-knowledge, born of years of experience, that it's rarely that straightforward.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It's the experience of receiving another email or phone call from the client within a few hours saying, "Hey Ganesh, I just discussed this with the team, and we realised that we need the system to do something more. So when you implement your change, can you please ensure that it also does X?"<br /><br />It's the experience of looking at a script I wrote earlier and thinking, "Hey, why am I doing it like this? I can do it much more simply in this other way!"</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
And then I have to change the script I initially wrote, and undo all the changes I had made earlier.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's really what's changed in me. I knew SQL even 25 years ago, and I could possibly have come up with the same script even back then.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's knowledge, and I haven't significantly added to that knowledge in so many years.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The difference is that 25 years ago, I would have implemented that change immediately.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Today, I have a voice inside me that says, "Just wait. Save this script in a file and look at it again tomorrow."</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's wisdom.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-37981916402911441442018-01-04T07:56:00.004-08:002018-03-24T03:36:17.494-07:00Why The Aadhar Data Breach Is A Very Big Deal<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
A sting operation by the newspaper <a href="http://www.tribuneindia.com/news/nation/rs-500-10-minutes-and-you-have-access-to-billion-aadhaar-details/523361.html">The Tribune has reported</a> that with a very nominal payment of 500 rupees, their team was able to get access to an Aadhar portal that was intended for use only by authorised officials responsible for helping citizens retrieve lost or forgotten data.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGnHsoGa7wzjsCO6EtOLtsO3pQdL8DFaJ8i2gvIL1hfSuCfWSps_a6QJloOdR2hcy0wK5m-vAl3oXueoKNgVBTdQG2cO3PaXY3brd8U4Jr6kKeKyYK9_6UCahionuBwsep9L_7gA/s1600/aadhaar-logo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="772" data-original-width="1200" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGnHsoGa7wzjsCO6EtOLtsO3pQdL8DFaJ8i2gvIL1hfSuCfWSps_a6QJloOdR2hcy0wK5m-vAl3oXueoKNgVBTdQG2cO3PaXY3brd8U4Jr6kKeKyYK9_6UCahionuBwsep9L_7gA/s400/aadhaar-logo.png" width="400" /></a></div>
<div style="text-align: center;">
<i>Aadhar is a relatively new unique identifier for all residents of India</i></div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
When the news broke, the organisation in charge of India's unique ID database, the Unique Identification Authority of India (UIDAI), <a href="https://economictimes.indiatimes.com/news/politics-and-nation/major-security-breach-your-aadhaar-data-is-on-sale-for-just-rs-500/articleshow/62364915.cms">played down suggestions</a> that a data breach had taken place. Their main contention was that the biometric data (fingerprints and iris scans) of residents was stored in a secure and encrypted manner, and that it was not exposed through the mechanism used by the Tribune.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let us analyse what happened, and why it is in fact a big deal.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There are four primary security threats that organisations have to guard against:</div>
<div style="text-align: justify;">
<br /></div>
<ul>
<li>Disclosure (unauthorised persons gaining access to sensitive information)</li>
<li>Deception (the system being presented with false data and made to accept it)</li>
<li>Disruption (interruption in normal operations and loss of service)</li>
<li>Usurpation (unauthorised persons gaining control of the system)</li>
</ul>
<br />
<div style="text-align: justify;">
What the UIDAI is saying is that there has been no Disclosure of authentication tokens (biometric data) that could lead to a future Deception or Usurpation attack. But importantly, they have not denied that a breach has occurred which could have given an unauthorised user access to <i>certain kinds of information</i>. In fact, some of their officials have confirmed this:<br />
<br />
<blockquote class="tr_bq">
Sanjay Jindal, Additional Director-General, UIDAI Regional Centre, Chandigarh, accepting that this was a lapse, told The Tribune: "Except the Director-General and I, no third person in Punjab should have a login access to our official portal. Anyone else having access is illegal, and is a major national security breach."</blockquote>
<br />
<br />
In other words, an attack could have successfully taken place resulting in the Disclosure of certain kinds of information.</div>
<div style="text-align: justify;">
<br />
What kind of information? According to the Tribune article, they were able to retrieve the following data on provision of an Aadhar number:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<ul>
<li>Name</li>
<li>Address</li>
<li>Post code (PIN)</li>
<li>Photo</li>
<li>Phone number</li>
<li>Email address</li>
</ul>
<br />
<div style="text-align: justify;">
In fact, this is probably the <i>minimal</i> set of data that is accessible through the portal.<br />
<br />
<blockquote class="tr_bq">
It took just Rs 500, paid through Paytm, and 10 minutes in which an “agent” of the group running the racket created a "gateway" for this correspondent and gave a login ID and password. Lo and behold, you could enter any Aadhaar number in the portal, and instantly get <b><i>all particulars that an individual may have submitted to the UIDAI</i></b> (Unique Identification Authority of India), <b><i>including</i></b> name, address, postal code (PIN), photo, phone number and email.</blockquote>
<br />
<br />
Reading between the lines, it doesn't appear that an API (a non-visual means by which a software program could retrieve data) was provided. It looks like login credentials were provided into an administrator's portal, in other words, access to a secure web page.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
What is the worst that could happen if such access were granted to a non-authorised user? How much data could they steal? In other words, how severe is the Disclosure exposure?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
To a layperson, this may not seem like a huge exposure. How many people's data can a person steal by sitting at a portal and entering Aadhar numbers on a screen? A few hundred, perhaps a couple of thousand records. Unfortunately, a potential data thief is much more efficient.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I'm not a security expert, but even I would potentially be able to steal the entire Aadhar database (i.e., not biometric data but the set of data listed above) in a matter of hours or days, without much personal effort on my part. Hackers may have much more efficient means at their disposal, but I would probably use a web application testing tool like Selenium, which I use for user testing of software as part of my day job. Selenium is built on top of a basic browser "engine", and has a number of programmable features built around it. It can be "trained" by a user to follow a certain sequence of steps, and it can then repeat that sequence of steps <i>ad nauseam</i>, using different data values based on its controlling script. Best of all, Selenium looks just like a regular browser to any web server, so the server would have no idea that an automated tool is logging in and moving around the site, and not a human user.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiLTfVeEnkKcXSEGfw4RokMMeQprVlELc5i_kNFPrMjkWxj54azau-uQCSx-nZVkkno-ETDFIBzsXq4-xDdFpZWmJsW0uw1PzMUnJw0Z5qEKn5JPKlQM2Pl2prTsORFejhS-FLFg/s1600/selenium-testing.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="315" data-original-width="500" height="251" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiLTfVeEnkKcXSEGfw4RokMMeQprVlELc5i_kNFPrMjkWxj54azau-uQCSx-nZVkkno-ETDFIBzsXq4-xDdFpZWmJsW0uw1PzMUnJw0Z5qEKn5JPKlQM2Pl2prTsORFejhS-FLFg/s400/selenium-testing.jpg" width="400" /></a></div>
<div style="text-align: center;">
<i>An <a href="http://www.developerfusion.com/article/84484/light-up-your-development-with-selenium-tests/">article from DeveloperFusion</a> explains how Selenium works</i></div>
<br />
Assuming I have been granted login credentials into the Aadhar administrator's portal (on payment of the going rate of 500 rupees), I would first put Selenium into "learning mode", where it would record my actions to be replayed later. I would use it just as I would use a regular browser, except that this browser is recording my every action, including the data values I am entering. Based on its observation of my actions, it would then know which URL to navigate to, what username and password to enter on the login form, which menu item to select to get to the search screen, etc. Then it would learn about the repeatable part of the task, which is the entry of an Aadhar number in a certain field, and a click on a Search or Retrieve button. When the system responded with the data of the resident (name, address, etc.), I would stop the learning mode. (In practice, I would train Selenium to deal with invalid Aadhar numbers also, since it should be able to recognise when a query was unsuccessful.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I would then look into the script that Selenium generated to describe the sequence of actions that it had learnt. I would modify this script to make Selenium repeat its search in a loop.<br />
<br />
Aadhar numbers are 12-digit numeric strings, which means they can theoretically be any number in the range "000000000000" to "999999999999", a trillion (10<sup>12</sup>) numbers in all. I would modify the script to loop through all trillion numbers, perhaps in lots of a million at a time, and I would get it to extract the data from within specific HTML tags on the result screen. If these tags had helpful "id" attributes, it would make my job much easier, otherwise I would have to rely on the relative position of each field's tag within the returned page (known as a <a href="https://www.w3schools.com/js/js_htmldom_elements.asp">DOM search</a>). This is how I would get Selenium to "read" the returned name, address, postcode, phone number, email address, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The last thing I would do within the loop is to record the Aadhar number and all the retrieved fields into a local database on my machine, provided the query returned a value. I expect that only about a billion of the trillion numbers I use in my loop will return valid data, since there are just about a billion Indian residents.<br />
<br />
And this is how I would collect the basic personal and contact details of every single resident of India. Unless UIDAI has a throttling or choking mechanism to prevent such a rapid-fire query of data, it's possible that I will be able to get away with this over a couple of days at most.<br />
<br />
More sophisticated hackers would hide behind multiple IP addresses, and use multiple sets of user credentials, over a longer time period, so as to fool any auditing system on the UIDAI side from realising that a bulk theft of records was underway.<br />
<br />
Since the Aadhar numbers are permanent identifiers for residents, the data in this database is likely to remain useful for decades to whoever steals it. It can form the foundation of a database to which other data can be added.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
And that brings us to the even bigger threat that this breach enables.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The Indian government has also committed another cardinal sin from a privacy angle. It has mandated the <i>linking</i> of Aadhar numbers to a number of other important data, for example, bank account numbers and mobile SIM cards. In fact, although the courts have ruled that such linking is to be voluntary, the government, banks and telcos are not endorsing that liberal message at all. Residents are being virtually threatened into providing their Aadhar numbers to their telecom providers and their banks. Aadhar is also being used across various arms and services of the government, such as <a href="https://www.incometaxindiaefiling.gov.in/e-Filing/Services/LinkAadhaarHome.html">the Tax department</a> and the <a href="http://www.linkaadharcard.com/link-aadhaar-card-with-ration-card/">Public Distribution System</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now, the databases of such organisations are generally a lot less secure than the biometric data stored by UIDAI. It is unlikely that banks and telcos are being diligent enough to encrypt their data. Besides, with just a few large banks and telcos operating in the country, it is relatively easy for a malicious organisation, such as the secret service agency of a foreign power, to perform the necessary "social engineering" required to access this data. No conventional "hacking" is even necessary for such simple data theft. The same goes for government departments holding Aadhar-linked data.<br />
<br />
Now, if one had a list of bank account numbers with Aadhar numbers against them, it would be a trivial matter to map these to the Aadhar database stolen from UIDAI. One would then have the personal and contact details of every resident of India, -- plus their bank account numbers!<br />
<br />
Repeat this for mobile SIM cards, ration cards, PAN cards (tax), etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now one has put together a very lucrative set of data that a number of hostile powers would be very interested in. The cost of acquiring this data, as I have shown, is well within their budgets.<br />
<br />
The Tribune's report also claims<br />
<br />
<blockquote class="tr_bq">
Spotting an opportunity to make a quick buck, more than one lakh VLEs (Village-Level Enterprises) are now suspected to have gained this illegal access to UIDAI data to provide “Aadhaar services” to common people for a charge, including the printing of Aadhaar cards. However, in wrong hands, this access could provide an opportunity for gross misuse of the data.</blockquote>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Indeed, if the vulnerability has been around for the last few months, as suspected, it would not be unreasonable to assume that sensitive information on every Indian resident is now sitting in a Big Data lab in more than one foreign country, subject to sophisticated analysis and insight mining. In fact, if organisations like the NSA have not already acquired this data, my opinion of their competence has plummeted.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It's nothing short of a national security disaster.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Still, from the muted press around it, it appears that no one has a realistic handle on how grave the breach is. Critics of the government have seized on The Tribune's initial exposé to claim that Aadhar has been a massive security failure, but without understanding the nuances of what we have seen in this analysis. Supporters of the government have seized on the UIDAI's reassurances to downplay the significance of the breach, again without a sophisticated analysis of the potential exposure. Both sides are being irresponsible.<br />
<br />
My conclusion is that a serious breach of data security has been proven by The Tribune. This vulnerability has probably been around for a few months, enough time for a competent organisation or set of individuals to steal the master data (about a billion records), and create a foundation to add more useful data as it is acquired, since the Aadhar number is a permanent identifier that is likely to be associated with every significant product or service that residents may own or use.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A security assessment of the implications is imperative. At the very least, linking of Aadhar numbers to services must be halted.<br />
<br />
And it would not be unreasonable to demand that someone somewhere should resign.<br /><br />Update 24/03/2018: It appears that nothing has been done to fix the Aadhaar breach. If anything, even more breaches have been discovered, as described in this <a href="https://zd.net/2ufz1Jg">ZDNet article</a>.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-56259589577277330712017-10-13T06:15:00.000-07:002017-10-13T14:49:05.868-07:00Designing A Tamper-Proof Electronic Voting System<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2kERwr-PaGRbFJMpDdLwY0XhafU3-oh0rjIa_W6MeH3RlnUqhupFd3FjH8zf5_sfGZkRMSEafw8h4ObaVQyH48gcWhsyTQCj9k-L3TL5quMzIvgdHIC2ZsnLamMibwyL2S_WGmw/s1600/evm-00.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="733" data-original-width="1100" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2kERwr-PaGRbFJMpDdLwY0XhafU3-oh0rjIa_W6MeH3RlnUqhupFd3FjH8zf5_sfGZkRMSEafw8h4ObaVQyH48gcWhsyTQCj9k-L3TL5quMzIvgdHIC2ZsnLamMibwyL2S_WGmw/s400/evm-00.jpg" width="400" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<i>India's Electronic Voting Machine (EVM)</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
India's Electronic Voting Machines (EVMs) have been in the news a lot lately, and not always for the right reasons. <a href="http://indianexpress.com/article/india/faulty-evm-machine-ocassionally-casts-vote-in-favour-of-bjp-in-buldhana-4763183/">There have been complaints</a> by some candidates that when voters pressed the button in their favour, another party's symbol lit up. Faced with accusations that the EVMs may have been hacked (especially with the string of electoral successes of the ruling Bharatiya Janata Party), India's Election Commission has begun to conduct elections with a <a href="https://en.wikipedia.org/wiki/Voter-verified_paper_audit_trail">Voter-Verifiable Paper Audit Trail (VVPAT)</a>, which prints out the details of the party/candidate that a voter selected, so they can verify that their vote was registered correctly.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgFnTAN3lESjFMlxj0zY3Fe9uU0awD6eZteIZIs_3mTgLc8f_pOadBvK8lAvU3NQr1WiCgjefOYOJnRBpHlOKTiFFv-uzW5DcgVa1bJIHn5Pk77uHMFDsPJ87EsLz6aDyGaJaifw/s1600/evm-01-vvpat.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="722" data-original-width="1175" height="245" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgFnTAN3lESjFMlxj0zY3Fe9uU0awD6eZteIZIs_3mTgLc8f_pOadBvK8lAvU3NQr1WiCgjefOYOJnRBpHlOKTiFFv-uzW5DcgVa1bJIHn5Pk77uHMFDsPJ87EsLz6aDyGaJaifw/s400/evm-01-vvpat.jpg" width="400" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<i>An EVM unit with a printer to provide immediate paper verification to voters</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
As a systems architect, I'm afraid I have to say that may not be good enough. Let me explain why, and then suggest a more foolproof alternative.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
First of all, my familiarity with IT security tells me never to believe that a hardware device has in-built safeguards. We have all heard about how backdoors can be built into hardware, with whispers about the Russian mafia or Chinese government having control of fabrication plants that produce integrated circuits, so we know it's at least theoretically possible for criminal elements to inject malicious logic right into the hardware of an electronic device.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the same time, I believe it's being Luddite to advocate a return to entirely paper-based ballots. It's true that many Western countries stick to paper ballots for the sheer auditability of a poll (which electronic voting makes opaque), but India has had bad experiences with paper-based polls in the past, with uniquely Indian subversions of the system such as "<a href="https://en.wikipedia.org/wiki/Booth_capturing">booth-capturing</a>", as well as more conventional forms of fraud like "<a href="https://en.wikipedia.org/wiki/Electoral_fraud#Ballot_stuffing">ballot-stuffing</a>".</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
No, there's no going back to purely paper-based ballots, but there are serious vulnerabilities with the electronic voting system, even with VVPAT.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let me illustrate.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The basic EVM logic is as follows. The voter presses a button corresponding to their preferred party or candidate, and the machine confirms their selection by lighting up the corresponding election symbol (because many voters are illiterate and can't read). The choice is also recorded in the unit's memory. After the polls close, all the voting units are collected and connected to a central unit that tallies the votes in each. Once all units have uploaded their votes to the central unit, the results of that election can be announced, with the tallies of all parties and candidates available.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJjdS-Fjg3yhQAGhyNanGTvq-yDDikiUlkpJMU18fLcTtrhRcV37H-44DSfKEsyIgI0aYHU0_Xa0jVU3bK0kCepry7UfipILt0zUwJq2j339VXSxWdUE9eEAFdpVCmtRFj-KfwfA/s1600/evm-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="250" data-original-width="525" height="190" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJjdS-Fjg3yhQAGhyNanGTvq-yDDikiUlkpJMU18fLcTtrhRcV37H-44DSfKEsyIgI0aYHU0_Xa0jVU3bK0kCepry7UfipILt0zUwJq2j339VXSxWdUE9eEAFdpVCmtRFj-KfwfA/s400/evm-1.png" width="400" /></a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now, based on voter complaints about the wrong symbol lighting up, here's what many people suspect happened. Somehow (never mind how) a hack was introduced into some of the units that recorded a selection of party A as a selection of party B.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiBNHNLRKu-EIAeuA4kYVS0M9EK7aN0j1VDIwbqC0gjGaoT1KWPpEH6MyPzmPa_J_y89G-zGtBydNzNZSxYcIvRaGxBNPpXfl-rYhHKhO9pSmPHLVOlzJUjAdmka4iL-b-LQax8g/s1600/evm-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="309" data-original-width="525" height="235" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiBNHNLRKu-EIAeuA4kYVS0M9EK7aN0j1VDIwbqC0gjGaoT1KWPpEH6MyPzmPa_J_y89G-zGtBydNzNZSxYcIvRaGxBNPpXfl-rYhHKhO9pSmPHLVOlzJUjAdmka4iL-b-LQax8g/s400/evm-2.png" width="400" /></a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This is actually a pretty amateurish hack, as I'll explain shortly. It's readily detectable by an alert voter. What the Election Commission is attempting to do with the Voter-Verifiable Paper Audit Trail (VVPAT) is to make the voter's selection more explicit, in the hope that more of them will be forced to verify that their choice was correctly recorded. It does <i>not</i> make the system more secure in the sense of being able to trap more subtle hacks.<br />
<br />
Here's the schematic of the basic logic when things go well.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6BhnYZiXj-NlqnkvsYjQII9S-JIa3FAcpuuv9OwHbwu4wPCbhNTdzYhgeOe7MibL-G2LEJHz4uwoNoI-G-dWsk7H-BRLB6KTcHAkvO0GrpbQqBpUqkVIL93f7gvzrCPjEik6wkQ/s1600/evm-3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="181" data-original-width="782" height="92" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6BhnYZiXj-NlqnkvsYjQII9S-JIa3FAcpuuv9OwHbwu4wPCbhNTdzYhgeOe7MibL-G2LEJHz4uwoNoI-G-dWsk7H-BRLB6KTcHAkvO0GrpbQqBpUqkVIL93f7gvzrCPjEik6wkQ/s400/evm-3.png" width="400" /></a></div>
<div style="text-align: justify;">
<div style="text-align: center;">
<i>(Click to expand)</i></div>
<br /></div>
<div style="text-align: justify;">
When faced with a simple hack like the suspected one above, the system will respond as below.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVvXQ9s7cBtAgM6f2MGG1UShL8KA4LSpAASofW5G-U6dliUJz8X9cHC366iRWn7ZFbrKowUJarE1LR4n4BbFlo3RBxB2yNowQvKIJPqmvtcqmF2jhj2M0XxO7m_0NuacDRL60g2A/s1600/evm-4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="324" data-original-width="782" height="165" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVvXQ9s7cBtAgM6f2MGG1UShL8KA4LSpAASofW5G-U6dliUJz8X9cHC366iRWn7ZFbrKowUJarE1LR4n4BbFlo3RBxB2yNowQvKIJPqmvtcqmF2jhj2M0XxO7m_0NuacDRL60g2A/s400/evm-4.png" width="400" /></a></div>
<div style="text-align: justify;">
<div style="text-align: center;">
<i>(Click to expand)</i></div>
<br /></div>
<div style="text-align: justify;">
However, any hacker with a little more smarts will realise that their subversion will have to be less readily detectable. In other words, the hack would have to be placed in a slightly different place.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl8CM3SfEruhWpwmXTIbybwmM4hQil931XKL7o9ImFQNs5T8kfYCTGffP983GKJPvG0RWiKL1eJoKHGyQcSAoD2XB_Nc4yrAJ0IE8tnawTGd20V4AUNMq2VW1g5geL8eVgG0mI7w/s1600/evm-5.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="271" data-original-width="783" height="137" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl8CM3SfEruhWpwmXTIbybwmM4hQil931XKL7o9ImFQNs5T8kfYCTGffP983GKJPvG0RWiKL1eJoKHGyQcSAoD2XB_Nc4yrAJ0IE8tnawTGd20V4AUNMq2VW1g5geL8eVgG0mI7w/s400/evm-5.png" width="400" /></a></div>
<div style="text-align: center;">
<i>(Click to expand)</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
With this kind of hack, any mischief would be virtually undetectable. Both the lighted symbol and the paper printout would confirm to the voter that their choice was faithfully recorded, yet their vote would have been subtly hijacked in favour of another party.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The logic of the hack could be designed to be extremely subtle indeed. Instead of switching every single vote from party A to party B, it could be designed to apply a random function so that, on average, only 1 in N votes was switched across. In many marginal constituencies, even a small skimming of votes would be enough to tip the balance, so desired results could be achieved without any suspiciously large vote swings. There could even be a threshold below which the logic would not start to kick in, say a few thousand votes. That way, if the Election Commission conducted a few test runs to ensure that a unit was working correctly, it would not arouse suspicions.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now all this seems depressing. Is there any way to combat this?<br />
<br />
Yes, there is, but it's not purely in hardware and software. If it were, this post would have been titled "Designing A Tamper-Proof Electronic Voting <i>Machine</i>". The system that we design needs to incorporate electronic and manual elements.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
What we need are not one but two printouts for every vote. One copy is for the voter's own records. The other is for the Election Commission. The voter must verify that both match their selection, then place the EC copy into a ballot box before they leave the booth, just like in a paper-based poll. However, this paper ballot will only be used for verification, not for the actual vote tally on counting day, otherwise we may as well go back to a purely manual vote count.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhySutq4q0IUnw56uaxhYOFBrzifd0rXN99bnn4xy_6S-Swb_iihEwhj3QPwIgZA6tFX01yKuzeJ04_dSJnWf3NunVsGpX_HqHODk-v0W_x8j4cOQXGhflZSyh_2VMLC4bTWFBFEQ/s1600/evm-6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="399" data-original-width="924" height="172" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhySutq4q0IUnw56uaxhYOFBrzifd0rXN99bnn4xy_6S-Swb_iihEwhj3QPwIgZA6tFX01yKuzeJ04_dSJnWf3NunVsGpX_HqHODk-v0W_x8j4cOQXGhflZSyh_2VMLC4bTWFBFEQ/s400/evm-6.png" width="400" /></a></div>
<div style="text-align: justify;">
<div style="text-align: center;">
<i>(Click to expand)</i></div>
<br /></div>
<div style="text-align: justify;">
A number of statistical techniques may be used to sample and test the performance of voting machine units in various constituencies.<br />
<br />
Under the most pessimistic scenario, the ballot boxes of every single booth will be tallied offline, and the counting may continue for weeks after the official results. Elections will only be rescinded if the manual tally grossly contradicts the electronic one (there will always be minor discrepancies due to voter or official error).<br />
<br />
Under less pessimistic scenarios, a random sample of booths may be chosen for such manual verification. If gross discrepancies are detected in any booth, then <i>all</i> of the ballot boxes in that constituency will have to be manually tallied. If more than a certain number of constituencies show suspicious results, then the tally may be expanded to cover an entire state, and so on.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There can be further refinements, such as ensuring that the random sample of booths to be verified is drawn publicly, after the voting is completed, so as to afford no opportunity for malicious elements to know in advance which booths are "safe" from being audited.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In general, the design of the overall process is meant to detect subversions after the fact, so the technically accurate term is <i>tamper-evident</i> rather than <i>tamper-proof</i>. However, advertising the fact that such audits will be taking place may deter malicious elements from attempting these hacks in the first place. Hence, in a larger sense, the system consisting of the combined electronic and manual process, plus a widespread foreknowledge of an inevitable audit, may result in a tamper-proof system after all.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Democracy works because citizens have faith that their will is reflected in the results of elections. If citizens lose faith in the electoral process, it could cause a breakdown in society, with violent revolution in the worst case. That's why it's important to act quickly to restore faith in the process, even if this makes the process costlier.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
As the quote commonly attributed to Thomas Jefferson goes, "Eternal vigilance is the price of freedom."</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com3tag:blogger.com,1999:blog-13639021.post-88047729410917709632014-08-05T05:25:00.000-07:002017-10-13T14:43:48.486-07:00My Books On Dependency-Oriented Thinking - Why They Should Count<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
InfoQ has published both volumes of my book "Dependency-Oriented Thinking". The links are below.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<a href="http://www.infoq.com/minibooks/dependency-oriented-thinking-1">Dependency-Oriented Thinking: Volume 1 - Analysis and Design (Service-Oriented Architecture Made Simple)</a></div>
<div style="text-align: justify;">
<a href="http://www.infoq.com/minibooks/dependency-oriented-thinking-2">Dependency-Oriented Thinking: Volume 2 - Governance and Management (Control Systems Made Simple)</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I'll admit it feels somewhat anticlimactic for me to see these books finally published, because I finished writing them in December 2013 after about two years of intermittent work. They have been available as white papers on Slideshare since Christmas 2013. The last seven months have gone by in reviews, revisions and the various other necessary steps in the publication process. And they have made their appearance on InfoQ's site with scarcely a splash. Is that all?, I feel like asking myself. But I guess I shouldn't feel blasé. These two books are a major personal achievement for me and represent a significant milestone for the industry, and I say this entirely without vanity.<br />
<br />
You see, the IT industry has been misled for over 15 years by a distorted and heavyweight philosophy that has gone by the name "Service-Oriented Architecture" (SOA). It has cost organisations billions of dollars of unnecessary spend, and has fallen far short of the benefits that it promised. I too fell victim to the hype around SOA in its early days, and like many other converted faithful, tried hard to practise my new religion. Finally, like many others who turned apostate, I grew disillusioned with the lies, and what disillusioned me the most was the heavyhandedness of the "Church of SOA", a ponderous cathedral of orthodox practice that promised salvation, yet delivered nothing but daily guilt.<br />
<br />
But unlike others who turned atheist and denounced SOA itself, I realised that I had to found a new church. Because I realised that there was a divine truth to SOA after all. It was just not to be found in the anointed bible of the SOA church, for that was a cynical document designed to suit the greed of the cardinals of the church rather than the needs of the millions of churchgoers. The actual truth was much, much simpler. It was not <i>easy</i>, because "simple" and "easy" are not the same thing. (If you find this hard to understand, think about the simple principle "Don't tell lies", and tell me whether it is easy to follow.)<br />
<br />
I stumbled upon this simple truth through a series of learnings. I thought I had hit upon it when I wrote my white paper "<a href="http://wso2.com/library/whitepapers/2011/10/practical-soa-solution-architect/">Practical SOA for the Solution Architect</a>" under the aegis of WSO2. But later, I realised there was more. The WSO2 white paper identified three core components at the technology layer. It also recognised that there was something above the technology layer that had to be considered during design. What was that something? Apart from a recognition of the importance of data, the paper did not manage to pierce the veil.<br />
<br />
The remaining pieces of the puzzle fell into place as I began to consider the notion of <i>dependencies</i> as a common principle across the technology and data layers. The more I thought about dependencies, the more things started to make sense at layers even above data, and the more logical design at all these layers followed from requirements and constraints.<br />
<br />
In parallel, there was another train of thought to which I once again owe a debt of gratitude to WSO2. While I was employed with the company, I was asked to write another white paper on SOA governance. A lot of the material I got from company sources hewed to the established industry line on SOA governance, but as with SOA design, the accepted industry notion of SOA governance made me deeply uncomfortable. Fortunately, I'm not the kind to suppress my misgivings to please my paymasters, and so at some point, I had to tell them that my own views on SOA governance were very different. To WSO2's credit, they encouraged me to write up my thoughts without the pressure to conform to any expected models. And although the end result was something so alien to establishment thought that they could not endorse it as a company, they made no criticism.<br />
<br />
So at the end of 2011, I found myself with two related but half-baked notions of SOA design and SOA governance, and as 2012 wore on, my thoughts began to crystallise. The notion of dependencies, I saw, played a central role in every formulation. The concept of dependencies also suggested how analysis, design, governance and management had to be approached. It had a clear, compelling logic.<br />
<br />
I followed my instincts and resisted all temptation to cut corners. Gradually, the model of "Dependency-Oriented Thinking" began to take shape. I conducted a workshop where I presented the model to some practising architects, and received heartening validation and encouragement. The gradual evolution of the model mainly came about through my own ruminations upon past experiences, but I also received significant help from a few friends. Sushil Gajwani and Ravish Juneja are two personal friends who gave me examples from their own (non-IT) experience. These examples confirmed to me that dependencies underpin every interaction in the world. Another friend and colleague, Awadhesh Kumar, provided an input that elegantly closed a gaping hole in my model of the application layer. He pointed out that grouping operations according to shared <i>interface </i>data models and according to shared <i>internal </i>data models would lead to services and to products, respectively. Kalyan Kumar, another friend who attended one of my workshops, suggested that I split <a href="http://www.slideshare.net/ganeshcprasad/slicing-the-gordian-knot-of-soa-governance-prefinal">my governance whitepaper</a> into two to address the needs of two different audiences - designers and managers.<br />
<br />
And so, sometime in 2013, the model crystallised. All I then had to do was write it down. On December 24th, I completed the two whitepapers and uploaded them to Slideshare. There has been a steady trickle of downloads since then, but it was only after their publication by InfoQ that the documents have gained more visibility.<br />
<br />
These are not timid, establishment-aligned documents. They are audacious and iconoclastic. I believe the IT industry has been badly misled by a wrongheaded notion of SOA, and that I have discovered (or re-discovered, if you will) the core principle that makes SOA practice dazzlingly simple and blindingly obvious. I have not just criticised an existing model. I have been constructive in proposing an alternative - a model that I have developed rigorously from first principles, validated against my decades of experience, and delineated in painstaking detail. This is not an edifice that can be lightly dismissed. Again, these are not statements of vanity, just honest conviction.<br />
<br />
I believe that if an organisation adopts the method of "Dependency-Oriented Thinking" that I have laid out in these two books (after testing the concepts and being satisfied that they are sound), then it will obtain the many benefits of SOA that have been promised for years - business agility, sustainably lower operating costs, and reduced operational risk.<br />
<br />
It takes an arc of enormous radius to turn around a gigantic oil tanker cruising at top speed, and I have no illusions about the time it will take to bring the industry around to my way of thinking. It may be 5-10 years before the industry adopts Dependency-Oriented Thinking as a matter of course, but I'm confident it will happen. This is an idea whose time has come.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com3tag:blogger.com,1999:blog-13639021.post-31668286538237445372014-06-19T05:57:00.002-07:002014-06-19T05:59:00.849-07:00An Example Of Public Money Used For The Public Good<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I've always held that Free and Open Source Software (FOSS) is one of the best aspects of the modern IT landscape. But like all software, FOSS needs constant effort to keep up to date, and this effort costs money. A variety of funding models have sprung up, where for-profit companies try to sell a variety of peripheral services while keeping software free.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
However, one of the most obvious ways to fund the development of FOSS is government funding. Government funding is public money, and if it isn't used to fund the development of software that is freely available to the public but spent on proprietary software instead, then it's an unjustifiable waste of taxpayers' money.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It was therefore good to read that <a href="https://www.logius.nl/english/news-message/titel/dutch-government-actively-contributes-to-apache-open-source-software/">the Dutch government recently paid to develop better support</a> for the WS-ReliableMessaging standard in the popular Open Source Apache CXF services framework. I was also gratified to read that the developer who was commissioned to make these improvements was <a href="http://www.linkedin.com/pub/dennis-sosnoski/a/300/190">Dennis Sosnoski</a>, with whom I have been acquainted for many years, thanks mainly to his work on the <a href="http://jibx.sourceforge.net/">JiBX framework</a> for mapping Java to XML and vice-versa. It's good to know that talented developers can earn a decent dime while doing what they love and contributing to the world, all at the same time.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Here's to more such examples of publicly funded public software!</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-46419567839856855042014-06-09T21:19:00.000-07:002014-06-09T21:19:43.450-07:00A Neat Tool To Manage Sys V Services in Linux<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I was trying to get PostgreSQL's "pgagent" process (written to run as a daemon) to run on startup like other Linux services, and came upon this nice visual (i.e., curses) tool to manage services.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It's called "sysv-rc-conf" (install with "sudo apt-get install sysv-rc-conf"), and when run with "sudo sysv-rc-conf", brings up a screen like this:</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVB4GfjvZ89LQ-jMoKzIXYQvHG5w68EbHTcLvCfreaxsvyEQiYtNf_PL0BUmPO7MZ_hbD-yhNQzJsprw37skYGD1VysFBKyPLY13qIE3hYWrfwMP20w1TWmAwzFSM3KiMZTcCe7A/s1600/screenshot-sysv-rc-conf.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVB4GfjvZ89LQ-jMoKzIXYQvHG5w68EbHTcLvCfreaxsvyEQiYtNf_PL0BUmPO7MZ_hbD-yhNQzJsprw37skYGD1VysFBKyPLY13qIE3hYWrfwMP20w1TWmAwzFSM3KiMZTcCe7A/s1600/screenshot-sysv-rc-conf.png" height="315" width="320" /></a></div>
<div style="text-align: center;">
<i>It's not really "graphics", but to a command-line user, this is as graphical as it gets</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
All services listed in /etc/init.d appear in this table. The columns are different Unix runlevels. Most regular services need to be running in runlevels 2, 3, 4 and 5, and stopped in the others. Simply move the cursor to the desired cells and press Tab to toggle it on or off. The 'K' (stop) and 'S' (start) symbolic links are automatically written into the respective rc.d directories. Press 'q' to quit the tool and satisfy yourself that the symbolic links are all correctly set up.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You can manually start and stop as usual:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
/etc/init.d$ sudo ./myservice start</div>
<div>
<div style="text-align: justify;">
/etc/init.d$ sudo ./myservice stop</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Plus, your service will be automatically started and stopped when the system enters the appropriate runlevels.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Enjoy.</div>
</div>
<div>
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-76038830786962270712014-04-05T20:50:00.002-07:002014-04-05T21:00:56.646-07:00The End Of Ubuntu One - What It Means<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Although a big fan of Ubuntu Linux as a desktop OS, I've never been interested in their cloud storage platform Ubuntu One, and found it a bit of a nuisance when asked to sign up for it every time I installed the OS.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now <a href="http://bit.ly/QRirXF">Ubuntu One is being shut down</a>. I'm 'meh' but still a bit surprised.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The linked article talks about mobile, and how new mobiles such as the Ubuntu-powered ones need cloud storage to succeed. If so, isn't it really bad timing for Canonical to walk away from a fully operational cloud platform just when its mobile devices are entering the market?</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv6cUdC9W6fErhGn9MDj3IT63oF30Isn4WxmwH5VtN0zdoUQ3GmpnwQWeUsshTWaLIobaKfmtED6693DSvGA1yA8amRXDJtdFPOo03CzxYk-62TyNKx4yH3HFqmfqMEn5ZxTlx4w/s1600/ubuntu-smartphone.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv6cUdC9W6fErhGn9MDj3IT63oF30Isn4WxmwH5VtN0zdoUQ3GmpnwQWeUsshTWaLIobaKfmtED6693DSvGA1yA8amRXDJtdFPOo03CzxYk-62TyNKx4yH3HFqmfqMEn5ZxTlx4w/s1600/ubuntu-smartphone.jpg" height="187" width="320" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<i>Ubuntu-powered smartphones<br />(Do you know what the time on the middle phone <a href="http://releases.ubuntu.com/releases/13.10/">refers to</a>?)</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I think it's about economics.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ubuntu's statement says:</div>
<div style="text-align: justify;">
<br /></div>
<blockquote class="tr_bq">
If we offer a service, we want it to compete on a global scale, and for Ubuntu One to continue to do that would require more investment than we are willing to make. We choose instead to invest in making the absolute best, open platform and to highlight the best of our partners’ services and content.</blockquote>
<div style="text-align: justify;">
Hmm. I read this as Canonical trying to build a partner ecosystem that will substitute for having a big cloud-and-mobile story like Google does, without the investment that such a proprietary ecosystem will require. Let's see if they succeed.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The other side-story in the linked article is about telcos and their role. Having worked at a telco over the last two years, I can confirm that the major fear in the telco industry is being reduced to commodity carriers by "over the top" services. The telcos are fighting to offer content, and will want willing mobile wannabe partners like Mozilla and Canonical to offer smartphone platforms that will work with networking infrastructure and make the telcos more attractive (through content that both players source from content providers). It will be interesting to see how this four-way, federated partnership (between multiple telcos, independent smartphone platform vendors like Mozilla and Canonical, smartphone device OEMs and content providers) will play out. Many of these companies will think of themselves as the centre of the Universe and the others as partners.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1soZHIstz3vm6AsCsnILl8Xj7XbpSgNUUxrRsKp8Hs2O8hbqbutA5nVlUeWuu54h1gwreua6eOqkcrOovghm4kKZX_BybHlCxgtkB3JMVsUhA5rAnektFs1_6tKkZhs9wqF0V7A/s1600/firefox-smartphone.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1soZHIstz3vm6AsCsnILl8Xj7XbpSgNUUxrRsKp8Hs2O8hbqbutA5nVlUeWuu54h1gwreua6eOqkcrOovghm4kKZX_BybHlCxgtkB3JMVsUhA5rAnektFs1_6tKkZhs9wqF0V7A/s1600/firefox-smartphone.png" height="320" width="312" /></a></div>
<div style="text-align: center;">
<i>"Nothing runs like a fox" - Well, let's see if the Firefox Smartphone has legs</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In the meantime, some good news for startup cloud providers ("startup" only with respect to the cloud, since they will still need deep pockets to set up the infrastructure!): Canonical is open-sourcing its Ubuntu One storage code “to give others an opportunity to build on this code to create an open source file syncing platform.” This should be interesting.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-70026143015480944522014-03-11T22:01:00.000-07:002014-03-11T22:07:35.457-07:00Tools for HTML Table and Browser-Side Database Manipulation<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I've been having a lot of fun building a realistic-looking demo app that is meant to showcase the features of a coming product. A big challenge in such cases is obviously dynamic data, since hard-coded data won't cut it. It needs to behave like a web app, providing the illusion of a server-side database, but without a server-side database.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
HTML5 provides built-in client-side persistence features called sessionStorage and localStorage, but when the data requirements are complex, as in my application, these just aren't adequate. What I need is a client-side database like SQLite. As it turns out, different browsers have taken different routes to providing client-side databases, and it made my head hurt to read about Web SQL and SQLite and which browser incorporated which database and which browser abandoned which database. Finally, I found a JavaScript library called HTML5SQL.js that promised to abstract all those implementation issues from me, giving me a standard API to work with.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So far, it's worked great for me and seems very powerful and flexible. So that's the first tool I'd recommend, for client-side database manipulation - <a href="http://html5sql.com/">HTML5SQL.js</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Then I had the challenge of building HTML tables that would display this data, allow the user to manipulate it visually and save changes. After a lot of searching, I found another nice JavaScript library called DataTables. DataTables provides lots of powerful features, including sortable columns and pagination. These work even in the default settings with no configuration.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So that's the second tool I'd recommend, for HTML table manipulation - <a href="http://datatables.net/index">DataTables.js</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
By blending HTML5SQL and DataTables functions, I could create HTML tables from a client-side database. Even better, I could open multiple tabs on the browser, each representing a different part of the application, and they could all see the same data, because the database is a global resource to all tabs in the browser. Best of all, the data stayed persistent across browser restarts. It's a true database, with persistence, relational structure and SQL smarts.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Other tools:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Needless to say, <a href="http://jquery.com/">jQuery</a> has now become required technology, and a web developer simply cannot leave home without it. It's so powerful I'm still looking for the right categorisation to describe it.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Many of the new JavaScript libraries are built in an asynchronous style, so a rather naive usage assuming synchronous behaviour (that a function invoked first will complete before the next invoked function) will lead to some surprises. If you need to ensure that two asynchronous functions are executed in strict sequence, you will need to resort to callbacks, <a href="http://stackoverflow.com/questions/5187968/how-should-i-call-3-functions-in-order-to-execute-them-one-after-the-other">as explained on StackOverflow</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
For visual designers, the old method of using HTML tables to lay out components is now passé. Using CSS layouts is the in thing. A popular CSS layout framework is called the "960 Grid System", or <a href="http://960.gs/">960.gs</a>. It's named for the fact that most modern screens have a width of at least 960 pixels, and this number lends itself to being divided into 12 or 16 columns with spaces or gutters in-between. A newer one is <a href="http://unsemantic.com/">unsemantic</a>, which is said to be better for "responsive" UIs (those that adapt to different screen sizes, such as desktop browsers, tablets and mobile phones), but is a bit more complex to use. In both these frameworks, HTML components such as "div" and "table" elements just need to be given special class names, and the CSS then uses these to lay them out. It's quite neat and powerful, but I'm not working in that area because I'm not a graphic or layout designer. I've just seen the nice effects you can get with a CSS layout framework.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-4776133118425019022014-02-15T05:36:00.000-08:002014-02-15T05:36:02.050-08:00Sydney Workshop "Introduction to Dependency-Oriented Thinking" Held<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
After weeks of hectic preparation, Rahul Singh and I held our long-awaited workshop today on "Dependency-Oriented Thinking", comprising all-new material from my recent document <a href="http://slidesha.re/1cPwPD2">"Dependency-Oriented Thinking: Vol 1 - Analysis and Design"</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Somewhat disappointingly, we only had three signed-up participants, but the numbers only tell half the story. Only one of the three was from Sydney. One flew in from Melbourne the night before, and another got up at 4 am to make the 3+ hour drive from Canberra to Sydney. With such determination on their part, I just had to do my best, and I hope they were happy with the workshop. They certainly expressed satisfaction on their feedback forms :-).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The slides <a href="http://slidesha.re/1dwekrV">are now available on Slideshare</a>. If anyone was put off from reading the original document on account of its size (264 pages), they could go through this slide pack instead (only 220 slides, heh).</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-20714980109249616732014-01-21T18:28:00.000-08:002014-01-21T18:37:55.677-08:00Sydney Workshop On Dependency-Oriented Thinking (Saturday Feb 15, 2014)<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Well, it's time to road-test my SOA method "Dependency-Oriented Thinking". I released the two DOT documents before Christmas, <a href="http://slidesha.re/1cPwPD2">Volume 1 on Analysis and Design</a> and <a href="http://slidesha.re/1fEjz7A">Volume 2 on Governance and Management</a>. Now, Rahul Singh and I are conducting an all-day workshop to provide a more interactive instruction into the Analysis and Design aspects of the method. It'll be on Saturday the 15th of February, 2014.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The course fees are $450 plus GST for the all-day program. There's an early bird price of $400 plus GST for those who register on or before the 3rd of Feb.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You can download the workshop brochure and schedule here: <a href="http://slidesha.re/1j59nqK">http://slidesha.re/1j59nqK</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If you're a Sydney-based business analyst, solution architect or senior designer, you may be interested in this workshop. My objective is to make IT professionals more effective by helping them think more powerfully about complex, inter-connected systems. Dependency-Oriented Thinking is just structured common sense, but it doesn't come naturally. It needs to be taught, and it requires practice before it can become second nature.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-33515222481197432452013-12-25T00:05:00.000-08:002013-12-25T15:56:28.111-08:00Dependency-Oriented Thinking - Documents Released!<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I know I haven't been active on this blog for almost 6 months, but I haven't been idle. Ever since Rahul Singh and I conducted our first workshop on "Dead Simple SOA" in Sydney last year, I have been working on the feedback we received, namely that we needed to split "Analysis & Design" from "Governance & Management" because these two topics are of interest to two different audiences.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Splitting out just Governance & Management from the original document "<a href="http://www.slideshare.net/ganeshcprasad/slicing-the-gordian-knot-of-soa-governance-prefinal">Slicing the Gordian Knot of SOA Governance</a>" was the easy part. I realised that I didn't have much material on Analysis and Design, so I had to write that from scratch. That task ultimately took the better part of a year.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Well, that's completed now, and the two documents are now ready to download from SlideShare:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<a href="http://slidesha.re/1cPwPD2">Dependency-Oriented Thinking: Volume 1 - Analysis and Design</a></div>
<div style="text-align: justify;">
<a href="http://slidesha.re/1fEjz7A">Dependency-Oriented Thinking: Volume 2 - Governance and Management</a></div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
I have believed for a while now that the core concept behind SOA ought to be "dependencies". I could explain more here, but I'm exhausted after the marathon effort of the last few months. Besides, you'll find a very detailed argument in Volume 1.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Please do download these documents and have a read. More importantly, give me your feedback. My email address is in the "About the Author" section in both documents.</div>
</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-21097642118757996362013-07-02T23:53:00.002-07:002013-12-25T00:54:07.224-08:00Dependency Principles<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I've been used to thinking of SOA as "Dependency-Oriented Thinking" for such a long time that it suddenly struck me that I should readily be able to postulate "dependency principles" that can be applied at each of the BAIT layers. As it turned out, I was fortunate enough to have some actual case studies to verify my proposed set, and these cases were selected for being representative of different tiers, so they were quite comprehensive.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It turns out that the lesson to be learnt after a post-mortem of each of those case studies was that one or more dependency principles had been ignored or violated, resulting in the problem that was being faced. The corollary is that an organisation that scrupulously adheres to these principles will end up achieving SOA.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So, without further ado, here are the dependency principles (updated on 25/12/2013):</div>
<div style="text-align: justify;">
<br />
<b>Business Layer Principles</b><br />
<br />
1. Traceability – Enforce core governance; ensure that everything that is done makes sense with respect to the organisation's Vision<br />
2. Minimalism – Challenge assumptions, reject unwarranted constraints, do no more than required, reuse functional building blocks<br />
3. Domain Insight – Understand the true nature of the business; don't be misled by superficialities or conventional wisdom; re-imagine the business from first principles<br />
4. Business Process Coordination Style – Choose a coordination style (orchestration or choreography) based on whether tight control is possible and/or necessary. This influences the choice of technology standard (SOAP or REST), but may also be influenced by a prior choice of standard.<br />
<br />
<b>Application Layer Principles</b><br />
<br />
5. High Cohesion (“Belonging”) – What belongs together should go together, with minimal links between distinct systems; question instances of a single logical function split across multiple systems, or multiple logical functions combined within a single system. Group operations that share a Domain Data Model and business logic into Products, those that share an Interface Data Model into Services.<br />
6. Decoupling of Interfaces from Internals – Ensure that no external system develops dependencies on the internal aspects of a system; create an interface to isolate the systems from each other.<br />
7. “Goldilocks” Signatures (Stability versus Precision) – Identify multiple concurrent flavours of each logical operation; establish a way to express the business intent common to all of them; make sure that the interface doesn't change for minor variations in logic but does change with the business intent.<br />
8. Shared Semantics (Negotiation of Intent and Content) – In choreographed processes, ensure that the service provider and service consumer understand the meaning of every Operation as well as the mechanics of how each Operation should be invoked.<br />
<br />
<b>Information (Data) Layer Principles</b><br />
<br />
9. Decoupling of Interface Data from Internal Data – Distinguish the Interface Data Model from the Domain Data Model; use this to guide the grouping of Operations into both Products and Services<br />
10. Isolation of Context from Content – Separate the core data elements of the Interface Data Model from its qualifying elements; establish a separate Type Hierarchy for Context; use Context to categorise Variants and minimise Versions<br />
11. Low External Coupling (“Need to Know”) – Expose the minimum possible set of data to service consumers; make the data as generic as possible but exposing the business intent (i.e., conforming to the “Goldilocks” signature).<br />
12. Type Hierarchy – Create a data type hierarchy for both Content and Context elements; use this to expose multiple Variants as a single logical operation<br />
13. Identity Association – Ensure that entity identifiers do not leak out through the interface; provide a mapping between external and internal identifiers.<br />
<br />
<b>Technology Layer Principles</b><br />
<br />
14. Extraneous Constraints – Avoid introducing fresh dependencies between unrelated components in the process of implementing business logic<br />
15. Logic Bundling – Avoid combining unrelated pieces of data or logic<br />
16. State (“Stickiness”) – Avoid tight and unwarranted associations between instances of data/logic and physical components<br />
17. Topology Hotspots – Avoid associating physical components together in specific layouts and hard-wired connections unless warranted<br />
18. Late Binding – Delay unavoidable dependencies till the last responsible juncture</div>
<div style="text-align: justify;">
<br />
When you put these principles together with the entities at each layer, it forms a simple and mutually reinforcing set of techniques, and the complete approach is what is "Dependency-Oriented Thinking". This is an extract from the document "Dependency-Oriented Thinking: Volume 1 - Analysis and Design":</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq-rQheXIeieiAKT6w0c62ZPPD69UFDEV0U6Ys5dOPK-ZDCqZuJwKYQzBVyyM5ErgEQ3m5IKOd9csu1Ph5eDTn3YDQ_vpQfvW9PBxbuqzqqSMwN6sbiEM-YCAqhWAoEVpteHnyEA/s1600/DOT-design-principles.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq-rQheXIeieiAKT6w0c62ZPPD69UFDEV0U6Ys5dOPK-ZDCqZuJwKYQzBVyyM5ErgEQ3m5IKOd9csu1Ph5eDTn3YDQ_vpQfvW9PBxbuqzqqSMwN6sbiEM-YCAqhWAoEVpteHnyEA/s400/DOT-design-principles.png" height="400" width="281" /></a></div>
<br />
There is a companion document on Governance and Management. Feel free to download both documents:<br />
<br />
<a href="http://slidesha.re/1cPwPD2">Dependency-Oriented Thinking: Volume 1 - Analysis and Design</a><br />
<a href="http://slidesha.re/1fEjz7A">Dependency-Oriented Thinking: Volume 2 - Governance and Management</a><br />
<div>
<br /></div>
</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-62789354477117857342013-06-06T18:43:00.002-07:002013-06-06T18:46:10.748-07:00Red Hat's Competition Is From...Amazon<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I was talking to a colleague about Red Hat yesterday, and it struck me that a new competitor has emerged that threatens Red Hat's business model in a fundamental way.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Red Hat has two main lines of business, Linux and JBoss. Yes, they also have a cloud platform called Redshift, but I'm guessing it's not yet of the scale of the other two.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Both Linux and JBoss are Open Source, so the revenues to Red Hat are through support subscriptions. Put very bluntly, Red Hat's business model is based on fear, rather like that of insurance companies. Customer organisations are generally afraid to run unsupported software in their data centres, so they will gladly pay the insurance premiums to ensure that someone stands behind the software they run.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
But consider this subtle change in the model of reliability that comes about when we move to a cloud-based platform like Amazon. Reliability is achieved not so much by keeping servers running and getting them back online when there's a problem. The new model of reliability is to simply spin up new instances to replace failed servers. We can create images (AMIs) of our entire software stack, and spin up new instances either in response to increased volumes, or to replace instances that have died. This is actually done automatically, as part of the "elasticity" that cloud platforms deliver.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Mind you, Amazon itself suffers in adoption right now because of its own version of the fear factor. The thought of placing one's business-critical data and processes in the cloud keeps many CIOs awake at night. But that fear is gradually easing as more and more organisations are seen to be migrating to that cloud platform with no adverse effects.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
When Amazon becomes the norm for production infrastructure, the requirement for supported versions of operating systems may well reduce. The main difference between Red Hat Enterprise Linux and Centos (a RHEL clone) is that the former comes with paid support. If the reliability problem can be automatically addressed through elasticity, then Centos will do just as well.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's why I think Red Hat needs to be afraid of Amazon.</div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com2tag:blogger.com,1999:blog-13639021.post-38831786642678434302013-05-27T21:59:00.001-07:002013-05-27T22:26:43.404-07:00Resources Are Four-Dimensional<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The term ROA (Resource-Oriented Architecture) is misleading. It should ideally stand for "Resource/Representation-Oriented Architecture", even though that's quite a mouthful.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I've found in my discussions with people who work on REST-based systems that lots of them are very fuzzy about the notions of "resource" and "representation", even though these are the fundamental concepts underlying REST (and my forthcoming messaging-oriented variant, ROMA).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let me try and explain this. Let's say I found a space capsule that had fallen out of the sky, and by deciphering the alien glyphs on its surface, I understood that it contained a 4-dimensional object from the planet Royf. Unfortunately, I couldn't take the object out, because ours is a 3-dimensional world and such an operation is impossible. However, I found that it was possible to get the capsule to "project" a 3-dimensional image of the object it contained, so I could "see" it in a way that made sense to my limited mind. I found that I could also ask for the object to be manipulated in 3-dimensional terms. I knew, of course, that the object itself was 4-dimensional and so my instructions had to be somehow translated into terms that made sense in the 4D world. But I found to my satisfaction that the 3D image that resulted from my instructions was exactly what I wanted.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I realised then that my interactions with the space capsule were RESTian. The 4-dimensional object was the resource, an unseeable thing that I had no way of even comprehending and which was therefore mercifully shielded from my vision. What I could ask for (through a GET) was a 3D "representation" of the object, and this was something I could understand. I could also manipulate the object in several ways. I could show the capsule other 3D objects and say, "Change its shape to resemble this", or "Make its colour more like this", and it would happen! Obviously, the objects I was holding up were not the same as the object inside the capsule. They were representations of what I wanted the object to look like, when I saw it in 3D terms.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's really what REST is. The only aspect of the resource itself that we can directly deal with is its name, or URI. The actual resource is completely unseen, indeed <i>unseeable</i>. Everything that is actually seen is a representation, whether it's a representation of what the object is like right now, or a representation of what we want the object to be like. Everything that goes "over the wire" in REST is a representation.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2GS-N-7Zkf-eb1W542jQxZvb72HaObbNkrveHTU0Kv-_sFBhQm-7KIuRROUDVuGgXiEom9NrAf9bQNoIwb_h3Gc61Be_kAu_bic2OMdEcKS7bcvdCXm00w1nvVy1F5jLKFFYSpw/s1600/3d-projection.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2GS-N-7Zkf-eb1W542jQxZvb72HaObbNkrveHTU0Kv-_sFBhQm-7KIuRROUDVuGgXiEom9NrAf9bQNoIwb_h3Gc61Be_kAu_bic2OMdEcKS7bcvdCXm00w1nvVy1F5jLKFFYSpw/s400/3d-projection.jpg" width="400" /></a></div>
<div style="text-align: center;">
<i>Nerds can readily understand what a 3D projection is</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
[See also that REST is the very opposite of "Distributed Objects", although some industry personalities continue to insist that REST is DO! (JJ, I'm talking to you.) Distributed Objects tries to bring about an <i>illusion</i> that remote objects are local, allowing you to grasp them using virtual reality gloves. REST tries to bring about a <i>discipline</i> that says even local objects like the one inside the space capsule should be treated as remote, and we shouldn't try to grasp them directly, only deal with them indirectly through representations. Distributed Objects works well when it does and fails horribly when it doesn't. REST always works.]<br />
<br />
Hopefully, this should set to REST some of the confusion around resources and representations.</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-78362303435819795942013-05-20T08:18:00.002-07:002013-12-25T00:46:47.215-08:00SOA As Dependency-Oriented Thinking - One Diagram That Explains It All<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br />
I've been talking and writing about SOA as "Dependency-Oriented Thinking" for a while now, and have even conducted a couple of workshops on the theme. The feedback after the interactive sessions has always been positive, and it surprises me that such a simple concept is not already widely known.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I'm in the process of splitting (slicing?) my white paper "<a href="http://www.slideshare.net/ganeshcprasad/slicing-the-gordian-knot-of-soa-governance-prefinal">Slicing the Gordian Knot of SOA Governance</a>" into two, one dealing with SOA ("Dependency-Oriented Thinking" or DOT) and the other dealing with Governance and Management ("Dependency-Oriented Governance and Management" or DOGMa).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Partway through the DOT document, I realised that one of the diagrams in it explains the entire approach at a glance.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Here it is (updated after the <a href="http://wisdomofganesh.blogspot.com.au/2013/12/dependency-oriented-thinking-documents.html">release of the Dependency-Oriented Thinking documents</a>). Click to expand.</div>
<div style="text-align: justify;">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO_DEtZSUN7RUwQ7LdeP11EpKh3yk7RSy1LauP7cYwEGnrPJFekiWZiQF9AShA2kS05RIFhlSLsDfZaUkWE_sFKqFZjuU40TtPw1ZhnLxdd7fk7KlExjQMUwwr-h71ANMQD9rRmw/s1600/DOT-key-design-artifacts.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO_DEtZSUN7RUwQ7LdeP11EpKh3yk7RSy1LauP7cYwEGnrPJFekiWZiQF9AShA2kS05RIFhlSLsDfZaUkWE_sFKqFZjuU40TtPw1ZhnLxdd7fk7KlExjQMUwwr-h71ANMQD9rRmw/s400/DOT-key-design-artifacts.png" width="282" /></a></div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
</div>
<br /></div>
<div style="text-align: justify;">
This is of course the BAIT model of an organisation, with a specific focus on Dependencies. BAIT refers to Business, Application, Information (Data) and Technology, the four "layers" through which we can trace the journey of application logic from business intent to implementation.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
[Basic definitions: SOA is the science of analysing and managing dependencies between systems, and "managing dependencies" means eliminating needless dependencies and formalising legitimate dependencies into readily-understood contracts.]</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the Business layer, the focus on dependencies forces us to rationalise processes and make them leaner. Business processes need to be traceable back to the organisation's vision (its idea of Utopia), its mission (its strategy to bring about that Utopia) and the broad functions it needs to have in place to execute those strategies (Product Management, Engineering, Marketing, Sales, etc.). Within each function, there will need to be a set of processes, each made up of process steps. Here is where potential reuse of business logic is first identified.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the end of this phase, we know the basic process steps (operations) required, and how to string them together into processes that run the business. But we can't just have these operations floating around in an organisational "soup". We need to organise them better.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the Application layer, we try to group operations. Note that the Business Layer has already defined the run-time grouping of operations into Processes. At the application layer, we need to group them more statically. Which operations belong together and which do not? That's the dependency question that needs to be asked at this layer.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The answer though, is to be found only in the Information layer below, because operations only "belong" together if they share a data model. As it turns out, there are two groups of data models, those on the "outside" and those on the "inside". The data models on the "inside" of any system are also known as "domain data models", and these are never visible to other systems. In contrast, a data model on the "outside" of a system, known as an "interface data model", is always exposed and shared with other systems. In SOA, data on the outside is at least an order of magnitude more important than data on the inside because it impacts the integration of systems with one another, whereas data on the inside is only seen by a single system.<br />
<br />
Version churn is a potential problem at the Information Layer, because changing business requirements could result in changed interfaces. With a well-designed type hierarchy that only exposes generic super-types, the interface data model can remain stable even as newer implementations pop up to handle specialised sub-types. Most changes to interfaces are then compatible with older clients, and incompatible changes are minimised.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Once we have our data models, we can go back up one level to the Application layer and start to group our operations in two different ways, depending on whether they share an internal (domain) data model or an interface data model. Operations sharing a domain data model form Products. Operations sharing an interface data model form Services. (And that's where the "Service" in "Service-Oriented Architecture" comes from.) Products are "black boxes" meant to be used as standalone applications. Services are "glass boxes" with no other function than to loosely bundle together related operations.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Finally, we have to implement our Services. The description and deployment bundles that are used need not correspond one-to-one with the Services themselves. They should in general be smaller, so that the volatility (rate of change) of any single operation does not needlessly impact others merely because they share a description bundle (e.g., a WSDL file) or a deployment bundle (e.g., a JAR file). If we also pay attention to the right types of components to use to host logic, transform and adapt data, and coordinate logic, we will be implementing business intent in the most efficient and agile way possible.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This, in fact, is all there is to SOA. This is Dependency-Oriented Thinking in practice.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The white paper will explain all this in much greater detail and with examples, but this post is an early appetiser. [Update: you can fall to and help yourselves, since the main course is now ready. Grab the two documents below.]<br />
<br />
<br />
<a href="http://slidesha.re/1cPwPD2">Dependency-Oriented Thinking: Volume 1 - Analysis and Design</a><br />
<a href="http://slidesha.re/1fEjz7A">Dependency-Oriented Thinking: Volume 2 - Governance and Management</a><br />
</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-10633797641597961692013-05-16T17:41:00.002-07:002013-05-17T05:57:37.382-07:0050 Data Principles For Loosely-Coupled Identity Management<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br />
It's been a while since <a href="http://www.infoq.com/minibooks/Identity-Management-Shoestring">our eBook on Loosely-Coupled IAM</a> (Identity and Access Management) came out. In it, my co-author Umesh Rajbhandari and I had described a radically simpler and more elegant architecture for a corporate identity management system, an architecture we called LIMA (Lightweight/Low-cost/Loosely-coupled Identity Management Architecture).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Looking at developments since then, it looks like that book isn't going to be my last word on the subject.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
IAM has quickly moved from within the confines of a corporate firewall to encompass players over the web. New technology standards have emerged that are in general more lightweight and scalable than anything the corporation has seen before. The "cloud" has infected IAM like everything else, and it appears that IAM in the age of the cloud is a completely different beast.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
And yet, some things have remained the same.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I saw this for myself when reviewing the SCIM specification. This is a provisioning API that is meant to work across generic domains, not just "on the cloud". It's part of the OAuth 2.0 family of specifications, and OAuth 2.0 is an excellent, layerable protocol that can be applied as a cross-cutting concern to protect other APIs. SCIM too is OAuth 2.0-protected, but that's probably where the elegance ends.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The biggest problem with SCIM is its clumsy data model, which then impacts the intuitiveness and friendliness of its API. <a href="http://www.infoq.com/articles/scim-data-model-limitations">I critiqued SCIM on InfoQ</a>, and in response to a "put up or shut up" challenge from some of the members of the SCIM working group, I began working on an Internet Draft to propose a new distributed computing protocol, no less. That's a separate piece of work that should see the light of day in a couple of months.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In the meantime, I began to work on IAM at another organisation, a telco this time. My experiences with IAM at a bank, an insurance company and then a telco, had by then given me a much better understanding of Identity as a concept, and I began to see that many pervasive ideas about Identity were either limiting or just plain wrong. Funnily enough, most of these poor ideas had more to do with the Identity data model than with technology. I also observed that practitioners tended to focus more on the "sexy" technology bits of IAM and less on the "boring" data bits, and that explained to me, very convincingly, why systems were so clumsy.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I then consciously began to set down some data-specific tips and recommendations that I saw being ignored or violated. The irony is that it doesn't cost much to follow these tips. All it costs is a change of mindset, but perhaps that's too high a price to pay for many! In dollar terms, the business benefits of IAM can be had for a song. Expensive technology is simply not required.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So that's the lesson I learnt once more, and the lesson I want to share. No matter what changes we think are occurring in technology, the fundamental concepts of Identity have not changed. The data model underlying Identity has not changed. Collectively, we have a very poor understanding of this data model and how we need to design our systems to work with this data model.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So here are 50 data principles for you, the architect of your organisation's Identity Management solution. I hope these will be useful.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The presentation on Slideshare:<br />
<a href="http://slidesha.re/14uo3YY">http://slidesha.re/14uo3YY</a></div>
<div style="text-align: justify;">
<br />
The document hosted on mesfichiers.org:<br />
<a href="http://atarj9.mesfichiers.org/en/">http://atarj9.mesfichiers.org/en/</a></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com2tag:blogger.com,1999:blog-13639021.post-90782570954370913662013-05-03T20:14:00.001-07:002013-05-03T20:14:42.640-07:00"What Are The Drawbacks Of REST?"<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It seems the season for me to post comments in response to provocative topics on LinkedIn. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A few days ago, Pradeep Bhat posed the question, "What Are The Drawbacks Of REST?" on the REST Architects LinkedIn Group. As before, I had an opinion on this too, which I reproduce below:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>"I wouldn't say REST has "drawbacks" as such. It does what it says on the tin, and does that very well. But remember that the only implementation of the REST architecture uses the HTTP protocol. We can surely think of a future RESTian implementation that uses another transport protocol, and that is where some improvements could be made. </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>1. HTTP is a synchronous, request/response protocol. This means the protocol does not inherently support server-initiated notifications (peer-to-peer), which are often required. That's why callbacks in RESTian applications require the use of application-level design patterns like Webhooks. Now that we have a bidirectional transport protocol in the form of WebSockets, perhaps the industry should be looking at layering a new application protocol on top of it that follows RESTian principles. </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>2. The much-reviled WS-* suite of protocols has at least one very elegant feature. These are all end-to-end protocols layered on top of the core SOAP+WS-Addressing "messaging" capability. They resemble the TCP stack in that the basic protocol is IP, which only knows how to route packets. SOAP messages with WS-Addressing headers are analogous to IP packets. In the TCP world, end-to-end reliability is implemented through TCP over IP, and the SOAP world's analogy is WS-ReliableMessaging headers in SOAP messages. In the TCP stack, IPSec is the end-to-end security protocol (not TLS, which is point-to-point). The SOAP equivalent is WS-SecureConversation. Such Qualities of Service (QoS - reliability, security, transactions) can be specified by policy declaration (WS-PolicyFramework) and SOAP endpoints can apply them like an "aspect" to regular SOAP traffic. </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The REST world has nothing like this. Yes, an argument could be made that idempotence at the application level is a better form of reliability than automated timeouts and retries at the transport level. Similarly, we could argue that an application-level Try-Confirm/Cancel pattern is better than distributed transactions. But what remains is security. WS-SecureConversation with WS-Security is routable, unlike SSL/TLS, which is the only security mechanism in REST. With WS-Sec*, messages can also be partially encrypted, leaving some content in the clear to aid in content-based routing or switching. This is something REST does not have an elegant equivalent for. SSL is point-to-point, cannot be inspected by proxies and violates RESTian principles. It is just tolerated. </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The reason behind REST's inability to support such QoS in general is that all of these require *conversation state* to be maintained. Statefulness has known drawbacks (i.e., impacts to scalability and failure recovery), but with the advent of NoSQL datastores like Redis that claim constant-time, i.e., O(1), performance, it may be possible to delegate conversation state from memory to this datastore and thereby support shared sessions for multiple nodes for the purposes of QoS alone. I don't mean to use this for application-level session objects like shopping carts. If nodes can routinely use shared NoSQL datastores to maintain sessions, then the argument against statefulness weakens, and Qualities of Service can be more readily supported *as part of the protocol*. In RESTian terms, we can have a "uniform interface" for QoS.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
</div>
<i>3. While REST postulates a "limited" set of verbs, HTTP's verbs are too few! </i><br />
<i><br /></i>
<i>POST (add to a resource collection), PUT (replace in toto), PATCH (partially update), DELETE (remove from accessibility) and GET. These are actually not sufficient and they are frequently overloaded, resulting in ambiguity. </i><br />
<i><br /></i>
<i>I would postulate a more finely-defined set of verbs if defining a RESTian application protocol over a new peer-to-peer transport: </i><br />
<i><br /></i>
<i>INCLUDE (add to a resource collection and return a server-determined URI), PLACE (add to a resource collection with client-specified URI), REPLACE (in toto), FORCE (PLACE or REPLACE), AMEND (partial update, a container verb specifying one or more other verbs to specify operations on a resource subset), MERGE (populate parts of the resource with the supplied representation), RETIRE (a better word than DELETE) and SOLICIT (a GET replacement that is also a container verb, to tell the responding peer what to do to the initiator's own resource(s), because this is a peer-to-peer world now). Think of GET as a SOLICIT-POST to understand the peer-to-peer model. We also need a verb of last resort, a catch-all verb, APPLY, which caters to conditions not covered by any of the others. </i><br />
<i><br /></i>
<i>4. HTTP combines application-level and transport-level status codes (e.g., 304 Not Modified and 400 Bad Request vs 407 Proxy Authentication Required and 502 Bad Gateway). The next implementation of REST on another transport should design for a cleaner separation between the application protocol and the transport protocol. HTTP does double-duty and the results are often a trifle inelegant. </i><br />
<i><br /></i>
<i>So that's what I think could be done as an improvement to REST-over-HTTP. Apply the principles (which are very good) to a more capable peer-to-peer transport protocol, and design the combination more elegantly."</i><br />
<br />
I'm in the process of writing an Internet Draft for a new application protocol that can be bound to any transport (Pub/Sub, Asynchronous Point-to-Point or Synchronous Request/Response). The protocol is part of a new distributed computing architecture that I call ROMA (Resource/Representation-Oriented Messaging Architecture) and covers not just the data model and message API but also higher levels (QoS, description and process coordination). It's been 5 years in the making and has reached 170 pages so far. It may take another couple of months to get to a reviewable state. Stay tuned.<br />
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com3tag:blogger.com,1999:blog-13639021.post-1881219042792808932013-04-30T20:58:00.000-07:002013-04-30T21:56:56.510-07:00"Can Anyone Explain SOA In Simple Terms?"<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A few days ago, David Diamond posed a deceptively simple question on one of the LinkedIn Group sites (SOA SIG) - "Can Anyone Explain SOA In Simple Terms?"</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The barrage of widely varying responses that followed was, in a way, an eloquent answer to that question!</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I've had my own take on SOA for quite a while now, so this gave me the opportunity to validate my model against what other practitioners had to say. And I must say this: I'm more convinced than ever that the industry is horribly confused about SOA. There are those whose understanding of SOA is at a purely technology level (even some of those who profess to understand that SOA is not (just) about technology). And there are others who may understand SOA for all I know, but whose explanations tend to be couched in so much jargon that they're really hard to understand.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<div style="text-align: justify;">
In hindsight, David Diamond could not have asked a more insightful question.</div>
</div>
<div style="text-align: justify;">
<div style="text-align: justify;">
<br /></div>
</div>
<div style="text-align: justify;">
<div style="text-align: justify;">
Well, this is my blog, so just as history is written by the victors, the one correct answer to David's question is to be found here :-).</div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Here's what I wrote (put together from more than one post that I made to that topic):</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
My initial one-paragraph answer: <i>"<b>SOA is the science of analysing and managing dependencies between systems.</b> That means the elimination of unnecessary dependencies and the formalisation of legitimate dependencies into readily understood contracts. The more dependencies there are between systems, the less agile an organisation is (because of the number of related systems that have to change when one of them has to change), the higher its operating costs (because of all the unnecessary extra work to coupled systems) and the higher its operational risk (because of the number of things that could break when something changes). Dependencies exist at all of the BAIT layers - Business, Applications, Information (Data) and Technology. That's why a technology-only view of SOA does not solve an organisation's real problems. SOA should have been called DOT instead ("Dependency-Oriented Thinking")."</i></div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
After a few days of reading other responses and feeling dissatisfied, I posted again:</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
<i>"Many of the comments here emphasise reuse as part of the *definition* of SOA. Is reuse a core feature of SOA or just a side-benefit? If the latter, what are SOA's defining features (which is what the original question was about)? Also, while we use the word "services" a lot, how do we define the term?</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>Let me try and address these two points.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i><b>SOA is an organising principle for the enterprise</b>, and the fundamental skill that an architect requires to apply this organising principle is the ability to see dependencies between systems, - to be able to eliminate the ones that shouldn't exist and formalise the legitimate ones into "contracts" maintained in a single place and covering all the dependencies between two systems. This approach greatly reduces the cost of change, improves the speed with which changes are made (agility) and reduces the risk of making changes, all because the number of dependencies (aspects of an interaction affected by a change) are now smaller, one can tell at a glance what they are, and there are no surprises because there are no dependencies outside what is documented by the contract. This is not limited to technology interactions. One can apply this thinking to the design of business processes just as naturally.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>When we look through a dependency lens at an organisation, our tasks are quite distinct at its four layers (Business, Applications, Information (Data) and Technology).</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i><b>At the Business layer</b>, it is more of a BPR (Business Process Re-engineering) exercise, because <b>we end up rationalising processes when we weed out unnecessary dependencies</b>. When we finish, we have a traceability matrix linking the following:</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>Vision (Our idea of Utopia)</i></div>
<div style="text-align: justify;">
<i>Mission (Our strategy to bring about that Utopia)</i></div>
<div style="text-align: justify;">
<i>Functions (The main groups of activities we need to be doing as part of that strategy)</i></div>
<div style="text-align: justify;">
<i>Processes (The detailed and related sequences of steps comprising each function)</i></div>
<div style="text-align: justify;">
<i>Process Steps (The basic building blocks of these processes)</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>[At the business layer, we will come across some *potential* reuse when we look at the definition of some of the Process Steps (operations) we arrive at. Only further analysis at the Information layer will tell us if reuse is actually possible or these are independent operations.]</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The Application layer is all about grouping "related" operations, and the dependency principle used is that of "cohesion and coupling". In other words, we need to determine which process steps belong together and which do not. This cannot be done independently but must involve the Information (data) layer as well. [That's why architectural frameworks like TOGAF combine the two into a single step (Phase C)].</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The Information layer looks at data dependencies (shared models) and classifies data into two groups - "data on the outside" and "data on the inside". "Data on the inside" is the set of internal domain models for operations that other operations do not need to see. "Data on the outside" is what goes "over the wire" between operations.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i><b>When we apply the dependency principle of cohesion and coupling to the combined Application and Information layers, we have two ways of grouping operations together. Operations that share a domain model ("data on the inside") coalesce into Applications that are called Products. Operations that share an interface data model ("data on the outside") coalesce into Applications that are called Services. So this is where Services fit into SOA - as a bundle of related operations sharing an interface data model.</b></i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The Technology layer deals with "implementation". As others have pointed out as well, implementation need not have anything to do with SOAP, ESBs, etc. We need distinct components to host implementations of exposed operations (Service Containers), to mediate interactions (Brokers) and to coordinate operations (Process Coordinators). Other components merely support these (Rules engines, registries, monitoring tools).</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>This is SOA :-)."</i></div>
<br />
<br />
<div style="text-align: justify;">
I would have posted more, but I exceeded the word count for the site, so I had to post my thoughts about the Technology layer separately:</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
<i>"I must add that <b>when viewed through a dependency lens, the Technology layer often introduces artificial dependencies of its own</b>. There is a reason why many people prefer REST to SOAP. It's because <b>WSDL is a dependency hotspot</b>. Think about it. If a WSDL file describes just one service, and that service comprises 5 operations, each with an input document and an output document, then the version of the WSDL file has a dependency on the version of 10 document schemas. If any one of them changes, the WSDL will have to change! That's why we have so much version churn in organisations.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>In addition, because we don't build explicit interface data models with type hierarchies, our operation interfaces are too rigid and low-level, requiring a fresh *version* whenever a new *variant* is to be supported.</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>A second major dependency introduced by the technology layer is through the ESB, or more correctly, through incorrect use of the ESB. The dependency principle at the Technology layer is to use the right tool for the job and to use it the right way. If we use the ESB to host business logic, we are making it perform the role of a Service Container. If we use the ESB to orchestrate a process, we are making it perform the role of a Process Coordinator. Both of these mistakes create dependencies that reduce performance and increase the cost of change. </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>The other ESB-related mistake is its deployment in a hub-and-spokes architecture. Then the ESB becomes both a performance bottleneck and a single point of failure - both symptoms of a needless topological dependency that was created at the Technology layer. <b>IT organisations often ask for funds to buy an ESB because they want to "do SOA", then implement it in a topology that creates dependencies and thereby violates SOA principles</b>. What an irony! </i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i><b>So one of the reasons why SOA has acquired a bad name is that its practice often introduces dependencies at the Technology layer even as it tries to reduce dependencies at the Business, Application and Information layers. Worse, because organisations are often too technology-focused, they don't do enough of the dependency-reduction at these higher layers and their net effect is to introduce new, technology-related dependencies to an existing set of business processes and data structures. The net effect of SOA on such organisations is then entirely negative.</b></i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>I'm in the process of writing a white paper on "Dependency-Oriented Thinking" based on my experiences with SOA in large organisations. Stay tuned :-)."</i></div>
<br />
<br />
<div style="text-align: justify;">
Well, this represents my current thinking about SOA in a nutshell (a fairly large nutshell, I'll grant). The coming white paper on Dependency-Oriented Thinking will elaborate on these points. The workshops on "Dead Simple SOA" that I've been conducting through my company (Eigner Pty Ltd) along with my colleague Rahul Singh, address these very topics.</div>
<br /></div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com2tag:blogger.com,1999:blog-13639021.post-50651773924382686992013-04-29T21:56:00.000-07:002013-04-29T22:15:02.928-07:00JEM (JSON with Embedded Metadata) - A Simpler Alternative to JSON Schema?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I've long been a supporter of the <a href="http://json-schema.org/">JSON Schema</a> initiative, and <a href="http://wisdomofganesh.blogspot.com.au/2009/12/coming-overthrow-of-xml-orderly-makes.html">I was also happy</a> to see developments like <a href="http://orderly-json.org/">Orderly</a>, which offered a simpler and less verbose format than JSON Schema. But Orderly introduces its own format, which necessitates conversion to JSON Schema before it can be used. Both approaches are unsatisfactory in their own way. One is too verbose and the other needs translation.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
All of this made me wonder if we aren't approaching the problem the wrong way. JSON Schema is a conscious effort to replicate in the JSON world the descriptive capability that XML Schema brings to XML. But is this the best way to go about it?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I would like descriptive metadata about documents to be capable of being embedded inside the document itself, rather like annotations in Java programs. Indeed, this metadata should be capable of forming a "scaffold" around the data that then allows the data itself to be stripped out, leaving behind a template or schema for other data instances.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So I'm proposing something that I think is a whole lot simpler. It does require one fundamental naming convention to be followed, and that is this:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>Any attribute name that begins with an underscore is metadata. Everything else is data.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let's take this simple JSON document:</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtkgwVZfIw10tzfPmYXoln8JLguxDZBlk9wwZKTbD6X_uiMzWjJXZUhduAPE0PDMjtQgZEjYGGdtV84Xc6T7IztYOYu4nyS1dkPxb9Z3mAejcRAsr-_ioHWSeDPTBNcwrrxgAvzA/s1600/jem-0.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="96" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtkgwVZfIw10tzfPmYXoln8JLguxDZBlk9wwZKTbD6X_uiMzWjJXZUhduAPE0PDMjtQgZEjYGGdtV84Xc6T7IztYOYu4nyS1dkPxb9Z3mAejcRAsr-_ioHWSeDPTBNcwrrxgAvzA/s400/jem-0.png" width="400" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We can embed metadata about this document in two different ways. Click diagram to expand.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv9jYmzC5Xx8T6eWium9tXrSaUtTvdmUI-m4xqfFqlE2DvA-YKRGGN21ERaIgloWU2paJVVcfcUhJ00l7cSWOtly3NOi4nDcrXIPNAzA4DBD45A-_3BYS6JyH8Dw2E-uWM0etZOQ/s1600/jem-0-12.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="160" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv9jYmzC5Xx8T6eWium9tXrSaUtTvdmUI-m4xqfFqlE2DvA-YKRGGN21ERaIgloWU2paJVVcfcUhJ00l7cSWOtly3NOi4nDcrXIPNAzA4DBD45A-_3BYS6JyH8Dw2E-uWM0etZOQ/s400/jem-0-12.png" width="400" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I'm calling the first style "Metadata Markup", where the data elements of the JSON document retain their primacy, and the metadata around them is secondary and serves to add more detail to these data elements. One can readily see that "_value" is now just one of the possible attributes of an element, and many more such attributes can therefore be added at will.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I call the second style "Metadata Description", where the primary elements are metadata, and any data elements (whether keys or values) are modelled as the <i>values</i> of metadata elements. Note that describing a document as an array (a nested array in the general case) rather than as a dictionary (or nested dictionary) of elements allows the default order of the elements to be retained. This is quite useful when this format is used to publish data for human consumption.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The first style, Metadata Markup, is more suitable for document instances, because a lot of detailed meta-information can accompany a document and can be hidden or stripped out at will. It is easy for a recipient to distinguish data from metadata because of the leading underscore naming convention. There is no need to pre-negotiate a dictionary of metadata elements. (Click to expand.)</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgs4SuKTYbUF5x3s-9eGL8JKfzRorOTYqxoutJ_fEDsoZA_LaiRnsWADm1H41IP7_JBbyvhb9En9_dGqMAKmpr1Ehi3YpnLLTj1EinQOEIgLJ2SmEA2fUqkVpULaFV-RVrEYXPJwA/s1600/jem-1-11.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgs4SuKTYbUF5x3s-9eGL8JKfzRorOTYqxoutJ_fEDsoZA_LaiRnsWADm1H41IP7_JBbyvhb9En9_dGqMAKmpr1Ehi3YpnLLTj1EinQOEIgLJ2SmEA2fUqkVpULaFV-RVrEYXPJwA/s400/jem-1-11.png" width="280" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The second style, Metadata Description, is more suitable for schemas, because in this format, all elements pertaining to instance data (both keys and values) are just values. If only the values representing keys are retained, we get a "scaffold" structure describing the document, and more metadata elements representing constraints can be added, turning it into a schema definition. (Click to expand.)</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL_VFyZ8v7c49tym9Xnq-rxI5fzCxrHJjl6XRBPcpywbwEPwmyMLR5qJS0Rv6RMGBzSb4l5rNZ-0aAMa9eIMfKamPdE1sYrCu2iGD2VtNJEXnfuPR6Qo77PaNJusOehLooY_BDeg/s1600/jem-2-21.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL_VFyZ8v7c49tym9Xnq-rxI5fzCxrHJjl6XRBPcpywbwEPwmyMLR5qJS0Rv6RMGBzSb4l5rNZ-0aAMa9eIMfKamPdE1sYrCu2iGD2VtNJEXnfuPR6Qo77PaNJusOehLooY_BDeg/s400/jem-2-21.png" width="342" /></a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Obviously, this system will not work for everyone. I'm sure there are JSON documents out there that have underscores for regular data (HAL?), so adoption of this convention won't be feasible in such domains. But if a significant subset of the JSON-using crowd finds value in this approach, they're more than welcome to adopt it.</div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com1tag:blogger.com,1999:blog-13639021.post-52498025222162955152013-03-26T21:02:00.001-07:002013-03-29T02:41:35.386-07:00The Happy Confluence of IAM, SOA and Cloud<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Someone pointed me to <a href="http://blogs.gartner.com/ian-glazer/2013/02/08/killing-iam-in-order-to-save-it/">this Gartner blog post on IAM</a>, and I was once again reminded why Gartner doesn't get it, (or when they do, they get it much after everyone else).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The Gartner analyst in his presentation makes a big deal of the fact that LDAP, being a hierarchical data structure, is incapable of modelling the various complex relationships between entities in an IAM system. This is one of the reasons he believes we need to "kill IAM in order to save it". But is this limitation in traditional IAM systems really new? <a href="http://wisdomofganesh.blogspot.com.au/2012/08/ndap-because-user-provisioning-is-too.html">I'm no fan of LDAP</a>, and it has been known in IAM circles for at least 5 years that LDAP directories are suited for nothing other than the storage of authentication credentials (login names and passwords)! Everything else should go into a relational database, which is much better at modelling complex relationships. A meaning-free identifier links an LDAP entry with its corresponding record in the relational database. I describe this hybrid design in a fair amount of detail in my book "<a href="http://www.infoq.com/minibooks/Identity-Management-Shoestring">Identity Management on a Shoestring</a>". And this wasn't even my original idea. It was one of the pieces of advice my team got from a consultant (Stan Levine) that my employer hired to review our IAM plans.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Seriously, where has Gartner been?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Another big point made by the Gartner analyst was that IAM should not be "apart from" the rest of an organisation's systems but become "a part of" them. Joining the dots with my cynical knowledge of <a href="http://wisdomofganesh.blogspot.com.au/2012/03/my-goldilocks-logic-quadrant-as.html">where Gartner tends to go with this kind of argument</a>, I can see them making the case for big vendors that do everything including IAM. The cash registers at SAP, Oracle and Salesforce.com must have started ringing already, since Gartner has given those vendors' product strategies their all-important blessing.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Um, no. If there's anything we've learnt in the last few years (especially from SOA thinking), it's the great benefits that are gained from loose coupling. IAM should neither be "apart from" (decoupled) nor "a part of" (tightly coupled) with respect to an organisation's other, business-related systems. IAM needs to be <i>loosely-coupled</i> with respect to them.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
What does this mean in practical terms? It means IAM needs to be a cross-cutting concern that can be transparently layered onto business systems to enforce access policies, but without disrupting those systems with IAM-related logic.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That's really what the latest IAM technology, OAuth 2, brings to the table. But the Gartner analyst, while dwelling for quite a while on how great OAuth is, completely omits to define its true contribution.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<a href="http://blogs.forrester.com/eve_maler">Eve Maler of Forrester</a> says it much better in her presentations. She defines OAuth as a way <i>to delegate authorisation</i>, and positions it as a way <i>to protect APIs</i>. Can you see the confluence of IAM, SOA and the Cloud in that simple characterisation?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let's take those two aspects one by one and have a closer look.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>OAuth as a way to delegate authorisation</b>:</div>
<div style="text-align: justify;">
The traditional model of authorisation works like this. There is an entity that owns as well as physically controls access to a resource. When a client requests access to that resource, the owning entity does three things:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1. Authenticates the client (i.e., establishes that they are who they claim to be)</div>
<div style="text-align: justify;">
2. Checks the authorisation of the authenticated client to access the resource (i.e., acts as a Policy Decision Point)</div>
<div style="text-align: justify;">
3. Allows (or denies) the client access to the resource (i.e., acts as a Policy Enforcement Point)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
What OAuth does is recognise that the Policy Decision Point and the Policy Enforcement Point may be two very different organisational entities, not just two systems within the same organisational entity. The PDP role is typically performed by the owner of the resource. The PEP role is performed by the <i>custodian</i> of the resource. The owner need not be the custodian.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Under the OAuth model, there is a three-way handshake between the owner of a resource, the custodian of the resource and a client. Three separate trust relationships are established between the three pairs of entities in this model, and authentication is obviously required in setting these up (owner-to-client, owner-to-custodian and client-to-custodian-through-owner). Once the owner's permission to access the resource for a certain window of time is recorded in the form of an access token that the client stores, the owner's presence is no longer required when such access takes place. The custodian is able to verify the token and allow access in accordance with the owner's wishes even in the owner's absence. This is delegated authorisation.<br />
<br />
And since the resource doesn't even know it's being protected, this is loose coupling. IAM is neither "apart from" nor "a part of" the business system with OAuth.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>OAuth as a way to protect APIs</b>:</div>
<div style="text-align: justify;">
The delegated authorisation model can be used to protect resources that are not just "things" but also "actions". In other words, OAuth can be used to control who can invoke what logic, and do so in a delegated manner. In other words, owners of business logic can grant access to clients to invoke business logic, and custodians that host such business logic can validate the access tokens presented by clients and allow or deny access in accordance with the wishes of the owners.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now why does this development in the IAM world bring it into confluence with the SOA and cloud worlds?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The SOA bit is easy to understand. We did mention that an API is a form of resource. If all business logic can be reduced to service operations exposed through endpoints, then these form an API. Endpoints can be protected by OAuth as we saw, so OAuth can be an effective security mechanism for SOA.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The cloud bit isn't hard to understand either. If business logic can be abstracted behind APIs, then does it matter where that logic sits? Bingo - cloud! The cloud also forces separation of owner and custodian roles, with the cloud platform performing the role of custodian, and the cloud customer performing the role of resource owner or API owner. With OAuth as the authorisation mechanism, the cloud model becomes viable from an access control perspective as well.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So that's really what OAuth signifies. It's not just a development in IAM. It has profound implications for SOA security and the viability of the cloud model.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Watch for Gartner to break this news to their clients in 3 to 5 years' time...</div>
<div style="text-align: justify;">
<br />
(Meanwhile, someone at Gartner or elsewhere ought to tell that analyst that "staid" is not spelled "stayed". This presentation has irritated me on so many levels - spiritually, ecumenically, grammatically, <a href="http://www.urbandictionary.com/define.php?term=spiritually%20ecumenically,%20grammatically">as Captain Jack Sparrow said</a>.)</div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-70241466932510467572013-03-12T13:33:00.000-07:002013-03-12T19:24:30.897-07:00How to Implement An Atomic "Get And Set" Operation In REST<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br />
This question came up yesterday at work, and it's probably a common requirement.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You need to retrieve the value of a record (if it exists), or else create it with a default value. An example would be when you're mapping identifiers between an external domain and your own. If the external domain is passing in a reference to an existing entity in your domain, you need to look up the local identifier for that entity. If the entity doesn't yet exist in your domain, you need to create (i.e., auto-provision) it and insert a record in the mapping table associating the two identifiers. The two operations have to be atomic because you can't allow two processes to both check for the existence of the mapping record, find out it doesn't exist, then create two new entity instances. Only one of the processes should win the race.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
(Let's ignore for a moment the possibility that you can rely on a uniqueness constraint in a relational database to prevent this situation from occurring. We're talking about a general pattern here.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Normally, you would be tempted to create an atomic operation called "Get or Create". But if this is to be a RESTian service operation, there is no verb that combines the effects of GET and POST, nor would it be advisable to invent one, because it would in effect be a GET with side-effects - never a good idea.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
One solution is as follows (and there could be others):</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Step 1:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
GET /records/{external-id}</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If a record exists, you receive a <b>"200 OK"</b> status and the mapping record containing the internal ID.<br />
<br />
Body:</div>
<div style="text-align: justify;">
<div>
{</div>
<div>
"external-id" : ...</div>
<div>
"internal-id" : ...</div>
<div>
}</div>
<div>
</div>
</div>
<div style="text-align: justify;">
<br />
If the record does not exist, you get a <b>"404 Not found"</b> and a one-time URI in the "Location" header.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Location: /newrecords/84c5d65a-2198-42eb-8537-b16f58733791<br />
<br />
(The server will also use the header "Cache-control: no-cache" to ensure that intermediate proxies do not cache this time-sensitive response but defer to the origin server on every request.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Step 2 (Required only if you receive a "404 Not found"):</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
2a) Generate an internal ID.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
2b) Create a new entity with this internal ID and also create a mapping record that associates this internal ID with the external ID passed in. This can be done with a single POST to the one-time URI.<br />
<br />
POST /newrecords/84c5d65a-2198-42eb-8537-b16f58733791</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Body:</div>
<div style="text-align: justify;">
{</div>
<div style="text-align: justify;">
"external-id" : ...</div>
<div style="text-align: justify;">
"internal-id" : ... (what you just generated)<br />
"other-entity-attributes" : ...</div>
<div style="text-align: justify;">
}</div>
<div style="text-align: justify;">
<br />
The implementation of the POST will create a new local entity instance as well as insert a new record in the mapping table - in one atomic operation (which is easy enough to ensure on the server side).<br />
<br /></div>
<div style="text-align: justify;">
If you win the race, you receive a <b>"201 Created"</b> and the mapping record as a confirmation.</div>
<div style="text-align: justify;">
<div>
<br />
Body:</div>
<div>
<div>
{</div>
<div>
"external-id" : ...</div>
<div>
"internal-id" : ... (what you generated)</div>
<div>
}</div>
<div>
</div>
</div>
<div>
</div>
<br />
If you lose the race, you receive a <b>"409 Conflict"</b> and the mapping record that was created by the previous (successful) process.<br />
<br />
<div>
Body:</div>
<div>
<div>
{</div>
<div>
"external-id" : ...</div>
<div>
"internal-id" : ... (what the winning process generated)</div>
<div>
}</div>
<div>
</div>
</div>
<div>
</div>
</div>
<div style="text-align: justify;">
<br />
Either way, the local system now has an entity instance with a local (internal) identifier, and a mapping from the external domain's identifier to this one. Subsequent GETs will return this mapping along with a "200 OK". The operation is guaranteeably consistent, without having to rely on an atomic "Get or Create" verb.<br />
<br /></div>
<div style="text-align: justify;">
One could quibble that a GET that fails to retrieve a representation of a resource does have a side-effect - the creation of a one-time URI with the value "84c5d65a-2198-42eb-8537-b16f58733791" being inserted somewhere. This is strictly true, but the operation is idempotent, which mitigates its impact. The next process to do an unsuccessful GET on the same value must receive the same one-time URI.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It's a bit of work on the server side, but it results in an elegant RESTian solution.</div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com4tag:blogger.com,1999:blog-13639021.post-10848639358900673522012-12-08T17:11:00.001-08:002012-12-08T17:57:44.600-08:00Learnings From My "Dead Simple SOA" Workshop on Saturday<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br />
As announced earlier, the workshop that we (my business partner Rahul Singh and I) organised on "Dead Simple SOA" took place yesterday (Saturday the 8th Dec), and here's what we learnt from it.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Fundamentally, the ideas we are trying to popularise are seen as useful and worth pursuing. That was a very welcome piece of validation. However, we do need to refine our message and target our audience better.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We got largely positive feedback from the two participants (the low registration rate is itself a symptom of poor messaging and targeting), but also some valuable feedback on how we could improve it.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1. There are two sets of messages in the workshop, and this dilutes its appeal. This is because the draft white paper on which the workshop is based ("<a href="http://wisdomofganesh.blogspot.com.au/2012/11/slicing-gordian-knot-of-soa-governance.html">Slicing the Gordian Knot of SOA Governance</a>") itself deals with two separate (though related) themes.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
One theme is "How to do SOA". This had a number of new and useful ideas that the participants commented favourably on.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The other theme is about "How to do SOA Governance and Management". While the ideas behind this were also appreciated, here's what seemed to be lacking:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
a. This topic is of interest to a <i>different</i> group of people, - perhaps managers and enterprise architects, whereas "How to do SOA" is of interest to solution architects, designers and perhaps even developers.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
b. There is likely to be unease over the fact that my method challenges the accepted industry view of SOA Governance as a technology-related practice, which creates dissonance and may make people reluctant to pay for a "heterodox" course. If I want my approach of governing the entire enterprise through dependency-oriented thinking to be adopted, I should rename it to something else rather than try and redefine the term "SOA Governance". That train has left the station.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I seem to have a choice here. In the candid words of one of the participants, I have to "choose whether I want to be a philosopher or to build a business". Because if I want to build a business, his suggestion was to quietly align with the industry model instead of trying to challenge it, and then make money by offering to train people in the "universally accepted way". [I do think I can carve out a niche by being different without aligning submissively with conventional thinking, but there is a point here. A "flanking" strategy of coining a new term may work better than a "head-on" strategy of challenging a widely-held set of views.]</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
2. We need to improve our marketing, both in reach and in targeting. I don't know if we managed to reach most of our target audience with news of the workshop, and whether they could identify themselves as the target based on the workshop brochure. We relied on our membership of various LinkedIn groups to reach the professionals we were connected to, and some of our friends helped out by relaying the message to their contacts, but I'm not sure what proportion of our target audience is reached in this way. Some more research and refinement is required here.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
[Although we didn't get direct feedback on this aspect, I believe the price we are charging for a full-day workshop is reasonable ($450 plus 10% GST = $495, with an early-bird price of $400 plus GST = $440), and this includes morning and afternoon tea as well as lunch. The room and audio-visual equipment that we rented at the UTS Haymarket campus was OK, but not great. The air-conditioning couldn't be adjusted, and the data projector's screen obscured the fixed whiteboard, making it impossible to use both simultaneously. The catering was satisfactory in terms of quality but their commercial terms were somewhat unfavourable. We had to pay for a minimum of 10 people regardless, which was wasteful.]</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Action items:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1. Over the next few days, I will split my draft white paper into two parts, one dealing with "How to do SOA", aimed at solution architects and designers, and the other dealing with "How to do SOA Governance and Management", aimed at enterprise architects and managers. In the latter, I will touch upon the differences between my approach and the industry definition of "SOA Governance", and use a different name for mine.<br />
<br />
2. Future workshops will be better targeted. We will design our SOA workshops to focus on one or the other of the above topics, not both combined.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
3. We will look for newer and better ways to communicate news of forthcoming workshops to industry professionals. Some brainstorming will happen in the weeks ahead.</div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0tag:blogger.com,1999:blog-13639021.post-21598926858838422302012-11-27T22:14:00.003-08:002012-12-01T05:42:48.615-08:00Fighting City Hall Just Got Harder - When Bad Ideas Become Industry Standards<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hardly had the proverbial ink dried on my white paper "<a href="http://slidesha.re/Wt7yqq">Slicing the Gordian Knot of SOA Governance</a>" when I found out that The Open Group (which I praised so recently for their TOGAF architecture framework) has issued a SOA Governance standard.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Their opening position is exactly what I think is wrong with the IT industry's concept of SOA Governance.</div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjn3FkkcSGYvtkKRWKogebXqVNUOgY_lTSHy39hyphenhyphen4AI9zpXgW9quVJA7tMlHSTdeNTgSZU6y8fgqCFrGCYphrbeAOa0r7YKk9nr6aePOBap8vpYnwRlnLKeNYpYll1LOIK33q1X3w/s1600/TOG-SOA-governance.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjn3FkkcSGYvtkKRWKogebXqVNUOgY_lTSHy39hyphenhyphen4AI9zpXgW9quVJA7tMlHSTdeNTgSZU6y8fgqCFrGCYphrbeAOa0r7YKk9nr6aePOBap8vpYnwRlnLKeNYpYll1LOIK33q1X3w/s400/TOG-SOA-governance.png" width="400" /></a></div>
<div style="text-align: center;">
<i>The architecture for those who think "scientific thinking" means "thinking about science"</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
And why do I think this is horribly wrong? Read my white paper to find out - it's free :-).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If you have problems downloading it from <a href="http://slidesha.re/Wt7yqq">Slideshare</a>, try <a href="http://vjceqx.mesfichiers.org/en/index.html">mesfichiers.org</a> or <a href="http://bit.ly/SuDGu7">box.com</a>.</div>
<div style="text-align: justify;">
<br /></div>
</div>
prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.com0