Adapted from the following presentation:

“Testing an EAI Implementation”

Matt VanVleet
VP Product Development and Practice Management
Pillar Technology

Enterprise Application Integration Alliance
Columbus, Ohio
http://www.meetup.com/Enterprise-Application-Integration
4/8/2010

Before I begin, I want to give my thanks to Matt VanVleet of Pillar Technology for giving us his time, knowledge and experience for his presentation.  Most of the following article is directly from, or inspired by, what he shared.

I also want to thank the members of the Enterprise Application Integration Alliance for attending.  Without them, valuable presentations like Matt’s would not be possible.

Now to the topic at hand…

If you look at the architecture of a standard Enterprise Application Integration (EAI) implementation, it typically consists of a series of independent applications or systems that are loosely-coupled to one another through a central integration system (such as an Enterprise Service Bus).

EAI projects usually consist of 4 phases, each of which create unique challenges to the enterprise:

1. Implementation
2. Upgrade the EAI
3. Upgrade the Back-end Systems, Data Warehouse or Applications
4. Upgrade a 3rd Party Integration

1. Implementation

When EAI projects are started, the EAI team typically works closely with the teams that are in charge of each application that needs to be integrated.  Each team needs to cooperate with the development, documentation, and testing.  They also need to coordinate releases so that the integration does not break if some critical component or feature of the application or the EAI system itself is being upgraded.

Since so many teams are involved and the implementations are complex, the cost of implementing an EAI system are high.

In addition, since releases need to by sync’d across the enterprise, it slows down the speed of development and adds at least one additional layer of management.  Furthermore, while each endpoint is loosely-coupled to one another, it is tightly coupled to the EAI system itself.  Each EAI-to-endpoint integration creates a potential point of failure, so each change needs to be thoroughly tested before being deployed.

2. Upgrade the EAI

Once an EAI implementation is in place, upgrading the EAI can be as time consuming and expensive as developing the EAI in the first place.  Each team has to brought back together the plan, develop and synchronize the upgrade.

3. Upgrade the Back-end Systems, Data Warehouse or Applications

Some of the teams will be needed for this upgrade, including the EAI team and the team in charge of the application being upgraded.

4. Upgrade a 3rd Party Integration

The EAI team will be very involved in this, and it may require the coordination and help of the 3rd party service provider that you are integrating with.

Issues

Since each of these systems is now tightly-coupled to the EAI system, upgrades at any point along the enterprise become major events.  One slight change, unless properly planned, managed and tested, can have a significant impact at some other end of the enterprise.

As the enterprise generates more and more data, the EAI implementation is put under more and more load.  What could be simple tweaks to the persistance layer or server configuration now involve much more risk.

Also, once an EAI implementation is in place, it never gets the attention that the applications themselves get.  Since EAI is behind the scenes, it tends to be an afterthought when it comes to the corporate budget.  It’s necessary, but it’s not “sexy”.

What is the best way to manage this?  How can you ensure that your EAI system is stable, while allowing the teams responsible for each application to be as autonomous as possible?  How can we decrease the upgrade cost of an EAI and also make it flexible enough to now slow down the application developers?

Solution

If you look at an EAI implementation as a central data system and don’t worry about how it works on the inside (which is a reasonable assumption when you are just dealing with interfaces), you can simplify it as a black box connected to a series of interfaces: Application-to-EAI, Data Warehouse-to-EAI, Web Service-to-EAI, etc.

At each interface, you can then divide the interface into two halves: 1) Application-side and 2) EAI-side

If you are an application developer, you are developing your application to work with the interface that the EAI implementers expose.  It could be a database socket, a web service, flat files, messaging, etc.  This is essentially the same for the Database Warehouse and Back-end systems (such as SAP).

At each interface, there is typically inbound and outbound traffic.  Some of the traffic will be the result of the application itself (such as adding a customer to a CRM which is then forwarded to the ESB), some of the traffic will be responses to data sent by the application (a reply from the ESB), and some of the traffic will sent without any aparent trigger (the ESB sends a message to the application, caused by new data from another application).

To ensure that your EAI implementation and the applications are communicating properly, you can put tests in place to make sure that the systems respond properly.  You can also develop simulated systems, also known as mocks, that act like the system that is at the other end of the interface.

These tests and mocks can help you during any stage in the lifecycle of your EAI implementation:

1. During development – Test your applications and ESB, independently, to make sure that they respond to events in the right way.
2. During production – Regularly test your applications and ESB to identify any mismatches or problems immediately.  With up-to-date tests, it is even possible to detect defects in the system that were somehow missed by a development team.  You can then respond proactively and disconnect the communication to the bad system, for example, to keep the other systems across the enterprise running properly.

