I'm with Steve.
-- Udi Dahan - The Software Simplist From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Jones Sent: 16 September 2008 21:47 To: [email protected] 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/organisation/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] <mailto:kirstan%40xaware.com> >: > --- In [email protected] <mailto:service-orientated-architecture%40yahoogroups.com> , Dennis > Djenfer <[EMAIL PROTECTED]> wrote: >> >> >> >> Kirstan Vandersluis wrote: >> > --- In [email protected] <mailto:service-orientated-architecture%40yahoogroups.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 > > No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1672 - Release Date: 15/09/2008 09:21
<<image001.jpg>>
<<image002.jpg>>
