> 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.
True, but what makes one better than the other in this respect? The
WS-* stack doesn't come with more flexibility in this regard. As far
as I can tell, you don't like the lack of fixed / standardised XML
schemas for transportation of information?
> > 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!
Hmm, but deployment needs can also change. I'm not sure there is a
fixed answer to this one.
> 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.
So, by deployer you mean someone who installs and maintains the
"network" (or SOA) as opposed to the individual application developer?
Doesn't this depend on how big an enterprise you've got, how it's
structured and who's running it? For example, I'm a developer and
deployer of many things in my organisation. If there are rules (or
architectural descissions made to be followed) imposed from other
parts of the organisation, sure there will be something you can and
can't do. Just don't know if REST vs. WS-* *can* have a clear winner
is this respect.
> The problem with REST is that it really allows the content to be very
> unstructured in both directions.
Depends on how you set it up. It's easy enough to use XML technologies
to ensure highly structured data. SOAP is just a *given* standard to
do this that people can follow, but you don't have to play SOAP/WS-*
to have high structure. For example, in our SOA we use a Topic Maps
based schema that all services a guaranteed to deliver; input is
optional REST or the same schema, or some times even SOAP (without the
transaction bits).
> 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.
Why not? And how does SOAP/WS-* differ?
> 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.
Hmm. With SOAP, I need a library to handle the SOAP way of dealing
with things, but with most REST I can just pass it in to my XSLT
processor for some light-hearted handling (maybe my XSLT preference
also plays into this as well). In fact, I mostly get tired of all the
helper-classes I need to implement and possible frameworks to do just
basic stuff, and this *does* get in the way of rapid prototyping and
innovation. But again, I'm not a bank, and we don't do transactions.
To me, the SOAP/WS-* stack is a technologically over-designed and
highly restrictive way of trying to do SOA, while REST offers me more
room to play. Maybe the solution is to play in one and formalise in
the other? We've done that in a few instances, although I personally
fail to see long-term advantage of SOAP; applications will change,
infrastructures will fall, and the world will adopt. I don't think the
lack of rigidness will help in the long-term goals of SOA, but hey,
that's just me. :)
> > 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...
Hmm, but you are here asserting that more control is something you
must have. I think that might be where we disagree the most. I'm a bit
more fuzzy. :)
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
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.
