2 Replies Latest reply on Dec 21, 2007 6:29 PM by mattrpav

    Servicemix Tooling Goals and Ideas

    mattrpav

      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.

       

      Thanks,

      Matt Pavlovich

        • 1. Re: Servicemix Tooling Goals and Ideas
          mwr0707

          Matt,  I'm coming from almost the same place, (webMethods and webLogic WLI/ALSB).

           

          I assume that when you say GUI designers are not critical, you mean the graphical editing vs the overall Eclipse tooling/templates.  I've noticed that with the learning curve for XSD and WSDL, the graphical schema and WSDL editors can help newbies grasp the relationships of the constructs more quickly.  I still use these because they don't slow me down, and often save me from typos.

           

          That said,  I couldn't agree with you more about your priorities, especially maven assists.  As always with Eclipse, the 64K question is: "What is the best project to own making maven more friendly?".

           

          In addition to all the points you mentioned, I'd add lots of step-by-step walk-through tutorials.  In other words, written versions of what is shown in the screencasts.  These might be more easily updated from one release to the next.  For more complex examples, this can also help with fumbling with the screencast play and pause buttons as you try to follow along in your own Eclipse environment.

           

          Regards.

          • 2. Re: Servicemix Tooling Goals and Ideas
            mattrpav

            For the GUI part, I mostly mean drag and drop "components" or "steps".  Designing BPEL-like workflows and doing the actual data manipulations by setting properties and using GUI mappings, etc.

             

            I agree with you on the use of the XSD and WSDL editors, and would encourage any ServiceMix tooling to leverage those existing tools from WTP.