跟XFire对比, AXIS2是垃圾吗?

本文探讨了Axis2与XFire在Web服务领域的优劣。Axis2被批评代码质量差且文档碎片化严重,而XFire尽管文档不完善,但其架构更为合理。此外,文章还提到了JAX-WS标准的重要性。
Axis1.x->Axis2的最重要特征是:
hot deployment(Axis2 addresses技术)
hot update

但我个人却对hot deployment/update不感冒,因此我仍然抱着XFire不放.

很多人都认为AXIS2是垃圾代码产物, 打开AXIS2的Team页:http://ws.apache.org/axis2/team-list.html
,你发现WSO2几乎主导了整个AXIS2设计, WSO2据说是一个斯里兰卡的公司, AXIS2好多都是由学生式代码堆砌的, 可以用非常烂来形容.
http://www.jroller.com/page/fate?entry=axis2_why_bother

有些人被Apache的不纯洁感到忧虑, WTO2的主导者Davanum Srinivas本身是一个顾问, 他是否想通过AXIS2获取更多的顾问费, 不得而知了.

用江南白衣的话来形容AXIS2, "那是一点都不POJO,不Spring!"

最后, 看看Denis Robert是如何批斗AXIS2的:

No question about it, stick with XFire. You’ll be
 happy about it. My only gripe with XFire is the docs,
which are woefully incomplete. Hopefully that will
change with time. For the time being, you have to
plow through the source for any complex service.
But architecturally, it’s really sound.

Axis2 is a nightmare. Even with XFire’s incomplete
docs, I was able to go through the source to figure
out what I needed. Axis2 is such a jumble of code that
 doing the same thing would take weeks, not hours.

Also, compared to Axis2, XFire’s docs are positively
 brilliant! Not only are Axis2’s docs fragmentary
at best, half of it doesn’t correpond to the current
version.

XFire looks like it’s going in the right direction,
and Dan Diephouse (the lead) seems like he’s on top
 of the project.

You also have to take JAX-WS into account. Whether or
not it’s all it’s cracked up to be is another
discussion, but it nevertheless is the official standard.
 The Axis2 team have made clear that they have
 no intention of supporting it. JAX-RPC was horrible,
but it was at least common ground, and was the API
 used by most enterprise users. Same will end up happening
with JAX-WS and JAXB 2. Websphere users will
end up using that, and knowing it’s out there will
make interop a lot easier. XFire has taken a “can’t
beat ‘em, join ‘em” approach here.

The way I see it, the Axis team dropped the ball on
this one, and the new kid has taken the lead.
It’s the circle of life…


另外, TSS的AXIS2讨论也非常激烈:
http://www.theserverside.com/news/thread.tss?thread_id=40280

内容概要:本文介绍了一个基于多传感器融合的定位系统设计方案,采用GPS、里程计和电子罗盘作为定位传感器,利用扩展卡尔曼滤波(EKF)算法对多源传感器数据进行融合处理,最终输出目标的滤波后位置信息,并提供了完整的Matlab代码实现。该方法有效提升了定位精度稳定性,尤其适用于存在单一传感器误差或信号丢失的复杂环境,如自动驾驶、移动采用GPS、里程计和电子罗盘作为定位传感器,EKF作为多传感器的融合算法,最终输出目标的滤波位置(Matlab代码实现)机器人导航等领域。文中详细阐述了各传感器的数据建模方式、状态转移观测方程构建,以及EKF算法的具体实现步骤,具有较强的工程实践价值。; 适合人群:具备一定Matlab编程基础,熟悉传感器原理和滤波算法的高校研究生、科研人员及从事自动驾驶、机器人导航等相关领域的工程技术人员。; 使用场景及目标:①学习和掌握多传感器融合的基本理论实现方法;②应用于移动机器人、无人车、无人机等系统的高精度定位导航开发;③作为EKF算法在实际工程中应用的教学案例或项目参考; 阅读建议:建议读者结合Matlab代码逐行理解算法实现过程,重点关注状态预测观测更新模块的设计逻辑,可尝试引入真实传感器数据或仿真噪声环境以验证算法鲁棒性,并进一步拓展至UKF、PF等更高级滤波算法的研究对比
内容概要:文章围绕智能汽车新一代传感器的发展趋势,重点阐述了BEV(鸟瞰图视角)端到端感知融合架构如何成为智能驾驶感知系统的新范式。传统后融合前融合方案因信息丢失或算力需求过高难以满足高阶智驾需求,而基于Transformer的BEV融合方案通过统一坐标系下的多源传感器特征融合,在保证感知精度的同时兼顾算力可行性,显著提升复杂场景下的鲁棒性系统可靠性。此外,文章指出BEV模型落地面临大算力依赖高数据成本的挑战,提出“数据采集-模型训练-算法迭代-数据反哺”的高效数据闭环体系,通过自动化标注长尾数据反馈实现算法持续进化,降低对人工标注的依赖,提升数据利用效率。典型企业案例进一步验证了该路径的技术可行性经济价值。; 适合人群:从事汽车电子、智能驾驶感知算法研发的工程师,以及关注自动驾驶技术趋势的产品经理和技术管理者;具备一定自动驾驶基础知识,希望深入了解BEV架构数据闭环机制的专业人士。; 使用场景及目标:①理解BEV+Transformer为何成为当前感知融合的主流技术路线;②掌握数据闭环在BEV模型迭代中的关键作用及其工程实现逻辑;③为智能驾驶系统架构设计、传感器选型算法优化提供决策参考; 阅读建议:本文侧重技术趋势分析系统级思考,建议结合实际项目背景阅读,重点关注BEV融合逻辑数据闭环构建方法,并可延伸研究相关企业在舱泊一体等场景的应用实践。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值