Руководство по веб сервису - RukovodstvoRus.ru - инструкции пользования и руководства

Основанный на SOAP веб-сервис

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

Что такое сервис-ориентированная архитектура?

Сервис-ориентированная архитектура – это принцип проектирования программного обеспечения и шаблон архитектурного проектирования, представляющий автономную единицу функциональности, называемую сервисом. SOA продвигает принципы проектирования, включающие слабую связь, возможность повторного использования и грубые услуги. В терминах корпоративной архитектуры преимущества SOA заключаются в обеспечении гибкости и быстром реагировании на потребности бизнеса, повышении окупаемости инвестиций за счет снижения затрат на интеграцию, снижения затрат на разработку за счет повторного использования компонентов. Корпоративные Aarchitect’s продвигают использование Enterprise Service Bus в качестве уровня интеграции для крупномасштабных корпоративных онлайн-приложений.
Например, очень хорошим примером будут выписка со счета ваших транзакций, информация о ценах на продукты, услуга обработки изображений, служба карт, служба определения местоположения и т. Д.

Что такое веб-сервисы?

Веб-сервисы являются лишь формой реализации сервис-ориентированной архитектуры, которая может обмениваться данными между различными системами независимо от платформы. Поставщики услуг определяют интерфейс, описанный WSDL, и сообщения обмениваются с потребителями услуг с использованием сообщений SOAP. Сообщения могут передаваться по протоколам HTTP, FTP или SMTP.
Веб-сервисы могут быть на основе SOAP или REST.
В сегодняшнем пошаговом руководстве мы рассмотрим, как создать веб-сервис на основе SOAP и потребителя, который будет использовать веб-сервис. Мы будем использовать JAX-WS (API Java для веб-служб XML) для создания веб-службы.

Программного обеспечения:

Weblogic Application Server 12c
Eclipse Oepe 12c
Weblogic Webservice Tool – это автоматически создаст весь необходимый код и файлы WSDL и позволит разработчикам сосредоточиться на бизнес-логике.

Шаг 1:

В вашем Eclipse создайте новый динамический веб-проект.

Создать новый динамический веб-проект

Нажмите изменить и добавьте аспекты, связанные с компонентами Weblogic Webservice.

Шаг 2:

Установите флажки, чтобы убедиться, что все зависимые модули также включены, как указано на скриншоте.

Добавить аспекты проекта, связанные с Weblogic Webservice

Шаг 3:

Корнем контекста по умолчанию является CalculatorServiceServer, а каталогом содержимого веб-модуля – WebContent. Нажмите Готово.

Шаг 4:

Теперь щелкните правой кнопкой мыши по вновь созданному проекту и добавьте модуль Weblogic Web Service в ваш проект.

Создать новый Weblogic Webservice

Шаг 5:

Создайте новый веб-сервис. Добавьте детали пакета и дайте имя веб-сервису.

Создать новый веб-сервис

Шаг 6:

Инструмент веб-сервиса в Eclipse создаст интерфейс конечной точки сервиса (контракт) с веб-методом по умолчанию hello (). Мы можем заменить метод по умолчанию требуемым методом – add (). Рекомендуется создать интерфейс, который объявляет методы, сопоставленные с операциями веб-службы. Этот интерфейс известен как интерфейс конечной точки службы (SEI). Всякий раз, когда мы видим аннотацию @WebService, это означает, что интерфейс является SEI.

Интерфейс вычислителя SEI

Шаг 7:

CalculatorImpl.java создается как класс JWS (веб-служба Java).
Замените код по умолчанию, присутствующий в CalculatorImpl.java. Добавьте детали реализации в add ().

Реализация SEI – CalculatorImpl.java

Шаг 8:

На приведенной ниже диаграмме показано сопоставление между реализацией веб-службы, аннотированной @webService, и сопоставлением wsdl.
Javax.jws.WebService сообщает серверу приложений, что этот класс должен рассматриваться как веб-сервис. Различные атрибуты javax.jws.Webservice:

name – Имя веб-сервиса и отображается на элемент <wsdl: portType> в файле WSDL.
targetNameSpace – пространство имен XML, используемое для элементов WSDL и XML, сгенерированных из этой веб-службы.
serviceName – сервисное имя веб-сервиса. Значением по умолчанию является имя файла jws с суффиксом «service».
wsdlLocation – URL-адрес абсолютного файла wsdl.
endpointInterface – это основано на существующей конечной точке (SEI) службы веб-сервиса.

Сравнение JAX-WS и WSDL

На приведенном выше рисунке имя веб-службы в интерфейсе калькулятора сопоставлено с именем веб-службы, упомянутым в элементе portType в WSDL.
Взаимодействие portName, serviceName, целевого пространства имен и конечной точки службы (SEI) из CalculatorImpl.java сопоставляется с файлом CalculatorService.wsdl.

Шаг 9:

Теперь пришло время запустить веб-сервис на сервере Weblogic 12c, щелкнув правой кнопкой мыши по проекту и выбрав «Выполнить на сервере», добавив проект CalculatorServiceServer на сервер Weblogic и сконфигурировав их.

Добавить проект CalculatorServiceServer на сервер Weblogic

Шаг 10:

Веб-сервис теперь развернут на сервере и предоставлен клиентам для использования. Доступ к нему и управление им можно получить из консоли сервера weblogic.

Weblogic Server Console

Файл wsdl можно просмотреть и протестировать с места, как показано на скриншоте.

Шаг 11:

Файл wsdl с адресом удаленного расположения.

CalculatorService WSDL

http://10.0.2.15:7001/CalculatorServiceServer/CalculatorServer?WSDL

Шаг 12:

На приведенной ниже диаграмме показан файл CalculatorService.wsdl и объяснены все ключевые элементы файла WSDL. WSDL – это контракт на обслуживание с клиентами и поставщиками услуг.
Определение – самый внешний элемент файла WSDL – это <определения>. Это контейнер для всех других элементов, определенных в документе wsdl. В итоге это корневой элемент.

<types> – описывает все типы данных, используемые и актуальные для обмена сообщениями между клиентом и сервером. Это необязательное поле. Раздел типов ссылается на XSD (определение схемы XML), которое определяет типы данных. Если этот раздел пуст, то веб-сервис будет использовать только простые типы данных.
<messages> – определяет данные, которыми обмениваются между поставщиком и потребителем веб-службы. Сообщения создаются из типов данных.
<portType> – представляет веб-сервис как именованные операции. Каждая операция может иметь одно или несколько сообщений.
<binding> – определяет способ передачи сообщений. Он доступен через HTTP GET, HTTP POST, SOAP (поверх протокола HTTP). Из раздела связывания определения WSDL переходят от абстрактного к конкретному, предоставляя конкретные сведения о веб-службе. Элемент привязки должен указывать подробности реализации веб-службы, абстрактно определенные в portType.
<сервис> – указывает на конечную точку, клиенты могут получить доступ к веб-сервису по этому пути.

