Not exactly, you have to think about your web services written in PHP as completely separate from your Sencha app. You server-side PHP code will be located in it's own area on your server (wherever you host your web services) and they are only exposed through the web service themselves (think of them being on a different server than your Senha app). So you don't mix in your server-side PHP with Sencha at all, they are completely separate. Typically the tools used to create web services allow you to generate a manual access web page which lists your web services and allow you to manually call them with parameters and see the results right from your browser. This is a great way to check that the web service really works if you are having problems calling it from your Sencha app. This is also a great way to work if for example you have someone else write the web services on the server - they simply provide you with the manual access page for your browser and from that you have everything you need - the URL of the web service, the parameters, the results, and you can even try it with real data.
The one thing you need to be careful of is your domains - try and have your Senbcha app and your web service hosted from the same domain. If they are different then you can still access cross-domain using a JSONP store but you are limited to GET (no POSTs) so not that secure and certainly not good for something like a login. Also you can run into problems with mobile, the iPhone for example has the default cookies set to "From visited" which means that if your Sencha app is hosted on a different domain than your web service and you want to use POST then it won't be able to access them until you first browse to the web service URL manually - not very practical for your users. Using a JSONP store gets around this which is why you will see it used to access public web service like twitter because they are on a different domain than your Sencha app, but it is not very secure.