Single data View on a business object is as clumsy term as Web Service (not a service at all and not necessary on Web).
Single data View exists only from the from the CxO perspective. We need not a VIEW but MODEL+RESOURCE to be shared. The problem a Single Data View aims to resolve the case where different consumenrs use different meta-data and data sources (actual data) claiming they deal with the same business data. "Single" is meant to force all consumers using the same data and the same meta-data, nothing more. While you Governance enforces such sharing, you still cannot enforce all consumers to use the entire business object every time; it is insufficient and may be risky from security side. Thus, every one uses only needed fragment of common shared business object (subset of data set), and this is fine until the data coming from the shared source and means the same for everybody. Only business service models reality of the business, any data-centric approach addresses only a part of the picture (and not necessary the biggest one). I think that business service has to own the meta-data only, not data and absolutely not a physical data store. - Michael ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 16, 2008 7:47:13 PM Subject: Re: [service-orientated-architecture] Re: SOA over a Domain Model 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. Steve 2008/9/16 Kirstan Vandersluis <[EMAIL PROTECTED] com>: > --- In service-orientated- architecture@ yahoogroups. com, Dennis > Djenfer <[EMAIL PROTECTED]> wrote: >> >> >> >> Kirstan Vandersluis wrote: >> > --- In service-orientated- architecture@ yahoogroups. com, Dennis >> > Djenfer <dej@> wrote: >> > >> >> I'm not sure about the meaning of an Entity Service in Erl's > vocabulary, but my approach to a service portfolio is based on a > traditional data model for the enterprise. To explore the behaviour > of the services I'm using business process models and use cases that > are derived from the business process models. The most reusable > services in the service portfolio is derived from the enterprise > data model by grouping together data objects into coherent services. > This approach will typically result in services > like "Party", "Customer", "Order", "Product" and so on. I call these > services "Core Services". I'm not sure if a "Core Service" in my > vocabulary is the same as an "Entity Service" in Earl's vocabulary. >> >> >> >> Yes, Dennis, your definition is the same as Erl's: >> >> >> >> "The entity service model represents a business centric service > that >> >> bases its functional boundary and context on one or more > related >> >> business entities". (from Erl's "SOA Principles of Service > Design") >> >> >> >> He lists examples as building services around business entities > like >> >> customer, employee, invoice, claim. >> >> >> >> >From an SOA perspective, where you define services at the >> >> business/functional level first, you generally see entity > services >> >> at a lower level of decomposition. But I think you are doing > the >> >> right thing by formalizing and exploiting this type of service > in >> >> your architecture. You will get reuse, as you point out, and > your >> >> definition of services around business information helps align > IT >> >> with business on the data side, in addition to the functional > side >> >> driven at the higher level. >> >> >> >> -Kirstan >> >> >> >> >> >> Thanks Kirstan, >> >> I guess my approach is somehow in reverse order of the recommended >> approach, even though it is driven from business models. I think > this >> approach works well for small and mid-sized companies, but a high- > level >> functional decomposition is necessary for big companies. > > Well, I think the jury is still out on the risks of driving services > from the "business data" side. If you're doing SOA, you have to > address the functional side, too. So do you mix top-down functional > and bottom up entity design, hoping to meet nicely in the middle? > If you do this, is it the size of the company that predicts > success? Maybe in small to midsize companys, a small "win" with a > good inventory of entity services is a good first step. It > certainly sounds like this approach is providing value, at least in > the near term. What is in question is whether this is workable for > a longer term SOA initiative. > > -Kirstan > >
