To make integration code simple, flexible and fast, you need to separate technical code from business code, use integration layers wisely, and be aware of different ways of processing XML.
Separating technical code from business code simplifies coding and testing, and makes it possible to support multiple data transfer methods. Design business code so that it does not care whether data is sent using messaging middleware, files, or in-memory calls.
If your system already has a well-defined programming interface (API), but not one that is suitable for broad integration, build or acquire an integration layer to map between the API and your integration standards. For example, I have used a separate integration layer to map between XML messages sent on IBM's WMQ messaging middleware and calls to and from Oracle PL/SQL stored procedures.
Not all integration layers add value. I have seen some which have required the business code to call the layer's API, which is simply the wrong way around. It would be just as easy to hand code the integration without the additional layer.
Resist the temptation to add snippets of business logic to the integration layer, even though it may seem a quick and simple solution. It is very easy to lose sight of business logic in an integration layer. Keep all the business logic in the core system.
Programming with XML can be daunting. You can make it less daunting by using only simple XML structures. You also need to pick the most appropriate approach for processing XML.
Event-based XML processing, such as the simple API for XML (SAX), invokes your code as it reads an XML message. It is more suitable for technical programming than for business programming.
Object-based XML processing, such as the world wide web consortium (W3C) document object model (DOM), reads an XML document into memory and then allows the program to query the XML. DOM-based XML processing is widely available. Use DOM-based processing where it is available, where performance is not a major consideration, and when XML documents are not huge.
The W3C DOM API can be daunting. Consider writing some additional routines which simplify the main XML processing tasks that you need. An example is available at http://www.minimalit.com/integration/xml_helper.htm.
Pull-based processing, such as the streaming API for XML (StAX), involves calling a parser repeatedly to retrieve each item in the XML document. This is very fast, and can process documents of indefinite size.
If you are using an older language for which there is no XML support, such as COBOL, it is relatively simple to write your own pull-based parser. This provides a much more "traditional" view of XML than the other methods. For example, I have developed adapters which call a pull-based parser, and then present the data to legacy program using file-like semantics.
There is no silver bullet for programming interfaces. Be sceptical of tool vendors that promise to make it easy. In my experience, hand coding is usually the easiest way. But with a little forethought and care, it is possible to build simple, flexible and fast interfaces.