Generic Interface Implementation (GII), Thomas Schneider / March 2007

1. Introduction

In this paper, I would like to show a way to configure object trees through xml files and not implemented interfaces. This way may be used to avoid interface implementing mock objects for testing or prototyping. Another usecase is to import/export data from databases through objects to xml files. The third usecase is to create value objects or transient objects without a line of code. Features:
  1. generic mock objects
  2. generic data exchange
  3. generic transient objects or value objects
  4. generic creation of mass data with xslt (use of multiplier.xsl)
A small library will be able to instantiate the object tree (like the dependency injection does with implementing classes in spring) against the pure interfaces, using dynamic proxies and bean mechanism with reflection.
There are 3 mechanisms to enhance dynamic implementations for java.
  1. reflection (jdk)
  2. bean name conventions (standard, spring)
  3. dynamic proxy (jdk, only for interfaces)
To implement tests or prototypes against services that are at the moment not available, it is common to create mock objects - simple dummy objects you are able to work with. They implement given interfaces in a simple manner.
Spring is a framework, that enables to instantiate object trees through inversion of control. It parses xml files configuring this tree. But you need real classes. Interfaces have to be implemented! Spring has an own xml tag schema including the bean instance definitions. I would prefer an xml tag schema defined by the beans itself.
Dynamic Proxies are objects, implementing given interfaces on runtime. But there is no solution to work with properties and actions. The proxy objects give you absolutly empty interface implementations.
But we have the bean property conventions. So, there is a way to get or set properties without implementing that. For mocking, you can enhance this idea, using method calls as properties, too. A method, with special arguments is a key, the returning element of the method is the value.
Working with plain old objects and inversion of control is the most independ way to implement applications. But if you use any services, there have to be interfaces to implement against. To simplify the work with mock objects, there should be a way to work with generic mock objects, created on runtime. Like in spring, this configuration of mock objects should be done by filling xml files. But this xml files should be real trees. Spring only fills a flat xml file with a list of beans, referencing each other. Xml files can define complex trees, beans containing beans containing beans a.s.o.! Of course You need to reference some beans twice or more, thats possible, too.
A possible and easy way to create bean instances from xml definition files is to use the bean type, the class name, as tag name. Each java bean property has a type, name and value. The easiest way to map a primitive java bean property is as xml tag property. Complex bean properties, not primitive types, having childs, should be child tags of the previous tag.

	
		
		
		...
		myTest2">mysimpleproperty2=myTest2
"/>
]]>
Here we need our first keyword: reference. If the reference gets more than one object, the property type has to be a collection. The bean classes will be found searching in the given packagepath.
The next step may be exchanging the real bean names with interface names (and, of course, their packagepaths.

	
		
		
		...
		
	

]]>
 getMysimpleproperty1();
	public void setMysimpleproperty1(Collection);
    Object actionAny(String arg1, SimpleTestInterface2 arg2);
interface myinterfacepackage1.MyInterface2 {
]]>
But how would you define method calls? The name of a method call could be "myAction(arg1,arg2)", the relating value for example of type MyInterfaceY. This should be a property of an xml tag, but this is not possible. We have to define the second keyword: The xml tag name "MethodCall".

	...
	
		
	
	...

]]>
The MethodCall should be a simple class of type java.util.Map, provided by the base library. With the described mechanisms, its possible to configure any java instance, using reflection and bean conventions. The xml file wil be read, the instances will be created through dynamic proxies. The invokationhandler of the proxy implements a generic mechanism to store and read bean properties and to call not implemented (interface-) methods, returning results, defined by the MethodCall-tag.
The implementation for this ideas is already done. Have a look at the tsl library (included in JArtifex) defining the following classes:

2. The usecase im-/exporting data from objects to xml

In times of SOA, a lot of applications communicate through given interfaces and data, stored in xml files. A lot of interfaces provide getters and setters to handle the data. Existing applications have to be extended to implement these interfaces and to wrap their data into this new object types or to get their data from this types. There is a way to do that in a automatic manner. The existing objects can be enhanced through proxies to implement this new interfaces. This proxies can work with bean mechanisms and handle some special constraints given by the existing application or framework. For example, there is data, that doesn't follow the bean mechanism.
The following list describes some constraints of an existing application: