+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 > >
