WebService实现平台选择与接口设计要点
博客讨论了WebService实现平台，指出非高性能需求用tomcat+Axis，有EJB可用JBOSS+Tomcat+Axis。强调接口设计对系统影响大，给出三点设计建议。还提到.net做WebService易被滥用，手动发布配置选择更多。
不是非常高性能需求的话，tomcat+Axis足以应付，推荐Axis，非常的实用，设计很漂亮，扩展性非常强，基本上已经成了除了.net下所有 webservice实现平台的基础。如果你原来的应用中有EJB的话，JBOSS+Tomcat+Axis is not bad。
一定要考虑好，不是简单的用webservice暴露就好，接口的设计用对整个系统的非常大的影响，除非你的原来的j2ee应用是用 statless session bean做facade，那样基本什么都不用改，要不然，就可能会造成很大规模的重构。记住三点，第一 服务是无状态的 第二 接口不宜过多，且相对独立性要强 第三 复杂的服务请求或是有更高松耦合要求的应用适合使用Document型的webservice而不是 rpc。这些都是我自己犯过的血的教训：）。
好多人都说.net适合做webservice，但我觉得最起码使用简单不应该成为选用.net 做为实现平台的理由。对于web服务应用来说，服务接口太重要了，开发前必须非常仔细的考虑好服务的语义，开发的过程中每一次的修改都会引起很大的设计变动。就是因为在.net中实现webservice很简单，所以webservice在.net下有被滥用的趋势。其实好好的读文档，在哪一个平台下做webservice的配置发布都不会有什么困难，也没有什么很大的工作量，而手动去发布会给你带来更多的配置上的选择。
blah了这么多，呵呵，大概是因为差不多一年前我在做和你同样的事情吧，good luck
----------------------------------------------
blog: http://blogger.org.cn/hal9000
一定要考虑好，不是简单的用webservice暴露就好，接口的设计用对整个系统的非常大的影响，除非你的原来的j2ee应用是用 statless session bean做facade，那样基本什么都不用改，要不然，就可能会造成很大规模的重构。记住三点，第一 服务是无状态的 第二 接口不宜过多，且相对独立性要强 第三 复杂的服务请求或是有更高松耦合要求的应用适合使用Document型的webservice而不是 rpc。这些都是我自己犯过的血的教训：）。
好多人都说.net适合做webservice，但我觉得最起码使用简单不应该成为选用.net 做为实现平台的理由。对于web服务应用来说，服务接口太重要了，开发前必须非常仔细的考虑好服务的语义，开发的过程中每一次的修改都会引起很大的设计变动。就是因为在.net中实现webservice很简单，所以webservice在.net下有被滥用的趋势。其实好好的读文档，在哪一个平台下做webservice的配置发布都不会有什么困难，也没有什么很大的工作量，而手动去发布会给你带来更多的配置上的选择。
blah了这么多，呵呵，大概是因为差不多一年前我在做和你同样的事情吧，good luck
----------------------------------------------
blog: http://blogger.org.cn/hal9000
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
