Сегодня, с бурным развитием информационной индустрии, конкуренция между предприятиями станет более жесткой. В условиях постоянного расширения масштабов и постоянного обновления бизнеса предприятиям срочно необходимы комплексные распределенные решения для управления сложными гетерогенными средами и достижения полной интеграции между различными аппаратными устройствами, программными системами, сетевыми средами и системами баз данных.
На протяжении всей истории развития человеческих компьютеров информационная индустрия претерпевала циклические изменения каждые десять-пятнадцать лет. С 1950 по 1970 годы предприятия в основном использовали архитектуру мэйнфрейм-терминал, в то время как корпоративные прикладные системы использовали единую систему предоставления пользователям услуг совместного использования ресурсов. , централизованно. В начале 1980-х годов открытые системы и системы управления реляционными базами данных получили широкое распространение на предприятиях. В отличие от централизованных систем логика приложений была рассредоточена между главным и подчиненным концами. С ростом популярности Windows 1990-е годы стали эрой графических приложений, и архитектура клиент/сервер также получила широкое распространение. В конце 1990-х годов в информационной индустрии появилась технология распределенных объектов. Приложения могут быть распределены на разных системных платформах, а взаимная связь объектов между разнородными платформами может быть достигнута с помощью распределенных технологий. Интеграция существующих корпоративных систем в распределенные системы может значительно улучшить масштабируемость корпоративных прикладных систем. Появление многоуровневых распределенных приложений в конце 1990-х годов открыло предприятиям путь к дальнейшему упрощению разработки прикладных систем.
В традиционной структуре клиент/сервер логика приложения обычно распределяется между клиентом и сервером. Клиент выдает запрос на доступ к ресурсу данных, а сервер возвращает результаты клиенту. Недостаток структуры «Клиент/Сервер» заключается в том, что при увеличении количества клиентов производительность сервера будет значительно снижаться, поскольку невозможно выполнить балансировку нагрузки. Как только требования к приложениям меняются, необходимо модифицировать как клиентские, так и серверные приложения, что доставляет большие неудобства при обслуживании и обновлении приложений, а передача больших объемов данных также увеличивает нагрузку на сеть. Чтобы решить проблемы клиент/сервера, предприятия могут только перейти к многоуровневым распределенным приложениям.
В многоуровневом распределенном приложении между клиентом и сервером можно добавить один или несколько уровней программ службы приложений. Эта программа называется «Сервер приложений». Разработчики могут разместить бизнес-логику корпоративных приложений на сервере среднего уровня вместо клиента, тем самым изолируя бизнес-логику приложения от пользовательского интерфейса и предоставляя пользователям тонкое (тонкое) приложение, обеспечивая при этом функциональность клиента. ) интерфейс. Это означает, что если код приложения необходимо изменить, это можно сделать в одном месте (на сервере среднего уровня), а не в тысячах клиентских приложений. Это позволяет разработчикам сосредоточиться на анализе, проектировании и разработке основной бизнес-логики системы приложений, упрощает разработку, обновление и модернизацию корпоративных систем и значительно повышает масштабируемость и гибкость корпоративных приложений.
Когда предприятиям необходимо создать системы коммерческих веб-приложений, многоуровневая распределенная архитектура также обеспечивает значительные преимущества, обеспечивая архитектуру «тонкого клиента» для коммерческих веб-приложений, позволяя клиентам, использующим браузер, эффективно взаимодействовать с ресурсами интрасети. взаимодействие, не требуя сложной работы по настройке приложений на стороне клиента. Многоуровневые распределенные решения создают мосты между разнородными платформами и позволяют интегрировать бизнес-приложения на основе веб-технологий с существующими корпоративными системами.
В настоящее время большое количество предприятий в нашей стране все еще используют архитектуру Клиент/Сервер, в то время как в развитых странах Запада переход предприятий от традиционных систем приложений к многоуровневым распределенным системам приложений стал основным направлением в отрасли. Предполагается, что многоуровневые распределенные системы получат более широкое распространение в нашей стране.
Проблемы, связанные с многоуровневыми распределенными приложениями
Хотя многоуровневая распределенная архитектура дает предприятиям большие преимущества, разрабатывать многоуровневые распределенные приложения сложнее, чем традиционный подход «клиент-сервер», что ставит перед разработчиками новые технические проблемы. В основном он включает в себя следующие три аспекта:
1. Диверсификация стандартов распределенных объектов
Если предприятия хотят создавать многоуровневые распределенные системы, они должны следовать распределенным промышленным стандартам. То, на чем основаны стандарты, напрямую влияет на открытость и масштабируемость корпоративных прикладных систем. В настоящее время существует три основных стандарта для распределенных объектов: DCOM от Microsoft, Enterprise JavaBeans/RMI от Sun Microsystems и CORBA (Common Object Request Broker Architecture) от OMG (Object Management Group). DCOM — это стандарт распределенных объектов, основанный на среде Windows, поэтому типы поддерживаемых платформ ограничены. RMI и Enterprise JavaBean — это распределенные объектные архитектуры, основанные на языке Java, которые подходят для кроссплатформенных нужд крупных предприятий. Однако реальная среда системы приложений обычно создается с помощью нескольких разных языков программирования и опирается только на один язык программирования. Корпоративные приложения встречаются редко. CORBA — это стандарт распределенных объектов, разработанный организацией OMG при участии более 800 крупных компаний, занимающихся программным и аппаратным обеспечением. Он поддерживается такими крупными компаниями, как IBM, Sun Microsystems, Oracle, Sybase, Novell и Netscape. Интеграция между различными платформами. Связь и совместимость объектов. Пока поставщики программного обеспечения следуют IDL (языку определения интерфейса) для связи между объектами приложений и ORB, они могут предоставлять или получать услуги в форме объектов. исключите необходимость рассмотрения гетерогенных платформ. Различные протоколы связи или разные языки программирования вызывают различия, и сосредоточьтесь на разработке логики приложения. Видно, что CORBA предоставляет открытый и гибкий распределенный стандарт, который подходит предприятиям для создания многоуровневых распределенных прикладных систем.
2. Разработка многоуровневых распределенных приложений очень сложна.
Если многоуровневые распределенные приложения разрабатываются традиционным способом, разработчикам необходимо обладать глубокими знаниями на уровне компьютерной системы и владеть знаниями в различных аспектах, таких как параллелизм, безопасность, масштабируемость и обработка транзакций. Более того, необходимо добиться эффективного управления доступом к системным ресурсам, таким как управление потоками, памятью, подключениями к базе данных и сетевыми подключениями. Эти сложные задачи сильно отнимают энергию у разработчиков и ограничивают ход разработки. Разработка систем корпоративных приложений требует от разработчиков уделять больше внимания разработке бизнес-логики, а не тратить больше времени на разработку на уровне системы.
3. Распространение и управление распределенными приложениями также представляют собой проблему.
Большинство распределенных приложений состоят из сотен или тысяч компонентов, и каждый компонент имеет свойства, которые необходимо настроить во время распространения. Обычно способ настройки свойств компонента зависит от платформы, на которой расположен компонент. Поэтому после того, как приложение будет распространено, управление распределенными компонентами станет непростой задачей. Менеджерам необходимо обеспечить корректную работу компонентов приложения, их расположение на любом компьютере в корпоративной сети и возможность своевременного обнаружения ошибок обработки (включая системные ошибки, сбои в работе сети, ошибки приложений и т. д.).
В традиционном смысле управление сетевой системой (например, SNMP) может получить статус работы приложений только путем анализа состояния хоста. Однако для распределенных систем приложений приложение не запускается на определенном хосте. Состоянием всей сети необходимо управлять, что требует поддержки соответствующих инструментов.
Требования к многоуровневым распределенным приложениям
Разработка корпоративных многоуровневых распределенных приложений обычно требует следующего:
Легко разрабатывать
Хотя многоуровневая распределенная архитектура требует в качестве основы глубоких знаний на уровне компьютерной системы (например, базы данных, обработки транзакций, сетевой безопасности, технологии CORBA и т. д.), от ИТ-разработчиков она не требует глубокого понимания лежащих в ее основе сложности системы. С помощью технологий можно быстро и легко разрабатывать мощные многоуровневые распределенные прикладные системы в дружественной визуальной интегрированной среде разработки (IDE).
Упрощение работы по распространению и управлению
Разработчикам требуется возможность тестировать и изменять распределенные приложения в интегрированной среде разработки, чтобы повысить производительность приложений, а также обеспечить распространение приложений и управление ими в одной и той же среде. Поскольку многие приложения включают в себя тысячи компонентов, распределенных по всему предприятию, необходим инструмент централизованного управления для управления и контроля распределенных приложений, а также реализации функций обнаружения и исправления ошибок.
Требования к надежности корпоративных приложений
Полноценное распределенное многоуровневое приложение предприятия должно отвечать требованиям обработки транзакций, управления безопасностью, отказоустойчивости, балансировки нагрузки, масштабируемости и высокой производительности.
Имеет открытую архитектуру, основанную на отраслевых стандартах.
Предприятиям нужны открытые решения, основанные на отраслевых стандартах, которые могут взаимодействовать с другими системами, соответствующими стандартам.
Может быть интегрирован с различными базами данных и существующими системами.
Распределенные корпоративные приложения должны иметь доступ к корпоративным ресурсам данных, а корпоративные данные обычно хранятся в популярных в настоящее время крупномасштабных базах данных (таких как Oracle, Sybase и т. д.) или доступны через TP Monitor (например, IBM CICS, BEA Tuxedo). ), поэтому требуется, чтобы распределенные системы предприятия могли быть интегрированы с базами данных и существующими системами.
Поддержка различных платформ
Многоуровневые распределенные приложения предприятия должны поддерживать различные платформенные среды. Серверная часть должна поддерживать платформы Windows NT или UNIX, а клиенты на разных платформах могут получать доступ к приложениям на сервере, включая: HTML, Java-апплеты, приложения Java, динамический HTML, C++. Приложения и т. д.
Корпоративный сервер приложений
По вышеуказанным причинам, когда предприятия переходят на многоуровневые распределенные приложения, им необходима поддержка серверов приложений, чтобы различные технологии приложений могли быть интегрированы вместе, что упрощает разработку, распространение и управление многоуровневыми распределенными приложениями. Полегче. Многие предприятия в настоящее время используют технологию серверов приложений, которая значительно повысила производительность корпоративных приложений. Однако технология серверов приложений, используемая в настоящее время в моей стране, не может полностью удовлетворить потребности предприятий в создании многоуровневых распределенных приложений. Эти серверы приложений в основном делятся на следующие две категории:
Сервер веб-приложений
Серверы веб-приложений обычно предоставляют среду разработки для веб-приложений Интернета и подходят для создания веб-систем приложений клиент/сервер. В этой системе сервер веб-приложений обычно работает на веб-сервере для обработки запросов клиентов. ODBC и JDBC обычно используются для подключения к базе данных. Этот тип сервера приложений, как правило, прост в использовании и поддерживает разработку серверных приложений на основе EJB (Enterprise JavaBeans). Однако к недостаткам такого типа сервера приложений относятся: он не поддерживает обработку транзакций, имеет низкую безопасность, ограниченную поддержку существующих торговых систем и низкую производительность.
Сервер приложений на основе промежуточного программного обеспечения
Серверы приложений на основе промежуточного программного обеспечения могут предоставить предприятиям более мощные функции за счет интеграции с существующими системами (такими как TP Monitors), включая обработку транзакций, управление безопасностью, отказоустойчивость, балансировку нагрузки и т. д., но большинство решений основаны на клиент-серверной системе. архитектура или ограничена трехуровневой архитектурой, не подходит для создания распределенных веб-приложений и не имеет эффективной среды разработки и управления.
Примечание. Балансировка нагрузки — это набор серверов, состоящий из нескольких серверов симметрично. Каждый сервер имеет равный статус и может предоставлять внешние услуги независимо, без помощи других серверов. Благодаря какой-то технологии распределения нагрузки запросы, отправленные извне, равномерно распределяются на определенный сервер в симметричной структуре, и сервер, получивший запрос, самостоятельно отвечает на запрос клиента. Сбалансированная нагрузка позволяет равномерно распределять запросы клиентов на массив серверов, тем самым обеспечивая быстрый доступ к важным данным и решая проблему большого количества сервисов одновременного доступа. Эта кластерная технология позволяет достичь производительности, близкой к производительности мэйнфрейма, при минимальных инвестициях. Преимущества балансировки сетевой нагрузки: во-первых, технология балансировки сетевой нагрузки гарантирует, что сервер может быстро реагировать даже при большой нагрузке; во-вторых, для балансировки сетевой нагрузки требуется только предоставление внешнего мира IP-адреса (или имени домена); или несколько серверов балансировки сетевой нагрузки недоступны, обслуживание не будет прервано. Балансировка сетевой нагрузки автоматически определяет, когда сервер недоступен, и может быстро перераспределять клиентский трафик между оставшимися серверами. Эта мера защиты может помочь вам обеспечить бесперебойное обслуживание ключевых бизнес-программ и увеличить количество серверов балансировки сетевой нагрузки в соответствии с увеличением доступа к сети. В-четвертых, балансировку сетевой нагрузки можно реализовать на обычных компьютерах.
Эта статья взята из блога CSDN. При перепечатке указывайте источник: http://blog.csdn.net/deantry119/archive/2009/12/28/5089598.aspx.