Let me continue Mike's line. Not only " "non functional" aspects of a service will depend mostly on how the service is *implemented*" but some functional ones also. This is the difference between SOA Service and REST or WS-* (Web Services). Example? Here you are the provider changes the accuracy of risk calculations behind immutable interface and the consumer gets directly affected by new values in old format. This is why we need Service Contracts in SOA in addition to the interfaces, unified or not. In SOA, the consumer requires certain behavior of the provider behind the interface because it is the business relationship. Can REST or WS-* provide such thing per se? - Michael
Mike Glendinning <[EMAIL PROTECTED]> wrote: --- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > Let me reiterate. REST is about the way you design/implement a > capability (i.e., a service). If you abide by the REST constraints, > your service will exhibit a number of desirable characteristics, such > as simplicity, scalability, performance, reliability, evolvability, > maintainability, visibility, and portability. Oh come on, Anne! Aren't you overstating the case just a little bit here? I hope Burton Group clients receive somewhat more thoughtful analysis than this! Surely these "non functional" aspects of a service will depend mostly on how the service is *implemented*, for which the REST constraints provide no guidance. If I model my resources poorly, or code my services badly and using inefficient programming techniques, the services will not exhibit any of the qualities you suggest, despite my conformance to all of the REST principles. To expect otherwise is about as silly as thinking that just because I define similar attributes of a service using WS-Policy, or even store these in a SOA registry, that this will ensure that my service implementation will actually *meet* the declared requirements. The success of any WS/SOA or REST initiative is still reliant on good quality engineering practice. The adoption challenge for both is to find ways to bring this within reach of the average developer and IT organisation. This might be done through tools, patterns, documented best practices or otherwise. Regards, -Mike Glendinning. --------------------------------- Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit.
