Если что-то написано через сервлет или jsp, то затем это небольшим усилием спинного мозга легко переводится в портлет портала. И даже совсем не обязательно будет переплывать с Tomcat куда-то. И там не Jserv работает, а OC4J.

Это уже по существу. Описываю только идею.
В сам сервлет вносим правки:
public void doGet(.....) throws ... {
PortletRenderRequest pr = (PortletRenderRequest) req.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
PrintWriter out;
if (pr != null) {
// режим портлета
out = pr.getWriter();
} else {
// режим "чистого" сервлета
out = res.getWriter();
}
try {
out.println(...);
} catch ... {
}
} //doGet

В описаниие провайдера надо внести правку. В showPage говорить не про класс, а про расположение сервлета. Т.е.:
ЗАМЕНИТЬ: <showPage class="..." />
НА: <showPage>/path/to/your/servlet</showPage>
Например:
<showPage>/jpdk/Servlet1</showPage>

1. Что ставить и как: для начала возьми OC4J контейнер (из JDeveloper, например), запусти его (java -jar oc4j.jar), выполни деплоймент портлета в этот OC4J, зарегистрируй провайдера в портале. В промышленной эксплуатации надо будет размещать портлеты в OC4J, который в iAS-е находится.
2. Всё это к JServ-у относится. Тут это без надобности, поскольку мы его не используем.
3. External Application: это зависит от того, что именно хотим встроить.

Вообще-бы я порекомендовал:
С http://portalstudio.oracle.com/ можно скачать PDK (~30MB), в котором кроме свежих jar-ов есть набор (~50...70) статеек (каталог articles), в которых есть описание что и как делать по шагам для различных случаев. См. http://portalstudio.oracle.com/servlet/page?_pageid=2744&_dad=ops&_schema=OPSTUDIO

1. Не совсем понял вопрос. Отвечаю на то, что понял: Всю созданную байду надо деплоить на OC4J. А в портале надо потом зарегистрировать провайдера, указав, в частности URL доступа к задеплоеному провайдеру+портлетам.
2, 3. Renderer - это абстрактные классы в PDK, выполнив наследование которых, можно генерить данные для портлета. Но можно и не наследовать, а написать сервлет (как я и писал выше). Т.е. есть два возможных варианта написания портлетов: писать "чистые" порлеты, которые нигде кроме как в портале не запустишь или писать портлеты на основе сервлетов - их можно запустить отдельно (как сервлет), а можно запустить и в портале (как портлет).

См. http://www.rdtex.ru/win/courses.overview?ccode=O9iBPJ
Welcome!

Не 2000, а 500.

Как ни смешно, но я эти курсы читаю.

Здесь имеет место недопонимание.
Теория:
Есть задача аутентификации пользователей в приложениях (каких-то). И есть задача интеграции этих приложений. Это может быть сделано одним из следующих способов:
1) Написать (переделать) приложение под портлет портала. Тогда задача интеграции и аутентификации решается сама по себе.
2) Написать приложение отдельно, зарегистрировать его как партнёрское SSO приложение. Тогда, аутентифицировавшись в портале, пользователь автоматически аутентифицируется в приложении. Ну а интегровать в единую систему: поставить в портале ссылку на приложение. Т.е. здесь надо понимать, что, по хорошему, здесь портал-то на третьем плане, и можно без него обойтись, т.к. он нужен тут только как точка входа в приложение.
3) Использовать возможность работы с т.н. внешними приложениями (external applications). В чем идея: есть некоторое внешнее приложение, на логику работы которого мы _никак_ повлиять не можем (Oracle любит приводить в качестве примера yahoo.com). Но хочется интегрировать это в портал и, заходя в портал, не регистироваться в этом приложении. Что фактически предлагается Ораклом: определить, как прокидывать параметры пользователя в из портала в HTTP форму регистрации пользователя во внешнем приложении. Т.е. после регистрации того же yahoo.com как внешнего приложения, портал берёт на себя регистрацию (т.е. заполнение HTTP формы, отправка её на yahoo.com происходят незаметно от пользователя). А пользователю кажется, что вот, он зашёл в портал, в портале кликнул на ссылку и оп, он, не регистрируясь уже работает с yahoo.com

Все наши предыдущие разговоры были про вариант 1. В нём не надо регистрировать никакие внешние приложения и самому думать про SSO. Логика работы должна быть такая:
1) Разместили созданные портлеты на удалённом контейнере. (тут портал ничего не знает про этот удалённый контейнер).
2) Зарегистрировали провайдера из удалённого контейнера в портале (этим, фактически, говорим порталу, что существуют портлеты и если кто-то будет их размещать на страницах, то html-содержимое портлетов надо брать оттуда-то).
3) Размещаем портлеты на страницах.

Ещё. Касательно того, что сервлетов много и есть JSP впридачу. Сомневаюсь, что тут удастся запихнуть это хозяйство один портлет. М.б. есть смысл разбить это на множество независимых компонентов? Ведь в чём идея портлета: есть портал, есть страницы, есть пользователи. Зайдя в портал, пользователь на одной и страниц может увидеть портлет, который ему что-то должен показывать (например, погоду). Нажав на ссылку в портлете, пользователь может инициировать дальнейщую "активность" портлета (нажав на ссылку в портлете, например, показать погоду не на завтра, а на неделю). Вот в чём и есть логика работы с портлетами. Ну, понятно, гиперссылки надо формировать используя специальные методы в PDK.
Вообшем, сначала надо подумать, как будет ложиться приложение в портал. Ведь не совсем логично его бубухать as is. Тем более, через портлет.
Я бы предложил начать с простого. Портлет, который пишет Hello world, ты создал?

Простой путь:
Поставь расширение http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/utilities/jdev/portal-addin.zip к JDeveloper
Потом, через New в JDeveloper можно найти создание портлета через wizard-а. Есть опции, как его создавать: через JSP, сервлет или через рукописный класс.
Думаю, что для понимания сути работы этого достаточно.