Java Enterprise软件与应有的软件

最新推荐文章于 2024-07-08 17:25:42 发布

dnc8371

最新推荐文章于 2024-07-08 17:25:42 发布

阅读量181

点赞数

文章标签：大数据 python 人工智能 java 编程语言

原文链接：https://www.javacodegeeks.com/2014/03/java-enterprise-software-versus-what-it-should-be.html

版权

许多开发人员在其职业生涯的某个阶段最终进入了Java“企业”世界。我知道这个词会引起各种React，这是正确的。通常，存在许多有趣的技术挑战的环境最终会成为那些没人愿意从事的环境，因为它们脆弱，难以处理且没有乐趣。大型项目中经常出现的问题通常是由于管理引起的，但是我已经看到开发人员做出了许多错误的决定，这些错误的决定导致了糟糕的软件，而这些都是以“企业”为名的。

什么是企业？

您可能会争辩说该术语几乎可以表示任何东西，这是正确的，但是出于本文的目的，我将以一种我认为与常用用法一致的方式对其进行定义。普通的企业项目具有以下属性：

通常在大型公司环境中
涉及多层管理/指导
首选来自Red Hat，IBM或Microsoft等大型供应商的解决方案
偏爱知名的，既定的（尽管有时是不足的）产品和标准
有关扩展和性能的担忧

既然我已经定义了我们正在谈论的项目类型，让我们看看它们通常看起来像什么。

典型的企业Java项目

我们大多数人都看到过企业项目的标志。如果我们举个例子，那会有所帮助，所以让我们假设它是一个具有某些B2B功能的电子商务平台。可能是这样的：

EJB3加上JPA和JSF –它们符合“标准”，每个人都可以使用它们，因此是安全的选择。
SOAP –它是标准的，定义了安全性之类的工作方式，因此无需担心。
JMS 消息驱动的Bean –适合平台，并提供可靠性和负载平衡。
石英用于工作安排–一种“安全”的选择（比不认识的魔鬼好，比你认识的敌人好）。
部署在JBoss上 –它得到了一家大公司的支持和付费支持渠道。

现在，像这样的项目存在的问题不一定是所选的单个技术。我的示例中确实有一些问题，但真正的问题是如何做出选择以及使用某些技术的动机。

众所周知，与其他选择相比，上面的软件堆栈更难管理和使用。开发将需要更长的时间才能启动，随着需求的发展，变更将变得更加困难，并且该项目最终将比其他可能的解决方案更加复杂。

企业决策

企业项目在做出选择时通常要确定的目标是：

低风险技术–选择“安全”的选择，即使已知有严重的缺陷，也不会造成反吹。
对标准的痴迷–与提供诸如EJB3或SOAP之类的定义明确的规范相比，对于提供有效地完成工作的最简单解决方案的担忧更多。
需要SLA的有偿支持，通常无需担心响应的质量或及时性。
出于对未知未来需求的担心而进行设计。

除了最后一个目标，这些目标不是坏目标，但它们往往使每个软件项目的实际目标都蒙上阴影。所有软件项目的主要目标是交付一个项目，该项目：

准时；
符合要求；
可靠；
表现良好；和
易于维护和扩展。

这些应该是决策者在软件项目中无论大小的重点。显而易见，有时特殊的组织需求会影响做出的选择，但是从根本上讲，好的选择通常适用于所有类型的组织。

那么，如果我们以这些目标重新构想我们的项目怎么办？

重新构想的企业项目

首先，有一点免责声明：在任何项目中都有很多方法可以使用，我不会断言以下技术要比前面提到的技术更好。需要根据您的需求对工具进行评估，每个工具都不尽相同。

我将尝试做的是演示示例技术堆栈以及每种选择的理由。这将显示出如何构建精心设计的系统，这些系统可以在企业环境中生存，而不必屈服于经常做出的错误选择。

这是建议的堆栈：

使用Thymeleaf的 Spring MVC –稳定的历史，大量的开发资源，快速的开发和灵活性。不要害怕使用平台或库，但是要避免过多地“购买”它们的堆栈，您可能会后悔。
在有用的地方使用jOOQ进行持久化的简单数据库层。这使我们能够以更细粒度的方式管理性能，同时仍然可以轻松地与数据库进行交互并避免ORM陷阱。
使用杰克逊 JSON处理器的REST – REST和JSON都很流行，因为它们易于使用和理解，开发便宜，使用简单的标准并且为开发人员所熟悉。锁定也不是什么大问题–与SOAP不同，我们可以轻松切换到另一个JSON处理器而没有太多困难。可以使用SSL和基本身份验证轻松保护这一点。
在ActiveMQ上使用JSON编码的消息进行JMS消息传递-松散耦合，可靠性和负载平衡，而不会被消息驱动Bean所困扰。
黑曜石调度程序 –简单易用，可提供出色的监控并减轻开发人员的负担。再一次，目标是在可能的情况下简化并降低成本。
部署在Tomcat上 -不使用专有功能。这可以帮助我们遵循标准，避免升级问题，并确保将来的工作正常。当事情并非总是无法解决时，谁需要SLA支持？