|
五个反对向.NET移植Java EJB应用软件的理由 |
作者：未知 发布时间：2005-03-12 来源：JSP天空网
|
五个反对向.NET移植Java EJB应用软件的理由
作者： BUILDER.COM
Wednesday, September 18 2002 5:05 PM
.NET架构已经被吹捧为分布式计算业界的又一个重大的事件。通过重新设计，微软在XML整合、错误处理、部件处理和可重用架构等方面有了显著的进步。Web开发的前景十分的明确：更快的开发，较少的自定义编码和稳定性的增强。
但是如果你目前的应用软件是一个Java EJB应用的话会怎么样呢？值得付出时间和金钱向微软的新型平台进行移植吗？当.NET通过Java EJB所能获得的收益这一问题会在未来几年中继续被争论时，这样的平台接口中所涉及的难点却更容易预料一些。即使有着重要的技术或商业原因在促使这方面的需要，这里还是有五个反对向.NET移植Java或J2EE应用软件的理由。
1. CLR并不支持Java
向.NET移植的第一个障碍就是它对所支持语言的设置。.NET架构是依靠Common Language Runtime (CLR)来实现多语言的兼容性，但是这个兼容性目前只限于C#, C++, VB和J# 。所以，Java并不被CLR所支持是很正常的。
通过使用Java COM或是Web服务，将Java应用软件层向.NET移植而不需要用CLR所支持的语言重新编写应用软件代码将会是可能的。然而，Java COM依靠于第三方应用软件来直接从纯Java代码中创建COM DLLs。调试结果二进制编码的困难，还有复杂性的增加，都说明了为什么在进行这种应用软件开发时要谨慎行事，要不然就彻底地避开它。
另一种策略就是将你的Java代码导向C# 代码。理论上，你可以通过自动化的应用程序将Java代码直接翻译成C# (还有J#)。例如，ArtinSoft的Java Language Conversion Assistant Enterprise Edition (JLCA EE)承诺了百分之九十九的从Java到C#的自动转换，但是这样的产品还没有在市场上被证明，而且有人争论要不要相信这种自动代码转换。不管是使用自动化的处理方式还是通过人工来进行，这种转换都毫无疑问地需要有相关的体系架构上的改变。当将一个Java应用程序重新编写成VB, C++, C# 或J# 时，可能就需要进行大量的再分解工作，这取决于你的应用软件的具体设定。
2. IIS并不支持JSP
就好像将一个应用程序的语言端口从Java转换为C# 还不够麻烦似的，.NET还需要有一个表示语言端口。而JSP并不被IIS所支持。从JSP转向ASP.NET是意义重大的一件事，它将需要对表示层彻底的重新编写。还有大型架构模型，例如通过标签库的代码再利用，并不被ASP.NET所支持。标签库必须被转换至服务器控制或是服务器端包含内容(ssi)。有意思的是，支持标签库的Java类正好与.NET的代码之后的类相匹配，但是实际的转换之中还需要大量的工作。
3.服务器需要重新设计
前面提到了，在对.NET的代码进行语言的重新编写时必然需要有新的体系结构。如果.NET服务器控制的执行已经做出计划，这就会变成非常的明显。ASP.NET服务器控制是.NET所提供的最大的优势之一。通过利用预建构的服务器部件，开发者可以减少重复性编码并轻松地通过对象访问函数功能。在向.NET移植的过程中利用服务器控制的优势将可以实现自定义presentation，应用程序和数据库代码的去除并取而代之以服务器控制和所要求的数据库逻辑。
当从一个现有的微软公司应用软件进行升级时，这个代码的解压缩并不困难，特别是在由良好的编程习惯带来的划分清楚和组织良好的代码时。然而，当从一个Java EJB应用软件升级时，服务器控制则要求垂直纵深的移植，且可能同时地影响到应用软件的数据，应用程序和presentation层。存储程序，Java对象和JSP文件不仅是需要改为微软支持标准，他们还需要通过修改来支持Server Control。
例如，DataGrid对象提供了综合的表格功能来显示一整套数据记录。行和列选项，标题风格和分页功能只是客制化的属性中的一小部分。DataGrid对象比任何客制化或是私有化代码都更具有功能性和可维持性。在从Java应用软件升级时（假设你将一个Oracle数据层移向SQL服务器），要利用这种控制的优势，你需要：
当格式化查询来支持DataGrid时重新编写P/L SQL至Transact SQL。
将Java应用软件代码重新编写为.NET所支持的语言来调用SQL或存储程序并支持DataGrid的事件模型。
当去除支持现有的客制化数据presentation对象的代码时将JSP模板重新编写至ASP.NET。
4.不支持Container Managed Persistence
假设现有的Java应用软件是由一个非SQL服务器数据库所支持，对应用软件的移植将很可能要求将数据库导向SQL服务器或是整合适当的驱动程序来允许.NET应用软件通过非SQL服务器数据库来保持数据。在两种情况下，你都需要将你的JDBC连接类重新编写至ADO.NET并将Java ResultSets移植到ADO.NET DataSets。这个任务根本不是什么非常困难的。DataSets和ResultSets具有相似的机制并超越了实行细节，他们并不需要重大的架构重建。
当开发团队开始从Java导向对象到.NET时，移植过程的困难就会开始出现。.NET并不支持Container Managed Persistence (CMP)，并且也没有相似的机制。如果你的应用软件依靠于CMP来实现对象保持，你就会被迫通过内嵌的逻辑来重新编写这些对象类来实现数据恢复和装载。
5.不同的session处理
EJB标准并没有指定对session数据的处理，所以EJBsession处理变成了完全的应用软件服务器设定。由于在session处理方面的差异会对性能表现，可升级性和网络设计产生很重大的影响，所以你必须对应用软件中的session-handling机制的详情有所了解。
在.NET之中，微软公司引入了一个分布式session模型，它通过使用Microsoft SQL Server存储应用软件的状态使得session数据在Web farm中的多个应用软件服务器上可用。由于.NET依靠于SQL服务器中的内嵌功能来做sessioning，使用Oracle或是其它非SQL服务器数据库的不同类型的应用软件将需要为分布式sessions单独实现一个SQL服务器实例。此外，由于大量的session数据将会降低系统的总体性能，所以对session存储谨慎的使用时十分必要的。
平等之战
.NET架构代表着微软公司在高可用性，企业级应用软件领域中的最新成果。许多在从前的IIS，Visual Studio, VB和SQL Server之中没有的功能都在新的平台上得以实现。微软的开发者和用户可以感受到在可升级性，可扩展性，安全性和性能表现等方面与其他业界竞争者平等的优势。
关键问题是，.NET只代表着与EJB解决方案供应商之间的平等，而没有迹象表明.NET平台超出于WebSphere，WebLogic，或是任何其它EJB应用软件服务器。对于现有的IIS/ASP解决方案，移植工作的好处是很明显的。而对于新的事物，就取决于员工的技能和公司的定位，.NET也许会是合适的架构。但是对于现有的Java EJB应用软件，除非你想要为平等性而战，留着他们不用管了。
原作者： BUILDER.COM
原出处： BUILDER.COM |
| |
|
|
|
