XML Gateway Myths

There are some common XML Gateway myths that this post would like to dispel. These myths are a manifestation of vendors overwhelming the customers with the latest bells and whistles of their product without explaining to the user fundamental basic capabilities of the product.

Myth #1: FTP protocol is only used to transfer unstructured bulk data to our back end systems.

FTP (File Transport Protocol) is the workhorse protocol that is still used today for majority bulk file transfers between enterprise corporations. FTP maybe a legacy protocol, but this legacy protocol is one of the most reliable and interoperable file transfer protocols available today to businesses. FTP can be used not only to transfer unstructured data but it can also be used to transfer SOAP or XML data between various different systems. An XML Gateway provides the capability to support XML data transfers over FTP for inbound or outbound traffic. Alternatively, an XML Gateway provides the means to protocol mix between FTP and HTTP protocol. For example, an incoming HTTP protocol carrying XML can be transformed into an FTP protocol carrying XML data or vice versa.

Myth #2: We don't need to virus scan SOAP with attachments since we have a virus scanner deployed at the edge.

This notion that a virus scanner can take any incoming raw file at the edge of the network before sending it to the back end is sufficient for processing SOAP with attachments provides a false sense of security. First, most SOAP/XML incoming traffic from the internet is SSL enabled. A virus scanner at the edge is not capable of peering into the encrypted data that is being sent to the back end application servers. Second, even if the SSL traffic is being decrypted at the edge, it is possible that SOAP with attachments might be encrypted or Base64 encoded thus rendering a edge virus scanner ineffective. An XML gateway provides the capabilities to terminate SSL connections, perform content-level decryption, and decode attachments for on board virus scanning.

Myth #3: XML Gateways cannot handle non-XML requests for authentication and authorization.

XML gateways always had strong integration capabilities with traditional identity management systems. Authentication and authorization of inbound SOAP or XML traffic is one of the strongest pillars of an XML Gateway. Given the tie in with traditional identity management systems, XML Gateways are no longer relegated to authenticating and authorizing XML traffic only. An XML Gateway today has the same capabilities to authenticate and authorize non-XML data that one would find in a software web agent installed in a Microsoft IIs or an Apache server. In fact, XML gateways make it easier for enterprise users to manage the authentication and authorization of XML and non-XML (HTML) requests on a single gateway.

Enterprise customers that are deploying Service-Oriented Architecture (SOA) using XML web services should be cognizant of these myths. An XML Gateway provides rich functionality that extends its capabilities beyond traditional web services XML integration use cases.