Mark Baker wrote:
> On 5/24/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>  > Mark Baker wrote:
>  > > Not for me.  Even if the language was "static", I think it's still
>  > > simpler to turn a string (URI) into data (via HTTP GET)- as a Java or
>  > > .NET developer would be able to do with java.net or System.Net - than
>  > > it would be to call a proprietary getFoo API via SOAP.  Even if the
>  > > response were serialized Java objects, I think this would still hold.
>  >
>  > Okay Mark, so my question is, why would a developer even care what
>  > transport/transfer protocol was used?  In the end, isn't it only the data that
>  > goes and the data that returns which matters to the developer? Do they care
>  > about how the two devices interact with each other?  At deployment time, someone
>  > will probably care to make the right things talk to the right places.  But, as a
>  > developer, do I really care?
>
> No, of course not.  As Werner said, developers want the simplest way
> possible to do something.  What Werner doesn't appear to acknowledge
> though, is that the architectural style impacts the simplicity.
>
> When it comes down to it, a Web services solution will always be more
> complex because it requires the developer to know more things ("more
> moving parts" as Patrick says).  If the developer wants data, then the
> choice is between requiring them to a) have an identifier for the
> service and understand the meaning of the getFoo operation, or b) have
> an identifier for the service.  I think it goes without saying that b)
> is simpler for all values of "Foo".

I think that's kind of a sweeping statement.  The question is, is it easier to
carry around a 'service-access' object and ask for a Foo, a Bar, a Goog and a
Bek, or is it easier to 'know' all, store and manage all the pieces of
information about these things that will allow me to get them, and understand them.

For a single URL, typed into a browser, it's easy to feel empowered by the
interface.

> So, insofar as HTTP-as-transfer-protocol enables b) to happen, while
> HTTP-as-transport does not, I think the distinction matters.  Greatly.

I thought HTTP was a transfer protocol?  Why do you mention transport?

Gregg Wonderly




SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to