PaaS能力开放安全鉴权，主要关注两点：
1、授权许可：
1）谁可以使用P层的能力？
2）哪些能力能被哪些人使用？
3）你怎么证明你就是你？
2、访问控制：
1）正确的用户获得他可以获得的能力
2）度量
sae:
服务限制与配额
SAE设置服务限制和配额的目的是为了防止个别用户攻击和滥用，从而在公有云计算平台上保证绝大多数开发者的正常使用。
服务限制和配额设定是在门户网站新浪自身长期运维的基础上经过严格计算得出的，所以正常使用一般不会出现问题。经过SAE实际统计，99%的应用不会受到任何影响
每一项服务有不同的限制项
查看 access key 和 secret key 需要输入安全密码，该安全密码和登录密码不一致，也可以采取动态密码。防止从客户这端无意的泄露密码。

在网上看到这么一句话觉得总结的非常好：
从高内聚，低耦合到设计模式，从 Ioc 、 Spring 框架 到 SOA 我们一步一步的抽象着、分离着。很显然，我们需要一个灵活而不失严谨的架构，需要一个功能强进而不令人生畏的产品；
企业的应用软件发展还有着很大的空间和尺度，也大概明白为什么OSGI起源于1999年却近几年才进入软件行业，当时软件业确实还不发达，人们确实想不了这么多，做软件只为了能解决一些问题而做。而如今更多是要资源最大化共享，就想着怎么能把原来做过的软件集成起来，不用再做个新的，于是就有了SOA。随着Eclipse的成功，大家对它以OSGI为核心的插件体系无不赞叹，原来做软件可以像搭积木一样的拼装，多么美妙，人们也就认识到了OSGI的重要性和带来的好处，近两年OSGI正在飞速发展，相信以后会有更大的发展空间，网上有人预言说将来OSGI一定会装在60%的java虚拟机上，还有人说这么好的架构应该直接纳入JDK，这些都有点极端，但是可以看出它是多么的优秀。越来越多的软件开始支持OSGI。
OSGI的强项是它的动态加载和对Bundle之间的通信和管理及依赖关系，而更细粒度bundle内部则没有严格的管理体系，Spring可以对bundle内部进行更为细粒度的管理，Spring将在配置文件中增加直接支持OSGI的配置项。
他们的组合可以把底耦合的应用程序“模块化”。
运行期间多个版本的应用同时部署，动态选择，当然这是OSGI的特性，但是有Spring的配置将更好。
运行期间多模块(服务)的替换。
运行期间动态部署，更新或反部署模块。
应用Spring配置，装配模块。
用简单和熟悉的编程方式开发具有OSGI特征的程序。
Hibernate现在也可以集成到OSGI，为OSGI持久层又添了一笔，可以看出Spring+OSGI+hibernate前途无量。