>> XML is a document formatting language. Not a transfer protocol. XML does
>> not do error handling, retransmits, keepalives, etc... If you use raw
>> TCP sockets, you need to reinvent all those wheels.
>
> You send an XML document explaining what method you want to call. The
> server sends back an XML document either saying it went OK, or
> describing why it didn't. Provided you standardise the XML, you don't
> particularly need anything from the transport protocol.

How would you implement splitting the payload across multiple packets, 
with a direct socket connection?  How would your server know the 
difference between a malformed XML document with missing closing tags 
and a missing packet?

How do you tell your server (or client) that there should be more data 
coming?

How do you handle errors?

The answer is to reinvent XML wheels that already exist in HTTP.

>
>> In an entreprise setting. you need to do application layer parsing of
>> your traffic to ensure that, amongst other things, PII does not excape,
>> so using HTTP means that a third party firewall will be able to do deep
>> packet inspection out of the box.
>
> How does HTTP have any baring on this?
>

Everyone knows how HTTP is defined, so it's easier to find the relevant 
data in an HTTP stream, than in a proprietary protocol.

>> Also, HTTP is very easy to proxify, so your application will work in
>> most entreprise settings, without having to resort to Socks, or other
>> forms of tunnels.
>
> If you're trying to send commands and replies, the *last* thing you want
> is some proxy caching it for you...
>

I'm not talking about caching, I'm talking about relaying.  Most proxies 
are indeed caching proxies, but their priamry function is to relay 
traffic from one network to another network and keeping both networks 
isolated.

> This is the fundamental problem with HTTP. It's designed to transfer
> static documents, not ephemeral commands and replies. Sure, if you bash
> it hard enough, you can just about make it work. But that's like saying
> that you *can* use a vegetable knife as a screwdriver...
>

You are correct, that there are more specialized messagin protocols out 
there (most of them proprietary), such as IBM MQ-Series or TIBCO 
Rendezvous, just to name them, that are more suited to handling 
ephemeral commands, than HTTP, but most of the civlized world has no 
problems whatsoever using HTTP (or more often HTTPS) to exchange data 
between systems and even companies.

Since the makers of WCF do not know ahead of time what you will be doing 
with their framework, they decided to pick the most widely used tranfer 
protocol to make most of their users' life less miserable.

>> You may not need this robustness in your isolated test bed environment,
>> but the makers of the WCF framework can't (or shouldn't) assume that no
>> one will ever release one of these apps into the wild.
>
> OK, well that's fair enough. But let *me* configure how I actually want
> the thing to work.
>
> [In fairness, WCF *has* the capability to configure it the way I want
> it. It's just that the Mono implementation is broken - it blatantly
> ignores my configuration settings!]
>

Well, the Mono project webpage fully acknowledges that their support for 
WCF is limited.

>> As I mentioned in my previous message, there should be no relationship
>> between the TCP connection and the application session. Your
>> application, over the course of a single user session, may need to
>> create and teardown multiple TCP sessions with the same server. Or at
>> least, this would be the smart way of doing it. You shouldn't have to
>> rely on TCP's limited error-handling to survive a network glitch.
>
> I don't see why you would ever need more than one TCP connection -
> unless you're actually trying to issue multiple commands simultaneously
> or something...
>

In your particular case, maybe, but you are using a general purpose 
framework that is built for general use.

Let's say a travel agent is discussing various possible plane/hotel 
combinations with a client.  She shouldn't "hog" a tcp socket open for 
minutes while the client makes up his mind, nor should she have to 
re-enter her credentials everytime she checks the availablity at another 
hotel, or makes the final reservation.

In the background, the application would open one session and issue a 
session ID, after having verified the user's credentials.  Then after 
that, whenever the travel agent makes a query through her reservation 
system, the client-side application would open a new TCP sessions, 
include the application ID inside the payload and send one (or more) 
commands to the server.  The server would send the reply and the TCP 
connection would then close to leave resources available for the next agent.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message