axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <davidills...@gmail.com>
Subject Re: [axis2] Clustering impl using tribes
Date Tue, 24 Oct 2006 07:44:00 GMT
OK, I wasn't fully up to speed on the new ClusterManager interface.
You make a good point... though if someone were to do the Factory work
I'd still be +1 :-)

Oh, where is the ClusterManager interface so I can have a better look at it?
Thanks,
David

On 24/10/06, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
> 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
> >
> >
>
>


-- 
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