2 АБ. Мне кажется, угодить всем и всегда ну никак не получится. Вот Вы, например, являетесь апологетом XForms. Допустим, Вы с его помощью реализовали "универсальность за исключением", но что Вы скажете тем, кто попал в категорию этого самого исключения? То есть, тем, кто использует браузер от MS? Наверное, их мало утешит утверждение, что MS - такая-сякая?

Вот Вы правильно сказали "Истинный тонкий клиент = браузер без java, плагинов или загружаемых модулей на стороне клиента"... Только у того же Unify все-таки используется Java, и правильно делается. Потому что клиент без возможностей скриптовых языков - это как нарисованная конфета. Смотреть можно сколько угодно, а сделать с ней толкового ничего нельзя.

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

В то же время до бесконечности прогибаться под клиента не получится. Клиент ведь может захотеть работать с формами в WAP и разгневается, что ему такая возможность не предоставлена. Он также может разгневаться, что от него требуется наличие вообще какого бы то ни было вычислительного устройства для того, чтобы воспользоваться предлагаемой услугой. На каком, собственно основании сделано предположение, что хотя бы какой-нибудь компьютер у него есть? А вдруг он житель тундры, в которой телефон с дисковым номеронабирателем воспринимается как вершина технического прогресса? А может быть, необходимость установки Java-машины на броузер, где он по умолчанию не установлен, кого-то приведет в состояние жуткой ярости? Всем не угодишь, это я вот к чему...

Существуют какие-то разумные компромисы. Точнее, у людей есть понимание, с чем они готовы мириться, а с чем - нет. Причем, у каждого - свое. Мы сейчас живем в странном мире. В котором продуктами MS пользуется подавляющая часть населения. Хотя, разумеется, есть еще очень много других вендоров. И в этом странном мире с точки зрения "демократических ценностей" не совсем понятно, кого считать "большинством". То ли наиболее многочисленную когорту потребителей продуктов одного вендора, то ли проcто число вендоров, выраженное в "штуках"... :)

P.S. Это я не к тому, что InfoPath - лучший выбор (кстати, я и сам так не считаю). Это я к тому, чтобы каждый решал сам, что для него лучше... :)

АБInfoPath для меня лично абсолютно неприемлемое решение, так как не является тонким клиентомТеперь я понял, что Вы подразумевали ранее, говоря о том, что InfoPath не является тонким клиентом. :)
Вы подразумевали необходимость предустановки некоторого программного обеспечения (а именно, InfoPath). Но ведь браузер тоже требует предварительной установки? В этом смысле не совсем корректно утверждать, что InfoPath - это "толстый клиент". Возможно, он еще более тонкий клиент, чем браузер, поскольку позволяет заполнять форму в несколько сеансов, сохраняя на собственном локальном диске ее содержимое до отправки на сервер. Я понимал под "толщиной" клиента объем информации, необходимый для обмена им с сервером - чем он меньше, тем клиент "тоньше". Вы, видимо, говорите немного о другой характеристике - доступности. InfoPath может не оказаться под рукой у заинтересованного лица. Немаловажно также, что за использование этой программой необходимо отдельно заплатить , в то время как браузер можно получить в составе операционной системы.

В этом плане я, разумеется, соглашусь с Вами, что InfoPath не является удачным вариантом для реализации взаимодействия с людьми, для которых нет уверенности, что в их распоряжении имеется InfoPath.

Наше с Вами обсуждение, помогло мне дойти до понимания, почему Microsoft не позиционирует BizTalk Server как BPM-систему. Видимо, это как раз связано с ограничениями в плане доступности инстументов для участников процесса. То "взаимодействие с людьми", которое продекларировано для BizTalk, следует понимать как не с любыми людьми, а только с теми, доступность программных инструментариев которых как минимум известна разработчикам бизнес-приложений и отвечает ряду требований, а в лучшем случае им подконтрольна (то есть, сотрудникам этой же компании или сотрудникам партнеров, факт использования которыми программы InfoPath можно заранее установить). Разумеется, остается еще возможность разработки WEB-форм "своими руками", но поскольку мы говорим об удобстве и скорости разработки, то такой вариант, разумеется, существенно проигрывает тем инструментариям, которые позволяют генерить формы (или по крайней мере их заготовки) автоматически.

Медитируя на обсуждаемую тему, дошел до понимания еще одного нюанса.
Для заполнения форм в браузере требуется непосредственный доступ к WEB-серверу. InfoPath этого НЕ требует. Форма InfoPath может сама отправить информацию, в частности, по электронной почте, непосредственно на некоторый узел ее обработки. Это может быть сервер (я уже говорил о том, что взаимодействие людей через портал, требующий авторизации, может несколько нервировать), но это может быть и просто другой человек, у которого тоже имеется InfoPath.
Если для BPM-системы какой-то шаг бизнес-процесса выполняется группой людей, то InfoPath позволяет взаимодействовать этим людям НЕПОСРЕДСТВЕННО, минуя сервер.

Хорошо это или плохо? Вообще, с точки зрения процессного подхода к управлению, идея контрпродуктивная. Процессный подход подразумевает детализацию всех телодвижений с регистрацией всех фактически произведенных телодвижений движком BPMS. Однако, если я правильно понял по просмотренным материалам на сайте Unify NXJ, некоторые операции при human-to-human взаимодействии там могут назначаться ГРУППЕ людей. В группе неизбежно возникает внутреннее взаимодействие, от которого, если я правильно понял, Unify NXJ позволяет абстрагироваться.

Это я всё не к тому, что InfoPath лучше (уже согласился, что хуже :) ). Просто хочется до конца понять отличия.

