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 [email protected], Michael Poulin <m3pou...@...> 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 <ge...@...> > To: [email protected] > 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 >
