This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
One of the nice things about SOAP is the fact that the structure of the faults is predefined as we can see at SOAP Fault Element.
With Firefow Poster you can simulate the situation and work on the Java code the processes these faults.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
It's good that you said which web service API you are using. But, it really doesn't matter when dealing with SOAP Faults!
Based on your details, I understand your Application 1 is acting as "client" to Application 2. Then you must have created your client stubs using Application 2 WSDL. If your Application 2 WSDL is defined with one or more SOAP faults, then your client stubs correspondingly contain methods throwing SOAP faults. For you, catching SOAP faults is like catching any other checked exceptions (viz. SQLException). SOAP fault details (like in Dan's reply) can be accessed by invoking methods on exception object.
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)