Of cause, it does Udi (there is not wrong or right things, all is based on objectives and risks, right?)
I have thought about this model before and concluded that it has a downside, which is not justifiable, IMO, even for a business service of big value (though, there is no a rule without exception - if the service is a 'mission critical', it will, probably, have everything it wants). 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. >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. thus, I think that a self-contained autonomous business service may use data from both private and shared data sources. As of performances, it is the same as with security - if you did not think it through at the beginning, in the architectural and design stages, adding it later costs a lot including performance degradation, correct? This means that design of Data Services has to take care of performance degradation by a compensating design - pre-loading, caching, data store distribution closer to the consumers, etc. 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... 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. This is what I think about the topic. - Michael ________________________________ From: Udi Dahan <[email protected]> To: [email protected] Sent: Friday, April 17, 2009 6:49:15 AM Subject: RE: [service-orientated-architecture] Re: Joe on Microsoft's combination of SOA & Storage > The data store is de-facto shared resource. What prevents us from allowing each service to have its own data store? I mean, if the business value provided from that service is high enough, the cost could be justified. Furthermore, if we were to design each business service to be autonomous all the way down, we could still choose to deploy to a shared infrastructure. However, should the performance of a given service suffer too much, it would be quite simple to transfer it to a dedicated environment. This flexibility is predicated on designing for autonomy. Does that make sense? -- Udi Dahan From:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin Sent: Thursday, April 16, 2009 10:35 PM To: service-orientated- architecture@ yahoogroups. com Subject: Re: [service-orientated -architecture] Re: Joe on Microsoft's combination of SOA & Storage Colin, I think there is a bit mismatch in "if you follow a business (or domain, or capability) first approach then you'd end up with larger services that internally manage their own data (and behavior, and message schemas, and data-stores, etc.)"Here is why: 1) the business service you end-up is not necessary large, it depends on concrete business function, feature or task you are implementing in the service 2) if you properly design your business service, you should never MANAGE data you service works with, you have to process/massage/ transform the data, not manage, and by no means - manage data store. The data store is de-facto shared resource.If you assume that your business service might be used in different service compositions (may be simultaneously),every shared resource will anchor your service and degrade its composability. Plus, it will be terribly difficult to manage this resource: any data store is the element of service execution context (EC) (environment) ; if it is shared, it constantly changes (different load, concurrent access, parallel processes, and so on). If your EC changes, you cannot guarantee service SLA and, sometimes, service behavior and results. So, instead of concentrating on the quality of business logic of the service, all efforts will go into endless re-testing and negotiation with other users of shared resource. Ownership of resources is typical application- oriented approach: applications try to occupy and own all possible entities they depend on at run-time. Service-oriented approach is based on separation of concerns and responsibilities placed on the top of competition in QoS. Tell me that I am wrong. - Michael ________________________________ From:Colin Jack <colin.j...@gmail. com> To: service-orientated- architecture@ yahoogroups. com Sent: Wednesday, April 15, 2009 8:11:23 PM Subject: [service-orientated -architecture] Re: Joe on Microsoft's combination of SOA & Storage > Is the question of whether or not data access/storage is "in SOA" > fuzzy because there are assumptions about the level of scope of > SOA? I think so, if you follow a business (or domain, or capability) first approach then you'd end up with larger services that internally manage their own data (and behavior, and message schemas, and data-stores, etc). These large services might choose to access the data through data (or entity) services but obviously they don't have to, and although where/how the data is stored is important it's relegated to being an internal implementation detail of that business meaningful service. However if you follow the whole layered SOA approach, right down to utility/entity services, then the data/entity services become part of your SOA (which has never made any sense to me and used to turn me off SOA).
