Actually I don't think it simplifies the problem overall. This just exchanges one complexity for another. Meaning while the transfer of data is simplified, the information about how to process it becomes more complex (i.e. entirely in the program now instead of partly in the interface).
Unless you take into account the difficulty of processing the data I do not believe you can really say one solution is simpler than another for exchanging documents.
Eric
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, May 24, 2006 12:17:04 PM
Subject: Re: [service-orientated-architecture] Re: an SOA in practice
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".
So, insofar as HTTP-as-transfer-protocol enables b) to happen, while
HTTP-as-transport does not, I think the distinction matters. Greatly.
Mark.
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, May 24, 2006 12:17:04 PM
Subject: Re: [service-orientated-architecture] Re: an SOA in practice
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".
So, insofar as HTTP-as-transfer-protocol enables b) to happen, while
HTTP-as-transport does not, I think the distinction matters. Greatly.
Mark.
SPONSORED LINKS
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.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
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.
