IshaniQ: An Open-Source Java Platform for Quantitative Analysis

There is something fascinating about how students are learning software development today. Learning Java no longer needs to stop at loops, arrays, inheritance, and textbook exercises. With open-source libraries, public APIs, and modern visualization tools readily available, a student can turn those fundamentals into something surprisingly real.

IshaniQ is one such project! It is an open-source Java quantitative analysis and financial data exploration platform developed by a student from the University of Washington while learning software programming.

What began as an exercise in Java programming has gradually evolved into an application that retrieves real financial market data, persists and analyzes it, calculates technical indicators, and presents the results through interactive visualizations.

IshaniQ brings together several interesting open-source and developer technologies, including Java, TA4J, FINOS Perspective, OpenXava, JPA/Hibernate, Gson, and Maven, with Alpha Vantage providing market data.

Using TA4J, the project currently performs technical analysis with indicators such as Simple Moving Average (SMA), Relative Strength Index (RSI), and Average True Range (ATR). FINOS Perspective adds interactive visualization and exploratory analysis on top of the resulting datasets.

What I find particularly interesting about projects like IshaniQ is not simply the finished software. It is the way students can learn today.

A concept such as an array can lead to JSON parsing. JSON leads to REST APIs. APIs lead to object modelling and persistence. Market data introduces statistics and quantitative analysis. That leads naturally to visualization, open-source libraries, architecture, Git, documentation, and eventually publishing software for others to inspect and use.

The classroom concepts have not become less important. Instead, students now have an extraordinary opportunity to discover why those concepts matter by building something tangible with them.

IshaniQ remains an evolving project, and that is part of what makes it interesting. Its source code is publicly available, making it possible to follow its development, experiment with it, contribute ideas, or simply use it as an example of building a quantitative analysis application with Java.

Explore IshaniQ on GitHub:

• IshaniQ - Open-Source Java Quantitative Analysis
• A Medium article series introducing the core concepts

Perhaps the most encouraging aspect of projects like this is seeing students move from learning a programming language to using programming as a tool for exploration and creation. That is a meaningful difference in how the next generation of developers can learn.

A Brief Journey Through Web Services - SOAP, REST, and Beyond

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 limited to HTTP), using XML to structure requests and responses in a standard way.

One of SOAP’s hallmark features was Remote Procedure Call (RPC) support, wherein you could call methods on a server like calling functions in your local code. While that felt intuitive, it also led to tight coupling between clients and servers. Plus, SOAP’s love for XML often caused messages to balloon in size, resulting in heavier network usage and slower processing times.

Challenges with SOAP

As cool as SOAP was in providing a universal format, it had a few pain points; some of which are -

• Excessive Verbosity: XML messages could become huge and weren’t always easy to parse or debug.
• Performance Hit: Parsing large XML documents demanded extra CPU cycles.
• RPC Coupling: Rigid, function-style calls made it trickier to evolve services without breaking clients.

These drawbacks prompted many developers to experiment with simpler, more flexible approaches.

WebDAV’s Subtle but Crucial Role

A Quick Look at WebDAV

Though not always labeled a web-service, Web Distributed Authoring and Versioning (WebDAV) expanded HTTP to support collaborative editing, file locking, and version management. Essentially, WebDAV took the standard HTTP methods—like GET and POST—and extended them so multiple users could work on the same files and resources.

This was particularly handy for document management, where version control mattered a lot. Even if WebDAV itself wasn’t about structured data or JSON, it showed how HTTP could be leveraged for more than just simple page fetches, paving the way for resource-focused patterns later on.

WebDAV’s Influence

WebDAV introduced the idea that HTTP methods could be used to manipulate resources in a standardized way. That concept would turn into a core principle of the REST approach—treating everything as an addressable resource and letting the standard HTTP verbs handle reading, writing, and deleting.

The Rise of Representational State Transfer (REST)

REST in a Nutshell

Around the early 2000s, Roy Fielding presented Representational State Transfer (REST) as a simpler architectural style that fully embraced the capabilities of HTTP.

Key Representational State Transfer (REST) principles include -

