Since a SOAP message is transmitted in plain text

[Johannes de Jong]

William Brogden made the above statement in this thread
Now one of the things I've always considered to be a drawback of XML in general is that it uses a lot of bandwidth. Why did the "designers" of SOAP not add compression to the SOAP "layer" in the Webservices solution/architecture.
Actually am I correct in seeing SOAP as a layer and must I see Webservices as a solution or architecture ??

[faisal mahmood]

I assume compression is done in one of the lower layers of TCP/IP to avoid overhead. I am not sure if TCP itself is compressed.
Faisal

[Johannes de Jong]

OK first it gets put in a SOAP mesg then it gets handed over to the lower level which might compress it.
Makes sense actually.

[sridhar satuloori]

In any distributed application you have to send more data and objects back and forth. Soap is doing the same thing, might be compressing and decompressing the soap message(header+body) will take time.
Sridhar

Originally posted by Johannes de Jong:
OK first it gets put in a SOAP mesg then it gets handed over to the lower level which [b]might compress it.
Makes sense actually.[/B]

[Johannes de Jong]

The decision to compress is simply a matter of deciding where the bottle-neck is. If I have a slow network connection and a fast server/pc surely the best solution is to compress the data.

[faisal mahmood]

I know that my 56k modem has the capability to compress data. I don't know if SOAP compression is taken care of some-where else. i.e. is something else is taking care of this case?
Faisal

[William Brogden]

SOAP allows for compression and encryption inside a SOAP message by intermediate "Nodes" that the message is passed through. The XML Protocol group is still arguing about related things. The great bulk of SOAP messages, compared to XML-RPC for example, is one drawback.
I saw one note from a guy who compressed the main body of his message, then encoded the resulting byte array in base64 so it could be transmitted.
Bill

[Andy Rodriguez]

