BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles EIP Designer: Bridging the Gap Between EA and Development

EIP Designer: Bridging the Gap Between EA and Development

Enterprise Integration Patterns - EIP for short - is an original work by Gregor Hohpe and Bobby Woolf that provides a consistent terminology and notation to design and document integration solutions independent from implementation technologies. The companion book - also named Enterprise Integration Patterns - was released in 2003 and contains something like 65 design patterns helpful for people involved into messaging and middleware systems design. Despite being on a growing usage trend - noticeable by the number of available implementations - EIP has not yet found the place it deserves among architecture and design practices, surely because of the lack of tooling.

This article introduces the EIP Designer project I have been working on for some months now and that is available on GitHub. It aims at bringing some background reflexions that led to the project’s genesis. My goal here is to explain how using an EIP design approach and associate tooling can help providing fluidity and continuity whilst filling the gap existing between Enterprise Architecture practices and concrete software development.

Why EIP?

Everything started last year, as I was involved into a Request-For-Information (RFI) on the state-of-the-art integration and Enterprise Services Bus solutions. During some brainstorming sessions with colleagues on how to specify the features and patterns we would like to implement within this kind of product, we ended up with a set of enterprise integration patterns describing some clean routes as canonical patterns. Actually, I was the one who introduced this idea, and everyone else was just fine with it. I know and use EIP as much as possible in any communication, both formal and hand-drawn on a blackboard during design workshops, and this approach is just pleasant to me.

But why EIP? As Principal SOA Architect in an insurance company, I have dealt with projects having middleware or integration problems for years. And in spite of the growing microservices trend - and I'm enthusiastic of this paradigm shift -, and the fact that we focus more and more on the web and mobile APIs, there's still a tremendous amount of plumbing to be done in order to reuse existing systems and applications. The integration of existing or legacy systems is the usual way to go in order to build reusable "Enterprise Services": one should focus on new business features and most of the time cannot “reinvent the wheel” by rewriting older system! In this context, we regularly deal with the problem of the right way to specify and describe the internal behaviour of such "Enterprise Services"; and in the past we often ended up with the usual "UML Sequence Diagram" suspect. Until recently, when we introduced the EIP notation providing clarity and expressiveness in the "Enterprise Services" context.

UML is a fantastic software engineering tool and it is useful in many ways. However, it happens to hurt you when used to describe complex orchestrations that may imply conditional routes, iterations, parallel invocations and join-points. Not saying that it's not possible, but it requires a good mastering level of UML and the resulting diagrams are usually tricky to read and understand (see for example this great introductory article). We found that such diagrams become difficult to share and use by a team.

While working on my RFI on integration solutions, after many tests, many proof of concepts, and vendor meetings, we were just astonished how poorly and "vendor-bloated" were the solutions embedding an "EIP view" within their product. Either the "EIP Support" label was just a marketing tag and we found it non-trivial to do the matching between solution components and patterns (despite the fact that a real matching always exists) or the design view presenting EIP was just not usable because it only provided an abstract representation of the source code, not a real design.

Enterprise Architecture and EIP

In addition to my +10 years of SOA background, I was led more recently (about 3 years ago) into considering Enterprise Architecture methodologies and frameworks (TOGAF, Archimate, ...), with a focus on how to integrate EA into the IT value chain while bringing continuity between activities: from high-level architectural design to operational activities delivering software. In many EA frameworks, the notion of "Service" coexists with the concept of "service dependencies": a way to tell that a service needs others in order to perform as expected. Because they embrace a wide scope, EA frameworks don't go beyond identifying services, providing no way for describing a service interface or behaviour regarding its dependencies - whether they are used once, multiple times, in sequence or in parallel. Thus, these activities should be done outside of EA activities, prior to the service implementation like illustrated in the schema below when reading top-down:

The Service Interface specification part is an "easy problem" because many meta-models now exist regarding how exchanged data should be described and what are the actual parts of a service interface contract (see for example OASIS RAMP, The Open Group SOA Ontology or API design methods such as Swagger or RAML and one of my previous blog post on the subject). It appears to me that the Service Behaviour specification part has not yet been deeply explored and I haven't found any standard nor mainstream solution for filling the gap between EA activities and realization for now.

So I was wondering why EIP had not been considered as a possible extension for Enterprise Architecture methods, frameworks and Domain Specific Languages as it brings formality when wanting to describe some integration or orchestration process largely involved when defining composed enterprise services.

The merits of an EIP Designer