CalculatorService WSDL объяснил

Шаг 13:

Мы можем протестировать веб-сервис с помощью клиента Weblogic Test.

Тестовый клиент WebLogic

Шаг 14:

Тестовый клиент Weblogic показывает успешный результат операции добавления и выдает SOAP-сообщение с запросом и ответом.

Тестовый клиент – SOAP-запрос и ответ

Шаг 15:

Теперь я хочу создать сервлет, который будет действовать как клиент веб-сервиса, который будет использовать веб-сервис калькулятора, который мы создали на предыдущих шагах.
Создайте новый динамический веб-проект – CalculatorServiceClient и добавьте аспекты клиентов веб-службы Oracle Weblogic.

Добавить фасет клиента Weblogic Webservice

Шаг 16:

Создайте новый клиент веб-службы, щелкнув правой кнопкой мыши проект CalculatorServiceClient -> Выбрать новый -> Выбрать другой -> Поиск клиента веб-службы Weblogic из мастеров. Теперь введите ссылку на файл WSDL. В этом случае мы будем использовать удаленное определение файла WSDL. Прежде чем щелкнуть, убедитесь, что файл WSDL подтвержден.

Добавьте местоположение WSDL

При следующем нажатии коды CalculatorServiceServer экспортируются в CalculatorService.jar. При нажатии «Далее» укажите местоположение места выполнения WSDL. Я использовал Копировать WSDL в опцию jar клиента.

Создать CalculatorService.jar

Шаг 17:

Теперь создайте класс Servlet, который будет вызывать Webservice.

Создать сервлет для вызова веб-службы

Шаг 18:

Давайте посмотрим на клиентский код сервлета.

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

CalculatorService service = new CalculatorService();

Calculator addservice = service.getCalculatorPort();

int sum = addservice.add(1, 6);

response.setContentType("text/html");

PrintWriter out = response.getWriter();

out.println("<h1> SUM=" + sum + "</h1>");

System.out.println("result sum-" + sum);

}

Выход сервлета отображает все результаты операции добавления.

TestCalculatorWS выход сервлета

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

Загрузите полный код:

Источник

Веб-сервисы в теории и на практике для начинающих

Время на прочтение
9 мин

Количество просмотров 578K

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

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

Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).

Протоколы веб-сервисов

На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:

SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
REST (Representational State Transfer)
XML-RPC (XML Remote Procedure Call)

На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.

Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.

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

SOAP против REST

Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.

По мнению же автора, кратко можно выделить следующее:

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

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

Практическое применение веб-сервисов

Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.

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

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

Этап первый — реализация приложения сбора информации о курсах валют.

Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.

Создадим структуру данных.

Таблица валют (currency):

+-------------+------------------+
| Field       | Type             |
+-------------+------------------+
| code        | int(10) unsigned |
| charcode    | char(3)          |
| description | varchar(100)     |
| value       | int(10) unsigned |
| base        | tinyint(1)       |
+-------------+------------------+

Таблица номиналов обмена (exchange):

+------------+------------------+
| Field      | Type             |
+------------+------------------+
| id         | bigint(20) ai    |
| rate_date  | timestamp        |
| rate_value | float            |
| code       | int(10) unsigned |
+------------+------------------+

Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:

класс Grubber (models/Grabber.php):

<?php
/*
 * @package Currency_Service
 */
class Grabber {

    /**
     * Extracts data from outer web resource and returns it
     *
     * @param  void
     * @return array
     */
    public static function getData() {
        /**
         * Extracting data drom outer web-resource
         */
        $content = file_get_contents( 'http://www.bank.gov.ua/Fin_ryn/OF_KURS/Currency/FindByDate.aspx');
        if(preg_match_all( '/(d+)</td>([A-Z]+)</td>(d+)</td>(.+?)</td>(d+.d+)</td>/i', $content, $m) == false) {
            throw new Exception( 'Can not parse data!');
        }

        /**
         * Preformatting data to return;
         */
        $data = array();
        foreach ($m[1] as $k => $code) {
            $data[] = array(
                'code'        => $code,
                'charcode'    => $m[2][$k],
                'value'       => $m[3][$k],
                'description' => $m[4][$k],
                'rate_value'  => $m[5][$k]
            );
        }
        return $data;
    }

    public static function run() {
        $data = self::getData();

        /**
         * Sets default currency if not exists
         */
        if (!Doctrine::getTable( 'Currency')->find( 980)) {
            $currency = new Currency();
            $currency->setCode( 980)
                     ->setCharcode( 'UAH')
                     ->setDescription( 'українська гривня')
                     ->setValue( 1)
                     ->setBase( 1)
                     ->save();
        }

        foreach ($data as $currencyData) {
            /**
             * Updating table of currencies with found values
             */
            if (!Doctrine::getTable( 'Currency')->find( $currencyData['code'])) {
                $currency = new Currency();
                $currency->setCode( $currencyData['code'])
                         ->setCharcode( $currencyData['charcode'])
                         ->setDescription( $currencyData['description'])
                         ->setValue( $currencyData['value'])
                         ->setBase( 0)
                         ->save();
            }

            /**
             * Updating exchange rates
             */
            $date = date( 'Y-m-d 00:00:00');
            $exchange = new Exchange();
            $exchange->setRateDate( $date)
                     ->setRateValue( $currencyData['rate_value'])
                     ->setCode( $currencyData['code'])
                     ->save();
        }

    }
}
?>

и сам граббер (grabber.php):

<?php
require_once('config.php');
Doctrine::loadModels('models');
Grabber::run();
?>

Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:

0 10 * * * /usr/bin/php /path/to/grabber.php

Все — у нас есть достаточно полезный сервис.

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

Реализация SOAP сервиса

Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.

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

WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.

На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.

класс CurrencyExchange (models/CurrencyExchange.php):

<?php
/**
 * Class providing web-service with all necessary methods
 * to provide information about currency exchange values
 *
 * @package Currency_Service
 */
class CurrencyExchange {

    /**
     * Retrievs exchange value for a given currency
     *
     * @param  integer $code - currency code
     * @param  string $data - currency exchange rate date
     * @return float - rate value
     */
    public function getExchange( $code, $date) {
        $currency = Doctrine::getTable( 'Currency')->find( $code);
        $exchange = $currency->getExchange( $date);
        return $exchange ? (float)$exchange->getRateValue() : null;
    }

    /**
     * Retrievs all available currencies
     *
     * @return array - list of all available currencies
     */
    public function getCurrencyList() {
        return Doctrine::getTable( 'Currency')->findAll()->toArray();
    }

}
?>

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

Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.

Теперь в Zend Studio входим в меню File->Export…, выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl

Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.

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

Реализация же самого сервера не предстваляет теперь никакой сложности:

файл index.php:

<?php
require_once('config.php');

Doctrine::loadModels('models');

$server = new SoapServer( 'http://mikhailstadnik.com/ctws/currency.wsdl');
$server->setClass( 'CurrencyExchange');
$server->handle();
?>

Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php

