组件化技术的思考

Corba,EJB和web service的本质没有什么区别，不过是封装参数、返回值的方式不同而已，一个用xml文本，一个用二进制而已。
想想你有没有遇到过这样的需求：用户现有一套系统，比如工资系统，需要你添加一个功能，比如给一个工资项赋值，假如这套系统各个组件用web service交互，那你添加功能是不是很方便？但如果用corba进行交互，没有文档的情况下不太可能分析出它的参数格式来
所以我认为，web service如果解决了安全性等问题，可以有非常好的发展，成为组件标准

突然想起一个有意思的事来，如果corba用soap协议进行传输，你说会怎么样？

Google uses the SOAP and WSDL standards so a developer can program in his or her favorite environment - such as Java, Perl, or Visual Studio .NET.

With the Google Web APIs service, software developers can query more than 3 billion web documents directly from their own computer programs.

http://www.google.com/apis/

关于组件，我发现我们好像忽略容器了

按我的理解，组件是我们的业务对象，容器提供了服务－－实质就是在业务代码外围包上底层API调用，这里可能使用代码生成技术或者反射等代码织入技巧

回过头来，发现自己对容器是如此的陌生

组件模型的成功与否，我看关键是在容器的实现上

虽然COM组件和EJB组件要在相应的容器中运行，但WebService和CORBA应不需要的, 容器是一个运行环境，是提供了对事务管理, 资源管理以及负载平衡等服务的运行环境，这些服务丰富了组件化的应用,  所以我不太同意

我现在对组件体系感觉反而模糊了

特别是轻量级容器概念的提出

先好好想想，再向各位请教

我反而有点体会到EJB的价值了

CORBA, EJB都是基于object delegation的, 因为面向对象设计在单机上很成功, 有的人就想到创建一个远程对象的本地stub来操纵远程对象, 对于设计开发人员来说, 机器间的边界就变的透明, 分布式系统的设计和开发都会变得简单, 但经过很多实际项目后发现,  object delegation的设计存在很多问题, 一是性能, 这中直接调用远程对象的方法会很容易导致很多round trip, 比如Setter, Getter,
这和session facade的原因是一样的, 二是增加了系统间的藕合, 使系统彼此的依赖过多, 导致整体的稳定性下降,
因为object delegation和分布式系统的要求差很远. 所以接口式设计开始变得流行, 这种方法可以通过设计coarse grained接口来减少远程访问, 又可以通过设计不同扁平的接口来实现系统的不同抽象, 当然接口式设计使系统的设计和开发的工作量都增加了, 但系统在性能, 藕合, 稳定,
重用上都获得了好处, 接口式设计的方案很多, java的session facade是一个, 但他无法在异构系统间使用. 还有端口和防火墙的问题, WS可以在异构系统间使用,也没有防火墙的问题, 但他的缺点是传输慢和server side stateless, 传输慢可以通过压缩来提高, server side stateless的问题是很多人指责的地方, 但实际上, server side stateful的方法很容易导致server side内存问题, 所以在client保持state受到越来越多人的推荐.

我觉得解析开销不会非常大，以至于网络奇慢。可能需要是硬件上的良好支持。

目前ASP模式和CRM市场的领头羊salesforce 的appexchange 使用的就是webservice， 它的appexchange 整合了近千个其他应用， 算不算大规模电子商务？个人的目光总是有限的，不要以自己的目光揣测别人一定做不到。

WebService 就是拿出来给别人调用的，怎么也不会比自家的调用快。要求那么高干嘛。有得吃就吃。