Сценарии интеграции приложений. Интранет-портал

Я думаю, что несколько предыдущих сообщений этого блога могли вызвать определенное недоумение. Какое отношение имеет концепция Digital Workplace и уж тем более простая базы данных с пользовательским интерфейсом к архитектуре информационных систем? В действительности, все эти задачи сильно связаны между собой, и все они относятся к интеграции приложений:

Таким образом, это сообщение можно назвать Сценарии интеграции приложений(4). Чуть раньше я уже писал о том, что Digital Workplace является зонтичной концепцией, композитным приложением, предоставляющим доступ к функциям других приложений. В полной мере это относится и к данным. Т.е. по сути Digital Worplace, он же новый интранет это способ избавить корпоративный ИТ ландшафт от множества маленьких приложений в стиле база данных плюс окошки, сократить усилия за счет повторного использования однажды разработанных компонент. Если этого своевременно не сделать, то мы довольно быстро получим сложнейшие интеграционные задачи, описанные в заметке Сценарии интеграции приложений(2) Это идеальный вариант. Сервис-ориентированная архитектура (SOA), как её видели стратеги десяток лет назад


Как и все благие намерения SOA разбилась о рифы реальности. И главное причина тому интероперабили (interoperability) унаследованных приложений, вернее её отсутствие. Большинство приложений делалось для людей, а не для интеграции. Для людей(пользователей) в прямом смысле, т.е. каждый из разработчиков считал, что с его приложением будет работать человек, а не другая информационная система. Интеграция приложений – это уже набор конкретных практик, возникших из желания обеспечить согласованную работу множества систем, по возможности, не напрягая при этом пользователей. Именно поэтому корпоративный интранет портал или, если угодно, digital workplace является основным элементом интеграции приложений, не менее важным, чем Enterprise service bus, ETL или же очереди сообщений.

Пользовательский интерфейс к базе данных Oracle

ИТ подразделение любой современной компании регулярно получает запросы на разработку новых систем. Обычно, речь идет о каком-нибудь небольшом решении, реализуемым простой базой данной и парой десятков пользовательских форм. Существует множество технологий, позволяющих это сделать. Наверное, наиболее распространенным на сегодняшний день является подход Microsoft: берем MS SQL Server + MS Internet Information server, рисуем базу данных и веб-приложение и задача решена. Я сам баловался этим подходом лет десять назад. (Кстати, сейчас нашел в интернет разработанный мною в 2000 году блог/форум тех.поддержки для дилеров нашей компании и с чувством нескрываемой гордости 😉 обнаружил, что за прошлую неделю там появилось штук пять новых сообщений. Значит работает! Сайт чуть-чуть отребрендили, к расширению файлов скриптов буковку “x” добавили, но существенно ничто не поменялось )

Но я сейчас не об этом. Де-факто стандартом реляционных баз данных для крупных компаний является СУБД Oracle. По Ораклу экспертизы больше как в части поддержки, так и у разработчиков баз данных. А вот с разработкой простых приложений порядка меньше. Поэтому, я хочу собрать подходы к решению задачи разработки БД с «окошками» в одно сообщение, в надежде их как систематизировать. Что я вижу на текущий момент

Подход 1. Берем приложение в архитектуре Microsоft и меняем MS SQL на Oracle

Подход 2. Oracle application Express. Я уже писал о том, почему следует использовать Oracle APEX. Развернуть такое решение можно как непосредственно на движке базы данных, так и с использованием промежуточного сервера приложений JavaEE. Кстати, недавно Oracle обновил приложение APEX Listener

Подход 3. Oracle Application Development Framework. Традиционный JavaEE подход к разработке приложений с бизнес-компонентами и JavaServer Faces для пользовательского интерфейса.

Подход 4. Кастомизация бизнес-приложений, реализованных в этих приложениях средствами.

Ничего не забыл? У каждого подхода есть преимущества и недостатки. Я всего лишь хочу сказать, что альтернативы есть.

Сервисная архитектура и Digital Workplace

Продолжаю тему цифрового рабочего места, затронутую в сообщении Что такое Digital Workplace. Сегодня я хотел бы дистанцироваться от технологий и уделить большее внимание методологии DW. Однако немного затронуть технологии все же придется.

Уже не первый год в ИТ-сообществе активно дискутируется тема сервис-ориентированной архитектуры (SOA). Что такое SOA и на какие сервисы следует ориентироваться так до конца и не выяснилось, но зато эксперты единодушны во мнение, что сервис, во-первых обладает программным интерфейсом, а во-вторых реализует определенный бизнес-процесс. Причем, такой бизнес-процесс не обязан быть полностью автоматизированным. Часть его этапов или даже процесс целиком может выполняться другими сотрудниками. Сервис в данном случае просто унифицирует взаимодействие между внутренним клиентом и исполнителем, позволяет отобразить поток обращений, а при необходимости и измерить процесс. Подробнее я писал об этом в сообщении Программный интерфейс к бизнесу и не раз рассказывал на презентациях.

Прототипом такого взаимодействия между подразделениями является управление ИТ услугами. Любой сотрудник компании может оформить заявку на получение ИТ услуги, зарегистрировать инцидент или сформировать запрос на изменение. Каким образом будут обрабатываться такие запросы это уже дело соответствующего подразделения, в данном случае дирекции ИТ. Деятельность других затратных подразделений можно организовать аналогичным образом.

