Many of the objects in the portal use Web services, which are components that run on a logically separate computer from the one that runs the portal. We call this separate computer a remote server. The Web service architecture allows multiple types of remote services (authentication sources, content crawlers, outgoing federated searches, portlets, and profile sources) to share a logical remote server, making it easier to manage the computers that make up the portal.
Web services also allow you to share settings (sometimes rather complex settings) with the objects created from those services. For example, administrative users creating portlet Web services need a greater understanding of the structure of the portlet, because they need to specify whether the portlet has preferences or whether it sends user information; whereas users creating portlets from that Web service might only need to set configuration settings appropriate for a non-technical user.
Objects that use Web services follow this general structure:
The remote server contains the base URL and credentials.
The Web service defines configuration settings for the associated object: remote authentication source, remote content source (used to create remote content crawlers), outgoing federated search, portlet, and remote profile source.
The associated object defines any remaining configuration settings.
Every Web service created by Oracle includes a PTE file containing the Web service settings. After running the Web service installer, the portal administrator should import the PTE file to create the Web service object in the portal. The portal administrator should not have to change any settings through the portal user interface.
For custom-built Web services, a developer should generally create the Web service object on a development system and then migrate it to the production system.