RE: [service-orientated-architecture] Re: an SOA in practice

Sun, 28 May 2006 11:00:54 -0700

I'm a bit late to the game here but it strikes me that this isn't
an either/or decision.   There are appropriate times to use WS-*
and appropriate times to use REST (there are also appropriate
times when they can be used together).  The decisions that impact
these decisions are obviously not always purely technical.


> -----Original Message-----
> From: [email protected]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Alexander Johannesen
> Sent: Saturday, May 27, 2006 11:03 PM
> To: [email protected]
> Subject: Re: [service-orientated-architecture] Re: an SOA in
practice
>
> On 5/28/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> >  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/
> __________________________________________________
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Home is just a click away.  Make Yahoo! your home page now.
> http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------
> ------~->
>
> 
> Yahoo! Groups Links
>
http://groups.yahoo.com/group/service-orientated-architecture/
>
>
> 
>
>
>






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

YAHOO! GROUPS LINKS



Reply via email to