It seems coping questions is easier than inserting answers... >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. <
I do not think so: service interface represents only 'exchange' data while the business meta-data model may be much richer than particular interface allows. Plus, a business service may have several interfaces, even several Web Service interfaces - this helps to distinguish between service's business meta-data model and 'exchange' data. Business data model is always data-oriented, IMO. >Wouldn't that be an entity-oriented approach? < I meant hear that each service may have its own view on shared model of data and interpret the model is its own way if needed. >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?< My understanding of 'autonomous' assumes that such business service does not need any other business services to provide its business functionality. This does not preclude the service from using utility services to obtain data. However, I would restrict any business service from direct assess to a legacy app or data source. I still think that each service may have its own view on the same data. For example, I had 3 services working with credit risk transactions; the unified transaction model defined 42 fields while services needed 5, 3 and 11 fields only. Performances dictated that related data services better CRUD 5, 3 and 11 fields directly rather than creating a hierarchy of data services (that CRUD only deltas between 5, 3 and 11 fields). >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.< Certainly agree! Thank you, Rob, - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Friday, April 17, 2009 11:32:08 PM 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
