Agile is many things to many people and some feel strongly about those things than other. Read Agile manifesto. This is just my opinion, but at the end of the day Agile is about doing what's right with minimal amount of overhead and using whatever good and proven methods/techniques (i.e. TDD...) that make sense for your specific situation.
As others have already mentioned, most agile teams strive to deliver small increments in small iterations. And whenever possible you should be doing the same thing. At the same time, it pays to have the right design done upfront. If your application requires a framework, by all means go ahead and put the framework in place. Yes, you will not be able to deliver anything working for several weeks and maybe more, but if you and your team feel that you need it, then do it. The corner stone of Agile is that it's about people, do what people believe you need to do and they will have your back and be vested in the product. We used to force constraints that made the entire team feel weird and awkward and that's just bad.
At the same time keep in mind that you can treat your framework as a separate deliverable that must be delivered to a "development team" so that the team can deliver the final product. Most of the time after the minimal foundation is in place, you can work on framework in increments just like you would on actual product. Decide the absolute minimum you would need from the framework to make the product do something and focus on that first.
Also IMHO, take the phrase "no big design upfront because you are agile" with a grain of salt. Although you definitely do not need to go into details and spend 6 weeks writing design documents, for a large scale project it still pays to spend some time thinking about overall architecture and high-level design. Put the big pieces in their right places so your team has a clear roadmap where you want to end up. Because you only do high-level design, if your direction changes, you will only need to update high-level documentation (shouldn't be a lot). I would never rely on refactoring alone to dictate the final structure of a large application. Your goal is to do minimal design NEEDED, not absolute minimum to a point where there's virtually no design upfront and requirements drive evolution of your modules.
Finally, just because you can't deliver anything actually working until the entire framework is in place, it doesn't mean you can't chop up the framework into several pieces and focus on each one individually along with TDD. You can abstract away SOA interfaces, database, network communications, some other back-end logic and even though all of this must be in the framework, you can do write each one using TDD and mock up whatever interfaces those pieces will talk to. Some of your team can start working on actual application code using mock classes that pretend that your final framework is in place.
So forget about methodology, take a step back and ask yourself (and the team), is SOA the right approach for this application? If it is, you can definitely make it work with agile.