answers2010 (1131265), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Мы уже упоминали выше о таких использованиях Сети в индивидуальных целях как обучение, игры, покупки, информационный поиск, получение справочной информации, общение. Этот список можно было бы продолжать долго. Вот, например, только краткий список основных средств общения в Интернете:

 Веб-форумы

 Блоги

 Вики-проекты (в частности, Википедия)

 Электронная почта

 Группы новостей (в основном, Usenet)

 Интернет-радио

 Интернет-телевидение

 Skype

 IP-телефония

 Мессенджеры

 FTP-серверы

 ICQ

 Поисковые системы (Google, Yahoo, Yandex)

 Социальные сети

Однако Сеть таит и много опасностей. Это и психологическая зависимость, когда виртуальное пространство и общение заменяют реальную жизнь. Определенную опасность представляют всевозможные формы социального хакинга (несанкционированного доступ, атаки на страницы социальных сайтов с целью получения доступа к конфиденциальной информации: паролей к е-почте, электронным денежным ресурсам и пр.).

7. Основные движущие силы развития информационных технологий (инженерия программного обеспечения)

третья движущая сила Информационных технологий – инженерия программного обеспечения.

В первые десятилетия компьютерной истории профессионального программирования как такого не было. К этому виду деятельности приобщались инженеры, учителя, специалисты самого разного профиля и, конечно же, математики. Это «вавилонское смешение» полное самостоятельности, энтузиазма было трудно изначально структурировать, отделить главное от второстепенного.

Программирование рассматривалось как кодирование. Программирование было ремеслом, а не видом индустриальной деятельностью. Программы в массе своей не были продуктами. Только к концу 60-х стало складываться представление о новой специальности. В это время А.А. Ляпунов открывает свой, ставший в последствии знаменитым, семинар по программированию. В 1970 году академиком А.Н. Тихоновым был основан факультет Вычислительной математики и кибернетики в Московском университете, где появились профильные кафедры. Программирование из кустарного производства стало трансформироваться с одной стороны в науку, с другой – в отрасль промышленности. Было осознанно, что программа – это самостоятельный продукт, не зависящий от изготовителя «железа», а программирование это область инженерии.

Закона, постулирующего количественное развитие программного обеспечения, наподобие закона Мура не существует. Но рост производительности труда программистов отмечают многие. Программирование в 70-х существенно отличается от программирования в 90-х или 2000-х. В тоже время там же отмечено, что за последние десятилетия темпы роста производительности труда, достигаемые только в самых автоматизированных секторах обрабатывающей промышленности, составляли около 80% за 10 лет. Средние же темпы роста производительности труда, например, в обрабатывающей промышленности США, не превышали 30% за тот же период. Таким образом, можно сделать вывод с одной стороны о рекордных, невиданно высоких темпах роста производительности труда программистов. С другой стороны, в сравнении с темпами роста, определяемыми законами Мура и Гилдера, приведенные оценки не пропорционально низкие.

С уверенностью можно сказать одно, что этот рост производительности труда представляет собой плохо управляемый процесс: программирование губит иллюзия простоты и вседозволенности; между разработчиком и конечным продуктом в большинстве проектов отсутствует череда специалистов-технологов и производственников. Сравните, как долго и дорого создавать такие изделия, как самолеты или автомобили, сколько времени уходит на проектирование, создание опытных образцов, испытания, запуск в производство с тем, как соблазнительно быстро пишутся программы. Следствие этой иллюзии — многочисленные аварии, вызванные ошибками. Они особенно эффектно, а порой и трагически проявляют себя во встроенных системах; ошибки в офисных программах менее заметны.

Уже в 70-е годы пришло понимание, что программы, как продукт инженерной деятельности, имеют беспрецедентную в истории человеческой цивилизации сложность; и нельзя каждый раз разработку программной системы начинать «с нуля». Поэтому активно стали развиваться методы программирования, основная идея которых состояла в том, чтобы программные системы можно было бы создавать из ранее написанных компонентов, кирпичиков, в которых аккумулировать опыт предшествующих разработок и корректность работы которых не надо было бы каждый раз обосновывать.

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

8. Сервис ориентированные архитектуры

