I am not sure I'd say that since the behavioral contracts in "REST" would have to be in the processing code, wouldn't they? And that might be harder to discover and change than behavioral contracts expressed in an interface...
Eric
----- Original Message ----
From: [EMAIL PROTECTED]
To: [email protected]
Sent: Friday, May 26, 2006 6:04:20 AM
Subject: AW: Re: [service-orientated-architecture] Re: an SOA in practice
>
>Given WSDL does not provide behavioral contracts (just functional ones
>over data)
>how can we:
> i) describe the behavior?
> ii) monitor services against their described behavior?
> iii) guarantee that services do behave correctly?
>All of course in a standard and unambiguous way. If we can do this then
>we can
>ensure that different implementations over different transports do the
>right thing
>at right time and that way ensure interoperability and substituability
>of participant
>services.
Since REST eliminates the design-time behavioural aspects and instead uses runtime discovery of possible state transitions+shared understanding of the link semantics the above suggests that REST is a promising candidate - at least more promising than architectural styles that make behavioural semantics part of the contract, eh?
Cheers,
Jan
>
>Cheers
>
>Steve T
>
>On 24 May 2006, at 15:22, Gregg Wonderly 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?
>>
>> 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.
>>
>>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
----- Original Message ----
From: [EMAIL PROTECTED]
To: [email protected]
Sent: Friday, May 26, 2006 6:04:20 AM
Subject: AW: Re: [service-orientated-architecture] Re: an SOA in practice
>
>Given WSDL does not provide behavioral contracts (just functional ones
>over data)
>how can we:
> i) describe the behavior?
> ii) monitor services against their described behavior?
> iii) guarantee that services do behave correctly?
>All of course in a standard and unambiguous way. If we can do this then
>we can
>ensure that different implementations over different transports do the
>right thing
>at right time and that way ensure interoperability and substituability
>of participant
>services.
Since REST eliminates the design-time behavioural aspects and instead uses runtime discovery of possible state transitions+shared understanding of the link semantics the above suggests that REST is a promising candidate - at least more promising than architectural styles that make behavioural semantics part of the contract, eh?
Cheers,
Jan
>
>Cheers
>
>Steve T
>
>On 24 May 2006, at 15:22, Gregg Wonderly 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?
>>
>> 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.
>>
>>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
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.
