XML Gateway Alchemy

Rizwan Mallal

Subscribe to Rizwan Mallal: eMailAlertsEmail Alerts
Get Rizwan Mallal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SSL Journal, Intel XML, XML Magazine, SOA Best Practices Digest, SOA & WOA Magazine, SOA in the Cloud Expo, Microsoft Developer, CIO/CTO Update, Telecom Innovation

Blog Feed Post

Three XML Gateway Myths

Enterprise customers that are deploying SOA using XML web services should be aware

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.

More Stories By Rizwan Mallal

Rizwan Mallal serves as the Vice President of Operations at Crosscheck Networks, Inc. As a founding member and Chief Security Architect of Forum Systems, the wholly owned subsidiary of Crosscheck Networks, Rizwan was responsible for all security related aspects of Forum's technology.

Previously, Rizwan was the Chief Architect at Phobos where he was responsible for developing the industry's first embedded SSL offloader. This product triggered Phobos's acquisition by Sonicwall (NASD: SNWL). Before joining Phobos, he was member of the core engineering group at Raptor Systems which pioneered the Firewall/VPN space. Raptor after its successful IPO was later acquired by Axent/Symantec (NASD:SYMC).

Rizwan started his career at Cambridge Technology Partners (acquired by Novell) where he was the technical lead in the client/server group.

Rizwan holds two patents in the area of XML Security. Rizwan has a BSc. in Computer Science from Albright College and MSc. in Computer Science from University of Vermont.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.