SSL is secure socket layer, and is an extension on TCP. So, all transport protocols on top of TCP can use it, like http(s), ftp(s), etc.
There are a few versions of it, that each have stronger encryption. SSL 3 is the latest, I think. But it is superceeded by TLS, which stands for Transport Layer Security.
You may see TLS 1.0 as SSL 4.0, but with another name and new versioning. Nowadays you shouldn't use SSL anymore because it is considered to be too weak.
In weblogic you can use SSL/TLS by enabling it in the console after creating and configuring a proper key-pair with signed certificate in your keystore for Weblogic.
But in most cases your Weblogic is fronted by a reversed proxy using Apache or Oracle HTTP Server. You can do TLS offloading there and route to weblogic using plain HTTP.
And if from the outside world the HTTP server is the only accessible server, this could be fine. Why would you do HTTPs within your datacenter if you can't get to it otherwise then using ssh, preferably using a stepping stone?
However, if you do want your Weblogic traffic to be secured, it's not that hard, as explained above. But you need to consider securing the admin channel as well. And you need to do so for every Weblogic server in your environment. For instance, why secure the Weblogic running your front-end application, but not the SOA Server that handles messages from the front-end application? Then your front-end application traffic is secured, but the messages to the SOA Servers can be read. And what if you have secured all the traffic inside your datacenter, but anyone with SSH access can get to your JKS files and introspect them? Keeping the keys safe is also an important issue.
So, the technology is not that hard, but the procedures to implement and govern the security are complex. And forgetting something like the SSH access to the JKS files could make all the efforts near to worthless, for instance.