Eric Newcomer wrote: > But an object is not a service, even though a service can be implemented > using one. And therefore it's bad or any counterproductive to think of > the world in terms of "things" that maps to objects, instead of as > "functions" that map to services.
So would a RESTful resource be an "object", a service, or just a resource? The term object is very problematic in these conversations because it seems to be a highly loaded term with biases behind its use which are not always unstood by the readers. > To me this is a conceptual problem, and a modeling problem, not an > implementation issue. People are so used to thinking about software > systems in terms of objects that they often misunderstand services. > Some folks prefer to draw parallels but I prefer to highlight > differences since so many people tend to equate the two. Well, I consider an 'object' to be a service if I can talk to it remotely, or outside of the environment that it runs within. The service contract is not an object. The service is an object. If you want to specify an object as a CORBA object, then I'd suggest the use of that qualification, or whatever is applicable to more directly indicate what kind of object is not a service. > This is why UML and MDA are not well suited for Web services, by the > way, since their design center is the class diagram. I don't agree with this as a good summary statement. There might be some things about such visualization tools which don't help for some types of 'services'. But visualization for the point of discussion if often helpful in the design process. Gregg Wonderly
