- •Введение. Система 360
- •Семейство компьютеров
- •Обратная совместимость
- •Наследники и клоны
- •Техническое описание
- •Важные унаследованные особенности
- •Архитектура
- •Операционная система
- •Периферические устройства
- •Устройства хранения с прямым доступом (dasd)
- •Ленточные накопители
- •Линейка мэйнфреймов ibm System/370
- •1. Классическая архитектура «клиент-
- •2. Многоуровневые (многозвенные)
- •2.1. Трехуровневая архитектура.
- •2.2. Менеджеры транзакций
- •3. Архитектура peer to peer
- •2. Понятие и виды кластеров
- •2.1 Отказоустойчивые кластеры
- •2.2 Кластеры с балансировкой нагрузки
- •2.3 Высокопроизводительные кластеры
- •3. Коммуникационной среды для повышения эффективности вычислений
- •4. Классы задач, решаемые кластерами
- •5. Типичные задачи кластерных систем
- •6. Пример вычислительного кластера
- •7. Заключение. Стоит ли использовать кластер
- •Изменения Интернет с появлением xml
- •Перевод с одного языка на другой
- •Edi против xml
- •Подход к распределению данных
- •Список литературы
- •Достоинства веб-служб
- •Список литературы
- •Введение
- •Потребность в технологиях Грид
- •Требования к Grid-архитектуре
- •Описание Grid-архитектуры
- •Fabric: управление локальными ресурсами
- •Connectivity: легкость и безопасность коммуникаций
- •Resource: разделение единичных ресурсов
- •Collective: координация ресурсов
- •Applications: уровень приложений
- •Концепция распределенных grid-вычислений
- •На счет grid
- •Вычислительный grid
- •Заключение
- •Список использованных источников
- •Облачные вычисления
- •SaaS (Software-as-a-service) - по-как-услуга
- •ПреимуществаSaaS
- •Концепция облачных вычислений
- •Классификация облаков
- •Преимущества облаков
- •Открытые решения по организации облачных вычислений
- •Eucalyptus
- •OpenNebula
- •Консолидация данных
- •Существующие подходы к консолидации
- •Архитектура централизованных баз данных
- •Архитектура федеративных баз данных
- •Сравнение федеративного и централизованного подходов
- •Требования к программному обеспечению федеративных баз данных
- •Существующие платформы федеративных баз данных
- •Ibm db2 Information Integrator
- •Этапы построения среды облачных вычислений
- •Этап 1. Анализ существующих ресурсов организации
- •Этап 2. Создание прототипа среды облачных вычислений
- •Этап 3. Развертывание прототипа в полном масштабе
Edi против xml
Крупные предприятия, вложившие немало денег в инфраструктуру EDI, могут воспользоваться механизмом перевода документов XML.
Технология EDI:
Оптимизирована для сжатия сообщений;
Требует применения выделенного сервера EDI ценой от 10 до 100 тыс. долл;
Опирается на сети с дополнительными функциями;
Освоение формата сообщений EDI может растянуться на месяцы;
Необходимы программисты на языке С++;
Формат пригоден для машинного считывания.
Технология XML:
Оптимизирована для простого отображения и программирования;
Требует применения Web-сервера ценой до 5 тыс. долл;
Опирается на существующие подключения к Интернету;
Формат сообщений XML можно освоить за считанные часы;
Необходимы программисты на языке JavaScript, Visual Basic, Python или Perl;
Формат пригоден для чтения как машинами, так и людьми.
XML называют универсальным Языком электронной коммерции, забывая порой, что в нем слишком много конфликтующих между собой диалектов. И менеджерам информационных технологий приходится искать именно ту его версию, которая в наибольшей степени подходит для их отрасли и лучше всего отвечает конкретным потребностям обмена данными. Однако реальность такова, что зачастую приходится налаживать поддержку нескольких вариантов XML.
Консорциум “Всемирной паутины” уже разработал спецификацию XML 1.0, однако всех проблем решить не смог. В центре внимания пользователей по-прежнему остается форматирование XML и специфические выражения, с помощью которых большинство компаний описывает различные объекты XML-документов. Это, в частности, может быть “счет”, “компания” или “партнер”.
Перед тем как приступить к разговору на языке XML, потенциальным собеседникам необходимо договориться относительно шаблона DTD (Document Type Definition - определение типа документа). Он подскажет приложениям, как интерпретировать получаемые данные XML. Участникам обмена информацией крайне необходимо согласовать применение важнейших деловых терминов. Достаточно малейших разночтений в описателях данных (например, один корреспондент решит обозначать компанию сокращением CO, а другой - писать полностью COMPANY), и даже членам одной и той же вертикальной отрасли будет нелегко понимать друг друга. Следует учесть, что во многих областях пока еще не стандартизованы даже те элементы данных, которые встречаются едва ли не в каждой транзакции. Правда, в здравоохранении, банковской системе и производственных отраслях уже ведется разработка стандартных определителей XML, однако этот процесс требует времени.
Учитывая все это, эксперты рекомендуют менеджерам информационных технологий не дожидаться появления стандартных шаблонов DTD. “Не пытайтесь искать стандарты обмена XML-данными, которые смогли бы полностью удовлетворить все ваши запросы, - предупреждает Рита Нокс, аналитик фирмы Gartner Group (Стэмфорд, шт. Коннектикут). - У этого языка слишком много разновидностей. Найдите наиболее подходящую и остановитесь на ней”. К сожалению, при этом редко кому удается ограничиться одной версией XML. Фирма Commerce One (Уолнат-Крик, шт. Калифорния) и другие разработчики приложений для электронной коммерции используют собственные спецификации XML, поэтому менеджеры по информатизации бывают буквально вынуждены учитывать множество определений одного и того же объекта.