The EA help does a pretty good job of defining what a port is, but then doesn't give a very helpful example.
Ports have their roots in ROOM (a predecessor of UML from the early/mid 90s, only implemented in IBM Rational Rose RealTime AFAIK), and in ITU Z.100 SDL gates, from the early 80s.
For me, port makes most sense when used on a composite element; they represent (the only) communication points for that assembly with the outside world. A composite element can be assembled into another composite element (as a part), which is the same thing as saying that a composite element may itself be an assembly of other composite elements (as parts).
Ports realise interface class(es), which specify and constrain communication through the port. Putting a required interface (socket symbol) on a port specifies communication out of the port to the environment, realised (lollipop symbol) specifies communication into the port from the environment.
In principle a composite element is then fully defined in isolation from the environment, something you couldn't do in UML 1.x, because 1.x didn't have the concept of 'required' interface, you ended up modelling a required interface as an association with an abstract class, then using inheritance from that class when you realised this in code. Same effect in the end, I suppose, but fairly opaque.
In other words, along with composite elements, ports allow you to model hierarchical decomposition of a complex system into subsystems, subsubsystems, etc, communicating through well-defined interfaces. Voila, Architecture in UML!
The bottom line for most people is how this turns into code. The short answer is, it doesn't AFAIK unless you use Telelogic UML 2.0 tools where they have full code-generation, i.e. into a framework which understands ports and architecture. I guess this is what Rose Realtime did from ROOM+UML 1.x. It certainly doesn't map onto vanilla C++. I don't know how EA generates it (if it does at all). Anyone help?
HTH
Ian