There are very few differences between SSL and TLS in the way they are used. There is, however, a fundamental difference between up-front establishment of SSL/TLS and the use of a command such as STARTTLS. Sometimes, “TLS” is used in contrast to “SSL”, to mean “using a STARTTLS mode” but this is incorrect.
Up-front TLS/SSL
In this case, the client initiates the TLS/SSL connection before anything else, so SSL/TLS handshake happens first. Once the secure socket is up, the application using it can start sending the various commands for the protocol above TLS (e.g. HTTP, LDAP in this mode, SMTP).
In this mode, the SSL/TLS versions have to run on a different port from their plain counterparts, for example: HTTPS on port 443, LDAPS on port 636, IMAPS on port 993, instead of 80, 389, 143 respectively.
The layers implementing these application protocols barely need to know they’re running on top of TLS/SSL. Sometimes, they’re simply tunneled in tools such as sslwrap.
TLS after STARTTLS (or equivalent)
The TLS specification allows for the handshake to happen at any time, including after having exchanged some data in plain TCP over the same TCP connection.
Some protocols, including LDAP, incorporate a command to tell the application protocol there will be an upgrade. Essentially, the first part of the LDAP communication happens in plain text, then a STARTTLS message is sent (still in plain text), which indicates that the current TCP connection will be reused but that the next commands will be wrapped within a TLS/SSL layer. At this stage, the TLS/SSL handshake happens and the communication is “upgraded” to TLS/SSL. Only after this the communication is secured via TLS/SSL, and both the client and servers know that they have to wrap/unwrap their commands from the TLS layer (typically adding a TLS library between the TCP layer and the application layer).
The details of how STARTTLS is implemented within each protocol vary depending on the protocol (because this has to be compatible with the protocol using it to some extent).
Even HTTP has a variant using this mechanism, although it’s mostly never supported: RFC 2817 Upgrading to TLS Within HTTP/1.1. This is completely different from the way HTTPS works (RFC 2818), which initiates TLS/SSL first.
The advantages of the STARTTLS approach is that you can run both secured and plain variants on the same port, the disadvantages are the consequences of that, in particular potential downgrade attacks or possible mistakes in the configuration.
(EDIT: I’ve removed an incorrect sentence, as @GregS pointed out, thanks.)
(EDIT: I’ve also put more on SSL vs. TLS in this answer on ServerFault.)