--- In [email protected], "Kirstan Vandersluis" <[EMAIL PROTECTED]> wrote: > > I am beginning to see where you and I divert. I suggested in > another post to Steve that using his service decomposition > strategy from his book, you would eventually recognize a set of > these entity-style services. He then called them "support > services" that would be governed by higher level services. Is that > what you mean by "CRUD components being used for service > implementation"?
Yes, this matches what I was thinking. > And these would fall outside your definition of a service? Well it brings into question what do we call a "service?" If we have layers of services, which seems a natural decomposition strategy, we have to ask how useful is it for lower layers to be discoverable. How reusable will they really be? Are lower level services to be used only by services in the next tier above? If not, then how will the complexity be managed? If so, how do we manage the restriction? Does calling all the components in the multiple layers "services" introduce confusion or clarity? If a component is intended for use by top-level services only (not applications) then IMO that's an implementation component and it avoids confusion to not call it a service. > > I would say the immediate benefit to having applications access > these entity-style services are exactly those attributable to the > DAL: loose coupling, availability business entities as coarse- > grained, CRUD-like operations, the ability to regulate and monitor > data usage (from Michael's post). Is this not much better than > every application coupling itself directly to a plethora of > physical data sources? DAL definitely provides benefits over every application accessing data directly. But an SO approach will provide this via services that do more than just CRUD. "Services" that simply abstract data and provide only CRUD operations is not the proper focus for SO, IMO. Data manipulation is a side- effect of service invocations. DAL tends to put the focus on data and CRUD, rather than on business-level operations. > But we should recognize (I'm sure you all do) that a good > bit of literature exists on service categorization, and it doesn't > all seem to match well with what I think this board's consensus is. > Example sources include Thomas Erl and Michael Carey (BEA), whose > definitions of "entity service" have greatly influenced my own. I agree that service categorization/classification can be useful. And we have several choices! ;-) Krafzig, Banke and Slama have the notion of "basic services" which are data centric and logic centric. I'm still of the mindset that data and the associated logic belong to a single service. And there will be more than CRUD ops there, if they explicitly exist at all. -Rob
