Browse Prior Art Database

Avoid code duplication in building multi-version web service through common object mapping

IP.com Disclosure Number: IPCOM000234961D
Publication Date: 2014-Feb-19
Document File: 2 page(s) / 412K

Publishing Venue

The IP.com Prior Art Database

Related People

Mayakrishnan Chakkarapani: AUTHOR [+2]

Related Documents

148076: IP.COM

Abstract

Developing and managing multiple versions of a web service that returns structured data is hard. Developers have to duplicate code in the business layer and also in the web layer in transforming database domain objects into say V1 or V2 specific schema objects. Web layer code duplication can easily be avoided by transforming database domain objects to common value objects (CVO) followed by a bean mapping from CVO to versioned schema objects at the run-time with no code.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Avoid code duplication in building multi-version web service

through common object mapping

Abstract

Developing and managing multiple versions of a web service that returns structured data is hard. Developers have to duplicate code in the business layer and also in the web layer in transforming database domain objects into say V1 or V2 specific schema objects.

Web layer code duplication can easily be avoided by transforming database domain objects to common value objects (CVO) followed by a bean mapping from CVO to versioned schema objects at the run-time with no code.

Detailed Description

Our idea is to specifically solve for code duplication in the web layer. We can define common value objects that encompass all active-versioned database domain objects and their associated fields. Then we can use Bean-Bean mapping libraries (no coding but minimal xml configuration may be required) to map the common value objects (CVO) to version-specific schema objects which adhere to the contract (WADL/WDSL) at the run-time. Bean to bean mapping will work with no code because class names and field names are same between CVO and version-specific schema objects. Only package names may be different.

Here's the high level workflow of proposed solution:


1. A user Foo calls the V1 method called getFoo as part of Rest service API.


2. The getFoo method then calls the web layer, which in-turn calls DAO to get the respective collection of database objects.


3. In the web layer, the Object Transformation facade converts database objects to Common value objects (CVO) (CVO will contain all fields of class from V1 and V2 version of schema objects). Some Custom Business logic may be needed to...