Debasish Ghosh

A domain-specific language (DSL)1,3 bridges the semantic gap between business users and developers by encouraging better collaboration through shared vocabulary. The domain model the developers build uses the same terminologies as the business. The abstractions the DSL offers match the syntax and semantics of the problem domain. As a result, users can get involved in verifying business rules throughout the life cycle of the project.

Your success—and sanity—are closer at hand when you work at a higher level of abstraction, allowing your attention to be on the business problem rather than the details of the programming platform. Domain Specific Languages—"little languages" implemented on top of conventional programming languages—give you a way to do this because they model the domain of your business problem.

DSLs in Action introduces the concepts you'll need to build high-quality domain-specific languages. It… Show more

Your success—and sanity—are closer at hand when you work at a higher level of abstraction, allowing your attention to be on the business problem rather than the details of the programming platform. Domain Specific Languages—"little languages" implemented on top of conventional programming languages—give you a way to do this because they model the domain of your business problem.

DSLs in Action introduces the concepts you'll need to build high-quality domain-specific languages. It explores DSL implementation based on JVM languages like Java, Scala, Clojure, Ruby, and Groovy and contains fully explained code snippets that implement real-world DSL designs. For experienced developers, the book addresses the intricacies of DSL design without the pain of writing parsers by hand. Show less

Most of today's enterprise applications use a relational database management system as the underlying data store. This often creates an impedance mismatch between the application layer and the data layer, because most applications use object-oriented or functional languages. Storing data the same way it's used in the application would simplify the programming model, making it easier to decentralize data processing and, in turn, enable horizontal scaling. Emerging NoSQL data-storage engines… Show more

Most of today's enterprise applications use a relational database management system as the underlying data store. This often creates an impedance mismatch between the application layer and the data layer, because most applications use object-oriented or functional languages. Storing data the same way it's used in the application would simplify the programming model, making it easier to decentralize data processing and, in turn, enable horizontal scaling. Emerging NoSQL data-storage engines support this strategy. Just like the application layer, the data-storage layer can use multiple paradigms and store data in a way that's semantically closer to the corresponding domain models. This article discusses a strategy for using multiparadigm data storage within a single application. It includes an architecture for keeping multiple data stores in sync by using a messaging system that asynchronously pushes updates between data stores, achieving eventual consistency. Show less

Today, there's significant interest in functional languages and frameworks that fit the Web better than imperative languages. We explore Scala, an OO-functional language on the Java virtual machine, and Lift, a framework implemented on Scala's functional features. The Scala language offers functional programming features and asynchronous message-passing concurrency alongside a statically typed model. Lift exploits this model to offer secure, higher-level abstractions to Web developers.

In Enterprise Reporting, we build a report template and reuse the template with different sets of data and parameters for rendering to different reports. While working for a product initiative towards catering to reporting solution space, we have designed and implemented a scheme for management of passing set of parameters to the report processing during rendering from same report template. For rendering a report with different set of parameters, we use an efficient algorithm to generate the… Show more

In Enterprise Reporting, we build a report template and reuse the template with different sets of data and parameters for rendering to different reports. While working for a product initiative towards catering to reporting solution space, we have designed and implemented a scheme for management of passing set of parameters to the report processing during rendering from same report template. For rendering a report with different set of parameters, we use an efficient algorithm to generate the ordered combination of parameters taken from a disjoint set of parameters. While the rendering is in progress, in case the process is abandoned suddenly, the process can restart the dynamic rendering process from the rest of the parameter tuples by using cached storage. In this paper, we discuss about the scenario, the algorithm, its computational complexity, implementation aspects and the benefits. Show less

AOP has recently been in the midst of controversies with Gavin King snubbing it as a totally over hyped, failed technology and Cedric Beust also expressing serious doubts regarding aspects making it to mainstream programming, branding AOP as a great idea that will remain the privilege of a few expert developers. This article does not try to create a fan syndrome of Aspect Oriented Programming (AOP) - it describes how this technology has delivered barrels of good to a real-life Java EE project… Show more

