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...
