One difficulty I have with "service-oriented architecture" (SOA) is that its acronym shares too much with "simple object access protocol" (SOAP) - which is not simple, barely object, and just about an access protocol. Strictly speaking, the two are independent, although SOA is most commonly implemented through web services, which frequently include SOAP. In fact, stripping off the web service layer and reimagining SOA without that implementation detail, it's close to what I've been doing for several years (and in what I'm doing now, web services are back on, this time in the form of REST).
In many ways, then, this book was reassuring, that I'm more or less on the right track in this area. Unfortunately, there was quite a lot of ego and opinion in it as well. Some of the Java code examples were blatantly syntactically broken (package names with invalid characters) and some of the description of "generic" interfaces pushed things to the point of meaninglessness without good examples. I've noticed of late that there's a growing trend in open-source software for packages to describe themselves as "opinionated", as though it were a good thing that choice is removed. Unfortunately, that too often means imposing an extra burden on the user of said packages as they fight to make them fit their particular case. That could be the case here. There was a useful appendix on SOA design patterns, and a less useful appendix on the SOA manifesto.