Within the Software Deployment Manager (SDM) you have the ability to deploy and manage various software packages that you receive from SAP.
SAP breaks those packages into two very detailed and catch all archives.
The Software Deployment Archive (SDA)
It is the delivery format for all non ABAP SAP applications. Essentially this archive is a ZIP compatible file which allows you to use it for a container for other archives. The SDA also contains the ever so important package related data information that is contained in the manifest. For instance the jar and war as well as any additional software logistics information.
The SDA is also the absolute smallest deployable unit as well as the smallest unit in which patches can be delivered and created.
So keep in mind that SDAs are not a representation of a version of a software component.
Now with that being said there is an exception to ever rule right? Yes... Yes of course there is. This exception is the EAR file. Within J2EE content the EAR file contains a manifest and is therefore seen and accepted as an SDA. It is recognized by the SDM and treated as an SDA. The only small difference is that the EAR file is not renamed with the .sda file extension.
The Software Component Archive (SCA)
The big differential here is the word "Component". The SCA allows you to deploy an archive that has a precisely defined version level and contains a specific number of SDAs.
It also is a physical representation of a version of a software component. So let me transfer that into good old straight forward english:
With every SCA update you always achieve a new version of the software component. This very point separates it far from the SDA that we have just spoken about.
So what does all this mean to you as a developer?
Simple: Use SDAs to push small bug fixes and such. Use SCAs as a way to push new versions of your applications.