Admittedly I'm talking about SOA here as a business concept rather than a technology concept, but that said I think the two go rather well together in fact. Thinking about defining services and then categorising them for delivery might mean that a Web 2.0 with AJAX, monkey nuts and side trimmings of agile could be the right way to deliver a particular service. I've used a 3D grid to try and explain to people that different services require different delivery approaches and to try and break the "one ring to bind them all" approach to project management that often exists.
Equally if one of the services is a package solution that needs almost no configuration and for which the requirements are already known and fixed by the package then you probably don't want to go down the XP route. And if its a business process centric solution like "employee take on" or something with big compliance concerns then again you probably want to pick a more formal method (but naturally one that has iterations).
One size doesn't fit all, and taking an architectural and particularly a business view of SOA helps you pick the right delivery approach for each service rather than trying to shoe-horn one method onto everything.
Its not SOA v Web 2.0, its about understanding the wider problems and understanding what works best where. SOA v Web 2.0 is like arguing Linux v VI, it doesn't make sense. Unless of course its the one that's "vendor bulls***" (how does Tim Bray talk with *s? Must be an XML guru thing) then there might be more of a point, but that is to concede that SOA must be defined solely by marketing hype and never by an actual Service Oriented Approach which is a shame.