--- In service-orientated- [EMAIL PROTECTED], "kavandersluis" <[EMAIL PROTECTED]> 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'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). -Rob
