Archive for January, 2009

An RPC Framework is on its way!

Monday, January 19th, 2009

I have started working on an RPC* Framework for PHP5, 6 months ago and been developing it in my spare times. In fact, although I haven’t published it, I had tested first beta version of it about 3 months ago on a web site and it amazingly worked well!

Since then I haven’t been able to continue working on it due to my business in other areas.

Nowadays, I have started looking at it again and would like to underline that it is going to be ready soon.
The basic idea is to provide a flexible framework that enables the web developers to call server sided and parameterized PHP5 procedures and retrieve the result of these to the client side. Moreover, all these tasks will be done asynchronously.

It will be open source and hopefully will be developed in a community. (The only member in the community is me at the moment, though.) Although it looks relatively simple, there are many things to deal with.

Once it is done, a project page will be created and announced here. Moreover, I am also intending to demonstrate it at Bilkent University; it could be an open workshop. I will announce the date/location info. for that if I can organize.

* RPC stands for Remote Procedure Call

Refactoring: Sync. to Async. (An Object Oriented Approach)

Sunday, January 4th, 2009

Let’s get back to the refactoring : sync to async problem. If you don’t know the scenario, then you will probably want to read this article first.

The purpose of this article is to prove that classical object oriented techniques would also be sufficient for solving this particular problem.

In fact, some people have been talking about AOP as if it is a total revolution and it provides radical solutions for the problems that have never been resolved before!

I am personally against those kind of ideas and believe that the main idea behind AOP is not to derive solutions to problems we haven’t been able to solve so far. I believe the idea is to improve the solutions to the problems we have dealed with.

Let’s step back to the example in previous article and solve the problem using object oriented techniques.

To do that, we are going to use the “Decorator” design pattern. However, for this approach to become a valid one, the class we are going to decorate should have been created in such a way that it is based on some carefully designed abstractions and coded on to an interface, not an implementation!

If you look through the code, you may notice that the class Foo is coded on top of an implementation rather than an interface.

In fact, it is this way; because my intention was just to introduce the problem and indicate how AOP could become a solution for that. Most of the time, a good programmer would depend on abstractions and program on top of interfaces, rather than implementations!

Hence, please assume that Foo implements IFoo and IFoo simply consists of the same methods as we have in Foo. Moreover, assume that all the other types depend on IFoo instead of Foo.

Caution: Notice that we are making the design in “the other way around”, this is not a good design practice! We should have identified the interface before and implementation later, however, I am trying to fit one problem that is subject for one particular article to another article, this was not my intention, hence there should be no problem at all, for this specific case.

By using Decorator pattern, we will decorate instances of Foo in such a way that they will represent an “asynchronous” behaviour rather than a “synchronous” one. AsynchronousFoo class will decorate Foo and simply delegate calls to an instance of Foo, but in an asynchronous way.

package ali.test;

public interface IFoo {

public void performFirstTask() throws InterruptedException;

public void performSecondTask() throws InterruptedException;

}

package ali.test;

public class Foo implements IFoo {

public Foo()

{

}

public void performFirstTask() throws InterruptedException

{

Thread.sleep(3000);

System.out.println(“Foo : the first complex task has been completed…”);

}

public void performSecondTask() throws InterruptedException

{

Thread.sleep(3000);

System.out.println(“Foo : the second complex task has been completed…”);

}

}

package ali.test;

