>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.
This exactly what I did in Entailment To Data (http://java.sys-con.com/read/163285.htm). As I recall, I was saying that architects have to consider DAL up-front and compensate performance hit buy other architectural means. When "Suddenly the data moves rapidly up", the risk of performance degradation has to be recognized and accepted by management to mitigate the effect of sudden change in behavior. That is, the architects have to see a bit further than what is under the nose :) - Michael ----- Original Message ---- From: kavandersluis <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, July 5, 2008 7:19:28 PM Subject: [service-orientated-architecture] Re: Vandersluis on a Data Abstraction Layer's Benefits 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 service-orientated- architecture@ yahoogroups. com, "Steve Jones" <jones.steveg@ ...> 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 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 > > > > >
