There are some issues with entity services that only appear in later stages of life-cycle.
They sound good in theory, however, in practice they will present performance issues, as well lack of proper transaction supports. Similar to CMP in J2EE that eventually lost public support due to performance and other issues, data virtualization has not become very popular. Sometimes it is practical to consolidate data sources (via ETL or other means) than utilization of entity services. Pete ----- Original Message ---- From: Kirstan Vandersluis <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, September 17, 2008 10:06:44 AM Subject: [service-orientated-architecture] Re: SOA over a Domain Model --- In service-orientated- architecture@ yahoogroups. com, "Steve Jones" <jones.steveg@ ...> wrote: > > My jury just returned. > > Using "business data" as the primary modelling view is fraught with > problems, not least the view of what the model is. What is customer? > What does it mean to whom? Does everyone need to know everything? > > I'll take a business service view from a functional/organisa tion/data > combined perspective and then worry about the "single" data views > later as a post transactional reporting element. > I agree, with a service oriented approach, you lead with the functional/organiza tional views at the top. But I believe the business data needs to be rationalized into the SOA as well, and entity services is a good way to do that. Data chaos is still a huge problem in many enterprises, and addressing the functional at the high level pushes the problem down, but doesn't solve it in my opinion. The data problems will be solved only with deliberate design and engineering, and the SO approach to solving them involves entity services. Steve, what is your opinion of Colin K's policy refund example? How would you partition services in that example? I think entity services are an important part of an SO approach here, and its not just post-transactional data. -Kirstan
