Архитектура распределенных приложений.

Итак, наша последняя тема: Веб-интервейс / Веб-приложения. Зовите, как хотите. Вообще сюда входит много тем, потому что направление богатое. Не знаю, может ли со временем курс вырасти или нет. Это уж как получится, на мой взгляд брать какую-то одну технологию и пытаться ее изучать досконально… А завтра выйдет другая технология и ее снова изучать досконально? Мы пытались по Swingдавать какие-то моменты достаточно подробно. У меня Swing2 занятия было. Первые приложения, которые писались в прошедшем времени на Web-архитектуре (расширения для браузера) – это апплеты. Вы видите два варианта, на чем их можно было писать.

Ну понятно, что Swing выглядит предпочтительнее. Но сегодня тему можно считать закрытой. Последний раз я помню шаманские трюки, чтобы запустить в браузере апплеты. Там же все выключено по умолчанию, кроме того, что нам пришлось писать разрешения. В итоге запустили его, но это никуда не годится.

Почему апплеты не используются сегодня? Мы могли бы расширение написать для клиента, чтобы там что-то интересное было. А сегодня есть средства визуального проектирования (какой-нибудь HTML5 и т.д.). Ну как можно конкурировать со средой, где визуально разрабатываешь, когда код приходится писать для апплета. Потому что если мы делаем графику в Swing, тонету никакого визуального проектирования. То, что мы с вами смотрели по Swing«Drag-and-Drop» - перекладывание. Это только элементы управления. А линии не являются элементами в Swing. Это обычные классы. Они не входят в иерархию. Их нет, как объектов, которые в эту архитектуру вписываются. А потом никакого визуального проектирования. Сделать руками графику красивую и эффективную, наверно можно. Но можно сделать в 10 раз за более короткий срок на Flash. Поэтому если где-то столкнетесь, то вы знаете, что есть возможность JAppletна Swing.

Сервер – это то место, где код на Javaхорошо смотрится. И самое главное, что он еще долго будет хорошо смотреться. ЯП Javaкак раз создавался под эту серверную сторону. Так что здесь все идеально должно быть. Простой список пунктов, что должна сделать серверная сторона. Просто хотелось бы из этих пунктов понять и разобраться, «а за что мы отвечаем?».

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

Вообще первый и второй пункт – это наша работа? Читать HTTPпротокол. Вынимать оттуда данные. Кто из вас специально изучал протокол HTTP? Практически нет таких. А сегодня у нас ООП и в конце концов, почему я должен этим заниматься? Протокол HTTP какой-то особенный? Поэтому первый и второй пункт – это задача веб-сервера.

А вот третий и четвертый пункт – это наша обязанность. Тут уж никуда не денешься. К вам пришли данные, вы решили в БД обратиться, вы должны как-то представить результат, продумать как он будет выглядеть и обратно отправлять это все на клиента. Соответственно, надо заголовки протокола HTTP задать, какой там отправляется тип данных, какой размер и т.д. С этим прекрасно справится веб-сервер сам. Представляете, как много получается? Из шести позиций, мы можем переложить четыре задачи на чьи-то крепкие плечи.

Сервлеты и страницы JSP.

Сервлеты

Как это организовать чтобы за нас делали первые и последние два пункта? А мы бы оказались по середине. И чтобы это работало, чтобы не было каких-то там трений и проблем! Вот то, что называется «сервлетом» представлено на этом слайде.

Есть некий класс (их несколько на самом деле). Есть как на этом – HTTP, а есть универсальный сервлет. И вот эти классы, которые являются частью уже Enterpriseверсии – они предполагают, что вы наследуете от них и переопределяете несколько методов. Если класс без HTTP, а просто сервлет – то переопределяете один метод. В варианте HTTP-сервлет есть методы соответстующие командам протокола – put, getи т.д. Вдруг у вас в зависимости от того putили getпроисходят разные действия. Может быть в каких-то ситуациях это было бы разумно делать. Это нам решать, те кто архитектурой будет заниматься. Но понимаете идеология какая. Пришел запрос, кто-то его обработал, кто-то создал нужные объекты, кто-то (веб-сервер) создал объект вашего класса, вызвал у него метод в зависимости от типа протокола в смысле зависимости от типа команды, выбранной в протоколе. Соответственно, в данном случае вызвал «do», например,doGet(). И вот эти входные параметры, которые что вам на вход, что от вас обратно заберут в виде двух аргументов сюда подставят. Получается, что для нас подготовили тонкий слой и сказали: «вот ребята, видите вашу задачу? Вот эти методы опишите, а мы уже там разберемся». И главное, когда метод завершится, они возьмут объект response. Вынут из него (или с помощью него) всю необходимую информацию для клиента. Он уже все красиво оформит. И отправит в виде ответа пользователю. Здорово было придумано.