This is a short-version of an e-mail conversation I've had with Oisin. I have put together a list of observations and suggestions based on my experiences with the hopes of spurring a productive discussion around defining goals for improved tooling for Servicemix.
I previously managed a Servicemix (2.0 to 3.0 clustered) implementation that handled 100,000 to 300,000 events a month and peaked to upwards of a million events a month. Web Services were handled with Axis+Tomcat. I am currently implementing a complete SOA re-build for a telecommunications company that will also utilize Servicemix heavily for both messaging and Web Services (CXF). I've used the Weblogic Integration platform, and have exposure to the Tibco and Webmethods offerings. Servicemix is a terrific platform, with a great technical base and has the potential for big things down the read. I believe the way to build developer loyalty and a strong user base is to make the lives of developers easier and more productive.
For me, the test of an exceptional Enterprise solution is one where average developers are able to exceed average productivity. If this can be achieved, the Tibco, Weblogic and Webmethods users will come in flocks.
- The ramp up time to get the first project running on ServiceMix is the "hard part" of developing on ServiceMix.
- Packaging is complicated and complicated projects make it more complicated (duh)-- multiple SU's and parent Maven projects, etc. (see cxf-wsdl-first example).
- Once past the packaging, developing a project is easy-- even for novice Java developers.
- How are you supposed to cleanly "stop" a running Servicemix instance?
- Configuration options-- understanding when to use the various flow types is confusing and difficult to switch between.
- Working examples that are easy to get up and running are the best form of documentation.
- Focus on making the basics easy-- initial project/packaging templates.
- Focus on "how its used", not "how it works". From a developer standpoint, they start with "I need to write a Web Service." or "I need to write a message routing rule". Build project templates and wizards that assist a developer from that approach.
- Do not forget the client side! Have a project template/wizard for building client projects that can be used for environments outside of Servicemix. Make it as plain Java as possible. JAXB is great, having to lug around the entire Servicemix dependency library is not so great.
- GUI designer not a critical issue. It is very easy to code modules, so I do not think a fancy GUI drag 'n drop is a must for novice developers to be very productive using Servicemix.
However, A useful "GUI view" would be something that graphically depicts the relationship between all the services and endpoints.
- Provide "helpers" for integrating things like source code repositories and continuous build environments.
- Servers are cheap, developers are not. A 10% improvement in developer efficiency is worth far more than a 10% improvement in Servicemix performance.
A good portion of the low hanging fruit centers around making it easier to manage Maven configuration. I believe if you make it easy to get some basic things done, that it will lower the learning curve for a novice developer to be more productive. As a developer is successful in deploying projects on Servicemix, he will gradually become more versed in Maven-- as opposed to how it is today, where you need to be well versed in Maven before being successful developing on Servicemix.