2008/7/5 kavandersluis <[EMAIL PROTECTED]>: > Steve, I believe your main point is that creating a data abstraction > layer degrades performance, sometimes unacceptably.
Nope that isn't my issue. Its the _opposite_ of my point. What I'm saying is that data abstractions like the ones proposed tend to be put forward by people who can't let go of relational databases and the creation of tiers of data abstraction independent of business services works for post-transactional information but makes little sense for operational information. > 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. Its a broader issue of having multiple tiers of data building up to process, this is a technology centric view (in the same way as SOA "stacks" with BPEL on top are technology centric) and assumes that multiple levels of data abstraction make sense. If I have a customer view, what is the abstraction above it? It certainly isn't "add customer" as that is a capability of a service rather than being something related to the data. For me data only architectures are a dangerous thing. Steve > > -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 >> > >> > >> > >
