Клиент и сервер

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

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

Применяемый им для передач запросов и ответов протокол должен поддерживать пересылку произвольных объектов, в то время как в традиционных Web-приложениях для запросов может применяться только HTTP, а для ответов — только HTML.

То есть разработчикам клиентских программ необходим механизм, с помощью которого они могли бы делать обычные вызовы методов, не волнуясь ни о пересылке данных по сети, ни о выполнении синтаксического анализа ответных данных. Для них решением является установка на клиента так называемого прокси-объекта(proxy object). Прокси-объект это такой объект, который размещается на виртуальной машине клиента и выглядит для клиентской программы так, будто бы он является удаленным объектом. Клиент может вызывать этот прокси-объект путем выполнения обычного вызова метода, а тот затем уже связываться с сервером посредством сетевого протокола.

Точно так же разработчикам служб необходим механизм, который бы позволял им не беспокоиться об обмене данными с клиентами. Для них решением является установка на сервере второго прокси-объекта. Прокси-объект сервера может взаимодействовать с прокси-объектом клиента и выполнять обычные вызовы методов для обмена данными  объектом, реализующим службу которая показана на рис.2.

Клиент и серверКаким образом прокси-объекты могут взаимодействовать друг с другом? Это зависит от применяемой для их реализации технологии. Наиболее распространенным являются три следующих варианта:

  • Технология Java RMI(Remote Method Invocation — удаленный вызов методов), которая позволяет обеспечивать вызов методов между распределенными объектами Java.
  • Технология CORBA(Common Object Request Broker Arhitecture — общая архитектура посредника запросов к объектам), которая позволяет обеспечивать вызов методов между объектами, написанными на любом языке программирования. Взаимодействие между объектами в этой технологии реализуется на основе протокола IIOP(Internet Inter-ORB Protocol).
  • Архитектура Web-служб, которая представляет собой целую коллекцию протоколов, часто в общем описываемых с помощью префикса WS-*. Она тоже подходит для объектов, написанных на любом языке программирования, однако для обеспечения взаимодействия между ними предусматривает применение форматов, основанных на XML. Форматом для передачи объектов является SOAP(Simple Object Access Protocol — простой протокол доступа к объектам).

В случае реализации рассчитанных или взаимодействие программ с помощью кода Java, в универсальности и сложности CORBA и WS-* нет абсолютно никакой необходимости. Такой простой механизм, как RMI, был специально разработан компанией Sun для обеспечения возможности взаимодействия между приложениями Java.

Познакомиться с технологией RMI стоит даже тем, кто и не планирует применять его в своих собственных программах. Это позволит изучить все важные для программирования распределенных приложений механизмы на примере довольно простой архитектуры. Более того, тем, кто пользуется Java-технологиями уровня предприятия, тоже будет очень полезно получить хотя бы общее представление о RMI, поскольку там именно этот протокол и применяется для обеспечения взаимодействия между been-компонентами уровня предприятия(Enterprise Java Beans — EJB).

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

В отличие от RMI, технология CORBA и WS-* не требуют использования никакого конкретного языка программирования. Они позволяются создавать клиентские и серверные программы на C, C++, Java и любом другом языке программирования. От разработчика ожидается предоставление описания интерфейса с указанием сигнатур методов и типов данных, которые его объекты способны обрабатывать. Это описание должно составляться на специальном языке, называемом IDL(Interface Definition Language — язык описания интерфейсов), если речь идет о CORBA, или WSDL(Web Services Description Language — язык описания Web-служб), если речь идет о WS-*.

На протяжении многих лет довольно много людей считали CORBA объектной моделью будущего. Однако сегодня, откровенно говоря, CORBA имеет репутацию(порой вполне заслуженной) архитектуры с низкой производительностью, сложной реализацией и проблемами взаимодействия, потому не пользуется особым успехом.

Web-службы тоже считались не менее перспективными, когда только появились, поскольку имели более простой вид и, конечно же, основывались на эффективных возможностях WWW и XML. Однако по прошествии времени после доработок многих комитетов стек протоколов Web-служб стал выглядеть гораздо сложнее и включать многие из тех же возможностей, которые уже давно присутствовал и CORBA.

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