> On 5/26/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>> Technically, my argument is away from SOAP. My argument is that wire
>> transport shouldn't be part of the puzzle that a developer thinkgs about.
>>
>
> I think that depends on what sort of developer you are, and wherre your
> comfort levels sit. There are many things I think about which aren't
> part of
> my "job description" (I've always said that I'm allowed to do premature
> optimisations in my head as long as I don't do it with my designs :) all the
> way down to the wire level, simply because I don't always trust others to
> make the right descission for all the silly little things I feel that our
> systems should do. And as such I'll have an opinion on it. :)
The issue is whether that optimization is an integral part of your architecture
such that it can't be removed or changed with deployment kinds of configuration
management. When there is little chance of configuration, there is little
chance of evolution.
> But yes, SOAP vs. REST should be void of wire discussions, up until a point
> where even wire means something to an enterprise architect. Again, it
> depends on how big a bang you're designing.
The decision should be based on deployment needs, not so much software
architecture. Software architectures and platforms can enable such flexibilities!
>> The dumbing
>> down of the interface for messaging/RPC causes people to think of problems
>> with less flexibility. What that implies, to me, is that they will me worse
>> decisions about how to manage data integrity and coherency, because they
>> have few language based tools at their disposal.
>
> Hmm. Not sure all the implications you speak of here; what do you mean by
> dumbing down? As with all things, there is a golden path between too complex
> and too simple. The whole SOA thinking in itself tries to push that golden
> path (now on a different level than say RPC and good ol' CORBA/COM) at the
> same time trying to make it business friendly, so from there it's just a
> matter of taste, really.
Specifically, I'm refering to the inability of the developer to allow the
deployer to make "arbitrary" choice of transport, because of arctecture or tools
available to them/used by them.
> A lot of emphasis has been made on the simpler but simplified nature of REST
> and the flexible but more complex nature of SOAP, but I'm willing to say
> that really, in the end it's a discussion about semantics more than anything
> else. For example, in terms of data integrity I'd say that with a good XML
> schema REST *can* be better than SOAP, but with a bad schema it *could* be
> worse; I personally design Topic Maps-based XML schemas over REST, and get a
> far more precise data integrity and higher throughput through that than SOAP
> and WS-* could ever hope to offer. But hey, I'm not a huge transactions hub,
> either.
The problem with REST is that it really allows the content to be very
unstructured in both directions. So much so that once you have REST in place,
you probably can never change the client nor the server to a different
transport/platform interface. Some think that this is the power of REST. I
consider it to be THE problem with REST. With a strict interface description
and implementation, you have the ability to loosen the details to fit the needs
of future clients. With a loose interface description and implementation, you
have no ability to tighten it later to provide a better QOS or other needed
functionality.
> It all ... depends. If you're in control, I'd choose REST, but if I'm
> relying on third-parties a lot, I'd go with SOAP, just as a pragmatic rule.
This is a good example of how REST fails to allow you to apply more control
later on...
Gregg Wonderly
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.
