View Full Version : Open sourcing WebMethods tools
It seems the community has needs for different or better tools than WebMethods provides out of the box.
Certainly, in our implementation, we've had some painful experiences dealing with the tools.
WebMethods' bread and butter is the broker, and the adapters. The developer's toolset is a necessary piece of their offering, but I doubt it's as high a priority as people using the tools wish it was.
Has anyone talked to WebMethods about them open-sourcing their development tools?
(Are you laughing?)
Failing that, does anyone know of licensing restrictions that would stop a grassroots open source administration tool?
How many people would be interested in sharing their efforts to make it easier to develop with WebMethods?
I see people asking about version control, remote adapter reporting, event logging and tracking, error correction, and so on.
It's good to see our company is not the only one having some trouble.
We're all hoping that maybe the tools will get better some day.
Meanwhile, we're all having the same trouble, and all developing roughly the same tools to deal with the problems.
Wouldn't it be a lot better if we could share this effort in the community?
Wayne S Olsen
03-28-2003, 12:37
Jeremy, I agree the (pre v6) webMethods Enterprise tools are "challenged" (see my previous post on Enterprise Integrator). Since the webMethods v6 Developer client replaces the Enterprise Integrator I wouldn't waste much time/energy trying to fix the existing tools. However you are welcome to get the Enterprise Integrator source code from webMethods and fix-up the folder problems http://www.wmusers.com/wmusers/clipart/happy.gif If you do fix all the problems please send me the new versions http://www.wmusers.com/wmusers/clipart/happy.gif
The tools are better in v6.
It would be nice just to do everything in v6 from now on, but in our case (and many other companies) we have to deal with a combination of v6 and pre-v6 for awhile. I would like nothing better than to toss out some of the tools.
Regards,
Wayne
Feel free to post any tools you can share to the Shareware section of wmusers. Or write an ezine article. The avenue for sharing solutions is definitely available!
Oh, and IMO, the broker is no longer the bread and butter of the company. I know this is probably counter to the wM and widely-accepted point of view, but the broker seems to becoming less and less meaningful.
I agree that its pub/sub and high-powered message brokering are good things. I disagree, however, with its positioning as *the* traffic cop between IS servers. IMO, the majority of integrations do not need pub/sub facilities. And when they do, I believe IS should provide those services.
Broker needs to hang around for backward compatibility, but I firmly believe that new integration should be developed solely on IS/TN.
Of course that's just my opinion. I could be wrong.
jbraunstein
06-17-2003, 17:25
Rob, I see your point. But IMHO, there is still a strong need for messaging, espcially when creating a fully-distributed environment with Integration objects dispersed throughout a company's network. Currently, IS to IS communication is not a speed daemon. IS itself is bogged down in high volume environment, due its "Flow (XML) Language", so imagine an all IS environment? I think pub/sub functionality is less important; what is more important is the scalability to send millions transactions/day through an Integration system and the flexibility to distribute this across the network. That is why we still need a high-speed traffic cop and why many Integration vendors still have a Broker or similiar technology. When the IS to IS (peer to peer) communication improves to support high bandwith, then the Broker can be retired.
As far as tools, there are quite a # of vendors creating 3rd-party products for the webMethods platform including: Business Activity Monitoring, Server and Object Monitoring, Queue Management, Performance Improvements, etc. Send me a private message, and I can point you to some of these vendors.
We seem to agree that the long-term solution is to fold the speed of the broker communication into IS itself. Architecturally we both seem to be leaning toward a flexible approach that architects can leverage for P2P or hub/spoke solutions.
Right now there is confusion as to how to "best" deploy an integration. When do I use the broker? When is doing everything on a single IS okay? When is IS to IS comm okay (it's certainly doable)? How do I incorporate the facilities of TN?
Speed is usually the thing that is pointed out when the question "Why do we need the broker?" is raised. I agree that IS to IS comm is pokey, but that's not really a good justification for the current architecture of the wM suite.
The distinction between EAI and B2Bi needs to disappear, and positioning the Broker between IS boxes perpetuates this--and forces the use of pub/sub even when it is not appropriate.
Thanks for the info and the excellent POV.