Jan,
Well this is exactly the problem with "REST" - the protocol completely ignores how the documents are processed. In some ways this is a good thing since it simplifies the exchange of state between cooperating parties. In some ways this is not a good thing since it complicates the processing environment since the interpretation of the state is left entirely up to the implementation.
I realize that "REST" adherents see nothing wrong with this and in fact tout it as a benefit. However to me this sounds a lot like the old file transfer protocols we used to use way back when. If you include within the message, or within the interface, some information helpful to the processing of the state being exchanged, you can simplfiy the processing environment accordingly.
This is what the SOAP envelope and headers are all about, and what WSDL is generally about, and what the SOAP Action was about - giving some type of helpful information to the developers writing programs to process the data. This can help ensure that requester and provider achieve consistency in the interpretation of a contract between them, and to the extent information can be added to the contract (such as policy, security, transactions, etc.) it simplifies the task of ensuring correct (or at least expected) behavior is achieved.
The "REST" folks don't do back office developers any favors by ignoring the issue of how state gets interpreted.
Eric
----- Original Message ----
From: Jan Algermissen <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, May 26, 2006 3:27:28 PM
Subject: Re: AW: Re: [service-orientated-architecture] Re: an SOA in practice
Eric,
hmm...not sure if we are talking past each other, but IMHO, behaviour
simply is not part of the contract between components in a REST style
system. Components are not licensed to make assumptions about each
other's behaviour (actually: about the state machine of an
application). They can only select state transitions at runtime and
observe the resulting state change.
Jan
On May 26, 2006, at 4:36 PM, Eric Newcomer wrote:
> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> SPONSORED LINKS
> Computer softwareComputer aided design softwareComputer job
> SoaService-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.
>
>
>
> SPONSORED LINKS
> Computer softwareComputer aided design softwareComputer job
> SoaService-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.
>
>
----- Original Message ----
From: Jan Algermissen <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, May 26, 2006 3:27:28 PM
Subject: Re: AW: Re: [service-orientated-architecture] Re: an SOA in practice
Eric,
hmm...not sure if we are talking past each other, but IMHO, behaviour
simply is not part of the contract between components in a REST style
system. Components are not licensed to make assumptions about each
other's behaviour (actually: about the state machine of an
application). They can only select state transitions at runtime and
observe the resulting state change.
Jan
On May 26, 2006, at 4:36 PM, Eric Newcomer wrote:
> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> SPONSORED LINKS
> Computer softwareComputer aided design softwareComputer job
> SoaService-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.
>
>
>
> SPONSORED LINKS
> Computer softwareComputer aided design softwareComputer job
> SoaService-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.
>
>
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.
