XML integration: Buy or build?
Published: 03 Oct 2002 12:03 BST
The System.XML namespace includes support for XML readers or the XML Document Object Model (DOM), which can take source files and convert them to their XML document equivalents based on predefined XML Schema Definitions (XSDs). Once converted to XML documents, the built-in Extended Stylesheet Template support allows you to write XSL templates that automatically convert files between different document schemas. Also, you can load an XML document into a standard ADO.Net data set using its schema and use any coding language to write out a new data set, effectively performing a translation. The DataSet.WriteXML command will produce a well-formed, valid XML document from the resulting data set.
Once you have the converted XML document, you can either send that document to the target system or create a new file in the format the target system expects. You can produce a file from the transformed XML document, written to the target system's expected format using an XML writer. Finally, you can use functions in System.Web to post data to a remote server using HTTP (System.Net.WebClient), FTP (System.Net.HTTPWebRequest), or sending it to the remote system using SMTP (System.Web.Mail).
BizTalk
Building your own XML messaging engine for a small number of installations or endpoints may be the most cost-effective choice. But it requires intimate knowledge of a family of XML protocols (i.e., XML, XSLT, XSD, and XQuery) and communications protocols (i.e., TCP/IP, SMTP, and HTTP). Unless you develop a custom workflow engine with a simple end-user interface, you'll also end up developing custom code around the business process that consumes multiple XML messaging transactions. For example, if you have a system that sends orders to a remote system for shipping and then needs to receive shipping information to update the local database, you'll have to wrap your XML messaging system with this business logic by developing custom code for each unique instance.
BizTalk solves several of these problems for you. First of all, BizTalk has a document editor that makes it simple to define transformation documents. The BizTalk Mapper allows you to develop transformations between two predefined XML documents. It even allows you to write custom functions (functoids) that can do specialised processing on data. Also, you can call your own processing routines from within a BizTalk transformation. BizTalk's Message Manager allows you to build ports and channels that handle the underlying protocol plumbing without having to write any code. The BizTalk Administrator allows you to define receive events that replace the Windows services you'd have to create to handle the workflow. Finally, the BizTalk Orchestration engine uses Visio to allow architects or business analysts to visually design the workflow process around multiple transactions and systems and then turn the design over to a developer for implementation.
Choose your path
If your system designs call for complicated or repeated development of XML messaging systems, you should decide in advance to pursue one of two paths. The first option: Develop your own set of standard tools that extend the .Net Framework and allow you to create repeatable and supportable XML messaging solutions. The second is to begin by supporting BizTalk in your applications. Although BizTalk has an associated server licensing cost, you'll recover the cost of the license many times over in the cost of maintenance associated with a custom solution for a system with large numbers of connections or endpoints
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
Previous
Did you find this article useful?
47 out of 97 people found this useful
- Share this article:
