I have mentioned a couple of times that this "enterprise canonical schema" should exist in the enterprise and owned by the enterprise, i.e. by the enterprise's data stores, not by the business functional entities.
None of business functions or services is obliged taking and moving the entire canonical schema but, on the contrary, everyone may have its own view or a customised subset of this schema. The only requirement here is that all subsets and all data for business services may come only from this single shared resource, no independent caches and no independent data sources. This "enterprise canonical schema" is the Master data schema, but each business may have its own meaning of this data (http://www.ebizq.net/blogs/service_oriented/2009/04/who_owns_data_that_the_service_uses.php). - Michael ________________________________ From: Udi Dahan <[email protected]> To: [email protected] Sent: Saturday, April 18, 2009 9:27:55 AM Subject: RE: [service-orientated-architecture] Re: Joe on Microsoft's combination of SOA & Storage I think I have a similar concern to Rob's around the following statement: > This leads us to the requirement of having single > and shared business data model To me that sounds like the enterprise canonical schema with all its attendant issues. -- Udi Dahan From:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Rob Eamon Sent: Saturday, April 18, 2009 1:32 AM To: service-orientated- architecture@ yahoogroups. com Subject: [service-orientated -architecture] Re: Joe on Microsoft's combination of SOA & Storage --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@...> wrote: > > So, my key point that the SO power is in business efficiency --> > flexibility in change adoption --> composability and in the > hierarchy of service compositions. At the bottom of this hierarchy, > I see self-contained autonomous business services. > > From another hand, any business functionality depends on the > quality of data. This leads us to the requirement of having single > and shared business data model and related data source (physically, > there may be many heterogeneous data storages and data feed > underneath the single logical business data model. This may be where we diverge. In an SO approach, wouldn't the business data model be the model presented by the service interfaces? I think a model at a lower level would be considered data oriented rather than service oriented. > The point here is in that the services use the same data value of > <name> and then interpreted it to the service benefits. This > approach also called 'Single Client View' or SCV. Wouldn't that be an entity-oriented approach? > > thus, I think that a self-contained autonomous business service may > use data from both private and shared data sources. Here's a different view for consideration. An autonomous business service uses its own data and data obtained via other services (not a a lower-layer data "service") to provide the functionality that its contract stipulates. If multiple services are trying to CRUD the same set of data, would that indicate some sort of service design/granularity issue? > At the same time, if we properly de-compose business model and > identified self-contained autonomous BUSINESS services (not trivial > activities or operations on data), there are not so many of such > services and we might be able (depending of the domain) provide a > DB/schema per service... Ah, we may have some common ground here! That looks like the level of abstraction I've been attempting to describe. > At least, when we were offered 450 services by one of the vendors > to support a SCV product, it resolved in about a dozen of business > services while the rest were CRUD and administration > (configuration) operations. I think we share the same view on this one. Many things the are called "services" really don't seem to be (of course it depends on one's definition of SOA and services). CRUD and admin facilities are necessary and possibly great to share. But if we call everything a service, then the term itself loses usefulness because confusion and miscommunication sets in. > This is what I think about the topic. Your thoughts appreciated as always! -Rob
