--- In [email protected], 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
