哪种类型的业务/技术使用可能证明 Websphere 许可证的高成本是合理的？
我之前工作过的一家大公司中，一位经理购买了价值 50,000 多美元的 Websphere 生产许可证，尽管事实上他只需要一个容器来在小型 Intranet 系统上运行几个 servlet。
假设我们同意至少可以说这是过度杀伤力，并且像 Tomcat 这样的免费 servlet 运行程序可能就足够了，那么什么类型的业务/技术使用可能证明 Websphere 等应用程序服务器的高成本是合理的？ 我认为集成项目是最有可能的候选者 - 即在需要使用 Java/Websphere 作为桥梁或包装器将多个遗留系统粘合在一起的环境中。 还有其他好的案例吗？
In a large corporation I worked in previously a manager purchased a $50,000+ Websphere production license despite the fact that he only needed a container to run a couple of servlets on a small intranet system.
Assuming we agree that this was overkill, to say the least, and that a free servlet runner like Tomcat would probably have sufficed, what type of business/technology use might justify the high cost of an application server such as Websphere? I'm thinking that integration projects are the most likely candidate - i.e. in environments in which multiple legacy systems need to be glued together using Java/Websphere as a bridge or wrapper. Any other good cases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不一定同意以下内容，但那里有一个相当有力的论点......
在考虑许可时要记住的关键并不一定是技术的成本，而是有人指指点点的成本凌晨 2 点，当你想要钱的事情都已经泡汤了的时候，他就来找你了。
有很多公司已经在这种方法上建立了自己的商业模式（例如 Sun - 抛开关于这种方法是否实际有效的明显争论，RedHat 等）。
IBM 可以为其产品提供的好处并不真正归结为技术本身（正如您所说，您可以以更优惠的价格获得能完成相同工作的东西），更多的是围绕其产品的业务流程产品。 如果您处于需要可预测的正常运行时间、可扩展性等的环境中（例如银行业），
IBM 的产品经过了相当好的测试（这也是它们通常落后于其他地方的领先版本的几个版本的原因之一）。 您知道您获得的东西将非常强大，可以与其他大型业务系统（如您所说的遗留系统，以及其他业务系统，如 Siebel、Oracle、SAP 等）很好地集成，更不用说一站式了- 购买与其他 IBM 产品集成的支持（如果您已经喝过完整的 IBM 酷援助）。
您还知道，如果所交付的内容存在问题，那么它是相对透明的，并且对于您可能遇到的问题，将会有记录的解决方法可供使用。
如果你有足够聪明的人，你不一定需要像 IBM 这样的人可以提供的支持（以 RedHat 为例 - 人们仍然可以免费下载 Linux 并在其上运行他们的业务）。 但到了 2:00，你就得靠自己了——你无法给 Linux（或 Tomcat 提交者之一）打电话，让他们告诉你做错了什么并帮助你修复它。
I don't necessarily agree with the following, but there is a fairly strong argument there...
The key thing to remember when looking at licensing isn't necessarily the cost of the technology, but rather the cost of having someone point their finger at you at 2am when it's all gone belly up that you want money for.
There are a bunch of companies who have built their business model on this approach (eg Sun - leaving the obvious debate aside on whether that actually worked or not, RedHat, et al).
The benefits that IBM can provide for their products don't really come down to technology per se (as you said, you can get something that'll do the same job for a much better price), it's more about the business process around their products. If you're in an environment where you need predictable uptime, scalability, etc etc. (Banking for example)
IBM's products are reasonably well tested (one of the reasons they're usually a couple of releases behind the bleading edge elsewhere). You know that the things you're getting will be pretty robust, integrate well with other big-business systems (both legacy systems as you said, and other business systems like Siebel, Oracle, SAP, etc) not to mention the one-stop-shop support for integration with other IBM products (if you've drunk the full IBM cool aid).
You also know that where there are issues with what's being delivered, it's relatively transparent and there will be documented workarounds available for things you're likely to bump into.
If you have smart enough people, you don't necessarily need the support that folk like IBM can offer (take the RedHat example - people can still go and download Linux for free and run their business on it). But at 2:00 you're on your own - you can't ring up Linux (or one of the Tomcat committers) and get them to tell you what you're doing wrong and help you fix it.
如果您继续环顾四周，您会发现许多类似的决策并不像您想象的那样基于技术考虑。 我和大多数其他经验丰富的从业者一样，会选择其他堆栈之一，例如 Tomcat 或 JBoss。 这并不是因为他们没有许可成本；而是因为他们没有许可成本。 这是因为与其他 J2EE 产品相比，开发人员可以使用它们在最短的时间内构建出最好的产品。
至于为什么IBM和其他J2EE厂商仍然拥有如此大的市场份额，就是因为“喉咙噎着”、“买了IBM就不会被解雇”这样的思维模式。 两者都没有太多技术价值，但这是因为大多数时候，做出这些决定的人在技术上不够先进，无法理解真正的因素，并且没有或不信任有资格做出决定的人。决定。
这个问题有点太细粒度，无法给出简短的技术答案，因为根据您的情况构建成功的产品有很多复杂的方面。 不过，有一些通用的“傻瓜式容器”指南：
If you continue to look around, you'll find that many decisions like this aren't as based on technical considerations as you'd think they should be. I, like most other experienced practicioners, would choose one of the other stacks like Tomcat or JBoss. This isn't because they don't have licensing costs; it's because developers can build the best product in the shortest amount of time with them compared to the other J2EE products.
As to why IBM and other J2EE vendors still have as big a market share as they do, it's because of thought patterns like "Having a throat to choke", and "Can't get fired for buying IBM". Neither of which contain much technical merit, but that's because most of the time the people making these decisions aren't technically curent enough to understand the real factors, and don't have or don't trust the people that are qualified to make the decision.
This question is a little too fine-grained to give a short technical answer, since there are so many complicated aspects to building a successful product in the context of your situation. A couple general "Containers For Dummies" guidelines though:
请记住，Websphere 不仅仅是一个过度设计的 Servlet 容器，它还是一个过度设计的 J2EE 容器。 因此，WebSphere 中也存在 J2EE 中支持的 EJB 之类的东西 - 因此，如果应用程序确实需要它们，它们就可用。 当然，我无法理解为什么人们需要 WebSphere 而不是通用的 J2EE 容器 - 除非他们需要过度设计的功能 Y，该功能将在免费竞争产品 Z 的 Milestone X 中发布。
Remember that Websphere is not just an overengineered Servlet container - it's an overengineered J2EE container. Hence, things like EJBs that are also supported in J2EE are present within WebSphere - so if an application does need them, they are available. Of course, why one would need WebSphere instead of a generic J2EE container is beyond me - unless they need overengineered feature Y that is due to be released in Milestone X of competing freely available product Z.
准确地说，Websphere 不是一个产品。 这是一个产品线。 正如 Martin 所说，服务是人们购买 IBM Websphere 产品的重要组成部分（顺便说一句，服务占 IBM 收入的很大一部分）。
Websphere 不仅包含 J2EE 堆栈（又名 Websphere 应用程序服务器）。 它有许多构建在其之上的组件/产品，例如 Websphere Process Choreographer（工作流引擎）、Websphere Portal、Websphere Business Monitor 以及其他用于运营业务的有用组件。
To be precise, Websphere is not a product. It's a product line. As stated by Martin, service is a crucial part of why people purchase IBM Websphere products (and btw. a big chunk of IBMs revenue).
Websphere consists not only of the J2EE stack (aka Websphere Application Server). It has many components/products built on top of it such as the Websphere Process Choreographer (workflow engine), Websphere Portal, Websphere Business Monitor and other useful components to run a business.
Websphere 是一个糟糕的产品。 除非您只需要与其集成的所有其他 IBM 产品，否则就没有合理的理由购买它。 如果您想要的只是 servlet 容器，请使用 Tomcat 或 Jetty。
它们速度无限快，不会给您的开发人员带来麻烦。 Websphere 是一个令人头疼的问题。 在 tomcat 中需要几秒钟的事情，例如部署一个小型 WAR，在 Websphere 中实际上需要几分钟和一千次点击。
最终，Websphere 只卖给了大型公司，这些公司的经理对技术知之甚少，不关心浪费^h^h^h^h 投资公司的资金，并且由于老话 - 没有人因为购买 IBM 而被解雇。
许多人不使用 EJB，而坚持使用 Hibernate 和 Servlet。 如果您一开始就这样做，那么当您决定迁移到 Websphere 时，您的 WAR 就没有理由在将来不起作用，因为它与某些东西集成。 话又说回来，您确实还应该确保您了解您将来可能需要哪些其他产品，并在您的决策过程中使用它。
我确信许多其他 java 类型在被迫与仅使用 servlet 的 Websphere 一起工作时通常在 Tomcat 中开发，然后在最后部署在 WS 中。
Websphere is a terrible product. Unless you need all the other IBM products that integrate with it and nothing else, theres no sensible reason to buy it. If all you want is a servlet container, grab Tomcat or Jetty.
They are infinitely faster and wont give your developers headaches. Websphere is a royal pain in the arse. Things that take seconds in tomcat eg deploying a small WAR, literally require minutes and a thousand clicks in Websphere.
In the end Websphere only gets sold to big corporate types where the manager, knows little technology, doesnt care about wasting^h^h^h^h investing the companies money, and becasuse of the old addage - nobody got fired buying IBM.
Many people dont use EJBs and stick to Hibernate and Servlets. If you do that in the beginning theres no reason why your WARs wont work in the future when you decide to move to Websphere because it - integrates with something. Then again you really should also be sure that you are aware of what other products you might need in the future and use that in your decision making process.
Im sure many other java types when forced to work with Websphere with just servlets often develop in Tomcat and then deploy at the very end in WS.