Cheers
Steve T
On 21 May 2006, at 20:11, Mike Glendinning wrote:
> --- In [email protected], Jan
> Algermissen <[EMAIL PROTECTED]> wrote:
> >
> >
> > On May 21, 2006, at 6:58 PM, Mike Glendinning wrote:
> >
> > > but I still think that REST would benefit from a simple but
> > > machine-processable way of defining exactly what resource
> > > representations will be exchanged ("types" and "messages") for
> each
> > > of the "operations" allowed (GET, POST, DELETE, PUT) on a
> particular
> > > resource identifier ("service").
> >
> > But this would introduce a kind of coupling REST deliberately
> chose
> > to *avoid* therby enabeling the service to evolve and especially
> to
> > change the exact representations it sends. Surely this demands for
> > client implementations that can handle this scenario but that is
> > after all the cost of the better evolvability.
> >
> > Or am I missing your point?
> >
> > Jan
> >
>
> Erm, the addition of a formal service description does not affect
> the "loosely coupled" or "tightly coupled" nature of a service (which
> is a separate topic). The service description merely describes the
> service as it exists, it does not *change* any attributes of the
> service.
>
> As we've been discussing, in practical implementations of REST the
> client and server are extremely tightly coupled because the
> representations cannot change without you rewriting your client or
> server application code.
>
> You can try and be clever about the kinds of changes you expect and
> code for those in advance, that is be "liberal with what you
> receive", but you won't catch everything in this way. There is also
> no reason why code automatically generated from a service description
> could not take the same approach (e.g. build in a bit of flexibility
> and looseness of processing).
>
> Ideally, of course the service description will provide ways to
> specify the messages exchanged by a service and how they are likely
> to evolve, that is provide guidance on what assumptions should and
> should not be made by clients.
>
> By *not* formalising such a service description, each client will
> take its own view of evolvability and [probably] make a different set
> of assumptions about future changes. When a client is dealing with
> hundreds of different services from different suppliers (e.g. in a
> SOA) this is clearly a recipe for complexity and chaos.
At least with respect to the message exchanges, what we might call the
observable
behavior, that a service supports (so over and above WSDL or a Java
interface description)
this is what WS-CDL does. It is also formal (that is it has clear
formal semantics) and
can be therefore be tested for behavioral equivalence statically (as a
type).
>
> One of the main goals of service description therefore is to surface
> these hidden assumptions for the benefit of interoperability and
> manageability. I agree that we don't have a good language for doing
> this yet, but that is what I am proposing needs to be created.
>
> -Mike.
>
>
>
>
>
>
>
>
> 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.
>
>
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.
