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