[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] multiple service call
|
HI Abhisek,
abhisek saikia wrote:
Hi Scott
Thanks a lot for your response.Actually my load balancer needs to
handle the following 2 queries
Query1:: consumer needs to make service calls to all the provider
and get the result and combine it.
Query2:: consumer needs to make service call in round robin fashion
Following is one of my abstract ideas
1)i have a cluster service run by jgroup which has info about node
type and its state(alive or not).
2)consumer can ask the cluster for list of alive provider nodes
3)for Query1 ,get the alive provider nodes and make service call using
ECF generic
4)for Query2,get any one alive provider node based on round robin and
make service call using ECF generic
Could you please suggest whether i can go ahead with this approach
using ECF generic.
This certainly could be done. If I understand you correctly, it might
require some significant work...i.e. to deal with issues of timing/fail
over/availability, etc., but it could be done...with the ECF generic
provider. I don't think I will be personally able to help out with the
implementation of such a thing over the next few months, but I
would/will do as much as I practically can to help support it if you go
this direction, given my own work needs/resources (e.g. if
fixes/enhancements are needed to ECF generic provider or remote services
infrastructure in general).
Whether i need to do some changes to make ECF generic fit into this
approach.Or do you suggest to go ahead with JMS.
I would say the 'correct' decision here does depend upon your
environment, requirements, and resources. If you have requirements
(e.g. for environment, integration, etc) that dictate using
javagroups/multicast IP over (e.g.) ActiveMQ...or some other JMS impl,
then obviously those requirements would dictate such choices. The
javagroups provider has not been as heavily used to this point as some
of the other providers...but ECF committer Pierre Henry Perret has used
it some himself, and probably can provide the best support for it's
usage in more significant use contexts...but I can't speak directly to
Pierre's availability or willingness to provide such support (especially
for free). Further, the javagroups provider is currently based on a
relatively old version of javagroups. I *think* making based on a more
recent version would not be a big deal technically, but I can't
guarantee either I or Pierre will have the resources to do this in the
near future without some external support to do so...e.g. direct
support/contracting with Pierre/myself or both to make this happen.
So, in short I think that either strategy would be workable...and which
one makes sense really does depend, I think, on your target deployment
environment, requirements, and resources. I don't really see any
technical blockers in either direction...and would be happy to see
either approach actually instantiated for you/your target
users/customer's benefit. But I would encourage you to think carefully
about the your own requirements and resources, in order to choose
between the approaches.
Thanks,
Scott