业务框架设计的一般感想

servlet容器设计感想（初级）

——对我们设计“umpay的前置和业务服务器”可能有帮助

——我们可以把通信框架看成是一个servlet容器，把交易处理类看成是一个个的servlet。

但是，我们可以思考下，我们的框架设计的怎么样，我们是不是能轻松地动态地加载一个新的业务处理类呢？我们又有没有考虑servlet协作呢，包括共享数据和共享控制呢？

 

servlet容器具备的职能：

 

1、管理servlet的生命周期，如何做到能够动态加载（包括对“新增动态加载”，“删除动态加载”和“修改动态加载”，tomcat目前都未能做到对“修改动态加载”。 ）；

2、会话跟踪，尽管我们的平台一般用的是异步长连接，可以依靠TCP的有状态来实现会话状态跟踪，但是一个好的应用层协议设计，最好应该设计成不依赖于通信层采用的是长连接还是短连接。http起初无状态，但是由于web应用很多都是有状态的，一个逻辑完整的conversation需要进行多次的交互，而且允许此间的交互过程中跨越多个TCP连接，于是出现了session（依赖于cookie或url rewriting来传递ID），session的加入其实就是对http协议的补充，因为session的正常工作，必须要求服务端和客户端的配合，客户端有责任把这个id通过cookie或url rewriting参数带给服务端。这一点在我们的非接项目中也有类似的情况，也就是所谓的“通信层流水号”和“应用层流水号”，因为一个Transaction可能需要多次网络交互。注意：一个逻辑完整的交易如果需要进行多次的网络交互，甚至这种交互还发生在多个分布式子系统之间的话，这种交易会涉及许多高难度的技术。这也是SOA中的一个热点话题。  http Session的虽然是一个交易跨好几个网络交互，但是它牵涉的分布式子系统不多，就客户端和服务端。  在SOA里把这种交易称为“分布式事务”，分布式表示这个交易要牵涉到多个子系统的网络交互，事务表示该交易的成功需要多个交互都成功。

（分布式事务）。

 

3、安全性（包括资源的访问控制）     现在我们的业务框架是没有对资源访问有什么控制的，因为我们的平台还没有真正的具有特别多的用户，或者特别多的合作伙伴，此时，我们的访问控制基本上都是在网络层做的，通过vpn，源IP限制，端口限制等来做访问控制的。当然，非接项目，安全性算做得比较好的，有资源的访问权限控制，也有ssl。

 

4、协作 （servlet的协作包括“共享数据”和“共享控制”）   共享数据包括共享内存数据（比如HttpSessionContext还有叫什么ContextManager的，再如System.getProperties()，ServletContext，都是利用面向对象的类中的静态方法什么的）来实现数据的跨类共享。当然如果共享发生在某几个相近的类之间，还可以抽象一个超类来共享这些数据。当然，如果数据还要跨网络共享怎么办？ 可以使用第三方数据源，比如数据库（对外提供的API是jdbc connection），分布式session容器（我们的sso服务器，本身就可以认为是个分布式的session容器，对外提供的API是HttpClient）。共享控制，也就是对于一个请求，需要两个或多个servlet共同处理，这种模型也很常见的，比如 公共过滤器-分发-特定的servlet-公共装饰器。对于，跨网络的共享控制，也就是要将请求转发到另一个分布式子系统。所以，无论是共享数据，共享控制，都包括是局部于本子系统内部的，还是要跨入其他子系统的（程序=数据+控制）。

 

注意：servlet之间一般不允许相互调用，而要通过共享数据的方式来进行通信。