On Apr 13, 2006, at 4:10 PM, Gregg Wonderly wrote:
>
>>
>> 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?
If you put semantics in the message that are not covered by the MIME
type, then you introduce
an undesired coupling between client and server. If you send someting
in MIME type X then the
meaning of that message should be understood by any component
handling that mime type.
(That is why for example application/xml is a bad choice because it
has no sematics beyond "this is XML")
If you send serialized Java objects, you surely should do that with
the proper MIME type, even if it is only
standadized within your adminstrative domain.
>
>>> 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
>
No, you do not send stuff as part of the query string and you do not
send stuff via GET. You send stuff via PUT or POST.
> 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.
Not necessarily. If you use a sopecialized MIME type for your
semantics, the receiving component can very well check for allowed
element names (e.g. HTML allows a title element, put no grupswush
element)
> 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.
You'll need to do verification on input data in any distributed
environment, so what?
>
>> 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.
Hmm...what do HTTP servers everywhere have to do with using HTTP as
your application protocol?
Can it be that the only thing that bothers you is that you do not get
compile time type checking???
(In the age of late binding and dynamic tping, who still want that
anyhow?)
>
>> 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.
The Ilities: http://www.ics.uci.edu/~fielding/pubs/dissertation/
net_app_arch.htm#sec_2_3
>
>> It is all about enabeling independent evolution of your components.
>
> As does the use of Java interfaces for client/server interactions.
But you have API coupling, don't you? When you use a uniform
interface, you do not.
>
>> 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.
So far, I think only compile time type checking in a single process
situation ca do that. What prevents some socket to return garbage to
a Jini client?
>
> 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.
I have never evaluated that, but I doubt that there is a prohibitive
overhead introduced by HTTP on top of sockets.
I am very interested in providing HTTP in small or embedded devices.
Does anyone have any figures about this?
>
>> - 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.
Hmm...I just do have totally contrary experience about this. And I do
not see how you can be sure that whatever you get over the network or
from another process on the same machine is in any way correct.
OTH, RESTs architectural properties of message self-descriptiveness
and visibility make it possible to check the validity of a message at
any point, by any component.
Jan
>
> Gregg Wonderly
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
