In the long run, it's better to choose a mechanism that you don't have to maintain. Whatever the implementation mechanism, the fundamental purpose of the middle tier is to provide a level of indirection to business logic that allows it to be executed and resource-managed elsewhere. This opens the door for building more scalable, easier to manage systems. They are easier to manage because, if properly implemented, middle-tier logic can be upgraded without affecting client installations. They address maintenance and scalability problems found in two-tier systems.
Implementation depends on clients, developer methodology, and the communication mechanism.
For example, if you developed your monolithic app with an eye to future three-tier expansion, and are now moving to a layered architecture, you would have fewer headaches in multitier land because you would have been able to move your cleanly partitioned layers to other computers. Much of your system would be composed of COM objects. Traditional three-tier approaches, depending on their implementation, can have a few problems when introduced to the Internet. Because the Internet is open to the public, you have to implement security mechanisms to keep out the bad guys. The ever-present firewall monitors network traffic between systems and either allows or disallows communication based on some authentication protocol.