А вот по взаимодействию BPMS с группой людей у меня к Вам, АБ, отдельный вопрос. Объясните пожалуйста, всегда ли подразумевается, что любой член группы (они там в группе сами разбираются, какой именно) может выполнить действия, назначенные группе? Или могут быть какие-то другие взаимодействия с группой людей, допустим, с учетом приоритетов ее членов внутри группы?

Представим себе такую ситуацию. Члены некоторой группы в количестве 10 человек задействованы в одной из операций какого-то бизнес-процесса, которая происходит довольно редко (допустим, один раз в несколько месяцев). При этом терриориально они размещаются в разных местах и взаимодействуют друг с другом не визуально, а с с помощью телефонной связи. Когда возникает необходимость в выполнении назначенной в бизнес-процессе на группу операции, нужно чтобы реакция этой группы была молниеносной. Для того, чтобы члены группы узнали о том, что возникла ситуация, требующая их срочного вмешательства, они либо должны часто заходить на портал и смотреть, не появилось ли для них новая информация (судя по всему, не очень удачная идея, если подавляющая часть заходов в портал будет производиться вхолостую), либо получать оповещение (по электронной почте, пейджеру, ICQ или как-либо иначе). Но они получают оповещение одновременно? Каждый из членов группы не в курсе, какова реакция других членов группы. Каждый из них может понадеяться на других и оставить оповещение без внимания. Или начинать обзванивать других членов группы, чтобы узнать, взялся ли кто-нибудь за обработку данной ситуации. Или (что иногда проще всего) просто взять и самому ее обработать. Последний вариант для исполнительных сотрудников может показаться наиболее очевидным и предпочтительным. Теперь представим, что все 10 членов группы - исполнительные сотрудники. Каждый из них, получив оповещение, сразу полез в портал и каждый из них увидел, что в пуле болтается форма, требующая обработки. Все 10 человек пытаются одновременно ее открыть и обработать. Ясное дело, что корректно это сможет сделать только самый первый. Какова будет реакция системы на действия остальных, когда они попытаются отправить на сервер заполненную форму - сообщение об ошибке? Или BPMS в принципе откажется открывать форму тем, кто не успел это сделать первым? Есть ли какие-то возможности управления многопользовательским доступом к информации внутри группы?

АБЧто значит к серверу, реально -- к интету? Ну так и для почты нужно то же самое, не понял в чем разница -- в скорости?В том, что параметры авторизации прописываются в почтовом клиенте, и почтовым клиентом прои соединении с почтовым сервером производится без участия человека. Вы представьте, что Вас, как стороннего участника некоторых бизнес-операциям привлекли к своим бизнес-процессам 10 разных организаций. И в каждой для регистрации нужно набрать логин и пароль. Какова будет Ваша реакция, если это придется делать по множеству раз в день?

АБМожно приучить пользователя не только следить за поступлением новой почты, но и постоянно держать открытым окно браузера, в котором автоматически будет обновляться перечень назначенных ему задач.Каким же образом окно автоматически будет обновляться? У Unify портал автоматически обновляет окно??? Насколько мне известно (не уверен, однако), в MS SharePoint окно автоматически не обновляется. Если оно обновляется автоматически, то не мешает ли это текущей работе при заполнении форм, например?

АБДалее, когда 10 пользователей получают одно и то же задание, движок конечно же помогает им координировать свои действия. Например, на форме могут быть кнопки "захватить задачу" и "освободить задачу". Вначале все пользователи являются как бы кандидатами на выполнение задачи. По нажатию кнопки "захватить" все пользователи, кроме самого шустрого, становятся "запасными игроками", задание исчезает из их списка, а если они уже успели получить форму и пытаются захватить задачу, то это диагностируется как ошибка. Если первый освобождает задачу, ее все снова получают.Спасибо, интересное решение! :)

АБЕсли это выглядит слишком сложным, то есть альтернативный путь. Разбиваем задание на два шага. На первом пользователь видит на форме кнопку "принять задачу". По ее нажатию процесс переходит к следующему шагу, в котором исполнитель прописан не статически, а динамически -- им становится тот, кто выполнил предыдущий шаг. Остальные пользователи, получившие первое задание, при попытке его выполнить получают уведомление "спасибо, данное задание уже выполняется другим пользователем".Предыдущий вариант мне понравился больше.

АБЕсть и совсем другой путь: назначать задание не группе, а одному пользователю, но при этом разрешить делегирование данного задания другому пользователю. Причем делегирование может быть двояким: либо я говорю другому пользователю "сделай это вместо меня", и он полностью за него отвечает; либо я говорю "сделай, а я проверю", и тогда за мной останется подтверждение задания после его выполнения.У такого решения есть недостаток. Может оказаться, что тот, кто должен "говорить", например, заболел.

АБНаконец, есть еще административная функция. Как быть, если задание назначено пользователю, а он по какой-либо причине не может ее выполнить? Администратор системы должен иметь возможность сменить исполнителя любому стартовавшему заданию.В Unify это может сделать только администратор системы? А может, например, руководитель отдела назначить задание подчиненному?

АБВ общем, имеется спектр возможностей, из которых можно выбирать. Примечательно, что эти аспекты в случае human-oriented BPMS задаются на уровне схемы бизнес-процесса. В BPEL места для подобных вещей нет, и это мне представляется концептуальным недостатком. Вы меня убедили... :)

АБ GaryaКаким же образом окно автоматически будет обновляться? С этим вообще нет проблем. Если у вас есть толковый веб-программист, то он сможет сделать веб-страницу, содержимое которой будет обновляться с заданной периодичностью, например, отражая изменившееся содержание базы данных.Мне даже в голову не приходило залезть в исходники стандартного портала, чтобы там править генерируемые им DHTML-коды страниц. Разумеется, так сделать можно.