Let us start with a declarative world

#r = f1(a1,a2,a3)
request.f1.classname=class1
request.f1.a1=xyz

#r = f2(a1,a2,a3)
request.f2.classname=class1
request.f2.a1=xyz

#r = f3(a1,a2,a3)
request.f3.classname=class2
request.f3.a1=xyz

Why declarative?

1. Evolve better for new functionality
2. Backward compatibility
2. Variations in data sources
3. Interception or aspect oriented services
4. better connection management
5. better control of object life
6. Compilation not needed
7. Easier to script
8. Making the programming intent clear

Why not declrative?

1. Not good for lower granularity
2. Difficult to discover types
3. Difficult to discover apis
4. Difficult to use in a multi-developer environment with out tools
5. Additional configuration files to maintain
6. Lookup cost

Let us see how we can solve the discoverability

Construct a typed module and redirect the calls

public class Mod1
{
	R f1(A2 a2, A3 a3)
	{
		return somehow_invoke("request.f1", vector(a2,a3));
	}
	
	R f2(A2 a2, A3 a3)
	{
		return somehow_invoke("request.f2", vector(a2,a3));
	}
	
	R f3(A2 a2, A3 a3)
	{
		return somehow_invoke("request.f3", vector(a2,a3));
	}
}

Use the typed module

public class System
{
	Mod1 mod1 = new Mod1();
}

R r = System.mod1.f1(a2,a3);
R r = System.mod1.f2(a2,a3);

Benefits

1. You can auto generate the modules
2. Fully typed
3. IDEs to discover
4. Java docs to help out
5. Keeps the benefits of declarativity intact

References

1. General Introduction to other Server side Patterns in this series

2. OSCON 2004 Summary page for Server side patterns session