One big problem, and I don't mean this personally to you Greg at all, is that technologists invest a lot of time understanding a certain technology very deeply, and then tend to see the world in terms of that technology because that's all they know. I remember before I knew anything about the underlying principles of transaction processing that all I knew about it was how certain TP monitors behaved. I mistook the specific for the general.
I believe that's one of the big challenges the industry faces now. To really understand and deal with SO and SOA all of us need to stick our heads up above our comfort zone technologies and appreciate multiple approaches to the problem. In other words, we are not in a world anymore in which any single technology will ever be used to solve every problem, and therefore we are not only going to have to be able to pick the right tool for the right job, we are also going to have to understand the interactions among multiple technologies, and the abstractions that are capable of tying them together into something like an enterprise SOA or multi-enterprise SOA. Eric ----- Original Message ---- From: Gregg Wonderly <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 8, 2007 2:56:12 PM Subject: Re: [service-orientated-architecture] Booch on SOA & Architecture 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 ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
