On 12/15/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > On 15/12/06, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > > > > Steve Jones wrote: > > > You are going to have to help me here, the provide a service but they > > > aren't a service? Sounds a bit zen. > > > > > Walmart is a business entity which provides and consumes services. > > Would you actually create a business or IT service named "Walmart"? > > They have created a service called Walmart they've even nicely packed > it up so consumers can interact with it... > > http://www.nyse.com/about/listed/lcddata.html?ticker=WMT
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. > > >> Sometimes loose coupling is a good idea sometime it isn't. Taking two > > >> sports as examples, if you are a football (soccer) team then you are > > >> pretty much loosely coupled with the players being interchangable to a > > >> degree and the other players adapting to those changes dyanamically. > > >> If you take an American Football (Joan Collins) team then there are > > >> parts of it that are very tightly coupled as they run set passing > > >> players and each player has to be in exactly the right place and other > > >> players depend on them being there, system failure occurs when players > > >> don't rigidly adhere to this plan. > > >> > > >> So that is what I mean by sensible coupling, don't assume that one > > >> size fits all and go after loose coupling as a religion, just look at > > >> the area you are working in and determine what level of coupling is > > >> required. > > >> > > I think Anne mentioned this a while back, but we don't want to make > > everything into a service. > > Not technically no, but at the business level lots of things already > are services. Quite often its just recognising the services as the > exist. 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. > > I'll also add to not make everything system be based on SOA. 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.) > > The point that may be up for discussion is when we decide to create > > services, whether there is any > > benefit in having different degree of "looseness" between services. > > Suppose we decide to assign number > > from 0 to 10 to represent the looseness of services. Should there be > > some services that are 0, some that > > are 3, some that are 8, and some 10 in the same system? > > Yes. Absolutely. System requirements will dictate the degree of looseness that is appropriate. More looseness delivers more flexibility, but sometimes other requirements outweight flexibility. > > > > > Cheers, > > H.Ozawa > > > > >
