Fog Creek Software
Discussion Board




What transport do you use for XML?

Earlier discussion on this forum showed that people are using XML for a variaty of applications; IPC, data format for storage, business transaction data exchange, HTML based reporting etcetera.  http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=17658 

Reffering to the data exchange users, I'm trying to determine the most common and/or preferred way of communication:
- How do you transport XML (eg plain socket IO, http, ftp, smtp, SOAP) and why this way? 
- When you have a business application which should request/accept data from a 3rd-party source, which transport would you need/expect?
- Who initiates the communication, producer or consumer?
- Any preferred 'standard'?

Gertjan de Back
Tuesday, March 11, 2003

The url gets a space appended to it - try this:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=17658

Duncan Smart
Tuesday, March 11, 2003

I've seen a system where EDI documents (bound to be XML if you were implementing it today) are emailed between nodes.  Daemons on the various systems monitored inboxes to respond to messages.

So add email to your list :-)

Jabber is really a promising way forward for sending messages between nodes.  It is designed with computer-to-computer in mind as well as user-to-user.

nice
Tuesday, March 11, 2003

There are pros and cons to using each
protocol, usually you are best served by
being able to send and receive using each
protocol.
Some real life examples from last week
alone:
* One of our client's uses a web/ssl service
to upload files, their corporate firewall
keeps timing out even though our web time
out is set to infinity.. they give up and
courier using CD Writables blanks.
* Another sets up a DMZ because of another
inflexible firewall situation (this was
talked about extensively in a thread on
Joel's forum but happened at my last job)
How do you get this into the database
securely? So they set up a FTP site with two
users, one can upload, one can download. The
internal network logs into the FTP to
download (PULL) what the external client
uploaded to the FTP server (PUSH). They have
to use digests to ensure no corruption and
authentication. They have to use encryption
to ensure no interception.
* A major mailing service refuses to take
anything bigger than 2 megabyte, customer
out-grew the limit with hundreds of
megabytes being hand-fed in chunks and can't
wait all day 1) clicking the web pick file
2) clicking go 3) waiting.. 4) checking
status...
* Some transfer processes are very well
designed (read elaborate), but all done by
hand.. so there are a lot of misnaming of
files or identifiers.. regardless of
protocol things needs to be automated to
reduce errors.
* The sender ignores the specification (no
special characters / CDATA around bad
data... ) and sends you junk. Your XML
parser or custom upload tool pukes and you
spend days figuring out what broke what.

* The list goes on.. I am afraid it's not as
simple as picking the perfect protocol...

-- David

Li-fan Chen
Tuesday, March 11, 2003

How about an actual messaging system, like JMS?

Bones
Tuesday, March 11, 2003

Bones:

I was thinking the same thing, but JMS only works within an organization, or two orgs that use the same JMS provider etc.

For the FTP people, use scp instead.  It is built on to of ssl so you are secure.

Peer to Peer apps (Jabber) are built on top of a lot of the issues a JMS provider has to deal with, plus firewalls and routing, as well as the fact that the target machine may not be on the newtowrk when you want to send (think cell phones)  Sun is pushing JXTA to do this in the Java World.

As a programmer I like the JMS api.  Ideally the programmer would use JMS and the tranport would be done using JXTA.

Whatever happened to MSMQ.  That is the MS equivalent to JMS.

Adam Young
Tuesday, March 11, 2003

Normally HTTP or HTTPS.

pb
Tuesday, March 11, 2003

HTTP

Prakash S
Tuesday, March 11, 2003

Is there anything open source or more basic like JMS or MSMQ? Just looking for something that can fire off POSTs with a pay-load of POST variables or XML.

pb
Wednesday, March 12, 2003

If you just want to fire off POSTs with a payload of XML as one of the query variable values... you probably don't even need Perl::LWP. But if the file is big enough you'll want auto resumption supported on both the server and the client.

Li-fan Chen
Wednesday, March 12, 2003

*  Recent Topics

*  Fog Creek Home