> 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: [email protected] [mailto:[email protected]] On Behalf Of Michael Poulin Sent: Thursday, April 16, 2009 10:35 PM To: [email protected] 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 <[email protected]> To: [email protected] 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).
<<image001.jpg>>
<<image002.jpg>>
