`
harry
  • 浏览: 179729 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

关于Python和Java结合的新思路

阅读更多
   本人所在的公司(一个创业型的网络公司),主要的系统都是在java平坦上开发的。不过坦率的说用Java开发网站,不如脚本语言Python,php等用起来方便、直接。我们新的系统主要是社区这一块,决定使用python开发,使用django。这样就带来了python和原来的java系统结合的问题。
   比如原来的已有的积分结算系统,里面有很多关于结算的logic,我不想在python这边再实现一遍,不仅是重复的劳动,而且又要测试一遍,是否和原来的一致,更可怕的是当结算逻辑更改的时候,要维护两份代码!!!
   首先想到的方案是让django跑在Jython上,在网上看到已经有人这样做了,不过貌似很麻烦,还有很多未解决的bug。
   这样遇到了困难,转而想通过python和java通讯的方式,通过socket?这样还要自己做一套java object和python object转化的程序,麻烦,没把握能否达到想要的效果。在google上搜了一把,有很多java和python通讯的东东,不过好像没有适合我需要的。突然想起学习spring的时候,提供web service的机制中有个叫hessian的方案,基于http的二进制协议,貌似速度快,而且简单好用。hessian也提供python client访问代码。貌似可行。
   那么现在要做就是把原来的代码按web service的方式,封装成一个个hessian service。比如积分结算的service。然后在django的views.py中通过hessian调用这个service就可以了。
   虽然http调用会带来一定的开销,不过用hessian的话应该开销不大。大家觉得怎么样,现在的方案是python+hessian+java?
分享到:
评论
5 楼 lqefn 2008-05-10  
帮助
搜索
退出
设置
我的圈子
我的博客
收件箱 (1)
欢迎 lqefn !
   圈子首页 → Python → 全部博客
2008-05-04
关于Python和Java结合的新思路
关键字: python java hessian

本人所在的公司(一个创业型的网络公司),主要的系统都是在java平坦上开发的。不过坦率的说用Java开发网站,不如脚本语言Python,php等用起来方便、直接。我们新的系统主要是社区这一块,决定使用python开发,使用django。这样就带来了python和原来的java系统结合的问题。
比如原来的已有的积分结算系统,里面有很多关于结算的logic,我不想在python这边再实现一遍,不仅是重复的劳动,而且又要测试一遍,是否和原来的一致,更可怕的是当结算逻辑更改的时候,要维护两份代码!!!
首先想到的方案是让django跑在Jython上,在网上看到已经有人这样做了,不过貌似很麻烦,还有很多未解决的bug。
这样遇到了困难,转而想通过python和java通讯的方式,通过socket?这样还要自己做一套java object和python object转化的程序,麻烦,没把握能否达到想要的效果。在google上搜了一把,有很多java和python通讯的东东,不过好像没有适合我需要的。突然想起学习spring的时候,提供web service的机制中有个叫hessian的方案,基于http的二进制协议,貌似速度快,而且简单好用。hessian也提供python client访问代码。貌似可行。
那么现在要做就是把原来的代码按web service的方式,封装成一个个hessian service。比如积分结算的service。然后在django的views.py中通过hessian调用这个service就可以了。
虽然http调用会带来一定的开销,不过用hessian的话应该开销不大。大家觉得怎么样,现在的方案是python+hessian+java?
by harry 浏览 (83) 评论 (4) 收藏 相关推荐 评论
cloudeye 2008-05-04
认同楼主的意见。

如果有遗留系统,将其功能封装起来对系统新的部分提供服务,是比较稳妥的方式。

不管它看起来多么的陈旧或者丑陋,遗留系统的价值就是,它经过了测试和长时间用户使用保证没有问题。用统一的语言重新实现或许不难,可是这部分的测试工作不做可是不行的(要保证程序正常测试的工作量和时间可比些代码多多了,或许就给你的项目加了一一半的工作量)。

所以,饭一口一口吃,遗留系统的迁移以后有机会的时候再做,不要把这部分工作引入到当前的项目里面增加风险。同时变动两个部分总是比较麻烦和为危险的,一个一个来,变动A部分的时候,B部分本来是好的不动它,这样可以做为参照,比较稳妥。
dennis_zane 2008-05-04
就这么个简单的功能还搞上ICE了?管道,标准IO通讯也成
coolmenu 2008-05-04
用ICE嘛,python/php作前端 java/c++作后端
robbin 2008-05-04
用单一的解决方案永远是TCO最低的方案。发表评论

4 楼 cloudeye 2008-05-04  
认同楼主的意见。

如果有遗留系统,将其功能封装起来对系统新的部分提供服务,是比较稳妥的方式。

不管它看起来多么的陈旧或者丑陋,遗留系统的价值就是,它经过了测试和长时间用户使用保证没有问题。用统一的语言重新实现或许不难,可是这部分的测试工作不做可是不行的(要保证程序正常测试的工作量和时间可比些代码多多了,或许就给你的项目加了一一半的工作量)。

所以,饭一口一口吃,遗留系统的迁移以后有机会的时候再做,不要把这部分工作引入到当前的项目里面增加风险。同时变动两个部分总是比较麻烦和为危险的,一个一个来,变动A部分的时候,B部分本来是好的不动它,这样可以做为参照,比较稳妥。
3 楼 dennis_zane 2008-05-04  
就这么个简单的功能还搞上ICE了?管道,标准IO通讯也成
2 楼 coolmenu 2008-05-04  
用ICE嘛,python/php作前端 java/c++作后端
1 楼 robbin 2008-05-04  
用单一的解决方案永远是TCO最低的方案。

相关推荐

Global site tag (gtag.js) - Google Analytics