I think, Rob, that data (values and shared schemas) is owned by data store. This is why many O/R tools try to separate object/entity development from data management.
Business service must know that it properly passed data structures to the entity, responsible for persisting it and received confirmation from that entity. Where and how the data stored is pure technical topic and task for the Data Service (which may be responsible for CRUD or for hundreds of CRUD for heterogeneous data storage). I think that one of fundamental difference between OO and SO is in the principle of encapsulation: service/function owns functionality and meta-model of input/output information (data) while objects own both functionality and data. I may be wrong but it seems logical to me. I developed services in one green-field project for one huge investment bank a few years ago. We had a business operation managing - BOM (orchestration) - service, which commanded functional services when they had to work and what Data Services they had to engage. The BOM service knew which Data service was associated with which data store; the functional service - didn't know. I hope, this helps to understand me :-) - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Thursday, April 16, 2009 4:32:48 AM Subject: [service-orientated-architecture] Re: Joe on Microsoft's combination of SOA & Storage We hardly ever disagree! :-) What owns the data then? Is it okay for multiple services to manipulate the same data set however they see fit? How many services can manage reservation data associated with the RWE of making airline reservations? If a service is not responsible for making sure the data is stored (via some implementation component that may be shared amongst service implemenations) , what is? Doesn't the service drive the CRUD operations for the data the service is managing? Shouldn't it be just one service doing that for a particular set of data? I'm not trying to sway you to my POV. I'm trying to better understand yours. -Rob --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > Rob, > > I've expressed my thoughts in my responses to AW. The overall point - I > disagree with "What component has responsibility/ ownership of the data > managed by a particular service? Implied in the "create reservation" > operation of an airline reservation service is that the service will store > that reservation for subsequent use. IMO, the service as a whole is > responsible and "owns" the data it manages. The data and its storage is not > independent from the service. It is an explicit part, though the specifics of > the service implementation can vary." However, I have no intentions to > convince you and recruite on my side :-) > > - Michael > > > > > ____________ _________ _________ __ > From: Rob Eamon <rea...@...> > To: service-orientated- architecture@ yahoogroups. com > Sent: Wednesday, April 15, 2009 4:17:29 PM > Subject: [service-orientated -architecture] Re: Joe on Microsoft's > combination of SOA & Storage > > > > > > Allow me to bend the issue a little bit. > > What component has responsibility/ ownership of the data managed by a > particular service? Implied in the "create reservation" operation of an > airline reservation service is that the service will store that reservation > for subsequent use. IMO, the service as a whole is responsible and "owns" the > data it manages. The data and its storage is not independent from the > service. It is an explicit part, though the specifics of the service > implementation can vary. > > Reservation data is to be accessed only through the exposed service > interfaces and its operations. Normally no other component should ever access > the reservation data (via the storage or the data access components) directly. > > Service implementations may share data access and data storage components, > but they still manage their own data. Service A never uses the shared > components to get the data managed by Service B. If Service B needs to > access/manipulate reservation data, it calls the operations on an interface > exposed by Service A. > > 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? SOA infers > style, not scope, correct? Would the discussion change if instead of > referring to SOA it referred to BA or EA or AA or infrastructure architecture > or some other explicit scope? > > Thoughts? > > -Rob > > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin > <m3poulin@ .> wrote: > > > > Gregg, you are making this up a little - data storage is out while > > data access is in SOA at the utility service level. Data storage is > > not a business thing but only implementation/ operational support to > > the business. Rooms of folders or rooms of magnetic tapes do not > > have any business functionality; business services depend on the > > storage a great deal but it does not change the business meaning of > > the storage. > > > > How implement quick access to needed data is pure technical task > > and I do not see reasons why it must be resolved exclusively by > > services. Nonetheless, I, probably, have to correct myself and say > > that data storage should be outside of scope of SOA business > > services. > > > > - Michael > > > > > > > > > > ____________ _________ _________ __ > > From: Gregg Wonderly <gergg@> > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Monday, April 13, 2009 11:18:16 PM > > Subject: Re: [service-orientated -architecture] Joe on Microsoft's > > combination of SOA & Storage > > > > > > > > > > > > Michael Poulin wrote: > > > I still think that data storage should be outside of SOA scope: business > > > services do not care where data comes from whilst the data is of good > > > quality. > > > > I think this is an interesting opening to some more discussion of what > > matters > > in what you call SOA and what doesn't. Data storage has an important > > aspect to > > it, and that is the storage technology and the retrieval technology. When > > you > > include technology, there is an interface involved, and that interface is > > important to the overall usability. > > > > For example, let's say we have three nice middle aged adults in your > > business > > that are responsible for data storage. If they decide that they want to > > keep > > everything printed on paper, and anytime you need data, you have to find > > one of > > them, have them look through the 3 rooms of file cabinets to find what you > > need, > > and then transcribe it into the format that you need it, would that be just > > as > > acceptable to you as a database system access using ONLY oracle PSQL, or > > just as > > acceptable as an HTTP based service? What if there core of your SOA was > > CORBA, > > JMS or Jini based? Would you still "consider" data storage to be "outside > > of > > SOA scope"? > > > > More directly, how would you decide what was acceptable performance of your > > system if the data storage decision didn't play into the architecture > > portion of > > your SOA? > > > > Gregg Wonderly > > >
