JavaEE真的可以移植吗?

javaee,就像(几乎?)任何标准一样,是实现者努力宣传遵守的东西,但却不想遵守。

想想这个问题:红帽是如何赚钱的?送东西还是卖东西?如果您编写的代码可以轻松地传输到另一个javaee应用程序服务器,这将妨碍他们从您那里赚钱。解决这一问题的方法是受人尊敬的“拥抱并扩展”技术,这一技术一直归功于微软,但实际上,自从第一个标准发布以来,它一直是商业软件供应商的首选工具。

严格地 对于代码中的javaeeapi,JBoss(或Geronimo(或JonAS(或…))将运行它以及任何其他兼容的应用程序服务器,只需要在特定于服务器的部署描述符中进行更改。这是拥抱阶段。

每个服务器——特别是商业服务器(比如JBoss)!-还倾向于向API添加额外的东西以“使事情变得更简单”(公平地说,这些通常会使事情变得更简单。)开发人员——尤其是那些对标准API不太熟悉的开发人员——经常陷入依赖这些额外API而不以任何方式包装它们的陷阱,因此,如果您希望更改平台,允许这些扩展淹没其代码,以至于很难删除它们。这是延伸阶段。

从软件历史的任何一个点上命名一个标准,你都会发现人们在拥抱和扩展(以至于当人们谈论“致命的拥抱”时,我不得不强行将我的想法从供应商锁定问题转移到合适的术语上来)。您还会发现最终用户(开发人员或其他人员)对它感兴趣。javaee在这方面与任何其他技术都没有区别。

然后考虑到大多数规范的措辞有多糟糕,并且。。。

all non-trivial abstractions are, to some degree, leaky “我发现这对JavaEE非常适用。考虑JMS异常可能是暂时性的,例如完整队列。这是一个典型的快速生产者/慢速消费者问题,理想情况下,生产者将节流以匹配消费者的速度。但是这个错误也可能是致命的,比如授权失败。在第一种情况下,重试最终会成功(通常),而在第二种情况下,在人类干预修复授权失败之前,再多的重试也无济于事。

那么你在你的便携程序中做了什么来解决这个问题呢?一种方法是将每个JMS异常都视为致命的。关闭所有对象并重新初始化程序。有点像用大锤打死苍蝇,但非常轻便。或者,您可以检查JMS异常,看看它是暂时的还是致命的错误,并采取一些适当的措施。这要有效得多,但由于JMS异常是特定于提供者的,因此很难移植。我的一些客户已经采取了编写特定于供应商的垫片的方法,这些垫片捕捉JMS异常并对它们执行适合供应商的操作,这样代码就可以“可移植”(想想:硬件抽象层的软件等价物)。

当然,这只是异常处理。类似的问题普遍存在。考虑重新连接细节。有些传输会导致到应用程序或容器的连接失败。有些人把它隐藏起来,认为代码不需要知道这一点。但实际情况是,如果网络永久关闭,几乎所有消息传递应用程序都需要提供警报或日志条目。如果网络出现故障,你不会希望应用程序永远挂起,对吧?因此,最终,即使是在提供透明重新连接的传输上运行的应用程序,也需要为连接失败编写代码。传输提供者的特定特性和行为将通过JMS的抽象泄漏出来。

为了我的钱,JavaEE 可跨传输提供商移动。应用程序需要对底层传输提供者有足够的了解,以处理浮出水面的抽象。在一定程度上,你可以避免泄漏的应用程序是便携式的,但没有进一步。

这只是部分答案,但JavaEE6,更准确地说是EJB3.1,最终指定了 Portable Global JNDI Names its own rules 这确实不利于可移植性(一种供应商锁定)。因此,在J2EE1.4世界中,如果您想简化企业应用程序的可移植性,就必须实现各种策略,通常是在您的应用程序中 ServiceLocator ServiceLocator 仍然需要。