1. Stateless Interactions: Each request has all the info needed for the server to process it, making the server more scalable.
2. Uniform Interface: You use the same set of HTTP verbs (like GET, POST, PUT, DELETE) for consistent operations across different resources.
3. Layered System: Caches, load balancers, and proxies can sit between client and server for higher efficiency and flexibility.
4. Resource Representation: A resource can be delivered in different formats—JSON, XML, or even HTML—and the client picks what it needs.

Why REST Became So Popular?

Representational State Transfer (REST) was an instant hit for a few obvious reasons.

• Simplicity: The reliance on HTTP kept the technology stack lean and familiar.
• Less Overhead: Switching from XML to JSON in many cases significantly cut down message size and parsing difficulty.
• Loose Coupling: Clients interact with resources via well-known URIs, so servers can evolve behind the scenes without constantly breaking client integrations.

As a result, RESTful APIs quickly became the go-to option for web-based communication, especially for public APIs—think social media platforms, payment gateways, and mapping services.

Where REST Falls Short?

Like every architecture, REST isn’t perfect! Following are some of the most common complaints -

1. Overfetching & Underfetching: You might get too much or too little data by hitting a single endpoint, forcing multiple calls or extra filtering.
2. Complex Queries: Dealing with nested or related resources can get messy, often leading to lots of endpoint variations.
3. No Real-Time Model: REST’s request-response pattern isn’t inherently set up for real-time data pushes. You’d have to bolt on WebSockets or another trick for two-way communication.

For many straightforward CRUD tasks, REST still rules. But as applications got more complex—especially on mobile or in richly interactive front-ends—developers began looking for solutions that could solve these particular pain points.

Evolving Past REST with GraphQL and gRPC

GraphQL - A Query Language for APIs

Developed at Facebook (now Meta) and open-sourced in 2015, GraphQL quickly gained traction for solving the overfetching and underfetching problems. Instead of juggling many REST endpoints, GraphQL condenses everything behind a single endpoint.

How GraphQL Works?

• Clients define exactly what data they need in a nested, declarative format. No more extra payload, no more missing data.
• The server has a strongly typed schema that outlines the data’s structure, enabling auto-documentation and robust validation.
• It’s particularly loved by front-end teams, as they can shape queries to match UI needs without waiting for the back-end to create new endpoints.

Trade-Offs

• It introduces a new query language and a more complex server-side resolver system.
• Traditional caching strategies based on resource URIs aren’t straightforward with a single GraphQL endpoint, so new caching patterns or frameworks are often required.

gRPC - High-Speed, Low-Latency Communication

While GraphQL tackles data-fetching issues, gRPC, originating from Google, focuses on performance and streaming scenarios. It’s built on HTTP/2 and uses Protocol Buffers (Protobuf) for a compact, binary approach.

Standout Features

• Small, Efficient Messages: Protobuf keeps data slim, reducing bandwidth usage and boosting speed.
• Streaming Support: gRPC can handle bidirectional streaming natively, making it perfect for real-time data and microservices that need constant updates.
• Contract-First Development: Defining a .proto file sets the structure for both client and server, reducing inconsistencies and integration errors.

Downsides

• Requires learning Protobuf schemas and dealing with a separate toolchain.
• Debugging binary messages is less intuitive than reading JSON or XML if something goes wrong.

Epilogue

From the XML heavy days of SOAP to the resource-friendly nature of REST, and finally, to the more refined problem-solving approaches of GraphQL and gRPC, web services have continually adapted to meet changing requirements. SOAP demonstrated the value of standardized protocols, while WebDAV paved the way for using HTTP verbs to manipulate resources. REST then capitalized on HTTP’s simplicity, but its one-size-fits-all approach sometimes struggled when data relationships got complex or real-time updates were crucial.

GraphQL stepped up to reduce excessive network calls and offer a front-end friendly API, while gRPC brought lightning-fast performance and streaming capabilities to microservices. Each style - whether SOAP, REST, GraphQL, or gRPC still has its place, catering to different technical and organizational needs. By understanding how these approaches evolved, developers can make more informed decisions, matching the right tool to the right job. After all, tech moves fast - but knowing our history helps us chart a better course forward.

Dynamic Traits with Java

