Hi Eric, On 2/8/07, Eric Newcomer <[EMAIL PROTECTED]> wrote: > > > > I think what Steve said in the previous post is very important. To gain the > benefit of service orientation it's important to design and model software > systems in terms of functions (services) rather than things (objects) since > functions are more naturally aligned with "what we do" as people and > businesses.
I used to use that argument in favour of objects! Anyhow, I think it's pretty specious; what matters is the architecture and its properties; how it relates to what we do is a distant second. > Given the service abstraction, implementation is a separate issue. As we > have heard many times on this list a wide variety of technologies can be used > for implementation. The most important thing is to get the design right - > meaning to meet the business requirements, to align with the services that > the business provides for its customers, or other departments. Agreed; as I say above, the properties of the architecture (induced by constraints). I'd like to hear about how services are better than objects from a technical POV though; what constraints and properties do services provide that objects don't? I've heard that services are supposed to be stateless, but I'm unclear a) what that means (i.e. what kind of state is absent), and b) whether they are in practice or not. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
