axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: [axis2] Clustering impl using tribes
Date Tue, 24 Oct 2006 02:41:52 GMT
Hi David,

I understand that if we were were trying to put some code that is dependent
on a particular clustering implementation into Axis2, we need to hide that
code. But the situation here is a bit different.

What we introduced was a ClusterManager interface. This will live within
Axis2. Now should the rest of the Axia2 code be completely unaware of this
interface. I think it should not.

In this particular scenario i'm talking about some method of Axis2 Context
classes which can be called for serializing their states (sorry abt calling
it 'replicate' may be we should simply call it 'serializeState'). If
somebody have configured Axis2 to enable clustering and if somebody have
mentioned an ClusterManager implementation in the axis2.xml. Some methods of
it will be also called.

I think introducing a factory to create Contexts will introduce an
unnecessary complexity. Still there may be many other places where we may
directly have to call the methods of the ClusterManager interface.

Chamikara



On 10/23/06, David Illsley <davidillsley@gmail.com> wrote:
>
> Moving to a factory creation style which allows the base Axis2
> implementations to not contain any clustering code sounds simplest and
> most attractive to me.
>
> David
>
> On 21/10/06, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
> > Hi Rajith,
> >
> > Please see my comments below.
> >
> > On 10/20/06, Rajith Attapattu <rajith77@gmail.com> wrote:
> > > Deepal,
> > >
> > > Thanks for your answers, I really appreciate it.
> > >
> > > >There is an id associate with ServiceGroupContext , so once you have
> SGC
> > > >from the you can get the service context . Then the id of the SC will
> be
> > > >the name of the corresponding AxisService.
> > > That is what I did so far, but service name is not a unique id.
> > > However can a service by the same name can exist in a diffrent service
> > group ???
> > >
> > > For now I use service group id + service name as a unique key.
> > >
> > > >>How big is the jar ?
> > > Deepal we should not have dependency on tribes as our clustering
> > implementation. So even if it's a samll jar we should decouple the
> > clustering impl from the kernal.
> > > Sanjiva also has an idea of using Richochet in the future, so we
> should be
> > able to implement that without doing too much work.
> > >
> > > >What do you mean by all over th place , as I know all of them are
> > > > created inside instance dispatcher.
> > >
> > >
> > > Sorry if I didn't explain the point properly.
> > >
> > > For example ServiceContext is created inside the getServiceContext()
> > method in the ServiceGroupContext class
> > > then ServiceGroupContext is created inside ConfigurationContext in the
> > method fillServiceContextAndServiceGroupContext ()
> > >
> > > What I really wanted to highlight was, not where the places we do a
> new
> > XXXContext(), but rather if we wanted to control the creation through a
> > factory class then all we have to do is to change it there. Now we have
> to
> > track down all the places we do new XXXContext() if want to control the
> > creation and we can't avoid to create new type of context, for example
> > ReplicatedServiceContext without introducing a dependency.
> > >
> > > What I would have liked to see is ( if possible) to hide the creation
> of
> > the context behind a Factory class, so that during creation we could
> serve a
> > Replicated context instead of a normal context transparently to the
> code.
> >
> >
> > There is another way. We can introduce a 'replicate' method to the
> > AbstractContext. Each  context can override this and have its own
> > replication logic. A a parent 'replicate' method may recursively call it
> for
> > all the childs. So even if we want to replicate the whole context
> hierarchy
> > it will be simple as calling this method from the ConfigurationContext
> > instance (we may not want to do that always).
> >  BTW is it possible for you to commit the code to some place (scratch?)
> so
> > that we can see what areas we can help on.
> >
> > Chamikara
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message