Loosely Coupled gives a quick definition:
composite application -- An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).
Applications are traditionally monolithic. Two applications may share the same reusable framework or component, but they each contain their own copy of the code and run it separately in their own process. Even an application with an n-tier architecture is a monolithic architecture distributed amongst multiple processes.
What makes SOA different is that applications share running parts--called services or service providers--not just at development time but at runtime as well. If a shared part goes down, the outage affects multiple applications. So an application is made of multiple parts, some of which are shared with other applications. Is such a shared service part of app A or app B? It's part of both. So the "composite application" term not only describes that the application is in multiple parts, but that the parts are shared between applications.
I've talked about The Two Parts of an SOA Application, service coordinators and service providers. The providers are the shared parts. The coordinators tend not to be shared, although they can be composite services that are reusable service providers as well. I expand on these ideas, and how to make use of them, in Streamline SOA development using service mocks.