有使用 Websphere Integration Developer (WID) 的经验吗？
我的公司（一个大型组织）正在开发一个“路线图”，以将他们相当陈旧、错综复杂的系统联盟发展为 SOA 模型。 少数人极力推动使用 Websphere Integration Developer 和 Websphere Process Server 作为开发未来应用程序的事实上的平台...因为他们认为 IBM 是一家稳定的供应商，这些工具是为企业打造的，他们享受“业务敏捷性” BPEL kool-aid 等。
有人对此平台有积极或消极的想法吗？ GUI 工具是否有助于消除单调/冗余的编码……或者只是使事情变得模糊并使事情变得更难以维护？ 基本上，好处是否证明复杂性是合理的？
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我对 IBM Java 工具集的体验是纯粹的痛苦。 几天来安装彼此不兼容的不同组件的许多不同版本，发现组件 A 中的错误，被告知更新以查看它是否修复，更新组件 A 破坏了组件 B 和 C，被告知更新这些等等。
我发现没有 IBM 扩展的 Eclipse 更加稳定、更快，并且提供更多功能（因为它的稳定版本比 WID/RAD 早几个版本）。
我建议不要采用 IBM 的开发工具方式。 至于流程服务器，我的经验较少，但我团队中使用它的人似乎很喜欢它，就像我喜欢 WID 一样。 不是很多。
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
到目前为止，我还没有对任何带有“SOA”和/或“BPM”标签的工具印象深刻。 我的“路线图”将非常非常迭代，以尽可能快地看到架构的一些结果，同时尝试获取一些简单的成果。 这样你就能感受到什么对你和你的员工有用。
我永远不会让任何供应商把我推到架构“雕塑”的任何地方。
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
我同意其他用户对 WID 的抱怨。 我们使用 WID 的唯一原因是我们的销售部门不久前决定全面使用 IBM 产品。
没错，我们的销售部门决定使用IBM 产品。
发展是痛苦的、令人沮丧的。 Process Server 存在很多稳定性问题，有时它不想正确启动或关闭。 是的，您可以轻松地在 IDE 中绘制流程，但现在大多数工具集都提供该功能。 对于 WID 或 IBM 来说，这并不是什么特别或独特的事情。 IBM 比主流产品落后了几次。
有很多开源实现可以提供强大的支持。 看看 JBoss 或 RedHat，它们都相当不错。 如果这不能让您满意，您可以随时使用 Apache 工具。
沃尔特
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
开发人员不会选择 WID、WMB 或 WPS。 经理们这样做，因为IBM是一个“稳定的供应商”。
看看JBoss，或者KISS
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS 实际上非常简单。 最初的目的是让分析师和业务人员“组合”服务（不要让他们这样做！），因此 UI 简单易用。
大部分工作将是定义和实现后端服务，这取决于平台，主要涉及将现有代码包装在 SOA 服务中。
最重要的是要记住，SOAP 是技术，SOA 是一种架构和一种心态。
成功的 SOA 实施有一种禅意。 一切都与“商业服务”有关，如果您无法用少于六个字向商业用户描述一项服务，那么您就错了！ 理想情况下，服务名称本身就足以描述服务的功能。
如果您最终得到一个名为“MyApp.GetContactData”的服务，其描述为“获取姓名、地址、电话、传真等”。 那么你就在那里。 如果您有一个名为 MyAppGetFaxNoFromOldSys 的服务，描述为“从旧系统中的电话表中检索当前传真 nmbr”，那么您就完蛋了！
顺便说一句，大多数用于 WS* 的 Websphere 工具都非常好。但我会推荐非常出色的 SAOPUI 工具来自 http://www.eviware.com，它非常适合编译/读取基于 WSDL 的消息，并且也具有功能作为有用的测试客户端或服务器。
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
作为一名开发人员，我发现不同级别的工具都没有错误。 6.0.1 很痛苦，6.2 好多了。 但是，一旦您使用该工具进行开发，维护它的工作量就很小了。 我在几个小时内开发出 Java 开发人员需要几天才能完成的工作。 它也很容易维护，因为可以非常快速地进行更改。 我无法从建筑师或经理的角度回答你的问题，但我同意其他一些人的评论。
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.