You may have an internal SharePoint site which is extended to an Extranet or Internet zone.  A simple InfoPath browser form will work fine in both zones without modification.  But when you add data connections to connect to an external web service, such as DBXL, it can become problematic.  When using Alternate Access Mappings (AAM), SharePoint will redirect calls to any referenced internal url to the url of the site the user accesses the form.  Say you have an internal site http://sharepoint, and is extended to the extranet zone as http://portal.domain.com.  If your form has a data connection to http://sharepoint/QdabraWebService/DbxlDocumentService.asmx ,it will be redirected to http://portal.domain.com/QdabraWebService/DbxlDocumentService.asmx when opening the form from http://portal.domain.com. 

When DBXL is installed, it is installed under the SharePoint site selected during installation.  In this scenario, it resides on http://sharepoint.  So when the form attempts to access it through http://portal.domain.com, it cannot be found.  To remedy this situation, and allow the browser form to submit without special casing the extranet scenario, you can create a QdabraWebService virtual directory under the extranet site which maps to the physical disk location of the QdabraWebService on the internal site.

Creating the virtual directory will vary slightly between IIS6 and IIS7. 

In IIS7:

1) Open IIS Manager

2) Right-click the extranet site, select "Add Virtual Directory"

3) Provide the Alias "QdabraWebService" and physical path of the QdabraWebService under the internal site (e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\80\QdabraWebService)

4) Right-click the newly added QdabraWebService directory under the extranet site and select "Convert to Application"

5) The DBXL webservice APIs are now available on the extranet site and an IPFS form using DBXL services should now function.

In II6:

1) Open IIS Manager

2) Right-click the extranet site and select "New", "Virtual Directory"

3) Provide the Alias "QdabraWebService" and physical path of the QdabraWebService under the internal site (e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\80\QdabraWebService) and configure for "Read" and "Run Scripts" in the permissions dialog.

4) The DBXL webservice APIs are now available on the extranet site and an IPFS form using DBXL services should now function.

The document and template urls will not function on the extranet site.  Accessing http://portal.domain.com/QdabraWebService/Forms/MyForm/template.xsn will result in an HTTP 404 Not Found.    These access methods can be enabled by additional configuration of the virtual directory, but is not recommended.  IPFS forms should be opened from the SharePoint site to function properly in both intranet and extranet scenarios.