Digital Workplace, в свою очередь, предлагает объединить эти службы единым веб-порталом, через который сотрудник может задействовать любые внутренние сервисы, не заботясь о том, какое именно подразделение их предоставляет. В телекоммуникациях давно и успешно абоненты используют такой инструмент как личный кабинет (web self-service). Это приложение позволяет включать, выключать и настраивать услуги, отслеживать историю звонков и платежей, отправлять оператору связи разнообразные запросы, получать таргетированные предложения и т.д. При этом сложная «внутренняя кухня» оператора скрыта от абонента. Он не должен заботиться о том, в каких системах предоставляется та или иная услуга, как организовано взаимодействие с контрагентами и партнерами, кто и когда строит сеть или устраняет неисправности.

DW предлагает реализовать «личный кабинет» для сотрудников. Эта идея очень похожа на концепцию адаптивного кейс-менеджмента (ACM). На самом деле, АСМ приложение и является тем порталом, через который сотрудник инициирует запуск экземпляров бизнес-процессов. Безусловно, делает он это не просто так, а для решения некоторой конкретной задачи, порученного ему кейса.

В общем, разные эксперты, разными словами говорят об одном и том же

Интранет, интеграционная среда или корпоративный портал?

Очень много отзывов собирает tibbr в сообществе Enterprise 2.0. И это при том, что толком его никто пока и не видел. TIBCO предлагает свое решение только крупным клиентам. Описание на сайте более чем лаконично. Никаких trial, демо-версий или вебкастов. В сети я даже внятных скриншотов не обнаружил (что подозрительно похоже на появление Sharepoint 2010 в прошлом году). Тем не менее, обсуждения идут в блогах Gartner и Forrester, CMSWare и ZDNet. Почему такой интерес? Кому TIBCO бросила вызов, на который нельзя не ответить? Попробуем разобраться чуть глубже в том, что есть tibbr
Читать далее Интранет, интеграционная среда или корпоративный портал?

Сценарии интеграции приложений (3)

Я довольно редко пишу о сценариях интеграции и потому не могу закончить с интеграцией данных и перейти к интеграции приложений и сквозным бизнес-процессам. Тем не менее, интеграция данных это важно. ESB, SOA и прочие трехбуквенные сокращения, занимая наше внимание, отвлекают нас от других, намного более важных трехбуквенных сокращений, таких как ODS и DWH. ODS и DWH – «рабочие лошадки» ИТ архитектуры предприятия, способные избавить нас от множества лишних информационных систем и оппортунистических связей между ними.
Читать далее Сценарии интеграции приложений (3)

Ожидания, разочарования и прогнозы 2010/2011

Под бой курантов принято подводить итоги прошедшего года и строить планы на будущее. Следуя этой традиции я проведу краткий обзор того о чем писал в своем блоге и того о чем намерен писать.

Безусловным хитом года 2010 стала тема адаптивного кейс менеджмента. Adaptive Case Management это разумная середина между излишней наукообразностью BPM подхода и отсутствием таковой у подхода ECM. Читать далее Ожидания, разочарования и прогнозы 2010/2011

Одна из ошибок при переходе от инхауса к аутсорсингу

На неделе выступал перед довольно масштабной аудиторией наших разработчиков. Так как развитием ИТ систем в нашей компании занимается несколько сотен человек, то недостатка в слушателях не было. Выступая, затронул новую для себя тему. Похоже, об этом я еще нигде не рассказывал.
Итак, зачем компании нужна сервис-ориентированная архитектура Читать далее Одна из ошибок при переходе от инхауса к аутсорсингу

Сервисная шина и очереди сообщений

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали — теперь это улица Марии Ульяновой, а дом 25 по этой улице — хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…


Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась. Читать далее Сервисная шина и очереди сообщений

Архитектор SOA

На прошлой неделе я три дня посвятил обучению на курсе Архитектор SOA Содержательную оценку курсу давать пока не хочу. Пожалуй, самое интересное, что я из него вынес это то, как организовать бизнес на пустом месте. Томас Эрл, в соавторстве с другими уважаемыми экспертами написал дюжину толстых книг про SOA http://www.soabooks.com, организовал школу сервис-ориентированной архитектуры http://www.soaschool.com , договорился с Prometric о проведении экзаменов http://www.soacp.com и продолжает развивать тему SOA. Лейтмотивом всей этой бурной деятельности, на мой взгляд, является тезис о том, что SOA – это не об интеграции приложений, а о том, как избежать интеграции приложений. О том, почему интеграция это долго, дорого и всегда рискованно я рассказывать здесь не стану, а интересующихся, переадресую к статье Глеб Ладыженский. “Интеграция приложений такая, как она есть”

Вернемся к SOA. Тем временем у самой SOA дела идут не столь хорошо, как у SOASystems Inc. Главное свое обещание – избавить нас от интеграции бизнес-приложений она не исполнила. И одна из причин тому чисто технологическая. SOAP и WS-* порождают интеграционных задач больше чем решают. Надежды на изменении ситуации к лучшему и достижению цели SOA, пусть хоть не в полном объеме, связаны теперь с RESTful Web services. Не обманут ли нас в очередной раз? Вообще-то, могут и обмануть. Просто интерфейсы бывают плохие и хорошие. А о том, почему одни интерфейсы лучше других я напишу в следующий раз

SOA обманула аналитиков

Под таким заголовком прошел очередной круглый стол CNews посвященный сервис-ориентированной архитектуре. Я так и не понял, кто и каким образом подчитал, что SOA-решения продаются существенно лучше прогноза. Но дело не в этом. Термин SOA по-прежнему жив, по крайней мере, в нашей стране. О нем действительно продолжают говорить, а значит эта тема до конца не раскрыта. Потому, позволю себе еще один «подход к снаряду». Читать далее SOA обманула аналитиков