On 17/12/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
Not disagreeing, I'd say that the WMT service acts as the overall guide and "container" for the wal-mart store as seen by the consumer. Hence WMT offers lots of store services to different consumer groups (e.g. Asda in the UK). > > > > >> 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. But you might manage it as a service from that applications perspective, even if you don't lob a Web Service on top of it. Managing something as a service doesn't impact performance from a technical perspective but it can help performance from an agility perspective. > > > > 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. Its also worth noting that sometimes more looseness gives _less_ flexibility as it requires more energy to change the system because of its flexibility. I know I'm not disgreeing with you here Anne but its a point worth making, if you make a system more flexible than it _needs_ to be then you end up constraining it because its more expensive than one which is flexible _enough_. > > > > > > > > Cheers, > > > H.Ozawa > > > > > > > > >
