Steve, a couple more comments and questions: --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > 2008/7/6 kavandersluis <[EMAIL PROTECTED]>: > > 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 yer. > > > Fair enough for me as long as its post-transactional information > rather than "live" information.
First, I'd like to be clear on what you mean by post-transactional data. My assumption is that we are talking about data that feeds BI/reporting/BAM functions. Feel free to point me to other posts/discussion areas if appropriate. Now, can you expand on why this is inappropriate for live data? I have seen it work for both live and post-transactional data, though I'm sure companies I work with are at a different scale than those you work with. > > "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 stomer" > 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. We've missed on semantics here, sorry. "Add customer" in my example is really "create customer", the 'C' in CRUD... I very recently attended a presentation that used this vocabulary. So, I'm not advocating that your "Add customer" be defined in the DAL. I agree with your placement and your point. Deeper in the service decomposition, I think there would be a "create customer" operation. > > 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). Hopefully the above clarification on post-transactional data will clear up my understanding of your point here. > > > > >> > >> 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. OK, good. I've already quoted you in another post :-) -Kirstan
