Good questions
I think that SOA as you define it in (1) - an architectural style - requires (2) as an implementation style in order to be useful.
For a SOA to be useful, it must be able to encompass a heterogeneous set of computing environments. Just like the Web, you need standards (e.g., HTTP) that all participants must support. But, any technology that supports HTTP, can participate in the Web.
SOA, as a distributed architecture, must have *some* standards, so that a heterogeneous set of participants can all deploy and consume services.
Sure, you can implement the principles of SOA in Java without XML, WSDL, SOAP, etc. But, what is the point? SOA isn't a great architecture for Object Oriented design and programming. That isn't its purpose. Java is good at that. So is C#. SOA comes into play when you want to coordinate application A with application B, in a loosely-coupled manner, to automate a business process. If application A is in Java and application B is in C#, then you need some way for them to communicate.
Now, there are lots of ways to get Java to talk to C#. But, if your organization has put in the effort to design a good SOA, then most of the work has been done. And you don't have to keep solving the integration problem over and over again. You can simply deploy services and hook them together to automate a business process.
If all components of your computing environment speak SOAP and WSDL, then they can actually be grouped together into a SOA that is a valuable platform for supporting flexible automation of business processes. And that is the business goal.
The reason that it is a *big deal* that Java is finally getting good at Web Services is that it means that Java applications can more easily participate in an organization's SOA.
My book is designed to show you how to use the Java Web Services standards effectively to enable your Java applications to participate in a SOA.