About as good a discussion as I've seen for why the world needs both HTTP/XML and Web services.
----- Original Message ----
From: Gregg Wonderly <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, April 13, 2006 10:10:30 AM
Subject: Re: [service-orientated-architecture] HTTP is immaterial?
Jan Algermissen wrote:
> > sending requests from the client to the server.
>
> Do all these uses of GET match the defined sematics of GET[1]?
The returned documents are either text/plain or text/errors which the
application handles as normal or error.
> > It's a very fragile application because the client/server protocol
> > is completely
> > unspecified in structure.
>
> You mean the messages, or? I mean, if you used HTTP (and not just (ab)
> used it as a transport) the client/server protocol is well specified.
> Only the messages can then be unspecified; for example if you put
> semantics in the message beyond the actual mime type semantics (e.g.
> exchanging structured data using text/plain).
I don't understand what you mean by this. The application is free to use
whatever mimetypes are appropriate with whatever content needed right?
> > The property value names have to be typed correctly
> > into the source code. You have to be sure to send all the right
> > values in the
> > GET URL, or the server will be missing information. Using HTTP
> > here has not
> > added any value into the integrity or maintainability of the
> > application.
>
> I guess you would be beter of if you had used POST and a standardized
> (at least across your system) message type to send data to the server.
The problem is about spelling of property names, which properties are included
in the content etc. When I have a Java object such as
public class MyData {
int v1, v2, v3;
String v4, v5, v6;
}
and I want to send this over HTTP, I might write a GET URL as
...?v1=23&v2=66&v3=223&v4=help%20me&v5=my%20name&v6=my%account
If I was returning this to the client, because I am using Java and I can use
java.util.Properties.load(InputStream), I might send back
Content-Type: text/plain
Content-Length: ...
v1=23
v2=66
v3=223
v4=help me
v5=my name
v6=my account
As an asside, if I was using XML, the same issues below would apply. I could
apply some other XML tools to help me get the "object" converted to a document
for return or POST, but the "get" would still require manual work. Using those
tools is extra knowledge and extra expense and time.
Let's say I want to add a new value to the MyData class that needs to go back
and forth between the client and the server. In an RMI application, just adding
the element to the class would cause the value to be part of the data going back
and forth. But, in the case of using a GET URL or a return document, I have to
find all the places where the data is transported to make sure that it goes back
and forth. In the get URL and in the "properties" list, I have to spell the
name correctly and spend a lot of extra effort to "get it right.".
> > Instead, it has created quite a mess, because it does not provide a
> > type based
> > mechanism to manage content correctness.
>
> Now wait - HTTP does not provide the ability to type the content that
> is exchanged between clients and servers? What else are MIME types
> for then? Surely your PDF reader can verify if some message is indeed
> application/pdf. Or am I missing your point?
I'd like to remind you of the classic problem with http servers everywhere.
There is a file for most servers that specifies what mime-type is associated
with what "extension" for files so that users can put links to all kinds of
documents on their pages and the users clicking on those links will get the
right answer. However, there is also a "default" mime-type that has to be set
for all unrecognized file types. This value, typically defaults to
application/binary. But some really smart admins decide that they always have
randomly named text files (like README) that they'd like to be able to see in
the browser, without saving and opening with an editor. So, they switch the
default to be text/plain.
Now, the problem is that when I have some kind of new fangled binary data file
format, and I put it on such a web site, noone can download and use the file
correctly because the web server is doing CRLF conversions on it.
The content-type: designation and the actual content type are not "guarenteed"
to be correct. Instead, it's a programming exercise, and guess what, people
make mistakes and get things wrong. So HTTPs type system, while useful, is not
at all able to guarentee much of anything.
> > At some point, I will in fact do this. We haven't had to make too
> > many changes
> > to this application over the years, but everytime we do, it's a
> > royal pain to
> > get the client/server exchange right. Many, many more details to
> > manage because
> > the application has the protocol imbedded in it.
>
> This sounds more like the trouble is the result of layering an
> application protocol (your specific one) on top of another
> application protocol (HTTP) instead of desiging your application to
> properly use that application protocol in the first place (not to
> suggest that I haven't made that mistake before also :-)
Again, how would proper use of HTTP keep me from mispelling property names,
forgetting to include particular values in the GET URL, or forgetting to return
particular values in the HTTP return document? This is the issue for me. HTTP
clearly does well at getting "documents" as a protocol. But it does not
facilitate a "cleaner" implementation of a "document" based application than
other, more rigorously typed environments. The standardization on strings for
control are friendly to human readers, but don't "enhance" the environment,
because there is no "limit" of what one might put in those strings, including
the incorrect information due to human error. I suppose you visited a broken
web site before? People do type the wrong things.
> If used properly, HTTP induces a certain set of properties into your
> system. If you are interested in your system having these properties
> then use HTTP.
Maybe you can enumerate the properties that you see and value in using HTTP.
> It is all about enabeling independent evolution of your components.
As does the use of Java interfaces for client/server interactions.
> It is about freeing service developers from coordinating their work
> with client developers as long as both stick to standardized message
> semantics (MIME types).
MIME types don't provide any guarentee that the content is correctly formatted
for my use; i.e. there is limited ability to "know" that the returned "document"
is actually ready for use.
> Especially when client and server live in
> different administrative- or trust domains I think it is of huge
> value that service developers know they can do whatever they want as
> long as they stick to the proper message semantics? What is that
> value? Massively reduced coordination cost.
I think that the primary enabling factor is standards associated with the
"content" more than the "use" of HTTP. There are some interesting features of
HTTP that some people take advantage of, but anything beyond http 1.0 is
pressing your luck unless you really have control over the clients and servers.
> > It's only the tools and layers
> > of abstraction on top of HTTP that would provide any additional
> > value, and then
> > you're not using HTTP as anything more than a transport, so why not
> > just use TCP
> > sockets in a layer of abstraction that would allow you to plug in
> > something else
> > if needed?
>
> Because
> - you need an application protocol anyhow, so why not use HTTP
> - HTTP is ubiqitous
HTTP is everywhere if you live in a document world. I live in a "data" world
where the data is down inside of very small devices using very limited computing
environments.
> - HTTP is a really save bet to invest in; it is standardized, has
> proven to be sucessful and
> the amount of deployment makes it very unlikely it is suddenly
> going to change.
I think that there are several issues. If all you need is to "get" something,
then HTTP works. If you need to exchange things and make a multi-facited
transaction, HTTP breaks down. HTTP is a publishing technology. It doesn't do
as well as a conversational technology because the lack of type validation and
associated control of content.
Gregg Wonderly
----- Original Message ----
From: Gregg Wonderly <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, April 13, 2006 10:10:30 AM
Subject: Re: [service-orientated-architecture] HTTP is immaterial?
Jan Algermissen wrote:
> > sending requests from the client to the server.
>
> Do all these uses of GET match the defined sematics of GET[1]?
The returned documents are either text/plain or text/errors which the
application handles as normal or error.
> > It's a very fragile application because the client/server protocol
> > is completely
> > unspecified in structure.
>
> You mean the messages, or? I mean, if you used HTTP (and not just (ab)
> used it as a transport) the client/server protocol is well specified.
> Only the messages can then be unspecified; for example if you put
> semantics in the message beyond the actual mime type semantics (e.g.
> exchanging structured data using text/plain).
I don't understand what you mean by this. The application is free to use
whatever mimetypes are appropriate with whatever content needed right?
> > The property value names have to be typed correctly
> > into the source code. You have to be sure to send all the right
> > values in the
> > GET URL, or the server will be missing information. Using HTTP
> > here has not
> > added any value into the integrity or maintainability of the
> > application.
>
> I guess you would be beter of if you had used POST and a standardized
> (at least across your system) message type to send data to the server.
The problem is about spelling of property names, which properties are included
in the content etc. When I have a Java object such as
public class MyData {
int v1, v2, v3;
String v4, v5, v6;
}
and I want to send this over HTTP, I might write a GET URL as
...?v1=23&v2=66&v3=223&v4=help%20me&v5=my%20name&v6=my%account
If I was returning this to the client, because I am using Java and I can use
java.util.Properties.load(InputStream), I might send back
Content-Type: text/plain
Content-Length: ...
v1=23
v2=66
v3=223
v4=help me
v5=my name
v6=my account
As an asside, if I was using XML, the same issues below would apply. I could
apply some other XML tools to help me get the "object" converted to a document
for return or POST, but the "get" would still require manual work. Using those
tools is extra knowledge and extra expense and time.
Let's say I want to add a new value to the MyData class that needs to go back
and forth between the client and the server. In an RMI application, just adding
the element to the class would cause the value to be part of the data going back
and forth. But, in the case of using a GET URL or a return document, I have to
find all the places where the data is transported to make sure that it goes back
and forth. In the get URL and in the "properties" list, I have to spell the
name correctly and spend a lot of extra effort to "get it right.".
> > Instead, it has created quite a mess, because it does not provide a
> > type based
> > mechanism to manage content correctness.
>
> Now wait - HTTP does not provide the ability to type the content that
> is exchanged between clients and servers? What else are MIME types
> for then? Surely your PDF reader can verify if some message is indeed
> application/pdf. Or am I missing your point?
I'd like to remind you of the classic problem with http servers everywhere.
There is a file for most servers that specifies what mime-type is associated
with what "extension" for files so that users can put links to all kinds of
documents on their pages and the users clicking on those links will get the
right answer. However, there is also a "default" mime-type that has to be set
for all unrecognized file types. This value, typically defaults to
application/binary. But some really smart admins decide that they always have
randomly named text files (like README) that they'd like to be able to see in
the browser, without saving and opening with an editor. So, they switch the
default to be text/plain.
Now, the problem is that when I have some kind of new fangled binary data file
format, and I put it on such a web site, noone can download and use the file
correctly because the web server is doing CRLF conversions on it.
The content-type: designation and the actual content type are not "guarenteed"
to be correct. Instead, it's a programming exercise, and guess what, people
make mistakes and get things wrong. So HTTPs type system, while useful, is not
at all able to guarentee much of anything.
> > At some point, I will in fact do this. We haven't had to make too
> > many changes
> > to this application over the years, but everytime we do, it's a
> > royal pain to
> > get the client/server exchange right. Many, many more details to
> > manage because
> > the application has the protocol imbedded in it.
>
> This sounds more like the trouble is the result of layering an
> application protocol (your specific one) on top of another
> application protocol (HTTP) instead of desiging your application to
> properly use that application protocol in the first place (not to
> suggest that I haven't made that mistake before also :-)
Again, how would proper use of HTTP keep me from mispelling property names,
forgetting to include particular values in the GET URL, or forgetting to return
particular values in the HTTP return document? This is the issue for me. HTTP
clearly does well at getting "documents" as a protocol. But it does not
facilitate a "cleaner" implementation of a "document" based application than
other, more rigorously typed environments. The standardization on strings for
control are friendly to human readers, but don't "enhance" the environment,
because there is no "limit" of what one might put in those strings, including
the incorrect information due to human error. I suppose you visited a broken
web site before? People do type the wrong things.
> If used properly, HTTP induces a certain set of properties into your
> system. If you are interested in your system having these properties
> then use HTTP.
Maybe you can enumerate the properties that you see and value in using HTTP.
> It is all about enabeling independent evolution of your components.
As does the use of Java interfaces for client/server interactions.
> It is about freeing service developers from coordinating their work
> with client developers as long as both stick to standardized message
> semantics (MIME types).
MIME types don't provide any guarentee that the content is correctly formatted
for my use; i.e. there is limited ability to "know" that the returned "document"
is actually ready for use.
> Especially when client and server live in
> different administrative- or trust domains I think it is of huge
> value that service developers know they can do whatever they want as
> long as they stick to the proper message semantics? What is that
> value? Massively reduced coordination cost.
I think that the primary enabling factor is standards associated with the
"content" more than the "use" of HTTP. There are some interesting features of
HTTP that some people take advantage of, but anything beyond http 1.0 is
pressing your luck unless you really have control over the clients and servers.
> > It's only the tools and layers
> > of abstraction on top of HTTP that would provide any additional
> > value, and then
> > you're not using HTTP as anything more than a transport, so why not
> > just use TCP
> > sockets in a layer of abstraction that would allow you to plug in
> > something else
> > if needed?
>
> Because
> - you need an application protocol anyhow, so why not use HTTP
> - HTTP is ubiqitous
HTTP is everywhere if you live in a document world. I live in a "data" world
where the data is down inside of very small devices using very limited computing
environments.
> - HTTP is a really save bet to invest in; it is standardized, has
> proven to be sucessful and
> the amount of deployment makes it very unlikely it is suddenly
> going to change.
I think that there are several issues. If all you need is to "get" something,
then HTTP works. If you need to exchange things and make a multi-facited
transaction, HTTP breaks down. HTTP is a publishing technology. It doesn't do
as well as a conversational technology because the lack of type validation and
associated control of content.
Gregg Wonderly
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
