Hi Anne, Nice to see you back posting on the list again. Anne Thomas Manes wrote: > This service called "Wal-Mart" (or "WMT") is a service to a stockholder. > I would also content that a Wal-Mart store is a representation of the > Wal-Mart service, which is a service to a shopping consumer. > > I'm not too sure what you mean by "Wal-Mart service". What is the difference between having an Wal-Mart object in OO and Wal-Mart service?
>> I meant this from a technical perspective. There is lots of >> functionality that is unique to a specific application. If this >> functionality will never be used in any other application, and the >> functionality is quite stable, it doesn't make sense to implement it >> as a service and impose the overhead of service creation, service >> management, and service invocation. Also, you might have application >> requirements that demand extremely high performance or atomic >> transactions, etc, that demand more tight coupling. >> >> Yes, thank you for restating it. Similarly, as there are limitations placed by the current technology and the cost associated with it in a technical perspective, there are limitations placed by people on a business perspective. It may be a "should" in the context of SOA , but that does not necessary translate to a "should" in the context of a project. >> SOA is a mindset -- it's your approach to designing systems. It's a >> set of principles that help ensure that you build flexible and >> adaptable systems. I recommend that you internalize these principles >> and apply to to every application system you're building. That does >> not mean that you will implement every application using any >> particular technology (SOA is independent of any particular >> technology), or that in every application system you will refactor >> reusable functionality into shared services, or that in every >> application system you will reuse an existing service rather than >> build the capability again, or that when you do implement a service, >> its interface must be completely loosely coupled. In all cases, you >> must let the application system requirements dictate your design and >> infrastructure decisions. But I reiterate, you should apply SOA >> principles to every system design. (Just as, I'm sure, you apply many >> other fundamental design principles to every project you do.) >> >> +1 on SOA is a mindset. "every" is a strong word which I'm hesitant to use. There are some fundamental design principles I use on "many" projects, but there's always some exceptions based on customers' requests. Cheers, H.Ozawa