Traits are reusable components representing a set of methods or behaviors that can be used to extend the functionality of multiple classes. Some programming languages like Groovy and Scala have been supporting Traits for a long time, and allow dynamic association of Traits to any object, at runtime.

Java being a strongly typed programming language, enforces a very strict discipline of type association, upfront whilst declaring any language element, e.g. variables, functions, etc; and the same is applicable for Classes too. Therefore when you implement a class in Java, the associative types for the class, must be specified as a part of the declaration of the class, which strongly binds the type interfaces to the class, and cannot be changed in runtime.

The concept of Traits is implemented in Java using Interfaces, which contain default methods and variables to allow maintaining an object's state. However, these interfaces then have to be tightly coupled with the class declaration, and as discussed above one cannot dynamically modify an interface association.

Java-DynaTraits is a very simple and minimalist library, that allows dynamic association of Traits/Interfaces; such that new interfaces could be added to your class at runtime, without really having to specify them, with the declaration of the class.

The core concept behind the code is to use a subscription model, which allows registering interfaces (or in other words Traits) with a class, in runtime, and then using an Invocation Handler to delegate function calls to the relevant subscriptions.

An Example Code

Following is a sample code, that demonstrates an example usage -

var catalog = (CatalogInterface & NamedEntity & PricedEntity) 
(new Catalog()).withTraits(new NamedEntity(){}, new PricedEntity(){});

// The setName function is rendered by the "NamedEntity" trait.

catalog.setName("Dynamic Traits with Java");

System.out.println(catalog.getName());

// The setPrice function is rendered by the "PricedEntity" trait

catalog.setPrice(20.00);

System.out.println(catalog.getPrice());

Please visit the project page on Github for further details.

Java 7, brings a simple yet a long awaited feature...

Would you be surprised to know that the API of java.io.File only supported getting the last modified time, and NOT the file's creation time, until Java 7...? Well, not many people seem to be aware of this and surprisingly even the Internet was very quiet on this topic all the while.

So if you are using anything below Java 7 and are desperate to fetch a file's creation time then, one solution would be to write some native code to call system routines and then call the native code using JNI. Most of this work seems to be already done for you in a library called JNA, though. Nevertheless, you will still need to do a little OS specific coding in Java for this, though, as you'll probably not find the same system calls available in Windows and Unix/Linux/BSD/OS X.

VMWare Cloud Foundry - Developing "cloud-ready" web applications has never been so easy

A lot has been said and done about services on the cloud lately and "Platform as a Service" (PaaS) is probably one of the most popular buzz-word that's been around for quite sometime now. However, I sincerely feel that the common man (read as "developer") is yet to get a taste of what it really means. Now, this very paradigm seems to be soon changing, with VMWare Cloud Foundry. Cloud Foundry is the world’s very first open Platform as a Service (PaaS). It is designed to help developers easily create web applications, using multiple programming frameworks including Spring for Java, Ruby on Rails and Sinatra for Ruby; that can run upon public and private cloud environments, with just about no additional learning curve. So, by now if you are dreaming of a possibility to port your existing web-applications to the cloud with minimal efforts, then let me give you the good news - "it's all possible here..."

Well, looks like i've done a lot of sales talks in favour of VMWare Cloud Foundry. Now lets get under the hood and get hands-on with developing an extreamly simple web application that demonstrates the following -

1. Setting up VMWare Cloud Foundry
2. Consuming Cloud Foundry's MySQL service in a JSP, using the standard JDBC way
3. Deploying a web archive and running the JSP on Cloud Foundry

Setting up VMWare Cloud Foundry

Windows Setup