By assembling all the above observations together, it comes to mind the idea that EIP can be used in a top-down process:

  1. where Enterprise Architecture activities identify enterprise services and their dependencies,
  2. those services and dependencies being inputs for a proper design of integration route using EIP,
  3. that EIP design being in turn an input asset for an implementation based on integration solutions (the main one supporting EIP directly or indirectly as stated before).

And because real life is never a top-down process but an iterative one, feedback and adaptations may be necessary as depicted by the ascending arrows shown in the diagram below.

And this is where the EIP Designer comes into play. Its goals are to provide:

  • a convenient, vendor-independent way of specifying a service’s behaviour by designing integration routes using an EIP Domain Specific Model approach,
  • accelerators for generating skeletons for common integration frameworks (Spring Integration and Apache Camel are supported with optional extensions for now),
  • control tools for architects and designers to compare final implementations with their original EIP design in order to verify compliance or adjust the model or even the service dependencies as needed,
  • and, finally, adapter and bridge mechanisms to plug this EIP Designer as an extension of other specific Enterprise Architecture designers.

Technically speaking, EIP Designer is just a bunch of Eclipse plugins that let you bring some of these features into your favourite workbench(s). The core designer module is done with Sirius and the use of underlying Eclipse EMF technology made it simple to write customizations using proven tools like Plugin Development Tools or Acceleo.

Following is an example of using the designer.

Sample usage

We are going to show here an ideal top-down activities process, but each module, including the designer, can be used independently.

First, let us consider an Enterprise Architecture activities process and an EA tool such as a TOGAF, Archimate Designer or any custom EA tool. During this phase, we’ll identify the enterprise services and their dependencies as shown in the screenshot below.

In our scenario, we have identified the BookingTrip service as having a dependency on the PurchasingTripToPartner service (see Properties tab below). EIP Designer allows to introduce an accelerator, providing a bridge between EA and its core designer:

The “Design an EIP Route…” contextual menu item enables navigation from the EA Designer to the EIP Designer and initializes a new Route by retrieving target service dependencies and making default connections (an invocation of the PurchasingTripToPartner service here). This example shows the integration with the Obeo TOGAF Designer, but such integration can be easily done in any Eclipse based modeler whether it is using GMF, Graphiti, Sirius or another. In fact, it can be done from any Eclipse tooling.

Following this first step, the EIP design activity can now start. As shown in the above screenshot, the EIP Designer provides a palette with EIP primitive Endpoints that can be assembled using Channels. At the end, the result may be something like this:

(Click on the image to enlarge it)

Starting from the left, we enter the Route through a gateway, transforming data by normalizing client objects, filtering invalid clients, checking clients using a service callout and entering a composite step. Within this composite, we split the message and iterate through clients, routing “Gold” clients to a “GoldService” and default ones to a “DefaultService”, aggregating everything before exiting and reaching the out gateway.

At this point, the EIP Designer offers a second set of accelerators allowing the generation of a skeleton to be used for bootstrapping the implementation phase to come. One may choose to generate assets for Spring Integration and Apache Camel, the later allowing generating routes in XML or Java.

The goal here is not to have a full blown generator that will generate everything but rather a skeleton that may speed up development while leaving the expert with the responsibility to add the detailed endpoint configurations, translate and optimize the filter and selection expressions, bring the monitoring requirements, and so on. I believe that the EIP Designer should be limited to design and do its job whether we use JMS, AMQP or HTTP protocols, whether an expert wants to insert intermediate transformations or debug messages, etc.

Finally, when development is done, the EIP Designer can be used for a compliance check via one of its extensions accessed through the “Compare with EIP Design…” contextual menu:

On the above capture, we can see that a developer has deleted a Router endpoint. From this point one can proceed with implementation or further refine the design, including an upwards realignment process.

Further considerations

We have shown during this sample some of the features that the EIP Designer provides. Another use case is porting a set of integration and mediation routes to another solution. Or, perhaps the complete documentation or models for each implemented route is missing. A solution could be to solve the problem with the EIP Designer and its toolchain. It provides model comparison from sources, and it also has parsers to transform source assets into an EIP model and from that model it is easy to generate bootstrap skeletons according to a migration plan.

I hope this article has convinced you to give EIP Designer a try.

About the Author

Laurent Broudoux  is the Principal SOA and IT Architect at Covéa, a leading insurance group in France. Within Covéa he is a contributor to the Digital Transformation program, involved into Information System transformation and definition of Web and Mobile integration strategies. Within MMA Insurance - a Covéa company - he used to led SOA and JEE teams and was in charge of defining the technical foundations on the following fields: Enterprise Architecture method and tooling, SOA urbanization principles and infrastructure, Model Driven Engineering and continuity with the software factories. 

Rate this Article

Adoption
Style

BT