ADF Ui Pages can be based on Webservice datacontrols to show the information fetched from webservices.
During Development the Ui might be based on services deployed in Developement server/Mock services running on tools like SOAP UI. When this UI moves to Integrated Test environment/Pre-Production Environment/Production Environment, the endpoints of the services used will change.

To make the UI work in all the environments, the endpoint URL's have to be changed based on the environment in which the UI is deployed.
(HERE I AM ASSUMING THAT THERE IS NO UDDI REGISTRY INVOLVED and this assumption is true in most of the client sites. If the UDDI registry is involved then there is nothing to change in the UI side. Everything will be maintained/changed only in the UDDI. If multiple UDDI registries are involved then again the url to the UDDI registry has to be changed in the UI.).

In ADF, the information about the service being invoked is present in the "connections.xml" file. This information includes things like the WSDL url, the endpoint etc. This information can be changed manually by changing the values of the following .

• Identify the "wsconnection" XML element that corresponds to the service being invoked.
• Change the "description" attribute of this element to point to appropriate WSDL url.
• Identify the "service"  XML element in the "wsconnection" element and within that element search for the element which looks like
  
  
  Change the "addressUrl" attribute so that it points to the appropriate endpoint.

That's it.
When you run the UI, it will start making calls to the new location instead of the old one.

Instead of changing this information manually, the above series of steps can be performend using an automated script (like ant/custom java /perl script) as well.

Found a good article which explains the differences between the usage of the EL expressions like
${expr} (immediate) and
#{expr} (deferred)

Here is the link

Here are some of the important points from the article (in case if you don't want to follow the link..

The primary limitation of the JSP EL (expressiongs like ${expr}) is that its expressions are evaluated immediately, meaning that the JSP container immediately parses and resolves the expression when it processes the page and returns a response.

Immediate evaluation is sufficient when a JavaServer Faces page is rendered for the first time. However, after the user enters values into the UI components and submits the page again, those values are converted, validated, and propagated to server-side data objects, and component events are processed. In order to convert data to the proper type, validate it, store it in an external object, and process events in an orderly fashion, the JavaServer Faces life cycle is split into separate phases to handle each of these tasks. Therefore, it must be possible to evaluate expressions at different phases of the life cycle rather than immediately, as is done in JSP technology.

Another problem with the immediate evaluation of expressions is that it is done in read-only mode. JavaServer Faces components need to be able to get data from server-side objects during the rendering phase and set the data in the server-side objects during postback.

Finally, JavaServer Faces components need a way to invoke methods on server-side objects during various stages of the life cycle in order to validate data and handle component events. JSP functions are not sufficient because they can only be used to call static methods defined in a TLD file; they cannot be used to dynamically invoke public methods on objects.

http://www.oracle.com/technology/products/adf/patterns/11.1.1.1.0/UnsavedDataWarning.html