Hi All,
The storage interface is really a thing that I look forward for having.
But how I see it (thanks to Dasarath who mentioned the original idea)
this Storage interface should be coupled with store / retrieve
methods in the engine (or such a central component)
Then we can have any kind of Storage implementation associated with an
instance of the engine and expect it to behave accordingly. The correct
storage instance can be kept in the engine conetext. have a look at the
code I am proposing.
class engine{
// Lot of methods here....
public Object store(Object obj) {
return this.getEngineContext().getStorage().put(obj);
}
public Objectstore(Object key) {
return this.getEngineContext().getStorage().get(key);
}
}
in this case the user (probably the handlers) need not think of the
underlying storage mechanism. Which implementation of the storage to
use will be in the server.xml. Hence high end servers can have more
robust storages (say a jdbcStorage) and low end ones can have simpler
ones (like the fileStorage).
Serializing the contexts is a different matter. They can
use the store and retrieve facilities if they want to but I will prefer
them to have a standard serialization since the contexts are part of
the systems run time environment. IMHO this storage thing is a facility
provided by Axis and does not come directly under the axis runtime
environment.
thoughts ??
--
Ajith Ranabahu
- Re: [Axis 2] Storage Mechanism for Axis 2 Ajith Ranabahu
- RE: [Axis2] Storage Mechanism for Axis 2 Jaliya Ekanayake
