Visual Integration Patterns
I’d like to know what people think on this subject.
Right now, today – there is a certain degree of expection that Business Processes – which are typically quite “step-by-step” – have a visual tool that allows (non-)technical creators/editors/debuggers to Create/Edit/View them. This is fine for Business Processes – their “flow” is typically represented as a “step-by-step” process, with some basic conditional routing. Importantly, typically in a Business Process, all the possible routes are pre-determined. At this level, we can focus our attentions at the service-level – we dont necessarily care where (or how) each service is invoked. So the BPEL “routes” are relatively straightforward in design. Which lends itself well to a “Drag and Drop”-style GUI tool.
So I find myself recently asked a similar question about (Enterprise) Integration Patterns. Because the very nature of these messages are much lower level, they have a much greater ability to create more complex flows. They are concerned with much more “physical” attributes, compared to a Business Process. An Integration Pattern typically DOES care “which server”, “which protocol”, etc. The real problem comes with the complexity of the “flow”. When the flow is conditional, and the possible routes are NOT explicitly stored in the flow, then it becomes much harder to represent this visually. I refer to patterns like Routing Slip, or where custom Java-DSL routes are defined that internally decide how to continue to route a particular message. How can we draw a “chart” of the flow of data through an Integration Pattern, if we don’t know up-front what the flow is going to be?
I’m of course picking on the more difficult EIP’s rather than generalising, but you see my point, right? What good is a tool if it can only (visually) represent some of the patterns?
Despite this, there are already efforts to visually represent Enterprise Integration Patterns. I’ve seen examples of ESB design tools in what was Oracle SOA Suite (not sure what exists today after the BEA/Oracle technology merge). Although the scope of this was somewhat reduced – I certainly didn’t see many Integration Patterns represented in there. More recently the Fuse product team have created the Fuse Integration Designer – which aims to visualize Apache Camel routes, and include other components such as CXF and Spring-based beans. Finally, more recently, the Sun team have been busy working on tooling for Project Fuji – which also looks promising.
But my question is this – how far can this realistically go, and what will it really be used for? How important is visual tooling for Integration Patterns. I can see the benefits to the developer – the ability to quickly “mock up” 50-80% of an EIP project visually clearly saves considerable time. But once that route includes non-visual aspects that affect the route (components that cannot be visually represented) – how useful is it then? Can it still be edited? Debugged? If we are debugging, and the runtime suddenly dives into a pattern we can’t represent, and then crashes – how valuable is this?
My main concern is that it will encourage “sloppy patterns” – patterns that avoid using non-visual components, because it’s easier to stick to the components that can be created and edited in the visual editor.
Or is there really an answer that enables all components to be represented visually? The only solution I can think of is to split EIP’s into “stages” delimited by endpoints. So every single start/end route combination has a separate view. Then a design/edit/view/debugging tool can “jump” from one diagram to another, without losing the context. Clearly for internal java-based errors, we will still need to jump into the code – but it might enable better web-based “first line” debugging to take place to focus the problem onto a particular EIP “stage”, or better still, a particular component…