To my knowledge even the compression over the wire is only supported by Mr. Paul Kulchenko's SOAP :Lite and was not ( the last time i checked ) by Apache v2.1 ? or MS implementation , haven't bothered to check yet with W3c.org spec .
( http://cookbook.soaplite.com/#enabling%20compression )
My 0.02$
[This message has been edited by Skinner Seymour (edited November 08, 2001).]

[Kyle Brown]

You guys are right that Apache SOAP 2.2 doesn't support compression. However, the Apache Axis SOAP classes will. The ability to add services like compression, encryption or internationalization is a key part of the new Axis architecture.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Pho Tek]

Even if Axis supports compression (for an example); it would only be interoperable until some sort of standard is hashed out among different vendors. For example, adding Basic authentication to SOAP1.1 is a pretty common wish list and I've seen countless people reinvent the wheel over and over again. It's only now that a glimmer of a standard is being considered.
See http://www.zolera.com/resources/opensrc/i-d/soap-auth.html
Pho

[Johannes de Jong]

Kyle do you think that compression should be at the "Soap" level of the Web Services architecture or at another ie. protocol level.
Personally it amazes me that it was not part of SOAP from the beginning. But then I'm no expert on the subject

[faisal mahmood]

I would have preferred another protocol which allows for both encryption and compression. SOAP messages can be tunneled through this anonymous protocol.
The other option is TCP/IP handling it for us. Or may be at the hardware level (will boost performance)
Faisal

[Andy Rodriguez]

Compression and security were probably after thoughts , when the direction was towards "silver bulleting" webservices via additions to SOAP .

Originally posted by Johannes de Jong:
Kyle do you think that compression should be at the "Soap" level of the Web Services architecture or at another ie. protocol level.
Personally it amazes me that it was not part of SOAP from the beginning. But then I'm no expert on the subject

[Kyle Brown]

Guys, think about this.
SOAP normally (not always, but a lot) goes over HTTP. HTTP ALREADY has a perfectly good, strong encryption standard -- it's called HTTPS -- Everyone supports it, and it's used all over the world (you've probably used it today sometime!)
Compression is an option. It can be added after the message is composed. It should be added below the level of the SOAP spec, at the transport level. That's what Axis does -- it makes it an option that both parties can agree on. The compression information is carried in the Envelope and then the body carries the compressed data.
However -- people have been using HTTP without compression for years without problems. If you're writing SOAP communication that's so chatty that you really require compression, you've got bigger architectural problems than a SOAP implementation help you with...
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Andy Rodriguez]

I second that - and my thoughts are , we should be able to adopt SOAP as is and implement it in production rather than waiting for accessories to be added to it at the protocol level , at least when using it within the firewall , i dont see any reasons for other compression or ...

[Tiger Scott]

IBM is working on Digital Soap- it deals with encryption and authentication. They have submitted something to the standards body. I am not aware of compression. IBM uddi site has details.
Sanjay

[Johannes de Jong]

"However -- people have been using HTTP without compression for years without problems. If you're writing SOAP communication that's so chatty that you really require compression, you've got bigger architectural problems than a SOAP implementation help you with"
Point taken Kyle but there is one mayor difference here I think. Webservices will address/solve problems in the bushiness domain. This means that large files might be x-mitted across HTTP. XML & SOAP only increase the size of these files, so I would have expected SOAP to at least offer an option to compress.

[Jim Baiter]

I suspect there will be many issues with security in the web services arena. It is a different model than normally encountered.

[Paul Newton]

Jim -
I was interested in this comment. How do you see security of Web Services being different from that of other distributed environments (e.g. CORBA Security Services, EJB Security Framework)? Do you mean from a granularity point of view? as a service-based architecture? or simply from a logistical perspective?
Thanks for any feedback on this.
regards,
paul.

[William Brogden]

Microsoft has proposed extensions to 4 areas of the SOAP standard , several of these are security related. See: http://www.microsoft.com/myservices/services/userexperiences.asp

[Jim Baiter]

Although noone seems to mention this, HP (also the co-inventor of
CORBA) was the first in this web services stuff with E-Speak. They have found some interesting things in these areas - check the open source distribution at http://e-speak.hp.com

Originally posted by Paul Newton:
Jim -
I was interested in this comment. How do you see security of Web Services being different from that of other distributed environments (e.g. CORBA Security Services, EJB Security Framework)? Do you mean from a granularity point of view? as a service-based architecture? or simply from a logistical perspective?
Thanks for any feedback on this.
regards,
paul.

[Andy Rodriguez]

I dont think they were really the first , Microsoft as well were in that space when espeak was concieved , and espeak really described what webservices really meant back then , while M$ was doing the thinking. And i also remember reading an article by the espeak team which planned to webservice enable (espeak enable) their printers , so that any type of device in the building can print to it , without being bothered about the location , drivers etc .,
Also refer to : http://www.e-speak.net/ http://platform.e-speak.net/platform-users/2000-06/msg00031.html
------------------
My ramblings @
http://javarecon.tripod.com
[This message has been edited by Skinner Seymour (edited November 15, 2001).]

[Jim Baiter]

E-Speak was nominated for a Smithsonian in March of 2000 and established long before that. Where was MS with this in March of 2000?

[baris harman]

Hello,
I wonder if anyone has information about what kind of compression Axis is offering. I tried to find an example or some information about compression in Axis documents and mail groups but could not.

[Kyle Brown]

What I was saying is that you have the opportunity to add it yourself if you choose through Axis handlers. I didn't say that Axis would ship with compression...
Kyle

[Kevin Wilson]

There is a lot in this discussion - but I had the following questions voiced as observations
1) I had understood that WebServices need not be delivered over http (or https) and in fact could be for example tcp/ip, smtp, by file.
2) http does support compression - see http://www.faqs.org/rfcs/rfc2616.html
Section 3.5 Content Codings. Whether one's server or client actually does I suppose is a different issue.
3) https could only be used if you assume that SOAP intermediary concept is not being used.
I saw some a reasonable approach in book Building Web Services with Java (SAMS) that discusses PKI with partial encryption of the soap message as well as a Authority/Authentication Service (a ticket approach). It didn't appear to be a standard but it certainly seemed to be groping towards something close.