I would join Kirstan in "not just "private" services used by other services" and "I advocate creating the data abstraction layer". I did it by myself a few years ago based on Hibernate+DB Views. The DAL became a point of indirection where all needed interceptions of data could happen. It was not related to any particular application. Moreover, it was a mandatory environment element for access all strategic DB.
- Michael ----- Original Message ---- From: kavandersluis <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, July 5, 2008 6:31:03 PM Subject: [service-orientated-architecture] Re: Vandersluis on a Data Abstraction Layer's Benefits Hi Rob, Sorry for chiming in so late, I was catching up after vacation the last week or so, and did not even know this article was posted here. I believe data abstraction is an approach that works in concert with other SO principles, rather than an old approach that is no longer relavent. However, I do agree in general with your basic assertion: > In other words, the services layer provides the data abstraction > layer implicitly. (But the focus isn't on simply providing access to > data--it is on behavior and real-world effects. Access to data is > incidental to *doing* something.) 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. This last point simply means that major entities in the business and their CRUD-like operations should be formalized as services. 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. -Kirstan --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > --- In service-orientated- architecture@ yahoogroups. com, Kirstan > Vandersluis wrote: > > > > Companies seeking increased agility and reuse through service- > > oriented architecture quickly find that making sense of widely > > distributed and disparate data is a major roadblock to achieving > > the benefits of SOA. > > IMO, this article is mixing old and new approaches and saying that > the old approach (data abstraction layer) is needed for the new > approach (SOA) to succeed. > > This is captured in one of the examples: > > > As an example, an application may request a customer record from > > the data abstraction layer. > > IMO, this is just outright off in an SO system. An application would > call an operation in the Customer Management service. The service > abstracts away the physical storage and presents the logical > representation. > > In other words, the services layer provides the data abstraction > layer implicitly. (But the focus isn't on simply providing access to > data--it is on behavior and real-world effects. Access to data is > incidental to *doing* something.) > > IMO, there is no need for a DAL except as a temporary transitional > construct to support services implementations that are fronting "old" > applications/ data. The transition of ownership of the data from those > apps/data stores to the services eliminates the need for a DAL. > > Thoughts? > > -Rob >
