You should be able to use a GCF such as Spread to do this across different technologies/languages. Anyway, implementing a membership service which can work with say Tribes, in .Net or any other language is trivial since that only needs to interpret the membership management TCP & multicast messages that are received.
Azeez On Fri, Jun 13, 2008 at 8:40 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Of course, we may have .Net nodes in this application domain. However, the >> group communications protocol at the .Net cluster and that used by Synapse >> need to be interoperable since the load balancer discovers the application >> members using the group communication service. > > > Azeez is this even possibe? > I am not aware of any group communication toolkit that has multiple > language support. > Even if one exists, then both the .NET cluster and axis2 has to implement > it. > The probability of that is very very low. > > However a more high level group communication protocol that uses SOAP may > do the trick. > It could use something like WS-Eventing to broadcast a health status every > x time interval. > The message will include current CPU/Memory and/or other system > information. > This does not assume any Axis2 group communication support and Synapse will > have full control of this. > > Since this works at the SOAP layer this can be used to manage a > heterogenous cluster. > I am not familliar with WSDM etc.. but worth looking into as they might > already have provisions for this. > > Just a wild idea that crossed my mind. > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > >> >> Azeez >> >> >> >> On Thu, Jun 12, 2008 at 5:44 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> >>> I guess what I mean is - suppose its not Axis2 that is being load >>> balanced. Can we make a plug-point/API where Synapse gets information >>> on the status of the cluster. Then we could also load-balance a .NET >>> cluster by writing a plug-in that provides that information. >>> >>> So rather than configuring this in the axis2.xml, we could have a >>> parameter in the Synapse config: >>> >>> <endpoint> >>> <intelligentLoadbalance >>> helper="org.apache.axis2.cluster.LoadBalanceInformationHelper"/> >>> </endpoint> >>> >>> or >>> >>> <endpoint> >>> <intelligentLoadbalance >>> >>> helper="org.apache.synapse.extensions.dotNetLoadBalanceInformationHelper"/> >>> </endpoint> >>> >>> Paul >>> On Thu, Jun 12, 2008 at 4:52 AM, Afkham Azeez <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <[EMAIL PROTECTED]> >>> wrote: >>> >> >>> >> Azeez >>> >> >>> >> First thoughts are this is *very* cool. >>> >> >>> >> My second thought is that its a little too "hard coded". It would be >>> >> nice to allow plugging in different group/cluster discovery >>> >> mechanisms. >>> > >>> > Can you further elaborate on what you meant by the group discovery >>> > mechanism being hard-coded? The underlying Axis2 based clustering >>> > implementation now supports dynamic, static & well-known address >>> (hybrid) >>> > group discovery, this will be automatically available. See >>> > http://afkham.org/2008/05/group-membership-management-schemes.html. >>> Also, >>> > the we can plug-in a different implementation based on a different >>> group >>> > communication framework. >>> > >>> > Azeez >>> > >>> > >>> >> >>> >> Paul >>> >> >>> >> On Wed, Jun 11, 2008 at 12:47 PM, Afkham Azeez <[EMAIL PROTECTED]> >>> wrote: >>> >> > Hi Folks, >>> >> > There are some limitations in the current load balancer. e.g. if we >>> have >>> >> > 2 >>> >> > identical services in 2 different worker nodes, which are fronted by >>> a >>> >> > synapse load balancer instance. In such a case, we need to provide 4 >>> >> > endpoints in the synapse.xml file. As can be seen, this is not a >>> very >>> >> > scalable solution. Hence, I'm implementing an Intelligent load >>> balancing >>> >> > mechanism where the application members are discovered at runtime, >>> and >>> >> > the >>> >> > endpoint do not need to be statically specified in the synapse.xml >>> file. >>> >> > So >>> >> > the synapse.xml file will simply look like this: >>> >> > >>> >> > <definitions xmlns="http://ws.apache.org/ns/synapse";> >>> >> > <sequence name="main" onError="errorHandler"> >>> >> > <in> >>> >> > <send> >>> >> > <endpoint> >>> >> > <intelligentLoadbalance/> >>> >> > </endpoint> >>> >> > </send> >>> >> > <drop/> >>> >> > </in> >>> >> > <out> >>> >> > <send/> >>> >> > </out> >>> >> > </sequence> >>> >> > >>> >> > <sequence name="errorHandler"> >>> >> > <makefault> >>> >> > <code value="tns:Receiver" >>> >> > xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/> >>> >> > <reason value="COULDN'T SEND THE MESSAGE TO THE >>> SERVER."/> >>> >> > </makefault> >>> >> > <header name="To" action="remove"/> >>> >> > <property name="RESPONSE" value="true"/> >>> >> > <send/> >>> >> > </sequence> >>> >> > </definitions> >>> >> > >>> >> > Currently, the application endpoints are calculated by replacing the >>> IP >>> >> > and >>> >> > port of the incoming request with that of the member to which this >>> >> > request >>> >> > will be forwarded to. I have only tested with HTTP/S for the moment. >>> >> > More >>> >> > details about the design can be found here: >>> >> > >>> http://afkham.org/2008/06/fault-resilient-dynamic-load-balancing.html >>> >> > >>> >> > Please provide your valuable feedback on this approach. >>> >> > >>> >> > -- >>> >> > Thanks >>> >> > Afkham Azeez >>> >> > >>> >> > http://afkham.org >>> >> > http://www.wso2.org >>> >> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >>> >> >>> >> >>> >> >>> >> -- >>> >> Paul Fremantle >>> >> Co-Founder and CTO, WSO2 >>> >> Apache Synapse PMC Chair >>> >> OASIS WS-RX TC Co-chair >>> >> >>> >> blog: http://pzf.fremantle.org >>> >> [EMAIL PROTECTED] >>> >> >>> >> "Oxygenating the Web Service Platform", www.wso2.com >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> >> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >>> > >>> > >>> > >>> > -- >>> > Thanks >>> > Afkham Azeez >>> > >>> > http://afkham.org >>> > http://www.wso2.org >>> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >>> >>> >>> >>> -- >>> Paul Fremantle >>> Co-Founder and CTO, WSO2 >>> Apache Synapse PMC Chair >>> OASIS WS-RX TC Co-chair >>> >>> blog: http://pzf.fremantle.org >>> [EMAIL PROTECTED] >>> >>> "Oxygenating the Web Service Platform", www.wso2.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> Thanks >> Afkham Azeez >> >> http://afkham.org >> http://www.wso2.org >> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >> > > > -- Thanks Afkham Azeez http://afkham.org http://www.wso2.org GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
