RestEasy 3.0.x implementation with your existing servlet based web application

Web.xml entry:


Your REST class:



public class UserREST {

	public String doGet(@QueryParam("userId") String userId, @HeaderParam("authorization") String sessionToValidate)
			throws Exception {
			return "SomeString";

Minimum jar files needed from jboss resteasy 3.0.19 bundle:


And call : http(s)://yourhost:port/yourapplication/rest/Users/getUserById?userId=xx
You may choose to pass your own authorization in header, use Postman, but you can ignore it also.

No Bluff Just Stuff – Role Of A Software Architect

Had an opportunity to under go in a three days technical sessions at NFJS. Initially it was mix feeling about sessions and speakers but when it was started I was kind of stuck with most sessions of three speakers. Neal, Kirk and Mark. I wish i could clone myself and attend other sessions too.  Mostly it was Mark who helped to understand what an architect should be  and architect’s do’s and don’ts. I am pointing out some very brief of one of the sessions from Mark.

An architect must have knowledge of all current trends of technology, industry and market of the company for which he is going to design system.

He should ensure that architecture design is followed by doing regular compliance check meeting.

He should have very good interpersonal skill. He should easily and without any resistance convey his things to other developers and product owner.

He should know 3 C – Communication with stakeholders, Collaboration with teams and most important Clarity on each element.

He may decide technologies to be used in any project but that is not an architectural decision.

He should have breadth of technology, its OK if he is not expert(depth of technology). One can become good architect if he has good brief knowledge of variety of technologies.

No RDD(Resume Driven Design)

He should not try to design solution of all the problems. Doing that will lead to failures mostly.

Memory Based Architecture For Enterprise Application – Introduction

We had this architecture discussion in one of the technical meetings in company recently and I was assigned to share all details on Memory Based Architecture. Sharing details from those sessions.

Memory, changing philosophy with enterprise applications and  Memory Based Architecture:

The main memory is high bandwidth and low latency component that can match performance of the processor in the computer. The bandwidth of main memory is around few GB per second as oppose to disk which is around hundred MB per second. The latency of main memory is in nanoseconds range where as that of disk is in milliseconds range. Traditionally main memory was considered as expensive resource and therefore it was scarcely used. However this perception that RAM is expensive component is now changing due to sharp drop in prices over past several years. Same time enterprise applications require more scalable and performance oriented use of those each chunk of available physical memory. Today they have enormous amount of such main memory cheaply available. Many applications are using memory in Gigabytes and Terabytes. The main memory empowers application architectures to achieve linear scalability and high performance. These qualities are extremely important to the modern enterprise applications for delivering guaranteed high performance under intensive and unpredictable workload.

As enterprises are using more memory, software vendors have flooded the market with several types of memory based products in order to size this new business opportunity. These products are targeted towards supporting various business use cases and architectural scenarios. This series is intended to introduce various memory based product categories along with business uses and architectural scenarios supported by them. 

When we think of any memory based products then high performance is the first thing that comes to our mind. Yes, high performance is primary reason why memory based products are used, but it is not the ‘only reason’. Many a times they are deployed to reduce IO operations over network or address the high latency issues with disk based products like databases. Typically with N Tier Architecture, properly design application code can easily scale out by adding more application servers. However the main scalability barrier is disk based database which is centrally access by all the clustered application servers. Here memory based products are typically deployed to overcome scalability bottleneck pose by disk based database and make application servers more scalable. Thus following can be considered as primary scenarios for any memory based product.

– Improve application performance
– Reduce network & disk IO Operations
– Overcome scalability barriers & make application servers more scalable.

The memory based products can be broadly classified as Caching(Standalone & Distributed Caching), In Memory Data Grid (IMDG), Main Memory Database (MMDB) and Application Platforms that enables Space Based Architecture and covered in great details under this series.