Код простейшего клиента может быть таким:

<?php
$client = new SoapClient( 'http://mikhailstadnik.com/ctws/currency.wsdl');
echo 'USD exchange: ' . $client->getExchange( 840, date( 'Y-m-d'));
?>

Реализация REST сервиса

REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.

И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.

Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.

Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:

rest.php:

<?php
require_once 'config.php';
require_once 'Zend/Rest/Server.php';

Doctrine::loadModels('models');

$server = new Zend_Rest_Server();
$server->setClass( 'CurrencyExchange');
$server->handle();
?>

Как видите все очень сходно и просто.

Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).

Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:

?method=getExchange&code=840&date=2008-11-29

или

?method=getExchange&arg1=840&arg2=2008-11-29

При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.

Простейший тестовый клиент к REST сервису может быть в нашем случае таким:

<?php
$client = new Zend_Rest_Client( 'http://mikhailstadnik.com/ctws/rest.php');
$result = $client->getExchange( 840, date( 'Y-m-d'))->get();
if ($result->isSuccess()) {
    echo 'USD exchange: ' . $result->response;
}
?>

В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.

Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).

Заключение

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

Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.

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

Удачи в девелопменте!

Источник

What are Web Services?

Different books and different organizations provide different definitions to Web Services. Some of them are listed here.

A web service is any piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service. For example, a client invokes a web service by sending an XML message, then waits for a corresponding XML response. As all communication is in XML, web services are not tied to any one operating system or programming language—Java can talk with Perl; Windows applications can talk with Unix applications.
Web services are self-contained, modular, distributed, dynamic applications that can be described, published, located, or invoked over the network to create products, processes, and supply chains. These applications can be local, distributed, or web-based. Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.
Web services are XML-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents.
A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards.

To summarize, a complete web service is, therefore, any service that −

Is available over the Internet or private (intranet) networks
Uses a standardized XML messaging system
Is not tied to any one operating system or programming language
Is self-describing via a common XML grammar
Is discoverable via a simple find mechanism

Components of Web Services

The basic web services platform is XML + HTTP. All the standard web services work using the following components −

SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

All these components have been discussed in the Web Services Architecture chapter.

How Does a Web Service Work?

A web service enables communication among various applications by using open standards such as HTML, XML, WSDL, and SOAP. A web service takes the help of −

XML to tag the data
SOAP to transfer a message
WSDL to describe the availability of service.

You can build a Java-based web service on Solaris that is accessible from your Visual Basic program that runs on Windows.

You can also use C# to build new web services on Windows that can be invoked from your web application that is based on JavaServer Pages (JSP) and runs on Linux.

Example

Consider a simple account-management and order processing system. The accounting personnel use a client application built with Visual Basic or JSP to create new accounts and enter new customer orders.

The processing logic for this system is written in Java and resides on a Solaris machine, which also interacts with a database to store information.

The steps to perform this operation are as follows −

The client program bundles the account registration information into a SOAP message.
This SOAP message is sent to the web service as the body of an HTTP POST request.
The web service unpacks the SOAP request and converts it into a command that the application can understand.
The application processes the information as required and responds with a new unique account number for that customer.
Next, the web service packages the response into another SOAP message, which it sends back to the client program in response to its HTTP request.
The client program unpacks the SOAP message to obtain the results of the account registration process.

Why Web Services?

Here are the benefits of using Web Services −

Exposing the Existing Function on the network

A web service is a unit of managed code that can be remotely invoked using HTTP. That is, it can be activated using HTTP requests. Web services allow you to expose the functionality of your existing code over the network. Once it is exposed on the network, other applications can use the functionality of your program.

Interoperability

Web services allow various applications to talk to each other and share data and services among themselves. Other applications can also use the web services. For example, a VB or .NET application can talk to Java web services and vice versa. Web services are used to make the application platform and technology independent.

Standardized Protocol

Web services use standardized industry standard protocol for the communication. All the four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack. This standardization of protocol stack gives the business many advantages such as a wide range of choices, reduction in the cost due to competition, and increase in the quality.

Low Cost Communication

Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services. This solution is much less costly compared to proprietary solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented on other reliable transport mechanisms like FTP.

Web Services — Characteristics

Web services have the following special behavioral characteristics −

XML-Based

Web services use XML at data representation and data transportation layers. Using XML eliminates any networking, operating system, or platform binding. Web services based applications are highly interoperable at their core level.

Loosely Coupled

A consumer of a web service is not tied to that web service directly. The web service interface can change over time without compromising the client’s ability to interact with the service. A tightly coupled system implies that the client and server logic are closely tied to one another, implying that if one interface changes, the other must be updated. Adopting a loosely coupled architecture tends to make software systems more manageable and allows simpler integration between different systems.

Coarse-Grained

Object-oriented technologies such as Java expose their services through individual methods. An individual method is too fine an operation to provide any useful capability at a corporate level. Building a Java program from scratch requires the creation of several fine-grained methods that are then composed into a coarse-grained service that is consumed by either a client or another service.

Businesses and the interfaces that they expose should be coarse-grained. Web services technology provides a natural way of defining coarse-grained services that access the right amount of business logic.

Ability to be Synchronous or Asynchronous

Synchronicity refers to the binding of the client to the execution of the service. In synchronous invocations, the client blocks and waits for the service to complete its operation before continuing. Asynchronous operations allow a client to invoke a service and then execute other functions.

Asynchronous clients retrieve their result at a later point in time, while synchronous clients receive their result when the service has completed. Asynchronous capability is a key factor in enabling loosely coupled systems.

Supports Remote Procedure Calls(RPCs)

Web services allow clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol. Remote procedures expose input and output parameters that a web service must support.

Component development through Enterprise JavaBeans (EJBs) and .NET Components has increasingly become a part of architectures and enterprise deployments over the past couple of years. Both technologies are distributed and accessible through a variety of RPC mechanisms.

A web service supports RPC by providing services of its own, equivalent to those of a traditional component, or by translating incoming invocations into an invocation of an EJB or a .NET component.

Supports Document Exchange

One of the key advantages of XML is its generic way of representing not only data, but also complex documents. These documents can be as simple as representing a current address, or they can be as complex as representing an entire book or Request for Quotation (RFQ). Web services support the transparent exchange of documents to facilitate business integration.

Web Services — Architecture

There are two ways to view the web service architecture −

The first is to examine the individual roles of each web service actor.
The second is to examine the emerging web service protocol stack.

Web Service Roles

There are three major roles within the web service architecture −

Service Provider

This is the provider of the web service. The service provider implements the service and makes it available on the Internet.

Service Requestor

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

Service Registry

This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearing house for companies and their services.

Web Service Protocol Stack

A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving, but currently has four main layers.

Service Transport

This layer is responsible for transporting messages between applications. Currently, this layer includes Hyper Text Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and newer protocols such as Blocks Extensible Exchange Protocol (BEEP).