Now, let’s use the internal application-to-EAI implementation interface as an example.

Application-to-EAI Testing

When you are developing an EAI or application to be compliant with the Application-to-EAI interface, there are 4 test assets that need to be developed in order to assure that both the application and EAI system are working properly.

1. Mock of EAI Implementation – Used to test the application against an EAI system that responds correctly to requests and generates application-bound traffic.
2. Test of Application interface – Used to test the application to make sure that it responds properly traffic from the EAI implementation.
3. Mock of Application – Used to test the EAI system against a fake application that responds correctly to requests and generates EAI-bound traffic.
4. Test of EAI interface – Used to test the EAI system to make sure that it responds properly to traffic from the application.

3rd Party-to-EAI Testing

If you are integrating with a 3rd party, the layout is the same.  However, there may be a larger barrier between the EAI team and the 3rd party team.  In that case, you probably will have to assume that their testing is in place, or work with them to ensure that they have their tests and mocks in place.

If they don’t have a valid mock system (which, unfortunately happens), you may have to build a mock internally using what you can learn about the 3rd-party system.

If you don’t currently have tests or mocks in place, one way to start is to use a “wire-tap” or proxy to log messages, requests and responses in order to build the test cases.

End-to-End Integration Testing

The necessity of testing an entire enterprise application can be significantly reduced by doing as much testing at the atomic level as possible.  By testing the application-to-EAI interfaces and the intra-EAI processing through EAI-specific tests, the need for end-to-end testing is, theoretically, eliminated.  If the tests cover all the corner cases, all the EAI processes and interfaces pass the tests, then the EAI is working properly.  At each interface, if all tests that invoke the mock services pass, then the applications work properly with the interfaces.  End-to-end testing, at that point, isn’t necessary.

However, there are commonly reasons for doing automated end-to-end tests just to “be absolutely sure” that data is flowing from one endpoint application to another.  In that case, it requires the collaboration of the application teams in order to build the tests and observers for the full end-to-end tests.

Technology

These are a few of the many open-source applications that can be used to help you develop the tests and mocks.

Tests

1. jUnit (or a member of the xUnit family)
2. Depending on the EAI implementation, some IDEs (such as Netbeans w/ OpenESB) have testing integrated into the system.

Mocks

1. jMock
2. Apache Camel mocking
3. SoapUI (web service mocking)

Considerations

1. Someone has to “own” the specification for each interface.  Personally, I believe that the specification should be owned by each application team, in collaboration with the EAI team.  However, due to the complexity of the interface or the size of the implementation, it may be better to have the EAI team own the specification, or perhaps put it in the hands of a higher-level enterprise data architect.
2. Someone has to develop the mock of the EAI.  A collaborative effort between the application team and the EAI team usually work best to build the interface specification, and then the mock is maintained by the EAI team so that it is always up-to-date with the production and development EAI implementations.
3. Someone has to develop the tests for the EAI.  Again, a collaborative effort to build the specification is needed, and then the tests are maintained by the EAI team so that it is always up-to-date.
4. Someone has to develop the mock of the applications.  A cross-team collaborative effort is needed, and then the mock is maintained by the application team so that it is always up-to-date.
5. Someone has to develop the tests for the applications.  The same application-EAI collaborative efforts is needed to build the specification, and then the tests are maintained by the application team so that it is always up-to-date.

Summary

Testing and mocking for EAI implementations allows each team to stay independent by testing their applications against an interface and catching problems before they go to production.  This decreases the cost of developing and maintaining enterprise architectures by reducing the interdependence between each development team, as well as by reducing the potential for regressions.

In one case that Matt talked about, a company he worked with was planning an upgrade to their EAI system, which ordinarily is a very expensive process.  Matt’s company had created all the tests and mocks for their old EAI system, so during the upgrade, they ran all their tests and mocks against the new EAI and they were able to immediately find the regressions and fix them.  This decreased the development and implementation time by over 50-fold.

Testing of EAI implementation is becoming more main-stream, but does involve some investment up front.  That investment, however, will pay handsome dividends when you upgrade any of your systems in the enterprise and you need to retest to make sure that it works properly.  Automated testing, built once, can save you weeks of hand-testing during each upgrade.

Thanks again to Matt VanVleet for his presentation and to the members of the EAI Alliance for attending.  If you are in the Columbus, OH area and are interested in EAI at any level, from programmer through executive, be sure to sign up (it’s free), and take part in our meetings.  http://www.meetup.com/Enterprise-Application-Integration