On Apr 13, 2006, at 6:19 AM, Gregg Wonderly wrote:
> Jan Algermissen wrote:
>> Gregg,
>>
>> On Apr 12, 2006, at 4:55 PM, Gregg Wonderly wrote:
>>
>>> If we go on about the GET vs POST issues and some of the
>>> semantics of the HEADER fields (redirection responses) etc, I
>>> consider this to
>>> be more about application supported features than about typical
>>> "protocol"
>>> supported feature.
>>
>> Hmm....but HTTP *is* an application protocol.
>>
>> IOW, HTTP is not about getting data across a network, it is about
>> invoking methods with explicit *application semantics* on objects
>> [1].
>>
>> Do you disagree?
>
> I believe that this starts to speak to our differing opinions.
> HTTP has a lot
> of different features that are not always used, and not always
> available.
What features do you have in mind that are not always available?
> Because of this, the application has to take all of these things
> into account,
> and handle them correctly. Thus, I don't consider those things to
> be part of
> "the protocol" that is "usable" for ALL applications. Instead,
> they are things
> that every single application that uses HTTP has to deal with.
Such as (see above)?
> Thus the binding of the protocol into the application which I find
> unacceptable
> as a general SOA practice.
But it is an illusion that you can have delivery semantics without an
application protocol (see Mark's reply). So why not use an existing,
well deployed one instead of rolling yet another one and (ab)using
the existing application protocols as transport?
Jan
> I have used HTTP for simple and complex dedicated
> applications because the data I needed was only available via
> HTTP. But from a
> practicle SOA architecture perspective, HTTP would not be a
> "specified" part of
> the "architecture" of my SOA for anything other than web pages
> delivered to
> users, and I would not include forms or AJAX because of the
> dependency on
> browsers doing the right thing.
>
> 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/