XML Messaging

This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this layer includes XML-RPC and SOAP.

Service Description

This layer is responsible for describing the public interface to a specific web service. Currently, service description is handled via the Web Service Description Language (WSDL).

Service Discovery

This layer is responsible for centralizing services into a common registry and providing easy publish/find functionality. Currently, service discovery is handled via Universal Description, Discovery, and Integration (UDDI).

As web services evolve, additional layers may be added and additional technologies may be added to each layer.

The next chapter explains the components of web services.

Few Words about Service Transport

The bottom of the web service protocol stack is service transport. This layer is responsible for actually transporting XML messages between two computers.

Hyper Text Transfer Protocol (HTTP)

Currently, HTTP is the most popular option for service transport. HTTP is simple, stable, and widely deployed. Furthermore, most firewalls allow HTTP traffic. This allows XMLRPC or SOAP messages to masquerade as HTTP messages. This is good if you want to integrate remote applications, but it does raise a number of security concerns.ise a number of security concerns.

Blocks Extensible Exchange Protocol (BEEP)

This is a promising alternative to HTTP. BEEP is a new Internet Engineering Task Force (IETF) framework for building new protocols. BEEP is layered directly on TCP and includes a number of built-in features, including an initial handshake protocol, authentication, security, and error handling. Using BEEP, one can create new protocols for a variety of applications, including instant messaging, file transfer, content syndication, and network management.

SOAP is not tied to any specific transport protocol. In fact, you can use SOAP via HTTP, SMTP, or FTP. One promising idea is therefore to use SOAP over BEEP.

Web Services — Components

Over the past few years, three primary technologies have emerged as worldwide standards that make up the core of today’s web services technology. These technologies are discussed below.

XML-RPC

This is the simplest XML-based protocol for exchanging information between computers.

XML-RPC is a simple protocol that uses XML messages to perform RPCs.
Requests are encoded in XML and sent via HTTP POST.
XML responses are embedded in the body of the HTTP response.
XML-RPC is platform-independent.
XML-RPC allows diverse applications to communicate.
A Java client can speak XML-RPC to a Perl server.
XML-RPC is the easiest way to get started with web services.

To learn more about XML-RPC, visit our XML-RPC Tutorial.

SOAP

SOAP is an XML-based protocol for exchanging information between computers.

SOAP is a communication protocol.
SOAP is for communication between applications.
SOAP is a format for sending messages.
SOAP is designed to communicate via Internet.
SOAP is platform independent.
SOAP is language independent.
SOAP is simple and extensible.
SOAP allows you to get around firewalls.
SOAP will be developed as a W3C standard.

To learn more about SOAP, visit our SOAP Tutorial.

WSDL

WSDL is an XML-based language for describing web services and how to access them.

WSDL stands for Web Services Description Language.
WSDL was developed jointly by Microsoft and IBM.
WSDL is an XML based protocol for information exchange in decentralized and distributed environments.
WSDL is the standard format for describing a web service.
WSDL definition describes how to access a web service and what operations it will perform.
WSDL is a language for describing how to interface with XML-based services.
WSDL is an integral part of UDDI, an XML-based worldwide business registry.
WSDL is the language that UDDI uses.
WSDL is pronounced as ‘wiz-dull’ and spelled out as ‘W-S-D-L’.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

UDDI stands for Universal Description, Discovery, and Integration.
UDDI is a specification for a distributed registry of web services.
UDDI is platform independent, open framework.
UDDI can communicate via SOAP, CORBA, and Java RMI Protocol.
UDDI uses WSDL to describe interfaces to web services.
UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
UDDI is an open industry initiative enabling businesses to discover each other and define how they interact over the Internet.

To learn more about UDDI, visit our UDDI Tutorial.

Web Services — Examples

Based on the web service architecture, we create the following two components as a part of web services implementation −

Service Provider or Publisher

This is the provider of the web service. The service provider implements the service and makes it available on the Internet or intranet.

We will write and publish a simple web service using .NET SDK.

Service Requestor or Consumer

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

We will also write two web service requestors: one web-based consumer (ASP.NET application) and another Windows application-based consumer.

