quite a lot of coding

[elwis]

I have been reading and playing with JBossESB for the last week or so, evaluating it for a bunch of complex projects we are about to do at work.

I don't know JBossESB at all, I've read some guides, watched some webinars and have taken a look at the quickstarts. I think theres a lot of nice stuff worth to take a closer look at, but one think came to my mind.

There seem to be a lot more coding required in a JBossESB integration? Theres actions to code and theres a bunch of xml files that needs to be present in every project? I'm used to Webpshere Message Broker where I do drag'n drop mapping of files and the only coding might be couple of lines of ESQL (*yes I know.. sigh*).
I also took a look at some GlassfishESB screencasts and they too seem (although movies are good at lying) to have mostly drag'n drop developing.

Is that the way it is, am I whining or am I doing it all wrong?
(see, thats why I would like a more complete "getting started with this complex project guide")

Oh, but a good thing already came out of this evaluation, I bought two groovy books :)

Regards
Stefan
Sweden

[elwis]

No luck, I know I will hear this argument from my colleagues when I hold my presentation.
I hoped for some arguments I could use ;)

[beve]

Not sure if you have checked it out already but JBoss Developer Studio contains a plugin for ESB Development:
http://www.jboss.org/tools

Regarding the amount of coding required. This will vary depending on the use cases you are going to implement. Since writing actions is very simple this also gives you flexibility if one of the out of the box actions does not do the work you require. Also unit tests are easy to write against the actions which I think is a plus.

I've previously worked with an integration platform that promised almost no programming using a drag and drop development process, but we soon discovered that this was quite far from the truth. But this might not hold true for the products that you have looked at.

My opinion is that the that best thing let your team evaluate and decide what to use.

Regards,

/Daniel

[elwis]

Thanks for answering.

Yes, I'm with you, there are two sides of "automagic coding". It is great when it works and it does as you expected it to do, but its hell when it doesn't and you try to find why.
Sure, I don't love XML but if I need to write it once, I'm ok with it.
Coding the actions doesn't seem that terrible when I consider using Groovy, which seem to be fast and simple and fit well for this task.

All of us won't have time to play with JBossESB, if my presentation makes it interesting enough we will educate some of us and then go for it. So, I have a lot to do, I hope it will snow and rain in sweden this weekend ;)

[beve]

Let me know if you'd like to get in touch with some Swedish companies that have been working on JBossESB projects.
If you do go ahead with JBossESB it might be nice to have someone with experience starting up a new project, perhaps a sort of "mentor". You can email me directly if this interests you.

Regards,

/Daniel

[tfennelly]

I'd like to second what Danny says here... there's no doubt that the "zero code"/"drag and drop" solutions are definitely easier to sell in many situations and to certain audiences. In my experience however, these solutions are not always the easiest to maintain. Sure, for some of the more basic use cases, you can drag and drop a solution together in a snap. This is very impressive for a staged demo etc, but in my experience, the abstractsions involved nearly always break down and when they do... you're invariably left stuck in the limitted virtual work that the drag and drop solution has provided for you. Then you have situations where the solution that was built 2 years ago was built with an earlier (and incompatible) version of the tools than you're using today... we all know the sort of heartbreak this can bring :)

That said, I know that such tools are high on the agenda. Danny mentioned the ESB plugin for eclipse and there is also other work going on wrt a data mapping tool. So, these tools are on the way, but my bet is that for "super users" (people that have to use this stuff on real projects), they will nearly always have to have the ability to drop down to the lower levels at some time or another.