--- In [email protected], "Colin Jack" <[EMAIL PROTECTED]> wrote: > > With that in mind does it not worry you that so many sites/books seem > to present CRUD services as being the bedrock of SOA and that without > them SOA wouldn't make sense?
It does concern me somewhat. In addition to Erl, the authors Krafzig, Banke and Slama also present a similar notion. "Basic services" which "cut into" data centric (Erl's entity services) and logic centric services. IMO, segmenting along data and logic, or data and transactional aspects (as presented by David Besemer in "Service Oriented Architecture: Getting it Right") is based on other conceptual approaches. For example, entity services seem far more OO than SO to me. Data services are data-driven constructs, not SO. Data access layers and tools that help aggregate data access are useful service implementation tools--but are the wrong level of focus for SO. Shared data access components might be very useful in an implemenation. But that's not the level to focus on and IMO should never be referred to as services (calling everything a service gets confusing). OO has its place but when defining an architecture following SO principles, OO notions (e.g. "business entities") shouldn't be the place where service identification starts. Neither should one start at identifying what data elements exist in a database. > I realize that a lot of content on the Web describes the tradeoffs of > an entity service based approach but many people are going to learn > about SOA primarily from books and at the moment the ones I've looked > at all provide one viewpoint on how you approach SOA. You're right. There is a lot of material about entity services and/or data services. As Steve Jones touched on, I think that's because that's the low hanging fruit. In many ways, it's familiar, looking very much like our OO upbringings of the past decade or so, thus we tend to gravitate toward that. As always, just my 2 bits. -Rob