Современным воплощением старозаветной мечты индустрии программирования о замене "кустарного" кодирования программ "от и до" на "промышленную" сборку приложений из "стандартных комплектующих", как в автомобильной, или других "традиционных" отраслях промышленности является се́рвис-ориенти́рованная архитекту́ра — подход к разработке программного обеспечения, основанный на использовании сетевых сервисов (служб) со стандартизированными интерфейсами.

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов. Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису – интерфейс должен не зависеть от среды разработки сервиса. SOA предполагает возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными – они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы.

Интерфейс компонентов SОА-программы скрывает детали реализации конкретного компонента (ОС, платформы, языка программирования и т. п.) от остальных компонентов. Таким образом, SОА предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределённых программных комплексов. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SОА, часто реализуются как набор веб-сервисрв, интегрированных при помощи известных стандартных протоколов. Веб-сервис – набор логически связанных функций, которые могут быть программно вызваны удаленно через Интернет.

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

Другими словами, SOA обеспечивает предприятию высокую скорость адаптации к динамично изменяющимся условиям современного рынка.

Итак, как мы видим, перспектива развития компьютера связана не развитием компьютера, как такового, а с развитием его сетевых возможностей. Это отражает и общую тенденцию в развитии человеческой цивилизации – интеграцию и глобализацию. Скорость развития столь велика, что сегодня речь идет не об оптимизации существующих структур, а об инновационном, прорывном создании новых. Только гибкость и разнообразие сетей способно поспевать за все ускоряющимися темпами появления нового.

Меняется понятие ценности. Аксиома прошлых лет: чем уникальнее предмет, тем он дороже, чем больше товара, тем он дешевле. В сети все не так, чем больше узлов в сети, тем ее ценность возрастает. Купив компьютер за несколько тысяч рублей, подключив его к Интернету, Вы получаете доступ к ресурсам, стоимость которых даже трудно подсчитать.

9. Модели сетевого взаимодействия OSI ISO и TCP/IP

Эталонная модель OSI.

Модель OSI (Open Systems Interconnection - модель взаимодействия открытых систем была разработана для определения международных стандартов компьютерных сетей. Эта модель описывает, как должна быть организована система, открытая для взаимодействия с другими системами.

Модель МОС имеет семь уровней. Принципы выделения этих уровней таковы:

1. Каждый уровень имеет определенное предназначение.

2. Каждый уровень защищает нижележащий уровень от различий возможных реализаций.

3. Предназначение каждого уровня выбиралось прежде всего так, чтобы для него можно было определить международный стандарт.

4. Границы между уровнями выбирались с целью минимизировать поток информации через интерфейсы.

5. Число уровней выбиралось достаточно большим, чтобы не объединять разные функции на одном уровне, но и достаточно малым, чтобы архитектура не была громоздкой.

Физический уровень отвечает за передачу последовательности битов через канал связи/ Здесь в основном решаются вопросы механики и электрики.

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

Другая проблема, возникающая на уровне канала данных (равно как и на других вышележащих уровнях), - как управлять потоком передачи. В сетях с вещательным способом передачи возникает проблема управления доступом к общему каналу. За это отвечает специальный подуровень канального уровня - подуровень доступа к среде (MAC - Media ACcess).

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

Поскольку за использование транспортной подсети, как правило, предполагается оплата, то на этом уровне присутствуют функции учета.

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

Сетевой уровень определяет, какой тип сервиса предоставить вышележащим уровням и пользователям сети. Наиболее часто используемым сервисом является канал «точка-точка» без ошибок, обеспечивающий доставку сообщений или байтов в той последовательности, в какой они были отправлены. Другой вид сервиса - доставка отдельных сообщений без гарантии сохранения их последовательности или, например, рассылка одного сообщения многим в режиме вещания. В каждом конкретном случае сервис определяют при установлении транспортного соединения.

Основная функция транспортного уровня - принять данные с уровня сессии, разделить, если надо, на более мелкие единицы, передать на сетевой уровень и позаботиться, чтобы все они дошли в целостности до адресата. Все это должно быть сделано эффективно и так, чтобы вышележащий уровень не зависел от того, как именно это было сделано.

Транспортный уровень - это уровень, обеспечивающий соединение «точка-точка».

Многие хост-машины - мультипрограммные, поэтому транспортный уровень для одной такой машины должен поддерживать несколько транспортных соединений. Чтобы определить, к какому соединению относится тот или иной пакет, в его заголовке помещается необходимая информация.

Характеристики

Список файлов ответов (шпаргалок)