When we were doing the initial design for this tool, we had the idea that there would be two icons on the palette for each endpoint. One would be an input endpoint, the other an output endpoint. Quite clear in terms of the semantics.
Camel is such a diverse beast, however, that with the huge number of endpoint styles available, it would mean the palette would be potentially enormous, which makes the tool more difficult to navigate.
So, right now, when you put an endpoint from the palette on the canvas, it's potentially bidirectional. When you wire it up, you've made the choice of whether it's to be an input or an output endpoint. What I think is confusing with the current approach is that once you wire an endpoint, the other port is still on the canvas.
Maybe a good approach would be to make sure that once an endpoint is wired up in a configuration, the other ports just disappear off the canvas. Then the semantics would be clearer. What do you think?
It's a good idea to suppress ports which are meaningless. But I think you have a more genral problem related to your graphical notation. Spagic 1.0 had the same problem : in my opinion each in-out component SHOULD have an additional response port. Without that, the design can become very complicated to do. For example in the simple chain : BC1 - XSL - BC2 how can I simply return the response of BC2 directly to BC1 ? impossible without the EIP Return-Address. Spagic introduced the "synchronizer" component to solve the problem but it is not a clean solution.
The other problem is related to errors. I thik each component SHOULD have an error port. without that it is not clear how to use the dead-letter eip.
A good idea is maybe to look at BPMN 1.1 which addresses in a very clean way error processing. Is seems that Spagic 2 has taken this way but the result is not satisfactory because we loose the eip graphical palette.
I think that the day you find a solution for these 2 problems you will have the killer ESB IDE!
Willy - I appreciate your creation of the document to show us what you mean, that makes it very clear. We'll certainly hold your suggestions under consideration as we advance the look and feel of the EIP designer.
The Return Address enterprise integration pattern is interesting, and we will certainly be looking at putting capabilities into the once the Camel runtime supports the approach - I took the liberty of putting a new feature request into the Camel JIRA.
We want to stay with the EIP palette rather than going top BPMN 1.x, so creating an error port on the EIP nodes in the graph sounds like the best approach to resolving this. I added a JIRA for this.