--- In service-orientated- [EMAIL PROTECTED], "kavandersluis" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Steve > Jones" <jones.steveg@> wrote: > > But the main point of the article is that the data abstraction > layer hides the underlying data source, making it irrelavant to the > consumer whether data is derived from relational, mainframe, other > apps, etc.
IMO, services do this already. For an SO approach, DAL may be helpful in some implementation details, but IMO it is not a key to SO success. > What I'm really suggesting is using XML models to define entities > which become the basis for entity-style services, which supply the > data to apps and higher level services. It is this set of entity- > style services that constitute the XML-based data abstraction layer. IMO, such "services" are misplaced. Data access-only components are not services, IMO. The value in an SO approach is in doing something with the data, not just reading/writing it. Services encapsulate the read/write/do. Facilities that only read/write are not SO, IMO. They are data oriented. "Entity-style" services may be a useful implementation approach, but IMO they should not be anything further than "private" services, if viewed as services at all. -Rob
