Saturday, 30 December 2006

Why WebMethods sucks

This is my very first blog post, ever. I feel I need to do some public complaining and get some thoughts out of my system that has been nagging me for a while. Maybe I'll continue to write some more posts, maybe even some positive ones. :-)




The future is bright, the future is SOA

In the last project for my previous employer I was unfortunate enough to be doing some development in WebMethods. WebMethods is a so called EAI platform, Enterprise Application Integration. It is riding the SOA storm trying to be the magic glue that will connect all the different systems in a company by drawing some bubbles and connecting them with some arrows.


The thing is that to connect different system and making them talk to each other you need business logic. And that business logic needs to be developed. That means WebMethods is actually an application server with a built in development environment. And in this development environment they have taken SOA to places it should never have gone.


Over the years a lot of people have done a lot of thinking on how to develop complex business logic. There is a lot of knowledge out there on how to use object oriented design to make software that is maintainable, understandable, testable, scalable, you name it. Well, WebMethods think they have a better idea. Let's throw all of that overboard and use services instead.




At your service

In WebMethods all code lives in services, which is analogous to functions or methods in programming languages. These services take one input parameter, a document, and returns one output parameter, another document. Or so it seems.. what actually happens is that you get a bunch of name/value pairs (where the value can be sub documents, arrays etc so it kind of maps to an xml document) in a bucket called ”the pipeline”. In your service you modify the pipeline, add and drop fields, and whatever is there when you're finished is the output document. The best thing is that there is one single pipeline that travels around from service to service so what you really have is a big set of global variables. (I learned in school that global variables is a bad thing, but that must have changed since then..) On more than one occasion in my team we were experiencing mysterious bugs because some data from some service that didn't clean up after itself properly popped up. You thought you were sending in a null parameter (by not assigning anything to a field) but there was old data there with the same name.


A service can be written in different ways. One way is in Java. So isn't that object orientation for you..? Well, not really. You don't get to write your own classes. You get to write the body of a static method that will be put in a class together with other static methods. And you still have to use the pipeline. So, sorry, no encapsulation of functionality into different classes.


The WebMethods way to write a service however is to use their own little toy language, Flow. It's one of those languages that a non programmer is supposed to be able to use by just dragging and dropping stuff with the mouse. Making something complex easy that way has failed before and it's not working now either. You have the same constructs as in a real programming language (if, while statements etc), just not as flexible and with little pictures instead of text. Writing even the simplest things gets complicated and hard to read. And since making and calling sub services is so complicated you get a massive amount of code duplication. Adding to the bad maintainability of the code.


And don't start thinking about things like automated unit testing or other good practices. You're locked in WM land now, and there are no such things.

Ok, so we have a development environment where it's just horrible to develop. But a development environment is more than just writing code. You also need things like version control, build and release management. The way that you want to work is that you start by getting the latest version of the code base you're going to work on. Do your changes, test it and then commit things back to the version control system. When it's time for release you check out the latest code and build yourself a release. (At least that's the way I want to work) Well, that's not the WebMethods way..


The WebMethods way is that you have a development environment where you develop. Then when you want to put what you just developed on some other environment you use the WebMethods Deployer application. No need for version control here.. All developers are supposed to be working on the same development environment, which of course leads to all sorts of chaos. If you still insist on putting something into version control you can export packages (the things that services are organized into) and check them in. They are however binary packages so forget about merging, branching etc. You also need to keep track of what actually needs to be checked in yourself. Since all of this is too cumbersome it didn't happen very often in my team that things were actually checked in.


The Deployer application we didn't really use either because it was extremely slow and buggy. We ended up exporting/importing packages between environment resulting in all sorts of confusion on what version was where. And WebMethods itself didn't help since it had a tendency of messing things up in an environment when importing packages.



Models

So is there nothing good in WebMethods? They actually have one pretty nice idea in something they call “Models”. A Model is where you define a business process. A process that takes a long time to run. And with “long time” I talk about days and maybe even weeks. The operational staff needs to be able to monitor each process, for example when a customer calls customer service and wonders why the ADSL connection he ordered a week ago isn't working yet. Maybe they need to phone up some other department or company to ask why the installation guy hasn't been to the telephony station to connect the cables yet. Maybe they need to re-execute some part of the process. With Models they get a GUI where they can see the process and do stuff with it.


A model consists literally of bubbles and arrows that you draw up. Each bubble is a step in the process and consists of a service that holds the code for the step. The arrows has conditions that dictates which step in the process to execute next. You can also define events that must happen for a step to execute (for example that an answer has been received from some external system). Events are actually documents that you “subscribe” to from a system wide message broker. A pretty crappy (and very error prone) event dispatcher.


So Models is a nice idea but the implementation of it, together with the rest of the WebMethods nonsense makes it a nightmare to work with. Is there nothing like this for the Java/J2EE platform? I can envision a pretty nice framework where you implement a special interface to make classes that are process steps. In the process you pass around some JavaBeans container that is easy both to persist and to edit in a GUI when needed. Someone must have written something like this??


That will be the end of my whining session. I'll skip talking about how buggy and unstable the system is, how much resources it uses and stuff like that. And I really don't want to talk about the Workflow module.. brrr...

10 comments:

chbe8475 said...

Hi,
This was fun to read, but hey, Niklas, you are not making much sense. First of all, there is a big difference between business logic and integration logic. the Integration Server (IS) is not, and has never claimed to be, an application server. If you start developing business logic in an IS, you are doing the wrong thing. So don't throw anything overboard, just develop the right stuff in the right place. :-)

A correction, a service in the IS can have any number of input and output parameters, and these parameters can be of any type (not necessarily a document).

