XML integration: Buy or build?
Published: 03 Oct 2002 12:03 BST

Visual Studio .Net has rapidly become the platform of choice for building systems that support XML Web services standards. Because of its deep support for XML technologies, I've also seen it used extensively by corporations to build XML messaging solutions.
Even though XML has become the universal standard for data representation, companies still write and maintain programs that transfer data between applications and systems by converting one flat file format to another and then sending the file to a receiving system. This hard-coded program has a huge associated maintenance cost because every conversation between two systems has to be coded uniquely and updated whenever a file format changes on either side. However, companies are beginning to recognise the advantage of building or buying XML messaging engines instead of continuing to hard code these integration applications.
Basic functions of an XML messaging engine
Creating an XML messaging engine basically involves placing a layer between every system and the representation of its data. When an XML messaging engine processes a transaction, it first retrieves data from the source system and maps the data to an XML format. Next, it runs a transformation process, converting the source system's XML format to an XML format for the target system. If the target system accepts the XML stream, it sends the data to the target system. If not, the messaging engine converts the data from an XML document into a format that the target system can understand before sending the data to the target system. This process is reversed when receiving additional data or response data from the target system.
If written properly, the XML mapping layer greatly reduces new development and maintenance. If the source system needs to send its data to a new endpoint, the developer can use the existing source map and only needs to develop the logic to perform the transformation to the target system's XML format. If the source format changes, only the mapping engine has to be changed, and the target system mapping can remain unchanged. Now that the industry has standard protocols like TCP/IP, HTTP, and SMTP, and markup languages like HTML and XML, the plumbing is in place in most organisations to build integration applications. The real question is: Should you build one or buy one?
.Net Framework support
The .Net Framework does a great job of wrapping the protocols and markup languages and adding additional system support for creating custom XML messaging engines. For example, it is now trivial to create Windows services that can monitor pickup locations to start an XML messaging process.
Developing a workflow process that looks for uploaded or extracted files placed at a specific location is easy using the FileSystemWatcher class. The FileSystemWatcher class monitors the file system and raises events whenever a specified directory or file within a specified directory changes. This class can watch for changes within the directory to include subdirectories and can monitor directories on a local machine, a network drive, or a remote computer. Once your Windows service picks up the file, it can use the built-in XML support to process it.






