|
|
Знаете ли Вы, что ... | |
...нарушения правил форума наказываются. Старайтесь их не нарушать. | |
<< Предыдущий совет - Случайный совет - Следующий совет >> |
Microsoft Обсуждение продуктов. Техническая поддержка. Вопросы лицензирования. |
Ответить |
|
Опции темы | Опции просмотра |
28.05.2007 21:42 | #21 |
Sharifa.Com
Директор по развитию
Сообщений: 2,928
+ 2,274
890/560
– 8
0/0
|
именно про это и говорил имея ввиду высокоуровневое описание - дальше уже по месту надо привязывать - так как любой заказчик (не смотря на отраслевую принадлежность) это уникальный набор требований. Шаблоны можно и нужно иметь под рукой чтобы не сбиться с курса (не завалить проект), чтобы не случилось подмены реальной цели - надуманной.
кроме того есть описания того как вообще (принципиально) должна строиться ИТ система - на сайте МС это MS Operational Framework, ну а более глобально это ITIL. |
|
Ответить |
Реклама и уведомления | |
28.05.2007 22:17 | #22 |
|
Ibrohim Djuraev
Вы правы, в случае с разработкой стандартов обмена информацией для государственных органов, стандартов будет много, но лучше один раз поработать головой чем пытаться на коленке разрабатывать приблуду для импорта и експорта для всех существующих в государстве систем управления документами и информацией. Я не знаком с "проектом ГОСТа "Требования к базам данных и обмену информацией между информационными системами органов государственного управления и государственной власти на местах"" но уже само название "требования к базам данных" вызывает скептицизм. Хотя хотелось бы почитать. Но не сейчас |
|
Ответить |
29.05.2007 03:15 | #23 | |
|
Цитата:
|
|
|
Ответить |
29.05.2007 04:27 | #24 | |
|
Цитата:
1. Необходимо, как я уже указал, разработать стандарт обмена информацией на основе XML. 2. Внедрять (можно на первых порах где нибудь в центре) брокер сообщений (к примеру Microsoft BizTalk Server 2006). Правда придется попотеть как и с стандартом так и со схемками BizTalkа. Как я понял, стоит задача интеграции информационных систем. Эта проблематика широко освещается и глубоко изучается ведущими топ-менеджерами занимающимися интеграцией в сфере ИТ. И выработано несколько современых подходов, в области интеграции информационных систем. Позволю местами процитировать очень умного человека А. Данилина и объяснить как это решается. Как правило, на уровне отдельной организации проблема интеграции возникает сразу, как только в ней внедряется несколько корпоративных приложений (управление финансово-хозяйственной деятельностью, складом, отраслевыми базами данных, системой документооборота, управление ресурсами, управление проектами, управление рисками и т.д. и т.п.). На уровне страны, региона или города предоставление услуг государством гражданам и бизнесу и реализация других деловых процессов в государстве требует также интеграции систем и данных. Наверное можно дать следующую классификацию технологий интеграции: Системы интеграции корпоративных приложений (Enterprise Applications Integration, EAI) — технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application — приложение-приложение). Системы интеграции между организациями (межведомственной интеграции) Business-to-Business (Business-to-Business Integration, B2Bi) — технологии, ориентированные на обеспечение безопасного, надежного информационного обмена между различными организациями и их информационными системами. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов (firewall) и дают возможность автоматизировать бизнес-процессы в рамках "расширенных организаций" (к примеру выработка изменений в законодательстве , требующая интеграции бизнес-процессов нескольких государственных организаций - МинЮст, КабМин, Олий Мажлис, Аппарат Президента), которые касаются поставщиков, партнеров, потребителей продуктов и услуг и т. д (я имею ввиду государственных услуг). Технологии управления бизнес-процессами (Business Process Management, BPM), являющиеся результатом естественной эволюции классических систем документооборота и делопроизводства (workflow systems) и систем класса EAI и B2Bi. Традиционные системы управления документами ориентировались в основном на пересылку информации между людьми, выполнявшими определенные действия. В отличие от технологий B2Bi, которые ориентированы на интеграцию данных в межведомственной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации "пересекают" границы различных приложений, департаментов и организаций. Возвращаясь к технологиями, приведу пример: Workflow использует руководитель департамента, отдела в сферу деятельности которого входит управление документами и пересылка документов, назначение исполнителей. EAI и B2Bi - Руководитель департамента информационных технологий в сферу деятельности которого входит интеграция данных BPM использует высшее руководство организации (бизнес-руководство) в сферу деятельности которого входят задачи по улучшение выполнения бизнес-процессов и повышение эффективности работы за счет большей гибкости процессов Традиционные технологии интеграции корпоративных приложений EAI и межведомственной интеграции B2Bi основаны на использовании так называемого брокера (узла пересылки, шлюза) сообщений. Технологическим фундаментом брокера сообщений является, как правило, программное обеспечение промежуточного слоя пересылки сообщений (Messaging-Oriented Middleware, MOM), которое обеспечивает транспорт доставки информации и данных между прикладными системами. Примером такого программного обеспечения является "сервер очередей сообщений" MSMQ (Microsoft Message Queuing -Вы его кстати используете в Live Communication Servere). Продукты этого класса обеспечивают транспорт гарантированной доставки сообщений между приложениями в территориально распределенной среде. Подход к интеграции приложений на основе продуктов класса MOM стал стандартным в области интеграции корпоративных информационных систем. Базовая идея этой технологии заключается в следующем: Пусть имеется несколько приложений, связанных некоторой коммуникационной средой, но, возможно, не очень надежной. Одно приложение (например, система документооборота - назовем ее системой "А") должно переслать информацию/документ другому приложению (соотвественно - "Б"). Система A передает документ серверу пересылки сообщений и "забывает" о нем. Сервер пересылки сообщений обеспечит гарантированную и однократную доставку информации в систему Б. Ну и обратно естественно. Если при этом интегрируемые приложения находятся внутри организации в рамках одной корпоративной сети, то обеспечивается пересылка информации в режиме, "близком к реальному времени". Если интегрируются приложения, находящиеся в разных организациях, то принцип "очереди сообщений" и гарантированной доставки, который реализуется MOM-продуктами, обеспечивает асинхронное взаимодействие и так называемое "слабое связывание" . Приложение организации A не вправе ожидать мгновенной доступности приложения организации B, но программное обеспечение гарантированной доставки сообщений берет на себя ответственность за доставку информации между ними. Роль правительственного шлюза (портала) в интеграции информационных систем и еобходимость наличия такого интеграционного элемента, как правительственный шлюз, не является очевидной в условиях, когда предоставление услуги не требует информационного обмена между ведомствами или когда число вовлеченных во взаимодействие ведомств невелико. В конце концов, при небольшом количестве ведомств или информационных систем можно организовать взаимодействие по принципу "каждый с каждым" и написать соответствующие независимые интерфейсы обмена. Что мы и любим обычно делать. Но на этапе реализации предоставления государством или государственным органом, электронных услуг, которые требуют выполнения транзакций и связанного с ними информационного обмена между несколькими ведомствами, возникает необходимость создания службы интеграции информационных систем различных ведомств между собой. В противном случае задача интеграции по принципу "каждый с каждым и все со всеми" приведет к квадратичному росту сложности, а, значит, и стоимости такой интеграции. Наличие одного узла, одной точки интеграции на основе брокера сообщений позволяет справиться с ростом сложности задачи интеграции по мере подключения новых информационных систем. По сути дела это является одной из задач, выполняемых правительственным шлюзом. При этом шлюз должен выполнять не только маршрутизацию сообщений (которые являются XML-документами) между информационными системами различных государственных структур, но и выполняет также задачу трансформации этих сообщений на основе соответствующих XML-схем в целях обеспечения совместимости информационных систем. Брокеры сообщений могут объединять большое количество взаимодействующих систем. Результатом этого является то, что называется "Корпоративной нервной системой", т.е. инфраструктура брокера сообщений, к которой легко могут быть подключены по сути дела любые приложения и которая обеспечивает взаимодействие между ними в режиме, близком к реальному времени. Брокер сообщений должен интегрировать гетерогенные приложения и хранилища данных и предоставлять три типа служб: 1. Пересылка сообщений и перемещение данных обеспечивает физический транспорт доставки сообщений между приложениями. Это может быть сделано на основе таких Интернет-протоколов, как Hypertext Transfer Protocol (HTTP) и традиционных систем пересылки сообщений, например Microsoft Messaging Queuing и IBM MQ Series. Языком описания сообщений практически все решения используют XML (!!!). 2. Интеллектуальная маршрутизация, которая определяет для каждого сообщения то, к какому приложению оно должно попасть. Маршрутизация часто включает механизмы публикации и подписки, когда серверное приложение один раз "публикует" некоторое бизнес-событие для брокера сообщений, а определенное количество других бизнес-приложений, заинтересованных в данном событии, "подписываются" на него. 3. Трансформирование обеспечивает мапирование(определение соответствия) данных между потенциальноразличными семантиками одного приложения или разныхприложений. Так, если одно приложение (система документооборота)использует в формате своих данных буквы "М" и "Ж"; для описания пола человека, а другое приложение (база данных "Народонаселения" Управления Въезда и Выезда Граждан МВД Р Уз в функционал которого входит и выдача паспортов) использует для такого кодирования "1" и "0", то уровень трансформации брокера сообщений может мапировать информацию между приложениями, не меняя логику каждого из них. В более сложных ситуациях, когда одно приложение может ожидать 5 атрибутов в записи о клиенте, а другое приложение обеспечивает эти же атрибуты в двух различных записях баз данных, уровень трансформации может обеспечить мапирование между такими различными структурами данных. Архитектура брокера сообщений может включать две дополнительных высокоуровневых службы: 1. Управление бизнес-процессами (оркестрирование бизнес-процессов) доводит уровень интеллектуальной маршрутизации до возможностей автоматизации потоков работ (workflow), которые полностью обслуживают внутренние и внешние процессы; 2. Мониторинг процессов и событий превращает брокер сообщений в центр информационных потоков внутри и вне предприятия, а также обеспечивает функции анализа бизнес-операций в масштабе близком к реальному времени. Помимо этого, брокеры сообщений, как правило, поддерживают работу со специфическими адаптерами для различных типов приложений и данных: адаптеры к веб-службам; адаптеры к мониторам транзакций; адаптеры к различным реляционным СУБД; API-адаптеры для популярных коробочных приложений; Наличие указанных дополнительных высокоуровневых служб, а также средств для моделирования процессов (графических средств описания и модификации процессов), по сути дела, превращает системы EAI и B2Bi в системы класса BPM (системы управления бизнес-процессами). Таким образом выглядит технология создания современных интегрированых корпоративных ИС (информационных систем\приложений). Другими словами, я хотел дать крраткую информацию о современных подходах к решению поставленых на сегоднешнем заседании задач и помочь Узинфокому быть готовым к большим интеграционным процессам, раз уж правительство Республики в самом деле и довольно серьезно внедряет элементы e-Gov, реагируя на современные тенденции и принимая законодательные акты, реализующие принципы электронного правительства. Ну с Узинфокома еще пиво если пост был полезен (если еще будете задавать интересные вопросы дешевле прикупить кегбочку) Последний раз редактировалось Erkin Kuchkarov; 29.05.2007 в 04:41. |
|
|
Ответить |
2 "+" от:
|
17.09.2007 12:50 | #25 |
UZINFOCOM
Сообщений: 1,935
+ 581
731/453
– 0
0/0
|
Ахад ака,
вот изучаю обзор технологии интеграции ИС и межведомственная взаимодействие (А. В. Данилин), вот там много опыта внедрение Microsoft по части внедрения government gateway и тут наткнулся на интересное «Среда межведомственного взаимодействия в правительстве» (Government Interoperability Framework, e-GIF), есть ли у вас какая нибудь инфо про e-GIF? и еще найдется ли у вас информация по «Созданию государственной электронной инфраструктуры на основе стандарта XML» |
|
Ответить |
17.09.2007 15:00 | #26 |
Sharifa.Com
Директор по развитию
Сообщений: 2,928
+ 2,274
890/560
– 8
0/0
|
Иброхим ака,
ну вот прямо что дали в подсказке нет, но есть: Microsoft Interoperability: Connected Government Framework: An ... могу еще порекомендовать: Local and Regional Government а еще я буду у вас сегодня дам DVD (Digital Town) с информацией как все это делается и примерами. на диске часть материалов приведена с возможностью локализации, жалко что скорее всего к выставке не успеем, но можно показывать как есть, а расказывать как надо |
|
Ответить |
"+" от:
|
|