--- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > --- In service-orientated- > [EMAIL PROTECTED], "kavandersluis" <kirstan@> wrote: > > > > I agree with this point in general, that to the consuming > > application in a SO environment, data acess is incidental to an > > operation. However, if you consider how the service is > > implemented, you could either create a data abstraction layer to > > supply data operations to the higher level service, or not. I > > advocate creating the data abstraction layer. If you don't, your > > services will be tightly coupled to the physical data sources, and > > an obvious opportunity for standardization and reuse will be > > missed. > > I agree that a DAL in this context can be useful, though I'm not all > that keen on "reuse" at the data access level--I wonder about the > segementation of services that are able to share a data store and > data access. Meaning, two or more services reading the Customer data > directly. Methinks that division of responsibilities isn't quite > right in such a case. IMO, just one service would do that. Other > services would call the service responsible for Customer. > > > This last point simply means that major entities in the business > > and their CRUD-like operations should be formalized as services. > > I've no problem with CRUD components being used for service > implementation. I don't lump them in to the "services" category > though. I question the value of a services style approach to such > components.
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"? And these would fall outside your definition of a service? > > > I'm suggesting these entity-style services also be available to > > applications (not just "private" services used by other services), > > but I'd love to hear other's opinions on that. > > I definitely do not subscribe to this approach. Data access from > applications must be via services--and as mentioned above, I don't > view data access components as services, private or otherwise. They > are service implementation components. > > If apps simply use CRUD facilities to manipulate data, how is this > really any different from what apps do now? Integrating at the data > level, which is what data access services effectively provide, is > the way right back to the spaghetti of point-to-point connections of > the past (as is SO if one is not careful). 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? But I do recognize that my definition of a service is broader than the consensus on this board. I'll need to catch up on people's view's on this point. 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. -Kirstan
