| |
REST is an architectural style. WS-* is a middleware framework. Mark went to a great deal of effort to ensure that SOAP could be used in a RESTful way. Therefore you absolutely can use REST and WS-* together.
Thanks Anne; yes that is of course correct. OTH I am pretty sure that the context of the paragraph I was answering was to combine REST's uniform API and WS-* implementations of specialized APIs in one and the same system.
Is that correct, John?
Jan
Anne
On 5/28/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
On May 28, 2006, at 7:53 PM, John Evdemon wrote:
> 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
Well, maybe. There are definitely cases when REST is a must (e.g.
mostly or completely decentralized systems). Regarding WS-* I cannot
really see a use case that would make WS-* sort of mandatory (but I
am willing to learn :-)
> (there are also appropriate
> times when they can be used together).
No, there are not. REST and WS-* represent two different
architectural styles so there is no point in the notion of mixing
them. It just makes no sense to say so. An arch. style constrains
your system in order to ensure certain properties. If you mix styles
that impose contrary constraints on the same arch. elements, the
whole point of either one of them is lost.
Jan
> 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/
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
> ------------------------ 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
>
>
>
>
>
>
>
------------------------ 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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
