--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > 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
But the main point of the article is that the data abstraction layer hides the underlying data source, making it irrelavant to the consumer whether data is derived from relational, mainframe, other apps, etc. It seems like you are saying that its usually the "relational-centric" people who propose hiding relational data behind a DAL, which is the opposite of my experience. > 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. I agree in general that multiple levels of data abstraction don't make sense, but I can see where implementations of *relational* abstraction layers (Composite Software, Redhat/Metamatrix) might create entity-style services on top. I would call this an XML-based data abstraction layer on top of a relational data abstraction layer. Seems like a real stretch, though, as those environments already have struggled with performance, so I do agree with your point. Figure 1 in the article is so general that it may confuse this point. I'm not recommending multiple layers of data abstraction, but the diagram does allow this. What I'm really suggesting is using XML models to define entities which become the basis for entity-style services, which supply the data to apps and higher level services. It is this set of entity- style services that constitute the XML-based data abstraction layer. > 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. "Add customer" is an operation in the "customer" service, which is an entity-style service which constitutes part of the "XML-based data abstraction layer" as described in the article. Then, applications, processes, and other higher level services access this service instead of accessing the data directly. This is an area I'd love to hear discussion on from you and others. > > For me data only architectures are a dangerous thing. The article is not intended to propose a data-only architecture, but rather a DAL as part of a larger SOA. From the intro section: "A data abstraction layer reduces the architectural complexity required to provide access to enterprise data, and allows organizations to create and leverage services that support critical business objectives." It seems to me that if you follow the process in your book "Enterprise SOA Adoption Strategies", at some level of service decomposition, you will begin to recognize entity-style services that form the basis of what I'm calling an XML-based data abstraction layer. I'd love to hear your opinion on this, too. -Kirstan
