{"id":399,"date":"2011-04-26T22:49:00","date_gmt":"2011-04-26T22:49:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/google-app-engine-java-capabilities-and-namespaces-api.html"},"modified":"2012-10-21T19:42:07","modified_gmt":"2012-10-21T19:42:07","slug":"app-engine-capabilities-namespaces-api","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/04\/app-engine-capabilities-namespaces-api.html","title":{"rendered":"Google App Engine Java Capabilities and Namespaces API"},"content":{"rendered":"
Capabilities API<\/span><\/p>\n

With the Capabilities API, your application can detect outages and scheduled downtime for specific API capabilities. You can use this API to reduce downtime in your application by detecting when a capability is unavailable and then bypassing it.<\/p>\n

How do we handle this, what\u2019s the tradeoff?<\/p>\n

1. Elegantly: create an aspect that cross cuts all data store writes, and checks for capability. Fail with friendly error message.
\n2. Not so elegantly: add capability checking into the repository code before every write. Fail with friendly error message.
\n3. Quickly: write filter that wraps the entire transaction and checks for data store writes.<\/p>\n

How can we test this on a local environment?<\/p>\n

1. No API hooks. Currently, I have not been able to find or use GAE Java proxies to test the capability call.
\n2. The solution would be to create different builds one with a Mocked Capability Service that is able to return the CapabilityStatus.DISABLED flags and test.<\/p>\n

Due to time reasons, I went for the quick approach. I will try to revisit this later and incorporate AspectJ or Google Juice to leverage aspects for this obvious cross-cutting concern.<\/p>\n

Map<Capability, Boolean> apis = new HashMap<Capability, Boolean>();\r\n\r\npublic void init(FilterConfig filterConfig) throws ServletException {\r\n    apis.put(Capability.DATASTORE, true); \r\n    apis.put(Capability.MEMCACHE,  false);  \r\n}\r\n\r\npublic void doFilter(ServletRequest req, ServletResponse res, \r\n        FilterChain chain) throws IOException, ServletException {\r\n\r\n    HttpServletResponse httpResponse = (HttpServletResponse)res;\r\n    HttpServletRequest httpRequest = (HttpServletRequest)req;\r\n\r\n    CapabilitiesService service = CapabilitiesServiceFactory.getCapabilitiesService();\r\n\r\n    for(Map.Entry api : apis.entrySet()) {\r\n\r\n        if(api.getValue()) {\r\n            CapabilityStatus status =  service.getStatus(api.getKey()).getStatus();\r\n\r\n            if (status != CapabilityStatus.ENABLED) {\r\n                log.warn(\"API \" + api.getKey().getPackageName() + \":\" + \r\n                        api.getKey().getName() + \" has been disabled!\");\r\n                httpResponse.sendRedirect(NEPAL_RES_HOST + \"\/html\/read-only.html\");\r\n                return; \r\n            }\r\n        }   \r\n    }  \r\n    chain.doFilter(req, res);  \r\n}\r\n<\/pre>\n
Namespaces API<\/span>
 
<\/div> <\/div><\/p>\n
Before we can talk about this API, let’s introduce the concept of Multitenancy.<\/p>\n
One of the most compelling uses of Namespaces API is multitenancy. Multitenancy is the name given to a software architecture in which one instance of an application, running on a remote server, serves many client organizations (also known as tenants).<\/p>\n
Multitenancy simplifies administration and provisioning of tenants. You can provide a more streamlined, customized user experience, and also aggregate different silos of data under a single database schema. As a result, your applications become more scalable as well as more cost-effective as you scale<\/p>\n
Data becomes easier to segregate and analyze across tenants because all tenants share the same database schema.<\/p>\n
Multitenancy is different than multi-instance:<\/p>\n