浏览 4364 次
|
锁定老帖子 主题：就说降龙十八掌
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-10-17
引用 JavaWorld：开发面向服务的J2EE应用
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-soa_p.html 这哥们很有意思，写英文文章还不忘了带着降龙十八掌。说实话，他写的service-oriented J2EE application跟我理解的大致不差，所以我才一直没闹明白，这个SOA到底带来些什么新东西。现在好了，JavaWorld告诉大家，原来我们一直都没理解错，咱们做的就是SOA。 这位降龙十八掌的作者描述的如何Reduce J2EE Action code coupling的方法毫无疑问可以将web layer和business logic layer之间的耦合度大大降低，但是作者提出的Action code before applying the service-oriented X18p framework: 引用 public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)throws IOException, ServletException {
... UserManager userManager = new UserManager(); String userIDRetured = userManager.addUser("John Smith") ... } 就有疑问了，作者的这种写法当然耦合度太高，因为作者没有用到接口。可以考虑这样，当不管是POJO，EJB，JMS，Web Service...如何都实现同一个接口，加入为User，这样同样在web layer只是针对接口，而没有针对具体的实现，而到bussiness logic layer，用什么实现，完全可以互相切换，而不需要改变客户端的代码，而且这种方法spring就是现成的解决方案，而不需要在写ServiceRequester和ServiceRouter了，岂不是更简单吗？而且同样达到了低耦合的目的，不知道作者的那种写法还有什么另外的好处？ 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2004-10-18
hpq852 写道 这位降龙十八掌的作者描述的如何Reduce J2EE Action code coupling的方法毫无疑问可以将web layer和business logic layer之间的耦合度大大降低，但是作者提出的Action code before applying the service-oriented X18p framework:
引用 public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)throws IOException, ServletException {
... UserManager userManager = new UserManager(); String userIDRetured = userManager.addUser("John Smith") ... } 就有疑问了，作者的这种写法当然耦合度太高，因为作者没有用到接口。可以考虑这样，当不管是POJO，EJB，JMS，Web Service...如何都实现同一个接口，加入为User，这样同样在web layer只是针对接口，而没有针对具体的实现，而到bussiness logic layer，用什么实现，完全可以互相切换，而不需要改变客户端的代码，而且这种方法spring就是现成的解决方案，而不需要在写ServiceRequester和ServiceRouter了，岂不是更简单吗？而且同样达到了低耦合的目的，不知道作者的那种写法还有什么另外的好处？ 我想这仅仅是一个展示的例子，并不真正代表它的架构。而且，POJO的business logic component要轻松替换成JMS的，也不是那么容易的事情。 |
| 返回顶楼 | |
|
发表时间：2004-10-18
那么SOA的思想究竟是什么？我觉得作者的那种思想更贴近service的思想，web layer调用business logic采用的是web service的调用方法，从而不需要与business logic耦合，而如果单纯的采用spring的话，至少business logic的接口是需要耦合到web layer层中的，那么这样到底算不算是SOA呢？SOA的目的是什么？如果单纯是为了降低耦合度的话，那么spring的方式虽然耦合了business logic的接口，但同样可以达到低耦合的目的（business logic变化而不需要修改web layer的代码）
另外，既然spring就可以实现的东西，那么作者为什么还要浪费精力再去设计一个框架来实现同样目的的东西呢？我想这其中还有另外的目的或是好处没考虑到？单用spring的方式相比作者的那种方式，又有什么弊端呢？ |
| 返回顶楼 | |
|
发表时间：2004-10-18
这是service-oriented阿，不是什么spring这种应用框架，没有可比性，SOA本来就不是给你在一个JVM或者一个环境中用的
|
| 返回顶楼 | |
|
发表时间：2004-10-18
mikecool 写道 这是service-oriented阿，不是什么spring这种应用框架，没有可比性，SOA本来就不是给你在一个JVM或者一个环境中用的 有点让我豁然开朗的感觉，难道可以这样说：Spring是一种可以让我们轻松实现SOA的Framework?
|
| 返回顶楼 | |
|
发表时间：2004-10-19
当然不是。SOA需要的是一个流程引擎为核心的集成框架。spring在这个方面的关注度几乎等于0。而且，应用集成要考虑的东西实在太多，首先，不能假设所有系统都是架构在java平台上。
|
| 返回顶楼 | |
|
发表时间：2004-10-20
大概看了Robbin推荐的SOA的几篇文章，大概明白了为何降龙十八掌作者开发的是SOA，而基于spring开发的不是SOA，我忽略了很重要的一点就是SOA在EAI方面的应用，而基于spring的方式，由于接口直接关联到business logic的接口，所以不能在异构平台上使用，所以也就丧失了EAI的特性，而作者开发的那种方式，可以很轻松的将ServiceRequester发布为web service，从而实现EAI，而同样bussiness logic layer，用什么实现，完全可以互相切换，而不需要改变客户端的代码。
|
| 返回顶楼 | |
