>If I am a regulated utility the "add customer" >I flow can take several months to complete. If I'm selling someone a >I car then "Add Customer" involves selling and supplying a car. >I Treating these elements as data centric is (IMO) very dangerous.
Agree. > My argument would be that a DAL can _increase_ architectural > complexity if it aims to separate functional aspects from data aspects > too far. I would be very interested in a measurement of "too far"... Sure, DAL increases complexity but it is in the same way as any security means. Where I see the real value of DAL ( besides a point of interception for any needs), it is in the separation of logical Business Data Object from physical Business Data Object storage. A Business Service has to have its Business Data model unrelated to the whatever data storage rules (e.g. data notmalisation) used to persist the data. > See above on how this would happen with customer. Yes you would but > the DAL would be "governed" by the business service and provided as > support service. Agree, DAL is the support service; though it provides a RWE - a Business Data model for particular Business Service, it does not provide a business functionality. - Michael ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, July 7, 2008 4:57:34 PM Subject: Re: [service-orientated-architecture] Re: Vandersluis on a Data Abstraction Layer's Benefits 2008/7/6 kavandersluis <[EMAIL PROTECTED] com>: > --- In service-orientated- architecture@ yahoogroups. com, "Steve > Jones" <jones.steveg@ ...> 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. What I'm saying is that for post-transactional data there aren't "layers" there is really only one layer and that is the provision of information to consumers. As you say this comes from multiple sources but there isn't really a set of layers, its just post-transactional store and how people access it. My other point is that doing this data abstraction works for post-transactional data. Relational folks normally try and apply it elsewhere (IME) and it doesn't work. > >> 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. Okay fair enough, as per my point above. Data abstractions don't make a great deal of sense to me in a tier sense, just one tier and you're done (it might be a big tier though). > > 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. Fair enough for me as long as its post-transactional information rather than "live" information. > >> 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. This is where you loose me I'm afraid. "Add Customer" is very rarely an entity based thing. If I am a regulated utility the "add customer" flow can take several months to complete. If I'm selling someone a car then "Add Customer" involves selling and supplying a car. Treating these elements as data centric is (IMO) very dangerous. > 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. I'd say that you have CustomerManagement as a service which provides access to the functional capabilities of the organisation around customer management, it is also responsible for the "blessing" of the customer data master record which is a data centric service that is supplied to the organisation to ensure single view of the customer. The two pieces represents different facets of Customer Management, one being about the capability and functional operational aspects (the true RWEs) and the other being about the provision of post-transaction facts (technical RWEs). > >> >> 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." My argument would be that a DAL can _increase_ architectural complexity if it aims to separate functional aspects from data aspects too far. > > 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. See above on how this would happen with customer. Yes you would but the DAL would be "governed" by the business service and provided as a support service. Steve > > -Kirstan > >