AOP has recently been in the midst of controversies with Gavin King snubbing it as a totally over hyped, failed technology and Cedric Beust also expressing serious doubts regarding aspects making it to mainstream programming, branding AOP as a great idea that will remain the privilege of a few expert developers. This article does not try to create a fan syndrome of Aspect Oriented Programming (AOP) - it describes how this technology has delivered barrels of good to a real-life Java EE project with a large financial organization in addressing some of the critical cross cutting concerns as last minute changes in project requirements. The scenarios described and the solutions implemented nicely portray how AOP complements OOP in addressing orthogonal concerns of modeling a business application. Show less

Java EE applications which use relational database for data persistence often face an impedance mismatch between the
object-oriented paradigm implementing business logic and the procedural SQL used for modeling database queries. In spite of all OO concepts implemented at the business layer, SQL queries
are still found buried within string constants or prepared
dynamically at runtime using type-less constructs. This paper identifies the problem of type-unsafety associated with this… Show more

Java EE applications which use relational database for data persistence often face an impedance mismatch between the
object-oriented paradigm implementing business logic and the procedural SQL used for modeling database queries. In spite of all OO concepts implemented at the business layer, SQL queries
are still found buried within string constants or prepared
dynamically at runtime using type-less constructs. This paper identifies the problem of type-unsafety associated with this approach and suggests a solution to make relational database query more typed. Instead of database queries being embedded within type-less structures, the paper suggests an implementation framework which constructs typed Data Accessor Objects (DAOs) for providing database query services. Typed DAOs can be organized in an hierarchy corresponding to all persistable entities of the application and provide a uniform query interface to all
clients. The paper also explores the idea of compounding the DAO pattern with the Value Object (VO) pattern of Java EE applications to provide a more flexible model of the business tier of the application. Show less

All object oriented programming languages offer various degrees of support for generic programming. C++ offers parametric polymorphism through templates [12], Eiffel [11] offers
parameterized classes, Haskell and ML also offers some form of parametric polymorphism. Till JDK 1.5 (beta), Java had no direct support for parameterized types – the user had to depend on
the “generic idiom” [1], where variable types were replaced by their typed upper bounds (typically Object) to provide the… Show more

All object oriented programming languages offer various degrees of support for generic programming. C++ offers parametric polymorphism through templates [12], Eiffel [11] offers
parameterized classes, Haskell and ML also offers some form of parametric polymorphism. Till JDK 1.5 (beta), Java had no direct support for parameterized types – the user had to depend on
the “generic idiom” [1], where variable types were replaced by their typed upper bounds (typically Object) to provide the façade of genericity, while introducing casts in referring to the specific uses of these types. The collection classes introduced in JDK 1.2, the Observer pattern implementation of JDK 1.1, all provided enough emphasis on the aspects of fostering genericity in the programming model, although direct language support was missing.
Come JDK 1.5 – we have the Java Generics, supposed to make type-safe container based programming a reality to the programmers. This paper tries to analyze the implementation of the Java Generics and its comparison with the templates of C++. In C++, templates provide one of
the vehicles of generic programming – class templates provide support for type-safe generic containers, while standalone function templates represent generic algorithms. Hence templates in
C++ are not strictly tied to the object oriented model – in fact, C++ templates go a long way in enriching the multi-paradigm design philosophy. Show less

Object oriented software systems that utilize relational databases for data-store have to deal with the problem of interfacing to the relational data. This aspect of the software is more relevant to the solution domain rather than the problem domain i.e., the business requirements of an application do not dictate that there be a mechanism that allows the application to store and retrieve relational data. Hence, de-coupling the application from the database and its interface is relevant from the… Show more

Object oriented software systems that utilize relational databases for data-store have to deal with the problem of interfacing to the relational data. This aspect of the software is more relevant to the solution domain rather than the problem domain i.e., the business requirements of an application do not dictate that there be a mechanism that allows the application to store and retrieve relational data. Hence, de-coupling the application from the database and its interface is relevant from the perspective of portability that of the application to other kinds of databases. For example, it is conceivable the application may be required to work with relational databases from different vendors. This article shows an adaptation of the Factory Method Pattern and the Abstract Factory Pattern [1] as a generic solution to the problem of de-coupling application code from the underlying database and its associated interface mechanisms. Show less