There are three parties involved (besides the network):

A) Push Initiator (PI) (NOT the device, but the push content provider)

B) Push Proxy/Gateway (PPG) (this is BlackBerry's Infrastructure)

C) Push client (BlackBerry device)

An example push message in a confirmed (ie. connection-oriented) manner:

1) The content provider (PI) sends a PAP push request to the BlackBerry Infrastructure (PPG). This request includes a list of the subscribed BlackBerry devices to which the data should be delivered, as well as the data to be delivered. 2) The BlackBerry Infrastructure returns a response to the content provider, acknowledging receipt of the request, and queues the request for delivery. 3) The BlackBerry Infrastructure pushes OTA the data to the specified BlackBerry devices. This doesn't have to be only a notification of new content; I think content (up to 8KB in size) can be pushed. 4) Each BlackBerry device returns a response to the BlackBerry Infrastructure, acknowledging receipt of the data. 5) The BlackBerry Infrastructure forwards the acknowledgement on to the content push initiator. 6) The Read notification is returned to the BlackBerry Infrastructure.

(One-way push only does steps 1. and 3.)

The push (step 3.) actually works through a Network Operating Center (NOC). RIM is able to do this because the BlackBerry device necessarily registers itself with a Telco, which then forwards the information on to the RIM NOC. The result is that the NOC now knows exactly where to push a message to. This is also the reason why a normal data plan is not adequate to give a BlackBerry push services. The PPG is able to send a Session Initiation Request to a device in a connectionless manner using e.g. SMS, indicating that it wants to push some content to a specific application on the push client. Content can be pushed in this manner as well. I think there are two protocols, PAP between a Push Initiator and the Push Proxy/Gateway, and Push OTA between the Push Proxy/Gateway and the device. If you're interested, the Open Mobile Alliance has a lot of technical documents that are publicly avaiable.

So, yeah, Blackberry's push is special, and it's necessary for them to plug into the telco infrastructure to do this; however, as an app developer, you just have to register with BlackBerry and use their APIs. Regarding the iPhone,I think Apple Push Notification Service is something like a "mini-NOC", that only does notification and isn't as full-featured as BlackBerry's, and is otherwise "push-like" by keeping open a session/polling.

I honestly don't know how Blackberry implements it, but there are a number of ways to accomplish it. Periodic polling (the way you mention) is generally regarded as 'bad'.

A better, but similar method is long-tail polling, in which you still poll periodically, but you wait for an answer, and don't time out the connection (or at least, don't time it out quickly.) You just leave the request hanging until you hear a response. If you don't hear a response before you have to time out, you just time out and then open a new long poll, doing the same thing. It's similar to polling every x seconds if there are constantly items to fetch, but if there aren't, it's much better.

Alternately, you can just set up a listener on the phone. I mean, Apache is the ultimate push client - it's just working the wrong way. If the phone number can act as the server IP address, then it just listens for a connection. The 'server' acts as a client, and 'requests' information from the phone whenever there is information to serve it.

for a consumer app, you push the message to blackberry... they send it to the phone. you don't interface with the telcos.

you have to register to use the push service and they have to approve your app.

https://www.blackberry.com/profile/?eventId=8121