Steve, I believe your main point is that creating a data abstraction layer degrades performance, sometimes unacceptably. Agreed, any type of abstraction (data or otherwise) is going to have a performance cost to some degree. This cost must be balanced against other desired characteristics, including performance. In retrospect, this would have been a good discussion point in the article.
As for the diagram in figure 1, I do appologize for it being high level and somewhat vague. It was added after the fact at the request of the editor, and I hastily created it during a session break at SOA World. However, you took liberties in distorting it to emphasize your point. In the end, I can't tell whether its just the diagram that is inappropriate in your mind, or the overall concept of a data abstraction layer. I do value your opinion, so it would be great to hear from you, at least to confirm that this is a performance issue, or something broader. -Kirstan --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > +1 > > Loving figure one > > Data > Data Abstraction > Data Services > Process > > > Hey its a 3 tier model just for the data. > > This is a consistent problem that I see when database people have been > forced to make the jump into middleware because they can't write > PL/SQL any more. Suddenly the data moves rapidly up the tiers but all > the time with "performance" in mind (direct access) so you get the > myth of abstraction with the reality of a horrible mess. > > Steve > > > 2008/6/23 Rob Eamon <[EMAIL PROTECTED]>: > > --- 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 > > > > >
