Always available web services are WS that do not have a single point of failure.  This includes the loadbalancer, database, and even the data center.

Grouper is conducive to always available web services.

Grouper allows readonly database replication to an off site database, with a Grouper WS application server which runs in readonly mode against that database (set readonly in the grouper.properties of the WS application).  Then the GrouperClient is a reference implementation showing how clients could interact with the multiple WS servers. Note that there might not be immediate consistency between the read/write and readonly depending on how the database replication is implemented.

If you want highly available web services (though not always available), then you could use a DNS-based loadbalancer that polls the servers to see which ones are available.  Though there could be a minute or two of downtime here or there until the loadbalancer catches up.  This does not require a special client.

Note that you could do local active/active load balancing but you might have a point of failure on the load balancer, firewall, or data center itself.  This also does not require a special client.  Note, this is just one way to do it, there are other ways to improve availability as well...




Logging

If you set the client to debug mode (--debug=true), or in log4j (if you are using the client as a library in an application or you include the log4j jar), log for these packages to debug

log4j.logger.edu.internet2.middleware.grouperClient.ws.GrouperClientWs = DEBUG
log4j.logger.edu.internet2.middleware.grouperClient.util.GrouperClientLdapUtils = DEBU


See Also

Grouper Client

Info on how this feature is used at Penn

  • No labels

1 Comment

  1. Implementing ths (always available) in the Grouper client misses the whole point of web services, and especially RESTful web services.  A web service is a user API, not a behind-the-scenes fat client communications path.  People access web services with many, varied clients, including web browsers, java applications, perl programs, php scripts, c and c++ programs, and many others --- I don't even keep track of all our clients' technologies.  It is the web service itself that needs to be always available, not just one client.