Roy's Technology Diary

Introduction In this post, we’ll dive deep into the fascinating evolution of web services—from their early SOAP-based beginnings, through the rise of WebDAV and REST, and all the way to modern solutions like GraphQL and gRPC. Each approach addressed a particular set of challenges, and all of them left a lasting mark on the way applications talk to each other over the Internet. Let’s explore how web services went from clunky XML exchanges to streamlined JSON endpoints to high-performance, real-time systems. Regardless of whether you are a seasoned developer or just starting your journey, understanding these historical shifts will give you valuable insights into the “why” behind today’s popular API styles. Early Days with SOAP and RPC-Focused Services The Advent of Simple Object Access Protocol (SOAP) In the late 1990s, Simple Object Access Protocol (SOAP) emerged as a game-changer for exchanging data across different platforms. It mainly ran over HTTP (though it wasn’t strictly li...

In the previous article, we glanced through Enterprise Architecture as a whole and also discussed the need for an Enterprise Architecture Framework, like TOGAF. With this article we shall continue exploring TOGAF further, and discusses TOGAF's Architecture Development Methodology (ADM). The Architecture Development Methodology (ADM) The Architecture Development Methodology (ADM) provides a proven and repeatable process for developing architectures. The Scope The scope of ADM includes or encompasses the below listed activities, which are generally carried out in iterative cycles of continuous architecture definition and realization; thus aiding a controlled transformation of an enterprises in response to business goals and opportunities - Establishing an architecture framework Developing architecture content Transitioning Governing the realization of architectures Implementation Phases The implementation of ADM could be envisioned across the following phases - Preliminary Initiation...

Lately I've been studying/reading The Open Group Architecture Framework (TOGAF), and I simply could not resist from appreciating the structural approach that it introduces towards envisioning and capturing Enterprise Architecture. I therefore thought of initiating a series of articles herein, with the sole purpose of sharing, simplifying and promoting the framework especially amongst the architecture aspirants out there who follow and read my blog. This write-up, which is the first one in the series, intends to provide a brief overview on Enterprise Architecture and then further goes on to illustrate the need for an Enterprise Architecture Framework. Preface ISO/IEC 42010: 2007 defines "architecture" as: "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution." TOGAF embraces but does not strictly adhere to ISO/IEC 42010: 2007 terminology. ...

Whilst developing web applications, more than often we are confronted with the need to validate user inputs. On the client-side (browsers) we generally do that with scripting languages; and for those users who have perhaps deliberately disabled their browser script support; we perform the same set validation on the server side, and this time we write some lines-of-code to extract the user input from the HTTP request and validate the same. Well, although ironic; yet it seems to be a de-facto that - we have to specify the validation rules separately on the client and server side, for eventually validating something that is semantically same. A technical analysis into the core reason reveals that – although the semantics of the herein discussed "thing" (i.e. the user input) are the same, yet the representations of the semantic on the client and server side are different; which enforces us to implement the extraction and validation logic differently. So going by that theory - if ...

Its been quite a while since my last post here. I understand that my sudden disappearing act must have annoyed a many of my regular visitors; especially the ones who are expecting the second part of the XRX tutorial. Whilst you wait for the concluding part of the XRX article, I thought of sharing somethings that i found to be interesting - As Java Web application frameworks have become more powerful and flexible, they've also become more complex. John O'Hanley's WEB4J framework in many ways flies in the face of this trend: it offers few customization options, but is easy to learn and work with. Read on to learn about the unusual (and somewhat contrarian) development principles behind WEB4J. You'll also have the opportunity to test out the framework by building a feature for a sample Web application... [ more ]

During my tenure at Software AG, I was introduced to the power of XML. To my candor, i was very impressed to see the wide range of problems that XML promised to solve. Especially, to mention the performance power-punch that XML databases unleash when combined with XQuery and REST. A couple of years later, I moved into the consultancy world. Being back in the consultancy world and seeing business systems with my renewed XML-ized eyes (all credits to Software AG Tamino API and tools laboratory), I was highly dismayed to find that business oriented systems seldom use the real power of XML. The usage of XML herein has been more-so confined to defining application configurations and bare minimum transformation to either render interface elements or reports. I agree, there have been a few exceptions to this statement too. After spending quite some years revolting the general underutilization of XML; apparently I found my preferred architecture – i.e. XRX (XForms/REST/XQuery). What is so u...

Scaling Database is one of the most common and important issue that every business confronts in order to accommodate the growing business and thus caused exponential data storage and availability demand. There two principle approaches to accomplish database scaling; v.i.z. vertical and horizontal. Regardless of which ever scaling strategy one decides to follow, we usual land-up buying ever bigger, faster, and more expensive machines; to either move the database on them for vertical scale-up or cluster them together to scale horizontally. While this arrangement is great if one has ample financial support, it doesn't work so well for the bank accounts of some of our heroic system builders who need to scale well past what they can afford. In this write-up, I intend to explain a revolutionary and fairly new database architecture; termed as Sharding, that some websites like Friendster and Flickr have been using since quite sometime now. The concept defines an affordable approach t...

Most product development starts with a good design in mind. The initial architecture is clear and elegant. But then something begins to happen. What really happens is that the programs, like people, get old. However, unlike (in most cases) people there is no guarantee that software will mature as it grows old. Even worse, if we aren’t taking care of standard Software Quality Assurance (SQA), our system is not only ageing, but infact it is rotting. A Software undesirably grows old for two major reasons – The product owners have failed to modify the software to meet changing needs. The changes are made that yield poor results. It is SQA that determines the way we can check and improve our software quality. SQA is a planned and systematic approach to evaluation of the quality and adherence to software product standards, processes, and procedures. It includes the process of assuring that standards and procedures are established and followed throughout the software acquisiti...