public class AsynchronizedFoo implements IFoo {

private Foo foo;

public AsynchronizedFoo(Foo f)

{

this.foo = f;

}

@Override

public void performFirstTask() throws InterruptedException {

// TODO Auto-generated method stub

Thread t = new Thread()

{

public void run()

{

try {

foo.performFirstTask();

} catch (InterruptedException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

};

t.start();

}

@Override

public void performSecondTask() throws InterruptedException {

// TODO Auto-generated method stub

Thread t = new Thread()

{

public void run()

{

try {

foo.performSecondTask();

} catch (InterruptedException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

};

t.start();

}

}

import ali.test.AsynchronizedFoo;

import ali.test.Foo;

import ali.test.IFoo;

public class Program {

public static void main(String[] args) throws InterruptedException

{

System.out.println(“Foo obj. will complete a complex task.”);

IFoo f = new AsynchronizedFoo(new Foo());

f.performFirstTask();

f.performSecondTask();

System.out.println(“end of sequence”);

}

}

Now that we have resolved this issue in two different ways; using an object oriented approach and an aspect oriented approach, you can select and use one of them, depending on the conditions.

Refactoring: Sync. to Async.

Saturday, January 3rd, 2009

Suppose that we are given a class Foo that contains some expensive methods; they make some complex operations and these operations take much time.

Sometimes, that kind of methods might be too slow for being left single-threaded.

For instance, assume you have a GUI view and when user clicks a button in the interface, one of these methods are called.

If you had faced with this type of issues before, you would immediately tell that GUI window is going to freeze and remain nonfunctional until the method call is completed.

Let’s illustrate this scenario with an example.

(I am not going to include a GUI for that, this is left as practice. )

package ali.test;

public class Foo {

public Foo()
{
}

public void performFirstTask() throws InterruptedException
{
Thread.sleep(3000);
System.out.println(“Foo : the first complex task has been completed…”);
}

public void performSecondTask() throws InterruptedException
{
Thread.sleep(3000);
System.out.println(“Foo : the second complex task has been completed…”);
}

}
public static void main(String[] args) throws InterruptedException
{
System.out.println(“Foo obj. will complete a complex task.”);
Foo f = new Foo();
f.performFirstTask();
f.performSecondTask();
System.out.println(“end of sequence”);

}

The output would be

Foo obj. will complete a complex task.
Foo : the first complex task has been completed…
Foo : the second complex task has been completed…
end of sequence

If, as the developer, you are allowed to modify Foo, then no problem, you can simply add Threading support to it. If you were not allowed to do that, what would you do ?

The solution is amazingly simple with AOP.

package ali.test;

public aspect FooThreadingAspect {

pointcut FooThreadingOperations() : call(void Foo.*());

void around() : FooThreadingOperations()
{
Thread t = new Thread()
{
public void run()
{
proceed();
}
};

t.start();
}

}

That’s it, we’re done! Now, each method in class Foo is working asynchronously; making output

Foo obj. will complete a complex task.
end of sequence
Foo : the first complex task has been completed…
Foo : the second complex task has been completed…

However, be careful using this technique. Add an annotation to class Foo or its methods and clearly indicate that the methods are working asynchronously. If you are not allowed to do that, you can still use AOP to declare warnings.

If you skip these details, this technique has potential to become very dangerous.

Using AOP to Retrieve Spring Beans

Saturday, January 3rd, 2009

In order to perform IoC with Spring, the programmer(s) should use a spring factory object to access each bean (might be defined in an XML file) when the beans are required.

This process might cause some problems in many ways and some of them are:

– The programmers who need to access an instance of a bean must be aware of the name of the bean that is specified in the XML file.

– Each time a programmer retrieves a bean, a casting to the requested type must be made.

* Although these two issues might be resolved by using one of the factory patterns, this type of solution would simply contradict with the use of Spring Framework and IoC for that case.

– A constructor call can still be made to one of these beans’ classes. This is problematic when we are dealing with singleton beans – which is most likely to be the case when we need Spring and IoC.

Using AOP, we can simply deal with those kind of problems. Although it would be wiser to use Spring Framework for wiring, I will demonstrate it using AspectJ.

package ali.test;

public class Foo {

private String bar;

public void setBar(String bar)
{
this.bar = bar;
}

public String getBar()
{
return bar;
}
}

We need to have a spring factory type.

package ali.test;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SpringFactory {

private ApplicationContext context = null;
public SpringFactory()
{
init();
}
private void init()
{
context = new ClassPathXmlApplicationContext(“/applicationContext.xml”);
}

public Object getBean(String name)
{
return context.getBean(name);
}
}

And let applicationContext.xml file be

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop”
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd”>

<bean id=”foo” class=”ali.test.Foo” scope=”singleton”>
<property name=”bar” value=”hello!”/>
</bean>

</beans>

So far so good. Now, we are adding our FooCreationAspect that will grab the instance of requested bean using Spring Factory in each call.

package ali.test;

public aspect FooCreationAspect {

private SpringFactory fac;

public FooCreationAspect()
{
fac = new SpringFactory();
}

pointcut fooCreationViaConstructor() : call(Foo.new(..));

Foo around() : fooCreationViaConstructor()
{
Foo f = (Foo)fac.getBean(“foo”);
return f;
}
}

Simple as that. A few tests are to be made:

public static void main(String[] args)
{
Foo f = new Foo();

System.out.println(f.getBar());

f.setBar(“bar2”);

Foo f2 = new Foo();

System.out.println(f2.getBar());
}

The output is :

hello!

bar2

Simply illustrates that the same bean is returned as f2, even if we make a separate constructor call.

Notice that one should be be careful using this technique. If some some complex tasks need to be completed at each execution of the constructor, perhaps the use of this technique needs some second considerations. However, usually (and ideally!) bean objects don’t perform any complex operations and this technique would work well frequently.

Moreover, you may also want to annotate the constructor to make developers aware of the fact that the type is singleton.