Yes, global variables can be a bad thing, but still, you should have the option to use them. If you specify an interface to a service (input and output parameters) but choose to leave some other variables in the pipeline when exiting your service, you have yourself to blame, not the tool. It is mentioned on several places in the webMethods documentation (GEAR) that you should NOT leave variables behind.

I agree that Flow is not the best development language in the world, but again, you are not supposed to develop business logic in the IS.
It is to easy to develop un-readable code in Flow, but so it is in Java or any other language as well.

You talk about version control. I have worked in several projects where we successfully have used CVS and SourceSafe. I just don't see your problem! You can easily check in the services themself and they are XML and can be merged. I have not used the new VCS package from webMethods but this should also easy your pain.

You say that all developers are supposed to work on the same environment. That is so lame to say. This is a choice you make. You can develop in a distributed environment with several IS (one for each developer for example), but this (as always) requires the need of a version control system.

Models are good, but they should not be used without caution. They do add a lot of overhead. This is why they should not be used for everything but only for high level business processes.

You sure did some whining here. Most of it I do not agree with, but I am glad you didn't bring up the Workflow :-)

Excuse me, are you saying that the webMethods Broker is crappy and error prone?!?

The webMethods Integration Server is as good as any other integration platform I have worked with and I must say that you are barking up the wrong tree here. It sounds like you should blame the project management for not having qualified staff on the project.

Niklas Lindholm said...

Thanks for you comment! I wasn't sure that anyone would actually read my rantings. :-)

Then the question is, what exactly is "integration logic" and when does it become complex enough to pass the scope of the IS? In the typical real world case it won't be a matter of taking value A that was received from an interface and blindly pass it into another interface. You're going to have decisions on what to do with the data, validation of the data, conversion etc. And if that isn't business logic I don't know what is. I'd say that almost any real world implementation will be complex enough to miss WebMethod's sweet spot. At least in the places I have seen it used.

Maybe I was a bit too flexible with terminology regarding service input. What I mean is that you will always send in whatever is in the pipeline. And that can be seen as some kind of root level ducument. Sure you can visually define different input fields and types but there is nothing actually enforcing it at compile time. And if you change the "signature" of a service the calls too it will never know. No refactoring support whatsoever.

The problem is that with the pipeline you only have global variables. Having to explicitly drop local variables all the time just clutters the code and makes it less readable. And it is very easy to make mistakes. A good tool should help you not to make mistakes. And what about if I have a local variable "foo" and then call a service that also uses the same varibale name? What about recursion?

It's very possible to write un-readable code in Java as well. I have seen my fair share of it. :-) But with Flow it's more or less unavoidable.

Regarding version control. Ok, so the services may be possible to version control. But if I remember correctly the models are just binary packages. And to only being able to properly version control half of the system doesn't make that much sense. But I agree that if you only develop services then you would be able to work properly against versin control and let each developer have his own environment.

There were a lot of times where I published a document that just didn't come out of the broker. Sometimes taking a coffee break did the trick. Sometimes restarting stuff. Sometimes the document was just lost forever..

In the very simple integration projects that you are talking about I could see WM making some sort of sense (altough I still wouldn't like it :-). But in my experience it never turns out to be that simple in reality.

Måns said...

And if the problem that you are solving is very simple (as in the supposed WM-sweetspot), why use a fancy tool at all? Why not opt for something less fancy but as functional, such as ServiceMix? Or even opt for bespoke software that doesn't try to be a solution for everyone but rather a solution for the exact needs.

Fabien said...

Good post! You care about the right issues.

I don't know much about Webmethods so I can't tell if your arguments against it are right or wrong, but chbe8475 likes WebMethods so much that he could be working for them...

To do similar things in plain Java I believe you would use Spring combined with an enterprise bus like Mule, or JBoss(with JBPM for workflow).

Niklas Lindholm said...

Fabien,

Thanks for pointing me in the direction oj JBPM! At first glance it seems to be exactly what I've been looking for.

Steven Peh said...

Hey, I know this is an old post, but I'd like to comment, as recently I have the unfortunate experience to use webmethods.

To start off webmethods is just bad for business logic. Period. Advocates would say they are perfect for integration logic. But that is a very naive comment. Very seldom would you have in large projects or enterprise integration pure integration logic. There will almost undoubtedly be some business transformation of data happening on top of the data delivery protocol transformation. With a tool like webmethods, it is very very easy to leak business data transformation it. Business data transformation IS business logic. Webmethods does not have a clear demarcation of protocol transformation vs. business transformation. It is all about transformation. Sure it supports calling Java code, but in a bad form (non-reusable outside of webmethods, non-oo).


I've seen it happen a few times already where we started to leak some business data transformation into our webmethods code because it is easy to do simple stuff in FLOW. But in all cases, as enhancements comes in overtime, these simple FLOW logic becomes massive piece of monolithic spaghetti that is a nightmare to maintain.

xitij said...

i am new in web methods.

i want know that if there is one project with different modules. one module is made in java and other are made in .net. so i can integrate one java module in .net module together.

and also i want material related to webmethods for beginners. so give me some link or documents.

cbz6442 said...

hai xitj,my cousin is working on webemethids and hes asking me join in it,as it is a tool i am not sure how long it gonna be in the market can u share ur experice with me hw long did it take u to crcak a job work in the job and other things,do u recomend fresher to wbemethods

sujith p said...

"Thanks for you comment! I wasn't sure that anyone would actually read my rantings. :-)"

Well, you thought no one would read but still spent a day describing your horrific experience! Pity! That shows how much you sucked at webMethods...

Next, either you have worked with a firm which has no clue how to put webMethods into best use or you have been highly unsuccessful in learning the tool itself.

PS: forget webMethods (or any tool for that matter) and get back to story writing in Java!

Joseph A. Wallace said...

Thanks for Information SAP Online Training