I'll get on my dope smoking horse... The basic reason is that it fits a vendor & technology view. There are few things easier in this day and age in taking a database and lobbing up a website and doing some CRUD. This makes it very easy to dust off the EJB books and the PL/SQL books and re-write them as SOA changing only a few works and a couple of technologies.
If you are flogging some technology then it makes sense to base anything you write about around the technologies that you have, and it makes no sense at all to highlight that its actually the intellectual model that matters. Steve 2008/9/19 Colin Jack <[EMAIL PROTECTED]>: >> That said, I do tend to think data access only services (focused on >> CRUD or entity states) are anathema to SO. Services should be more >> functional/capability leaning than data leaning. (Changing the state >> of an entity/object is not a "capability.") > > 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? > > 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. > > -Colin Jack > >