Given below is our first web service example which works as a service provider and exposes two methods (add and SayHello) as the web services to be used by applications. This is a standard template for a web service. .NET web services use the .asmx extension. Note that a method exposed as a web service has the WebMethod attribute. Save this file as FirstService.asmx in the IIS virtual directory (as explained in configuring IIS; for example, c:MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

To test a web service, it must be published. A web service can be published either on an intranet or the Internet. We will publish this web service on IIS running on a local machine. Let us start with configuring the IIS.

Open Start → Settings → Control Panel → Administrative tools → Internet Services Manager.
Expand and right-click on the default web site; select New &#rarr; Virtual Directory. The Virtual Directory Creation Wizard opens. Click Next.
The «Virtual Directory Alias» screen opens. Type the virtual directory name. For example, MyWebServices. Click Next.
The «Web Site Content Directory» screen opens.
Enter the directory path name for the virtual directory. For example, c:MyWebServices. Click Next.
The «Access Permission» screen opens. Change the settings as per your requirements. Let us keep the default settings for this exercise.
Click the Next button. It completes the IIS configuration.
Click Finish to complete the configuration.

To test whether the IIS has been configured properly, copy an HTML file (For example, x.html) in the virtual directory (C:MyWebServices) created above. Now, open Internet Explorer and type http://localhost/MyWebServices/x.html. It should open the x.html file.

Note − If it does not work, try replacing the localhost with the IP address of your machine. If it still does not work, check whether IIS is running; you may need to reconfigure the IIS and the Virtual Directory.

To test this web service, copy FirstService.asmx in the IIS virtual directory created above (C:MyWebServices). Open the web service in Internet Explorer (http://localhost/MyWebServices/FirstService.asmx). It should open your web service page. The page should have links to two methods exposed as web services by our application. Congratulations! You have written your first web service!

Testing the Web Service

As we have just seen, writing web services is easy in the .NET Framework. Writing web service consumers is also easy in the .NET framework; however, it is a bit more involved. As said earlier, we will write two types of service consumers, one web-based and another Windows application-based consumer. Let us write our first web service consumer.

Web-Based Service Consumer

Write a web-based consumer as given below. Call it WebApp.aspx. Note that it is an ASP.NET application. Save this in the virtual directory of the web service (c:MyWebServicesWebApp.axpx).

This application has two text fields that are used to get numbers from the user to be added. It has one button, Execute, that when clicked gets the Add and SayHello web services.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

After the consumer is created, we need to create a proxy for the web service to be consumed. This work is done automatically by Visual Studio .NET for us when referencing a web service that has been added. Here are the steps to be followed −

Create a proxy for the Web Service to be consumed. The proxy is created using the WSDL utility supplied with the .NET SDK. This utility extracts information from the Web Service and creates a proxy. The proxy is valid only for a particular Web Service. If you need to consume other Web Services, you need to create a proxy for this service as well. Visual Studio .NET creates a proxy automatically for you when the Web Service reference is added. Create a proxy for the Web Service using the WSDL utility supplied with the .NET SDK. It will create FirstSevice.cs file in the current directory. We need to compile it to create FirstService.dll (proxy) for the Web Service.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

Put the compiled proxy in the bin directory of the virtual directory of the Web Service (c:MyWebServicesbin). Internet Information Services (IIS) looks for the proxy in this directory.
Create the service consumer, in the same way we already did. Note that an object of the Web Service proxy is instantiated in the consumer. This proxy takes care of interacting with the service.
Type the URL of the consumer in IE to test it (for example, http://localhost/MyWebServices/WebApp.aspx).

Windows Application-Based Web Service Consumer

Writing a Windows application-based web service consumer is the same as writing any other Windows application. You only need to create the proxy (which we have already done) and reference this proxy when compiling the application. Following is our Windows application that uses the web service. This application creates a web service object (of course, proxy) and calls the SayHello, and Add methods on it.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compile it using c:>csc /r:FirstService.dll WinApp.cs. It will create WinApp.exe. Run it to test the application and the web service.

Now, the question arises: How can you be sure that this application is actually calling the web service?

It is simple to test. Stop your web server so that the web service cannot be contacted. Now, run the WinApp application. It will fire a runtime exception. Now, start the web server again. It should work.

Web Services — Security

Security is critical to web services. However, neither XML-RPC nor SOAP specifications make any explicit security or authentication requirements.

There are three specific security issues with web services −

Confidentiality
Authentication
Network Security

Confidentiality

If a client sends an XML request to a server, can we ensure that the communication remains confidential?

Answer lies here −

XML-RPC and SOAP run primarily on top of HTTP.
HTTP has support for Secure Sockets Layer (SSL).
Communication can be encrypted via SSL.
SSL is a proven technology and widely deployed.

A single web service may consist of a chain of applications. For example, one large service might tie together the services of three other applications. In this case, SSL is not adequate; the messages need to be encrypted at each node along the service path, and each node represents a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue, but one promising solution is the W3C XML Encryption Standard. This standard provides a framework for encrypting and decrypting entire XML documents or just portions of an XML document. You can check it at www.w3.org/Encryption

Authentication

If a client connects to a web service, how do we identify the user? Is the user authorized to use the service?

The following options can be considered but there is no clear consensus on a strong authentication scheme.

HTTP includes built-in support for Basic and Digest authentication, and services can therefore be protected in much the same manner as HTML documents are currently protected.
SOAP Digital Signature (SOAP-DSIG) leverages public key cryptography to digitally sign SOAP messages. It enables the client or server to validate the identity of the other party. Check it at www.w3.org/TR/SOAP-dsig.
The Organization for the Advancement of Structured Information Standards (OASIS) is working on the Security Assertion Markup Language (SAML).

Network Security

There is currently no easy answer to this problem, and it has been the subject of much debate. For now, if you are truly intent on filtering out SOAP or XML-RPC messages, one possibility is to filter out all HTTP POST requests that set their content type to text/xml.

Another alternative is to filter the SOAPAction HTTP header attribute. Firewall vendors are also currently developing tools explicitly designed to filter web service traffic.

Web Services — Standards

This chapter gives you an idea of all the latest standards related to web services.

Transports

BEEP, the Blocks Extensible Exchange Protocol (formerly referred to as BXXP), is a framework for building application protocols. It has been standardized by IETF and it does for Internet protocols what XML has done for data.

Blocks Extensible Exchange Protocol (BEEP)

Messaging

These messaging standards and specifications are intended to give a framework for exchanging information in a decentralized, distributed environment.

SOAP 1.1 (Note)
SOAP 1.2 (Specification)
Web Services Attachments Profile 1.0
SOAP Message Transmission Optimization Mechanism

Description and Discovery

Web services are meaningful only if potential users may find information sufficient to permit their execution. The focus of these specifications and standards is the definition of a set of services supporting the description and discovery of businesses, organizations, and other web services providers; the web services they make available; and the technical interfaces which may be used to access those services.

UDDI 3.0
WSDL 1.1 (Note)
WSDL 1.2 (Working draft)
WSDL 2.0 (Working Group)

Security

Using these security specifications, applications can engage in secure communication designed to work with the general web services framework.

Web Services Security 1.0
Security Assertion Markup Language (SAML)

Management

Web services manageability is defined as a set of capabilities for discovering the existence, availability, health, performance, usage, as well as the control and configuration of a web service within the web services architecture. As web services become pervasive and critical to business operations, the task of managing and implementing them is imperative to the success of business operations.

Web Services Distributed Management

Web Services — Summary

In this tutorial, you have learnt how to use web services. However, a web service also include components such as WSDL, UDDI, and SOAP that contribute to make it active. The next step is to learn WSDL, UDDI, and SOAP.

WSDL

WSDL is an XML-based language for describing web services and how to access them.

WSDL describes a web service, along with the message format and protocol details for the web service.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

To learn more about UDDI, visit our UDDI Tutorial.

SOAP

SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.

To learn more about SOAP, visit our SOAP Tutorial.

Источник

Written on 20 Августа 2012. Posted in Java

Скачать руководство по веб-сервису jboss — 11.58 KB

Введение

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

Назначение данной статьи – дать обстоятельное руководство по следующим темам:

Программное обеспечение, требуемое для этой статьи.
Как создать простой веб-сервис для сервера приложений JBoss?
Как развернуть и свернуть веб-сервис в сервере приложений JBoss?
Как разработать простое тестовое приложение для тестирования работающего веб-сервиса?

Установка и настройка необходимого программного обеспечения

Данное руководство требует установку и настройку следующих пакетов программ:

JDK 1.5 (или выше).
Apache Ant (текущая версия 1.7.1).
JBoss App Server (текущая версия 5.0.0 GA).
JBossWS (текущая версия 3.0.5 GA).

Также рекомендуется использовать Eclipse IDE (интегрированная среда разработки). Но для этого руководства всю работу можно сделать при помощи простого редактора кода (например, UltraEdit32, Crimson Editor или Notepad++), командной строки и Apache Ant.

Для удобства данное руководство было создано в Windows XP. Однако оно относительно легко перемещается на другие платформы.

Установка JDK и Apache Ant

Установить JDK в Windows XP очень легко, достаточно загрузить установщик MSI, затем установить его по умолчанию в «Program Files» или прямо в «C:». После установки JDK рекомендуется настроить системные переменные:

Создайте системную среду «JAVA_HOME» и укажите в ней базовый каталог JDK (т.е. C:Program FilesJavajdk-1.5.0_17 или C:jdk-1.5.0_17).
Также добавьте «%JAVA_HOME%bin» в системную переменную «PATH (путь)».

После настройки системной переменной откройте командную строку и наберите «java –version (версия java)». Вывод покажет версию JDK, установленную в системе. Это позволит проверить успешность установки JDK. После проверки закройте командную строку.

Установить Apache Ant также просто: загрузите исполняемый двоичный файл-архив с вебстраницы проекта Apache Ant (здесь). Затем распакуйте файл-архив в «C:». Это распакует файл-архив в «C:apache-ant-1.7.1». «C:apache-ant-1.7.1» будет базовым каталогом Apache Ant. После распаковки настройте системные переменные следующим образом:

Создайте системную среду «ANT_HOME» и укажите в ней базовый каталог Apache Ant (т.е. C:apache-ant-1.7.1).
Также добавьте «%ANT_HOME%bin» в системную переменную «PATH».

После настройки системной переменной выполните проверку, открыв командную строку и введя «ant –version». Если настройка выполнена правильно, вывод покажет версию Apache Ant, установленную в системе.

Установка JBoss и JBossWS

Это руководство учит, как создать веб-сервис, работающий в JBoss. Поэтому обязательно нужно установить и настроить сервер приложений JBoss (текущая версия 5.0.0.GA) и веб-сервисы JBoss (также называются JBossWS, текущая версия 3.0.5.GA). Установочные пакеты (zip архивы) можно найти в следующих местах:

Скачать сервер приложений JBoss. На настоящей странице загрузки есть два файла-архива, тот, который работает с JDK 1.5, называется jboss-5.0.0.GA.zip. Другой (jboss-5.0.0.GA-jdk6.zip) работает с JDK 1.6.
Скачать веб-сервисы JBoss

Процесс установки JBoss аналогичен установке Apache Ant. Вам лишь нужно распаковать файл-архив, содержащий исполняемые двоичные файлы сервера приложений JBoss в «C:». Это создаст новый каталог под названием «C:jboss-5.0.0.GA», являющийся базовым каталогом сервера приложений JBoss. После распаковки создайте системную среду «JBOSS_HOME» и укажите в ней «C:jboss-5.0.0.GA». Хотя это необязательно, также можно добавить «%JBOSS_HOME%bin» в системную переменную «PATH».

Последний шаг – установка пакета JBossWS. Выполните следующие шаги:

Сначала распакуйте исполняемый двоичный архив JBossWS в «C:». Это создаст папку «C:jbossws-native-bin-dist».
Через проводник Windows зайдите в «C:jbossws-native-bin-dist». Внутри папки найдите файл «ant.properties.example».
Создайте копию «ant.properties.example», затем переименуйте ее в «ant.properties».
Запустите ваш любимый редактор кода (например, UltraEdit32 или Notepad++), затем откройте файл «ant.properties» для редактирования.
Найдите строку «jboss500.home=@jboss500.home@», замените ее на «jboss500.home=/jboss-5.0.0.GA». Затем сохраните файл и закройте редактор кода.
Откройте командную строку, перейдите в «C:jbossws-native-bin-dist». Затем исполните команду «ant deploy-jboss500». Когда она успешно завершится, JBossWS будет установлен и правильно настроен для использования.

Создание простого веб-сервиса

Теперь все готово для создания простого веб-сервиса. Есть два способа создания веб-сервисов:

Нисходящий. JBossWS используется для создания классов-посредников из существующих файлов WSDL и связанных с ним файлов XSD. Затем реализуется интерфейс порта веб-сервиса.
Восходящий. Создается простой веб-сервис с помощью POJO. Затем классы упаковываются для развертывания.

В этом руководстве рассматривается восходящий подход, так как это простейший способ создания веб-сервиса. Исходный код можно найти в разделе загрузок. Шаги будут изложены в следующих подразделах.

Создание простого проекта Java

Данное руководство использует Eclipse IDE и Apache Ant для создания проекта-примера. Создание этого проекта-примера не отличается от создания простого проекта Java HelloWorld («привет мир»). Получив исходный код примера, вы сможете увидеть, что в базовом каталоге «webservice», есть две папки:

«bin»: Эта папка используется для хранения скомпонованных выходных файлов.
«src»: Эта папка содержит исходники. Файл исходного кода «Greeting.java» находится в подпапке tutorial/hanbo/webservice.

В базовом каталоге находится несколько текстовых файлов:

.classpath: Этот файл автоматически создан Eclipse.
.project: Этот файл автоматически создан Eclipse.
build.xml: Это файл компоновки Apache Ant.

Сначала посмотрим на файл исходного кода «Greeting.java». Весь исходный код выглядит так:

package tutorial.hanbo.webservice;  import javax.jws.WebService;
 import javax.jws.WebMethod;
  @WebService
 public class Greeting
 {
    @WebMethod
    public String greetClient(String userName)
    {
       return "Приветствие " + userName + "! Приятного дня!...";
    }
 }

Это весь код Java, который нужно написать для создания простого веб-сервиса. Давайте подробно рассмотрим исходник:
1.    Первая строка объявляет пакет веб-сервиса.
2.    Две следующие строки кода импортируют требуемые классы. Они являются аннотациями, используемыми объявлением класса и объявлением метода.
3.    Объявите класс под названием «Приветствие»; он снабжен комментарием «веб-сервис», что означает, что класс «Приветствие» – это веб-сервис.
4.    Внутри класса «Приветствие» объявите открытый метод с названием «greetClient()». Он снабжен комментарием «веб-метод», что означает, что этот метод – сетевой метод, который может быть вызван дистанционно.

Метод «greetClient()» принимает параметр строкового типа под названием «username (имя пользователя)». Его тело создаст новый объект “строка/и”? и выполнит возврат.

Если ссылочные библиотеки не добавлены в этот проект, он не будет компилироваться в Eclipse. Поэтому посмотрите файл .classpath и найдите все нужные ссылочные библиотеки (т.е. файлы jar со ссылками). Эти библиотеки были частью пакета JBoss. Их можно найти в 3 разных папках:

•    C:jboss-5.0.0.GAclient
 •    C:jboss-5.0.0.GAlib
 •    C:jboss-5.0.0.GAlibendorsed

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

•    C:jboss-5.0.0.GAclientjaxws-rt.jar
 •    C:jboss-5.0.0.GAclientjaxws-tools.jar

Их нужно удалить из проекта, чтобы избавиться от исключения. Это может быть странная ошибка в JBossWS. Когда я впервые работал над этим примером, столкнулся с исключением в то время, когда пытался развернуть готовый веб-сервис на сервере приложений JBoss. После перебора результатов поиска Google я нашел решение, согласно которому нужно удалить указанные два файла jar из пути классов проекта.

Дескриптор развертывания

Веб-сервис нужно развернуть, чтобы клиенты смогли иметь к нему доступ. В данном руководстве веб-сервис будет упакован как файл war и развернут как сервлет. Файл war содержит дескриптор развертывания, файл с именем «web.xml» задает преобразование URL.сервлет. Когда отправляется запрос к серверу приложений JBoss, JBoss направляет запрос к конкретному сервлету на основании преобразования URL/Servlet, заданного в файлах web.xml.
В базовом каталоге проекта вы найдете файл web.xml в подкаталоге src/resources (ресурсы). Содержимое этого файла выглядит так:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE web-app
  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
  "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">  <web-app>
   <servlet>
     <servlet-name>GreetingWebService</servlet-name>
     <servlet-class>tutorial.hanbo.webservice.Greeting</servlet-class>
   </servlet>
    <servlet-mapping>
     <servlet-name>GreetingWebService</servlet-name>
     <url-pattern>/*</url-pattern>
   </servlet-mapping>
 </web-app>

Содержимое данного файла дескриптора понять легко. Все содержимое поделено на две части:
• Первая часть (от <servlet> до </servlet>) указывает, чем является сервлет. Он имеет имя «GreetingWebService» и преобразуется в класс Java «tutorial.hanbo.webservice.Greeting».
• Вторая часть (от <servlet-mapping> до </servlet-mapping>) задает URL для преобразования сервлета. Если запрошенный URL указывает на веб-сервис, то запрос будет обработан веб-сервисом.

Следующий раздел описывает, как упаковать файл war.

Упаковка с помощью Apache Ant

Упаковка файла war может быть выполнена с помощью Apache Ant. В build.xml вы найдете несколько целей. Они используются для выполнения действий компоновки. Одна из целей называется «упаковка». Эта цель используется для создания файла war для развертывания, как показано ниже:

<target name="packaging" >
  <war destfile="bin/greeting.war" webxml="src/resources/web.xml">
    <classes dir="bin/classes"/>
  </war>
</target>

В этом разделе целей есть только одно действие для выполнения – компоновка файла war с использованием задачи с именем «war».

Эта задача принимает три параметра:
•    destfile: это первый атрибут тега XML «war», используемый для указания, какое имя имеет файл war и в какую папку он будет помещен.
•    webxml: это второй атрибут тега XML «war», используемый для указания, где находится файл web.xml, который будет упакован как часть файла war.
•    classes (классы): это субтег XML под тегом XML «war», используемый для указания файлов классов, которые будут включены в файл war.

Для запуска этой цели нужно использовать следующую команду в командной строке:

> ant packaging

Вывод команды выглядит так:

Buildfile: build.xml packaging:
[war] Building war: %project_base_directry%bingreeting.war

BUILD SUCCESSFUL
Total time: 1 second

В каталоге bin внутри базового каталога проекта находится только что созданный файл war. Используя инструмент сжатия/распаковки zip архива, такой как 7-zip, можно открыть данный файл-архив и изучить его внутреннюю структуру. Внутри есть два каталога, один называется «META-INF», который содержит файл «MANIFEST.MF»; другой называется WEB-INF, внутри него есть подкаталог с названием «classes» и файл с именем «web.xml». Greeting.class находится внутри подкаталога «tutorial/hanbo/webservices» в «classes».

Так как файл war был успешно скомпонован, пришло время его развернуть.

Развертывание и свертывание

Перед тем как пытаться развернуть файл war примера в сервере приложений JBoss, сначала нужно запустить сервер приложений JBoss. Так как JBoss используется только как средство тестирования простого веб-сервиса, в руководстве не рассматривается, как запустить JBoss в качестве сервиса. Вместо этого мы откроем еще одну командную строку, потом запустим сервер приложений JBoss в только что открытой командной строке.

Чтобы запустить сервер приложений JBoss, используйте только что открытую командную строку, чтобы перейти в «C:jboss-5.0.0.GAbin», затем запустите скрипт «run.bat». После того как сервер приложений JBoss запустится, придется подождать в течение некоторого времени, пока командная строка не покажет следующий вывод:

15:34:41,889 INFO  [ServerImpl] JBoss (Microcontainer)
[5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812041714)] Started in 5m:3s:150ms

Вышеуказанный вывод означает, что сервер приложений JBoss был успешно запущен.

Чтобы выключить сервер приложений JBoss, запустите командную строку, выполняющую сервер приложений JBoss. Нажмите Ctrl+C, чтобы остановить выполнение, затем закройте командную строку.

Чтобы развернуть файл war, скопируйте файл war (greeting.war), затем вставьте его в «C:jboss-5.0.0.GAserverdefaultdeploy». После выполнения этих действий вы заметите, что командная строка, в которой выполняется сервер приложений JBoss, выведет прогресс развертывания в следующем виде:

15:35:21,422 INFO  [DefaultEndpointRegistry] register: jboss.ws:context=greeting,endpoint=GreetingWebService
15:35:22,453 INFO  [TomcatDeployment] deploy, ctxPath=/greeting, vfsUrl=greeting.war
15:35:28,172 INFO  [WSDLFilePublisher] WSDL published to:
file:/C:/jboss-5.0.0.GA/server/default/data/wsdl/greeting.war/GreetingService4604908665079984702.wsdl

Вышеуказанный вывод показывает, что процесс развертывания прошел успешно.

Следующий шаг – протестировать развертывание. Откройте окно браузера, перейдите по адресу «http://localhost:8080/jbossws/services». После того как страница загрузится, вы сможете увидеть раздел «Конечные точки зарегистрированного сервиса», перечисляющий подробную информацию о развертывании веб-сервиса «GreetingWebService». Можно провести еще один тест – просмотреть файл WSDL, созданный динамически JBossWS. Для данного руководства ссылка на созданный WSDL — «http://127.0.0.1:8080/greeting?wsdl». Его можно просмотреть в том же самом окне браузера.

Свернуть веб-сервис можно путем удаления файла war (greeting.war) в «C:jboss-5.0.0.GAserverdefaultdeploy». Как только вы сделаете это, командная строка покажет прогресс сворачивания:

16:51:12,229 INFO  [TomcatDeployment] undeploy, ctxPath=/greeting, vfsUrl=greeting.war
16:51:13,307 INFO  [DefaultEndpointRegistry] remove: jboss.ws:context=greeting,endpoint=GreetingWebService

Вышеуказанный вывод показывает, что процесс сворачивания прошел успешно.

В build.xml указаны две цели для развертывания или сворачивания веб-сервиса. Они используют задачи копирования файла и удаления файла Apache Ant для выполнения операций развертывания и сворачивания. Чтобы развернуть веб-сервис, используйте цель «развернуть». Чтобы свернуть веб-сервис, используйте цель «свернуть».

Тестирование веб-сервиса при помощи клиента веб-сервиса

Если вы не протестируете только что созданный веб-сервис, вы не узнаете, работает он или нет. Так как в этом руководстве, веб-сервис крайне простой, предоставляющий только один веб-метод, принимающий строку в качестве параметра, его можно протестировать посредством динамического вызова. Динамический вызов, как многие отмечают, является «плохим способом создания клиента веб-сервиса». Большинство веб-сервисов в реальных условиях работы используют сложные объекты данных и выполняют сложные операции. Использование динамического вызова, чтобы создавать код для тестирования столь сложных веб-сервисов, может быть крайне трудным. Лучше создавать клиенты веб-сервисов путем использования классов-посредников, созданных JBossWS из файлов WSDL и связанных с ними файлов XSD.

Клиент веб-сервиса – консольное приложение, написанное на Java. Это тестовое приложение выделено в другой проект с названием «webservice-test». Этот проект использует тот же набор jar со ссылками, что и проект веб-сервиса. build.xml предусмотрен не только для компоновки проекта в командной строке, но и для запуска тестового приложения. Чтобы скомпоновать проект, используйте команду «ant compile». После компоновки проекта, чтобы протестировать приложение, используйте команду «ant run-test-app». Но перед запуском этого тестового приложения обязательно сначала разверните веб-сервис.

Посмотрим на исходный код тестового приложения. В исходном коде есть два следующих основных раздела:
• Инструкции импорта, используемые для импорта нескольких классов, используемых клиентом веб-сервиса.
• Главный метод, содержащий поток выполнения программы.
Инструкции импорта выглядят так:

import javax.xml.rpc.Call;
import javax.xml.rpc.Service;
import javax.xml.rpc.ServiceFactory;
import javax.xml.rpc.ParameterMode;
import javax.xml.namespace.QName;

Как показывает вышеуказанный код, импортируются только требуемые классы. Класс ServiceFactory используется для создания объекта Service. Объект Service может создать объект call (вызов). Используя объект Call, можно выполнить дистанционный вызов веб-метода, предоставляемого веб-сервисом. Так как веб-метод принимает входной параметр, потребуется ParameterMode, чтобы указать, как будет использоваться параметр. Так как созданный WSDL тоже использует пространства имен, нужны объекты QName, указывающие классифицированные имена.

Следующий код вызывает веб-сервис:

public static void main(String[] argv)
{
   try
   {
      String NS_XSD
         = "http://www.w3.org/2001/XMLSchema";
      ServiceFactory factory
         = ServiceFactory.newInstance();
      Service service = factory.createService(
         new QName(
            "http://webservice.hanbo.tutorial/",
            "GreetingService"
         )
      );      Call call = service.createCall(new QName(
         "http://webservice.hanbo.tutorial/",
         "GreetingPort"
      ));
      call.setTargetEndpointAddress(
         "http://localhost:8080/greeting?wsdl"
      );
      call.setOperationName(
         new QName(
            "http://webservice.hanbo.tutorial/",
            "greetClient"
         )
      );
      QName QNAME_TYPE_STRING = 
         new QName(NS_XSD, "string");
      call.setReturnType(QNAME_TYPE_STRING);
      call.addParameter(
         "arg0", QNAME_TYPE_STRING, 
         ParameterMode.IN
      );
      String[] params = { "Murphy Brown" };
      String result = (String)call.invoke(params);
      System.out.println(result);
   }
   catch (Exception e)
   {
      e.printStackTrace();
   }
}

Этот кусок кода показывает, как работает динамический вызов. Как видно, он довольно сложный. Алгоритм следующий:
1. Сначала создается объект ServiceFactory.
2. Затем вызывается метод createService() объекта ServiceFactory, чтобы создать объект Service. В качестве параметра ему передается объект QName.

Объект QName указывает сервис с именем «GreetingService» с пространством имен «http://webservice.hanbo.tutorial/».

3. Используется метод createCall() только что созданного объекта Service, чтобы создать объект Call. Объект Call указывает порт веб-сервиса.
4. Для объекта Call нужно:

Задать адрес целевой конечной точки (setTargetEndPointAddress()). Это URL динамически созданного WSDL.
Задать имя операции (setOperationName()). Это имя веб-метода, который нужно вызвать.
Задать тип возвращаемого значения (setReturnType()). В этом случае возвращается стандартное строковое значение.
Добавить передаваемые параметры (addParameter()). В этом случае единственный передаваемый параметр – строковый параметр.

5. После установки объекта Call наконец можно вызвать веб-метод путем вызова метода invoke() объекта Call. Параметр, переданный в invoke(), — массив объектов, представляющий собой входной параметр, который будет использовать удаленный веб-метод. В нашем случае есть только один параметр-это строка «Мэрфи Браун».
Если все прошло правильно, приложение можно запустить через Eclipse или Apache Ant в командной строке. Если вы решите запустить его через Apache Ant – команда следующая:

> ant run-test-app

Если все пройдет успешно, вывод будет выглядеть так:

> ant run-test-app
Buildfile: build.xml

run-test-app:
[java] Greeting Murphy Brown! Have a nice day...

BUILD SUCCESSFUL
Total time: 8 seconds

Интересные моменты

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

Источник

Что такое веб-сервис?

Веб-служба, веб-сервис (англ. web service) — идентифицируемая уникальным веб-адресом (URL-адресом) программная система со стандартизированными интерфейсами, а также HTML-документ сайта, отображаемый браузером пользователя. (Материал из Википедии)

Иными словами Web-сервис (служба) – программа, которая организовывает взаимодействие между сайтами. Информация с одного портала передается на другой.

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

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

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

В этой статье покажем Вам, как создать простой веб-сервис на базе Simple Object Access Protocol (SOAP).

Что такое SOAP?

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам; вплоть до спецификации 1.2) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Перейдем от теории к практике.

Soap Server: SimpleServer.php

    

// Simple Method get 1 parameter and return with Hello
function AddHello($name)
{
     return "Hello $name";
}

// Create SoapServer object using WSDL file.
// For the simplicity, our SoapServer is set to operate in non-WSDL mode. So we do not need a WSDL file
$server = new SoapServer(null, array('uri'=>'http://localhost/hello'));

// Add AddHello() function to the SoapServer using addFunction().
$server->addFunction("AddHello");

// To process the request, call handle() method of SoapServer.
$server->handle();

Soap Client для общения с сервером: SimpleClient.php

    

include "nusoap.php"; //Soap Library.

try {
    // Create a soap client using SoapClient class
    // Set the first parameter as null, because we are operating in non-WSDL mode.
    // Pass array containing url and uri of the soap server as second parameter.
    $client = new soapclient(null, array(
            'location' => "http://localhost/hello/HelloServer.php",
            'uri' => "http://localhost/hello"));

            // Read request parameter
            $param = $_POST['name'];
            
            // Invoke AddHello() method of the soap server (HelloServer)
            $result = $client->AddHello($param);
            echo $result; // Process the the result
}
    catch(SoapFault $ex) {
    $ex->getMessage();
}

Soap View для взаимодействия с пользователем: SimpleView.php

    

echo "<h2>Welcome to PHP Web Service</h2>";
echo "<form action='SimpleClient.php' method='POST'/>";
echo "<input name='name' /><br/>";
echo "<input type='Submit' name='submit' value='Send'/>";
echo "</form>";

2.96
1
2
3
4
5

Голосов: 916 | Просмотров: 10395

Источник