korchagin написал:
Хотя я не являюсь большим поклонником EP, на такие категоричные утверждения очень хочется возразить.
По поводу SSO. Во-первых, соответствие SAP Logon Tickets российским ГОСТам - это проблема НЕ портала и, тем паче, не Java WAS.
С утверждением согласен. Однако и у праворульных машин проблем тоже нет, кроме той, что в нашей стране машины леворукие по стандарту.
Я хочу заметить, что разработчик платформы должен адаптировать ее к стандартам страны, в которую он ее поставляет. Я имею в виду SAP, а не Sun в данном случае.
korchagin написал:
Во-вторых, SSO – это просто автоматическое инициирование процесса аутентификации, а не шифрование данных, поэтому не совсем верно связывать его с SNC (шифрование трафика) и SSF (шифрование данных с электронной подписью). Вовсе не обязательно, что в рамках SSO производится аутентификация посредством сертификата. Портал предоставляет инструменты User Mapping, позволяющие регистрировать пользователя приложений различными методами.
Полностью принимаю возражение. Однако давайте разберемся- что SAP предлагает в качестве основы для SSO? - SAPCRYPTOLIB .... Поправьте если я не прав.
По поводу технологии мепинга хочу заметить: технология хороша если она дает на практике выгоду от применения (и не только финансовую). Согласны? Теперь ответьте: нужен портал на 50 пользователей? или компании можно обойтись без него? - Наверное можно без портала .. я так думаю. А вот если в компании 2000 народу должно работать с порталом - а в портал допустим сведено порядка 40 различных АСУ и в среднем пользователь работает с 5-6 АСУ - попробуйте помепить месяцок такое решение - я готов буду подарить Вам веревку и мыло душистое ( не воспримите как оскорбление, но впору будет повесится).
korchagin написал:
Если для соответствия работы с портальными приложениями требованиям законодательства недостаточно передачи данных с использованием SSL и ticket/form-based/basic/digest аутентификации, то задача интеграции сертифицированных ФСБ/ФАПСИ алгоритмов встанет в любом случае. Совершенно не важно, какие инструменты построения удаленных интерфейсов используются. Кроме того, надо заметить, такие требования относятся к довольно узкой сфере возможного использования портала предприятия.
Про ФАПСИ Вы правильно заметили, но дальше тут очень скользкое утверждение по поводу узкой сферы использования. В вашем случае получается что интеграция в портал должна делаться по технологии "пользователь -> портал -> система". Т.е. Пользователь по HTTP(HTTPS) общается с порталом на SAP J2EE, а тот в закрытой зоне по закрытым от пользователя интерфейсам тягает данные и кажет в браузер пользователю. А как же интеграция "пользователь -> inframe(система)"? А такая интеграция используется в большинстве случаев! Статус 302 протокола HTTP никто не отменял
. А тут как-раз SSO и нужен. Передаете Вы в HTTP заголовке просто куку или SAPLogonTicket неважно! Удаленная система должна идентифицировать вашего пользователя. А что такое SSO для нас? - это или PKI+SAPCRYPTOLIB или UserMapping или своя разработка ( и потом, не дай бог, сертификация в ФАПСИ).
korchagin написал:
Небольшую свинью подложила Microsoft с патчем IE, после установки которого стала невозможной Basic HTTP Authentication через iView типа Application Integrator. Патч, вопреки RFC 2617, запрещает указание параметров авторизации в URL (
http://user:password@domain.zone), поэтому приходится искать решение, чтобы на лету изменять заголовок http-запросов. Несложный proxy-сервис на Java пишется за несколько дней.
Rapid Development. Very quick. Скажите пожалуйста - а что еще будет патчить MS в этом году???, а то надо план работ писать, программистам платить, время планировать, выдавать дату релиза и его функциональность.... Мне кажется что тут стоит сделать ремарку: в тени остался факт того что SAP EP "нормально" ( ну если браузер не патчить и рабочую станцию перевести на ручное обновление и с выходом на Windows Update тестировать каждый патч от MS ) работает только с IE. Попробуйте использовать Opera, Mozilla, FireFox и т.д. и вы поймете как иногда весело бывает смотреть в окно браузера. Вот он - несомненный плюс SAP EP. Мы уже повеселились разок с порталом, когда полкомпании могло войти в портал, а половина дальше логон-экрана не могла пройти. И фреймы очень весело отображались. А потом на SAP support нам тихонечко сказали "- ребята, только IE, и только такой. И не будем мы Вам официально это подтверждать, даже не просите. Потому что во всех анонсах у нас все поддерживается, уж Mozilla точно."...
korchagin написал:
Теперь про разработку. С чем идет сравнение WebDynpro, мне не удалось понять (не ABAP/4 же рассматривается как образец «платформы для Rapid Development»). Это всего лишь один из API, причем очень высокого уровня. Разному уровню задач соответствуют различные методы решения. Благо, технологии Java (в отличие от PHP, пока ориентированного исключительно на server scriptlets) предоставляют богатый выбор.
Если сравнивать WebDynpro на Java и WebDynpro (SAP WAS 7.0) на ABAP - я однозначно выбираю ABAP - быстрее, проще, мощнее. Если брать ядра SAP WAS 6.20/6.40 - BSP(MVC)+HTML_Template_Editor_любой+HTMLB практически аналогично по скорости начальной разработки SAP J2EE. А вот когда вопрос переходит в плоскость отладки и поддержки(читай развития Web-приложения) то тут сравнение практически неприемлемо. Все сильно зависит от качества разработки, ее объема и т.д.
Теперь про ABAP - я базисник, не программист, однако ABAP - язык ОЧЕНЬ высокого уровня. И уж выше чем Java
. На ABAP отчеты и диалоги пишутся ОЧЕНЬ быстро. Добавьте огромную библиотеку классов высокого уровня - написать сложный Web-сервис можно в пару строк.
И еще - когда говорят про PHP - почему-то всегда вспоминают его script_based. Предлагаю зайти на
http://www.php.net в раздел "Documentation". Дело в том что PHP уже 2-й релиз (4-й и 5-й PHP) во всю объектный. Более того Объектная модель в PHP-5 является частью ядра. Почитайте
http://www.zend.com. Полюбопытствуйте на
http://pear.php.net. Хотя уверен, что Вы неплохо сами осведомлены об объектности PHP.
А еще:
Можно обратить внимание
http://www.zope.org/ .
Можно обратить внимание
http://www.perl.org/ .
Дело в том что использование ООП не обосновано при построении портала - и выбор исключительно ООП систем для построения портала НИЧЕМ не обоснован, кроме моды. Я видел прекрасные реализации портала, построенные на PERL.
Также могу и дальше перечислять платформы для построения систем, порталов на базе HTTP протокола (а портал не подразумевает HTTP протокола).. Но надеюсь я Вам ответил: " ..с чем можно сравнивать".
korchagin написал:
К слову, о «слабоватой платформе J2EE». Так называемая «технология J2EE» собственно технологией не является. Это набор различных стандартизированных интерфейсов, по каким-то соображениям не включенных в стандартный пакет разработки. Имплементацией занимаются разработчики базового ПО, к которому относятся EJB серверы и клиенты, Servlet контейнеры, XML сервисы и т.д. Поэтому утверждение, будто бы «SAP по сути ПЕРЕПИСАЛ сановский J2EE» выглядит очень странно.
Согласен, некоректное с моей стороны утверждение. Вы тут более правы.
korchagin написал:
Судя по всему, автор периодически подразумевает под J2EE технологию EJB (опять же, Sun разрабатывает только интерфейсы этой надстройки над RMI). В таком ракурсе тем более странно сравнивать Java и PHP. EJB ориентирована на распределенные трансакции и обеспечивает персистенцию данных. Отсюда и ресурсоемкость с низкой, относительно единого приложения, производительностью. Еще бы – каждый модуль портала является самостоятельным приложением, способным работать в распределенном контексте сессии.
По вопросу некоректности сравнения хочу отметить следующее: PHP имеет PEAR/PECL расширения. И для них не нужно разрабатывать интерфейс. Потому что интерфейсов не много - он просто один. И сравнение я считаю правомерным.
Описывать недостаток системы - ее архитектурой я считаю неверным. Таким методом можно продавать запорожец по цене мерседес 600 и ставить их рядом. А на недоуменные вопросы покупателей отвечать - это такая архитектура. Давайте по модному сравним - на деньги. Если мне при прочих равных условиях для системы на Java надо закупить аппаратуры на 10 млн $, а для
тяжелой системы на ABAP нужно закупить аппаратуры на 5 млн $ - как вы думаете какой я выбор сделаю? И не говорите мне про TCO! Я сразу отвечу Вам:
Как я утверждал выше - скорость разработки на ABAP выше или сопоставима со скоростью разработки на Java. Стоимость сопровожнения ABAP сопоставима со стоимостью сопровождения на Java. Временные затраты на модификацию при использовании ABAP ниже чем при использовании Java. ПО на ABAP более стабильно; платформа ABAP более стабильная, более отказоустойчивая.
О чем кричат менеджеры, когда рекламируют Java -> о том что она дешевая. Для меня получается странно!! Однако когда почитаешь разные скуцес сториес - становится понятно почему менеджеры любят Java... Приведу пример, а потом его повторю со своим комментарием (в скобках жирным буду давать свой коментарий):
"... При использовании Java нам удалось сильно съэкономить. Мы оставили 2-х архитекторов, полностью разбирающихся в системе. И сформировали проектную команду из Java кодеров. В короткие сроки кодеры написали систему и полностью ее документировали. Учитывая частичный характер отладки приложения, нам удалось снизить время отладки и выпуска приложения для заказчика....
...
Затраты по сопровождению приложения мы покрыли из доп. соглашения с заказчиком на сопровождение. Для сопровождения мы использовали 2-х разработчиков из проектной команды, которые плотно работали с архитекторами и пользователями" ...Теперь комментарий:
"... При использовании Java нам удалось сильно съэкономить. Мы оставили 2-х архитекторов, полностью разбирающихся в системе( т.е. разогнали проектную команду которая была и перегрузили пару оставшихся "счастливцев". 1-я экономия за счет жесткой эксплуатации). И сформировали проектную команду из Java кодеров(раз ты "кодер" - значит дешевый! будешь хорошим, добрый дядя сделает тебя архитектором, чтобы ты пахал на меня с утра до ночи. 2-я экономи за счет жадности.). В короткие сроки кодеры написали систему и полностью ее документировали(зачем нам технические писатели? кодеры пишут, пусть и документируют. 3-я экономия за счет жадности.). Учитывая частичный характер отладки приложения(!!! люди пишут - а программа-то сырая, мы ее цуток потестировали, что запускается. 4-я экономия на тестерах и качестве), нам удалось снизить время отладки и выпуска приложения(не удивительно) для заказчика....
...
Затраты по сопровождению приложения мы покрыли из доп. соглашения с заказчиком(гениально! продать машину с заведомым браком, как новую и за сервис брать деньги! по полной! 5-я прибыль) на сопровождение. Для сопровождения мы использовали 2-х разработчиков из проектной команды(а тут и группу кодеров разогнали, оставили самых склоняемых на трудовые будни. 6-я экономия.), которые плотно работали с архитекторами и пользователями" ...Делайте выводы сами господа. Мне кажется, что делай по человечески продукт на Java - его стоимость зашкалила все что можно. Такими вот сукцес сториями кишит пол интернета.....
korchagin написал:
Собственно, разработка приложений под Java WAS практически ничем не отличается от обычного процесса создания приложений для прочих серверов EJB и Servlet-контейнеров (кроме того, что ряд работ выполняются еще проще даже персоналом с невысокой квалификацией за счет специальных средств разработки от SAP).
Извините, хочу уточнить, вы имеете в виду разработку интерфейса пользователя или разработку логики обработки данных? Если Вы говорите о разработке интерфейса, то я с вами согласен. Средства у SAP хорошие - Eclipse как-никак. Да и VisualComposer неплох для поделок.
А что мешает посадить за "рисование" пользовательского интерфейса для того же BSP новичка? В общем ничего. Дайте ему Macromedia Dreamweaver с загруженной HTMLB библиотекой - вот и все. Нарисует он экраны для любой BSP под ABAP. А можно и без HTMLB нарисовать. Кому что нужно....
А теперь про разработку логики обработки. Скажите - нужна здесь квалификация? или нет? знание объектов? репозитария? проектных решений? стандартов? так какая квалификация тут нужна?
korchagin написал:
Чрезвычайно удивило то, что сравнивается внедрение портала (middle tier) и R/3 (business logic). Понятное дело, что разработка продуктов на Java имеет собственную специфику, отработанную, кстати, в течение многих лет. Странно представлять все это как недостаток EP или J2EE в целом. Смею предположить, что масштабы внедрения разработок на основе стандартов J2EE на порядки превосходят внедрения ABAP-систем.
Ну хорошо хоть мидлтайр портала признаете.
Я не уверен что на J2EE на порядки больше внедрений, чем на ABAP. Думаю что необходимо сравнить по цифрам. В ракурсах внедрения, успешного внедрения. На моей памяти в 1998 году у SAP уже было более 25000 крупных много системных инсталляций ( собсно в системах называлась цифра в 120 000 установок). Сколько сейчас, я не знаю вполне возможно что цифра в районе 100 000 инсталляций и 4-500 000 систем. А вот сколько систем на Java???
korchagin написал:
Все вышесказанное не является аргументацией в пользу внедрения Enterprise Portal, выбора Java в качестве языка реализации и прочих общих положений. Однако критиковать эти продукты следует все-таки более обосновано.
С некоторыми Вашими утверждениями я согласен. Однако считаю что свое мнение я обосновал.