Geum.ru

Предисловие редакторов русского издания

Вид материалаДокументы

Содержание


Трехзвенный Объектный Web
Клиент/серверные взаимодействия в Object Web
4. Аплет вызывает серверные объекты CORBA.
Подобный материал:
1   ...   8   9   10   11   12   13   14   15   16

Трехзвенный Объектный Web


В результате всей этой работы родилась новая модель Объектного Web. Она отражена на рис. 2-2, который демонстрирует трехзвенную (3-tier) модель приложений клиент/сервер. Как обычно, первое звено при­надлежит клиенту. В данном случае клиент относится к браузеру и может являться клиентским Java-приложением или аплетом. Второе звено обес­печивается любым сервером, который может обслуживать как HTTP, так и CORBA-клиентов. Третье звено является традиционным сервером.

Комбинация промежуточного звена CORBA/HTTP поддерживает­ся почти всеми серверными платформами, включая Unix, NT, OS/2, NetWare, MacOS, OS/400, MVS, Tandem NonStop Kernel. Объекты CORBA функционируют как серверы приложений промежуточного зве­на и инкапсулируют прикладную логику. Они взаимодействуют с ком­понентами клиента посредством Java ОРВлетов (ORBlet) или каких-либо обычных CORBA ORB, которые могут обеспечить ПОР через Internet. Конечно, объекты CORBA на сервере могут взаимодействовать и друг с другом, используя CORBA ORB. Они могут также общаться с существующими серверными приложениями третьего звена, используя SQL (в данном случае подразумевается SQL-ориентированный механизм лос-rvna к базам данных, прим. ред.) или любую npvrvro форму middlewar Второе звено должно обеспечивать координатор (или объектный монитор транзакций — Object TP Monitor) компонентов на серверной стороне. Мы знаем два главных проекта, которые создают мониторы транзакций на основе CORBA: IBM Business Object Server Solution (BOSS) и ВЕА Systems ObjectWare, основанный на Tuxedo (указанные системы являются адаптацией обычных мониторов транзакций к миру CORBA; в 1998 году на рынке появились и изначально ориентированные на CORBA средства обработки объектных транзакций - реализация Transaction Service компании lona и VisiBroker ITS — Integrated Transaction Services от Inprise, уже лицензированный такими компаниями, как Sun и Hitachi, прим. ред.). Но что же такое серверный компонент. Это серверный объект CORBA, который, к тому же, реализует минимальный набор компо­нентных сервисов. Хорошим примером являются картриджи Orac\e(Cartridges). Это именованные объекты CORBA, которые являют­ся также транзакционными, защищенными и способными генериро­вать события.

Кроме того серверный компонент должен быть настраиваемым (в оригинале звучит как buildable, однако, смысловая нагрузка этого тер­мина более близка к настраиваемому, прим. ред.). Это означает, что он должен предоставить «настраиваемый» интерфейс, который можно бу­дет конфигурировать с помощью визуальных средств Например, объект может определить пиктограмму, которая будет его представлять в визу­альном средстве. При щелчке на этой пиктограмме объект выдаст спи­сок своих методов и генерируемых им событий CORBA, (все это делает­



ся благодаря возможности "самоанализа" - introspection). Таким обра­зом, вы сможете создавать целые ансамбли объектов, "стыкуя" выход­ные события с входными методами. (В настоящее время такие визуаль­ные инструменты называются средствами быстрой разработки прило­жений или RAD - Rapid Application Development; среди существующих RAD-систем, CORBA поддерживается в Borland C++Builder, JBuilder и Delphi, включающих Inprise VisiBroker и ряд дополнительных инстру­ментов для создания CORBA-систем на языках C++, Java и Object Pascal, соответственно, прим. ред.).

Третье звено - это практически все, к чему CORBA может иметь доступ. Сюда входят процедурные мониторы транзакций (TP Monitors), MOM (Message-Oriented Middleware - промежуточное программное обес­печение, ориентированное на обмен сообщениями, прим. ред.), СУБД (DBMS), ОСУБД (ODBMS - объектные СУБД), Lotus Notes и элект­ронная почта (e-mail). Таким образом, прикладные объекты CORBA вытесняют приложения CGI из промежуточного звена, и это -хорошо.

В дополнение ко всему, Java-клиент может непосредственно взаи­модействовать. с объектом CORBA, используя Java ORB. Это означает, что CORBA замещает HTTP/CGI в качестве уровня промежуточного программного обеспечения, обеспечивая взаимодействие между объек­тами (object-to-object), что опять же очень хорошо. Подобно HTTP, CORBA HOP использует Internet в качестве коммуникационной шины (backbone). Это означает, что как НОР, так и HTTP могут функциони­ровать в одних и тех же сетях. HTTP используется для загрузки Web-страниц, аплетов и графики, CORBA используется для Java-коммуни­каций клиент-сервер.

Клиент/серверные взаимодействия в Object Web


На рис. 2-3 показано, как типичный клиент Web взаимодействует со своим сервером в объектном Web:

1. Web-браузер загружает HTML-страницу. В этом случае страница содержит ссылки на встроенные аппреты Java.

2. Web- браузер ищет Java-аплет на HTML-сервере. HTML-сервер находит аплет и загружает его в браузер в форме байт-кода.

3. Web- браузер загружает аплет. Аплет сначала проходит через сис­тему безопасности реального времени Java и затем загружается в память.

4. Аплет вызывает серверные объекты CORBA. Java-аплет может вклю­чать IDL-сгенерированный клиентский стаб, который позволяет вызы­вать объекты сервера ORB. С другой стороны, аплет может использовать интерфейс динамических вызовов CORBA (DII — Dynamic Invocation Interface) для генерации запроса к серверу «на лету». Сеанс связи между



Java-аплетом и серверными объектами CORBA будет существовать до тех пор, пока одна из сторон не решит отсоединиться.

В данном примере Java-клиент представляет собой загружаемый ап-лет. Конечно, клиент может быть и обычным приложением Java. Разни­ца состоит в том, что вам не требуется загружать приложение Java через Internet, что исключает издержки загрузки HTTP. Но возможность дина­мически загружать клиента по требованию является большим преиму­ществом. Сегодняшние Java ORB поддерживают оба подхода. Таким об­разом, вы получаете эволюционное решение, которое не подрывает позиции Web-приложений.