1. Apply for a Cloud Foundry account at www.cloudfoundry.com; you will be notified by email when your account is activated
2. Install Ruby from www.rubyinstaller.org; The Cloud Foundry cloud-controller command line is built in Ruby so this is required. As the installer runs, make sure to check the boxes to add the ruby directory to your command path
3. Start the Windows command line client (Start Menu -> Run -> "cmd")
4. To install the cloud-controller tool type : gem install vmc (If you are behind a firewall then : gem install --http-proxy http://proxy.vmware.com:3128 vmc)

Congratulations! The Cloud Foundry Cloud Controller is now installed. From here on, you may type Cloud Foundry commands into the Windows command window.

1. Inform Cloud-Foundry which cloud you want to connect to : vmc target api.cloudfoundry.com
2. To login to Cloud Foundry type : vmc login (enter your account credentials when prompted)

Linux Setup

The document here is the best source of information for setting up the cloud-controller upon various Linux flavours.

Consuming Cloud Foundry's MySQL service

There are plenty of elaborate tutorials available on the web, that illustrate accessing the MySQL service at Cloud foundry using Spring. However, this one is a bit different, because it does not use Spring at all and demonstrates the same functionality with plain and simple Java and standard JDBC API.

The following code snippet demonstrates the approach -

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

<%@page import="java.sql.*,javax.sql.*"%>
<%@page import="org.cloudfoundry.services.*"%>
<%
String query = "Select * FROM users";
%>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Cloud Foundry with Simple Java</title>
</head>
<body>
Welcome to the simple web application on cloud-foundry...
<%
Connection connection = null;

try {
// establish connection to MySQL Service
ServiceManager services = ServiceManager.INSTANCE;
connection = (Connection) services.getInstance(CloudFoundryServices.MYSQL);

if (connection != null && !connection.isClosed()) {
out.println("<p>Successfully connected to MySQL service</p>");

// creating a database table and populating some values
Statement s = connection.createStatement();
int count;
s.executeUpdate("DROP TABLE IF EXISTS animal");
s.executeUpdate("CREATE TABLE animal ("
+ "id INT UNSIGNED NOT NULL AUTO_INCREMENT,"
+ "PRIMARY KEY (id),"
+ "name CHAR(40), category CHAR(40))");

out.println("<p>[1] Table successfully created.</p>");

count = s.executeUpdate("INSERT INTO animal (name, category)"
+ " VALUES"
+ "('snake', 'reptile'),"
+ "('frog', 'amphibian'),"
+ "('tuna', 'fish'),"
+ "('racoon', 'mammal')");

out.println("<p>[2] " + count + " rows were inserted.</p>");

count = 0;
ResultSet rs = s.executeQuery("select * from animal");
while (rs.next()) {
count++;
}
out.println("<p>[3] " + count + " rows were fetched.</p>");

s.close();
}
} catch (Exception e) {
out.println(e.getMessage());
} finally {
if (connection != null && !connection.isClosed()) {
connection.close();
}

connection = null;
}
%>
</body>
</html>

In the above code, org.cloudfoundry.services is a custom package which primarily contains a Singleton implementation, namely "ServiceManager"; and an interface to hold the constants, namely "CloudFoundryServices". Following are the sources for the same -

CloudFoundryServices.java

package org.cloudfoundry.services;

public interface CloudFoundryServices {
public static final int MYSQL = 1;
}

ServiceManager.java

package org.cloudfoundry.services;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import argo.jdom.JdomParser;
import argo.jdom.JsonNode;
import argo.jdom.JsonRootNode;

public enum ServiceManager implements CloudFoundryServices {

INSTANCE;

private static final String NULL_STRING = "";

public Object getInstance(int service_type) throws Exception {
if (service_type == MYSQL) {
return getMySQLConnection();
} else {
throw new IllegalArgumentException("Service for id " + service_type + " not found...");
}
}

/*
* This method is responsible for establishing a valid connection to the MySQL service,
* using the credentials available in the environment variable, namely "VCAP_SERVICES".
*
* The content of VCAP_SERVICES environment variable is a JSON string, thus this method
* uses standard interfaces from the Argo JSON parsing API to extract the credentials.
*/

private Object getMySQLConnection() throws SQLException {
String vcap_services = System.getenv("VCAP_SERVICES");

String hostname = NULL_STRING;
String dbname = NULL_STRING;
String user = NULL_STRING;
String password = NULL_STRING;
String port = NULL_STRING;

if (vcap_services != null && vcap_services.length() > 0) {
try {
JsonRootNode root = new JdomParser().parse(vcap_services);

JsonNode mysqlNode = root.getNode("mysql-5.1");
JsonNode credentials = mysqlNode.getNode(0).getNode("credentials");

dbname = credentials.getStringValue("name");
hostname = credentials.getStringValue("hostname");
user = credentials.getStringValue("user");
password = credentials.getStringValue("password");
port = credentials.getNumberValue("port");

String dbUrl = "jdbc:mysql://" + hostname + ":" + port + "/" + dbname;

Class.forName("com.mysql.jdbc.Driver");
Connection connection = DriverManager.getConnection(dbUrl, user, password);
return connection;
} catch (Exception e) {
throw new SQLException(e);
}
}

return null;
}
}

Now all you need to do now is, bundle everything together and get yourself a standard WAR (web archive) file.

Deploying a web archive and running the JSP on Cloud Foundry

Once you have the WAR file in place, browse to the location where the file is placed, using your command-line console; and execute the following cloud-controller commands -

• In case you are not yet logged in to the cloud, type : vmc login (and, provide the required credentials when prompted)
• vmc push
• Enter a unique application name when prompted, could be anything like in my case its my name "rahulr"
• Select 'Y' when prompted to bind a service and select the MySQL service from the offered list of services

Finally the status "Starting Application : OK", at the end of the command execution, indicates a successful deployment. So, now you are all set to start-up a browser and fire-up your first "cloud-enabled" web application, at the url <app-name>.cloudfoundry.com. Optionally, you might want to check the one that I've hosted at http://rahulr.cloudfoundry.com

Thats all for now, I hope you liked the post and should you have any issues getting this up and running feel free to reach out to me.

Additional Resources

Following are some links which I found useful -

• A Guide to creating your own services
• The "vmc" command internals

Demystifying Enterprise Architecture with TOGAF - Understanding the Architecture Development Methodology (ADM)

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
The Preliminary Initiation phase describes the preparation and initiation activities, required for meeting the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of core principles.

Architecture Vision Setup
The Architecture Vision Setup phase describes the initial phase of an architecture development cycle. It includes information about the following activities -

• Defining the scope
• Identifying the stakeholders
• Creating the architectural vision statement
• Obtaining the initial approval

Business Architecture Evolution
The Business Architecture Evolution phase describes the development of a Business Architecture and its alignment to support an agreed Architecture Vision.

Information Systems Architecture Definition
The Information Systems Architecture Definition phase describes the development of Information Systems Architectures required to support the Architecture Vision. This phase typically involves -

• Identification and development of Data Architectures
• Development of various Application Architectures

Technology Architecture Evolution
The Technology Architecture Evolution phase describes identification and development of the requisite Technology Architecture, with respect to supporting the Information Systems Architecture.

Opportunities & Solutions Identification
The Opportunities & Solutions Identification phase typically involves the following activities -

• Conducting initial implementation planning
• Identifying single or multiple delivery channels for the requisite architectures

Migration Planning
The Migration Planning phase addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.

Implementation Governance
The Implementation Governance phase involves providing an architectural oversight of the implementation.

Demystifying Enterprise Architecture with TOGAF

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. In TOGAF, "architecture" has two meanings depending upon the context:

• A formal description of a system, or a detailed plan of the system at component level to guide its implementation
• The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

Understanding Enterprise Architecture

The Definition of Enterprise

The term "enterprise" refers to any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

It is important to here note that the term "enterprise" in the context of "enterprise architecture" can be used to denote both [1] an entire enterprise as a collection encompassing all of its information and technology services, processes, and infrastructure — and [2] a specific domain within the enterprise. Nevertheless in both cases, the architecture crosses multiple systems and multiple functional groups within the enterprise.

Defining Enterprise Architecture

Enterprise architecture is a structural approach that optimizes the often fragmented organization wide processes (both manual and automated) into an integrated environment that is responsive to change and enables delivering the enterprise's business strategy.

Domains of Enterprise Architecture

There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support.

• Business Architecture
  The Business Architecture defines the business strategy, governance, organization, and key business processes.
  
  
• Data Architecture
  The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
  
  
• Application/Solution Architecture
  The Application or Solution Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
  
  
• Technology/Deployment Architecture
  The Technology or Deployment Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Understanding TOGAF

The Open Group Architecture Framework (TOGAF) provides the core methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

Illustrating the need for TOGAF

Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to de-mystify and de-risk the architecture development process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs.