|
锁定老帖子 主题：最后，说破了SOA精髓的还是中国人
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-10-08
JavaWorld：开发面向服务的J2EE应用
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-soa_p.html 这哥们很有意思，写英文文章还不忘了带着降龙十八掌。说实话，他写的service-oriented J2EE application跟我理解的大致不差，所以我才一直没闹明白，这个SOA到底带来些什么新东西。现在好了，JavaWorld告诉大家，原来我们一直都没理解错，咱们做的就是SOA。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2004-10-08
确实非常不错
不过我觉得作者应该同时写一份中文的，毕竟大多数人更愿意看母语。 |
| 返回顶楼 | |
|
发表时间：2004-10-08
可能是因为SOA这三个字太含糊不清了。基本上每个OO的应用都可能会有service, service provider, service consumer这样的概念，设计者甚至从来没有听过SOA也会自然而然的产生这样的想法。这是因为这SOA三个字太模糊了。我感觉一个系统架构是不是SOA，或者说是不是符合SOA的精髓，主要可以看它是否像SPRING那样有一套有consumer 寻找provider的机制，因为这一点是解藕的关键。还有就是，是否对service的方法调用有明确的契约。
|
| 返回顶楼 | |
|
发表时间：2004-10-10
gigix 写道 JavaWorld：开发面向服务的J2EE应用
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-soa_p.html 这哥们很有意思，写英文文章还不忘了带着降龙十八掌。说实话，他写的service-oriented J2EE application跟我理解的大致不差，所以我才一直没闹明白，这个SOA到底带来些什么新东西。现在好了，JavaWorld告诉大家，原来我们一直都没理解错，咱们做的就是SOA。 怎么就看出只中国人了？？？根本就是个美国人，扯上点关系，也是美籍华人，我觉得跟中国人一点关系都没有。 |
| 返回顶楼 | |
|
发表时间：2004-10-12
可能是看作者的名字是中国式名字，还有金庸小说中的降龙十八掌吧！
|
| 返回顶楼 | |
|
发表时间：2004-10-13
比较一下下面的两段代码，说真的，虽然说Java效率低一点可以原谅，不过比较一下这两段代码的效率，真是..............虽然java效率比C低n个等级大家都接受了，可是不意味着就可以把系统效率丢到爪哇国去了啊
第一个是直接new一个对象，接着调用一个方法。 第二个是首先getApplicationContext，这个过程就首先不知道耗费多少了。然后是间接的getBean，创建一个对象。接着通过调用3个比reflaction更低效率的方法，设置各个参数，最后是调用。 纯粹的比较方法数，已经是第一个的3倍了，更不提每个方法的效率比第一个还慢多少。 当然，第二段的灵活性可能是高很多，但是这样的灵活性真的需要嘛？在大部分系统的大部分区域，我们需要大量的在EJB,JMS 或者 WEB SERVICE 里面切换嘛？ 我们公司的答案不是，所以这个也是我们到现在还不普遍使用spring，而是部分使用spring的原因，也是spring的好处。系统小部分的灵活性需要非常高的部分，我们才利用spring的beanfactory功能，事务控制要求严格部分，才使用它的事务管理功能。但是绝大部分，我们不使用。可以说是刚柔并济吧，不灵活的部分是刚，灵活部分是柔，系统如果全部是柔的话，那就软绵绵无力了，如果全部是刚的话，那么就太脆而易断，作为一个真正实用的系统，刚柔还是按80/20原则的好。 引用 UserManager userManager = new UserManager();
String userIDRetured = userManager.addUser("John Smith") 引用 ServiceRequest bsr = this.getApplicationContext().getBean("businessServiceRequest");
bsr.setServiceName("User Services"); bsr.setOperation("addUser"); bsr.addRequestInput("param1", "addUser"); String userIDRetured = (String) bsr.service(); |
| 返回顶楼 | |
|
发表时间：2004-10-13
andyyehoo 写道 比较一下下面的两段代码，说真的，虽然说Java效率低一点可以原谅，不过比较一下这两段代码的效率，真是..............虽然java效率比C低n个等级大家都接受了，可是不意味着就可以把系统效率丢到爪哇国去了啊
第一个是直接new一个对象，接着调用一个方法。 第二个是首先getApplicationContext，这个过程就首先不知道耗费多少了。然后是间接的getBean，创建一个对象。接着通过调用3个比reflaction更低效率的方法，设置各个参数，最后是调用。 纯粹的比较方法数，已经是第一个的3倍了，更不提每个方法的效率比第一个还慢多少。 当然，第二段的灵活性可能是高很多，但是这样的灵活性真的需要嘛？在大部分系统的大部分区域，我们需要大量的在EJB,JMS 或者 WEB SERVICE 里面切换嘛？ 你讲这么大一通，我说你纯粹扯淡。只要addUser方法里面访问一次数据库，你所有那些性能考量全都是白费。哪怕你节约一万次对象创建和方法调用，连接数据库的网络开销就足以让你的整个努力化为乌有。你也知道80/20原则，按照80/20原则，J2EE应用根本就不应该考虑性能问题，除非涉及到RPC和I/O操作。你在内存里优化得再好，如果由于架构上的原因多一次RPC调用，整个系统的性能立马就掉下来了。与其追求这种毫无价值的、微秒级的性能提升，我宁可追求全面的灵活性。 |
| 返回顶楼 | |
|
发表时间：2004-10-13
andyyehoo 写道 虽然java效率比C低n个等级大家都接受了，可是不意味着就可以把系统效率丢到爪哇国去了啊
哪个大家接受？ 比较基本的操作，Java和.Net基本相当，甚至很多人的经验是Java比.Net要好。 有一个小小的实验： http://www.theserverside.com/news/thread.tss?thread_id=19378#82981 至于J2EE应用，性能瓶颈就更不在这些地方了，除了I/O和数据库操作，还有 体系机构，譬如你用c编写一个cgi程序和一个JSP项目试试看谁整体性能更好一点 |
| 返回顶楼 | |
|
发表时间：2004-10-13
gigix 写道 你讲这么大一通，我说你纯粹扯淡。只要addUser方法里面访问一次数据库，你所有那些性能考量全都是白费。哪怕你节约一万次对象创建和方法调用，连接数据库的网络开销就足以让你的整个努力化为乌有。你也知道80/20原则，按照80/20原则，J2EE应用根本就不应该考虑性能问题，除非涉及到RPC和I/O操作。你在内存里优化得再好，如果由于架构上的原因多一次RPC调用，整个系统的性能立马就掉下来了。与其追求这种毫无价值的、微秒级的性能提升，我宁可追求全面的灵活性。 addUser调用数据库的时间，大家都是一样的，为什么我不能考虑这里调优？ 这样写，并不会多出一次数据库或者RPC的调用。除非是很复杂的部分，那么我会考虑局部使用。对于系统80％的代码，简单化处理是不会带来任何问题的。 J2EE应用根本就不应该考虑性能问题？那我所有字符串连接都用+好不好？我做一步catch一次exception好不好？我所有Java方法的调用都通过reflection进行好不好？“根本”这个词用得太过了。 "我宁可追求全面的灵活性",这个正是问题所在，过分的追求灵活性，将降低效率，我们必须在灵活性和效率中间取得平衡点。xxx说了“添加多一个中间层，可以解决大部分的问题”。中间层越多，当然灵活性约好，但是效率是低了。其实当然，效率这个东西是两头大，中间小的一个东西，最耗费时间的，往往是一开始的调用（用户点击传到处理层）和最后的调用（调用数据库，WEB service），但是这并不意味着，我们就可以无节制的，忽略中间的效率。 |
| 返回顶楼 | |
|
发表时间：2004-10-13
andyyehoo 写道 addUser调用数据库的时间，大家都是一样的，为什么我不能考虑这里调优？
这样写，并不会多出一次数据库或者RPC的调用。除非是很复杂的部分，那么我会考虑局部使用。对于系统80％的代码，简单化处理是不会带来任何问题的。 你是真不明白呢还是故意抬杠？一次数据库操作或者RPC的速度是十毫秒级的，通常一个J2EE业务操作包括几次网络传输和几次数据库操作，也就是说在最理想的情况下一个业务操作的速度是百毫秒级甚至秒级的。我请问你，你要节省多少次对象创建、多少次方法调用才能把响应时间提升100毫秒？有个成语可以贴切地形容这种优化：杯水车薪。 andyyehoo 写道 J2EE应用根本就不应该考虑性能问题？那我所有字符串连接都用+好不好？我做一步catch一次exception好不好？我所有Java方法的调用都通过reflection进行好不好？“根本”这个词用得太过了。
你还真说对了。我所有字符串连接都是用+；我的业务对象外面有动态代理提供的AOP，也就是说所有方法调用都是通过reflection进行的；我的动态代理里面对异常全部做了包装，也就是说每个方法调用都有try...catch...的包裹。我得到的效果是什么？更清晰的代码，更优雅的架构，以及，更容易找到系统的性能瓶颈，更容易优化性能。有些事情也许你没有听说过，但不代表它不是真的。 andyyehoo 写道 "我宁可追求全面的灵活性",这个正是问题所在，过分的追求灵活性，将降低效率，我们必须在灵活性和效率中间取得平衡点。xxx说了“添加多一个中间层，可以解决大部分的问题”。中间层越多，当然灵活性约好，但是效率是低了。其实当然，效率这个东西是两头大，中间小的一个东西，最耗费时间的，往往是一开始的调用（用户点击传到处理层）和最后的调用（调用数据库，WEB service），但是这并不意味着，我们就可以无节制的，忽略中间的效率。
同样一个问题，我换另一个角度来问你：你要做多少次字符串连接，才能浪费100毫秒时间？你可以自己写个程序，对比一下StringBuffer.append和String.+的性能差距，看看需要多大的字符串才能让你损失100毫秒。如果你能告诉我这个结果，我一定很有兴趣知道。别忘了，100毫秒仅仅是一次普通J2EE业务操作整体响应时间的数十分之一而已。 |
| 返回顶楼 | |
