That does make it clearer. Thanks! --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > 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.
O/R tools separating object/entity dev from data management is cool. Good implementation stuff. > 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). Agreed. Where the data is stored isn't of much interest at the service level. The service simply uses some data component (I will never call this a data service) to do CRUD. > 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. It does seem logical. Let me offer this viewpoint. The service defintion and its interfaces are how consumers access the functionality provided by the service. The meta-model of the input/output information fits perfectly here. The service implementation, likely to be OO (and not necessarily SO), provides the functionality and owns its data. At the different implementation layers, the top level uses entities to interact with the lower data repository layers which in turn interact with specific storage facilities (DB). That top layer might interact with the data repository layer via web services instead of being compiled into a single executable (that's not SO and doesn't make the data repository layer a "service"). And that repository layer might be used by many, many different services. That's spiffy. But none of that changes that the service is responsible for a particular set of data. Service B better not be messing with Service A's data via the data repository layer. If Service B needs something done, it needs to use Service A's operations, not mess directly with Service A's data. Reservation data is defined, owned, managed, versioned, accessed, manipulated, etc. via the reservation service, not by anything that happens to want reservation data. > 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. That the service implementation doesn't know exactly where things are stored is fine. A great abstraction and decoupling approach. But the service is still responsible for the data. The data repository and related data store are the custodians of the data, not the owners. I'm not trying to sway you. Just presenting my POV. :-) -Rob
